Cessna 172 cockpit otthon

Építsünk szimulátort

NAV1 - COM1 adatok a szimulátorból

2019. szeptember 11. - C172Peti

LED kijelző koncepciója már megvan, következő lépésként a navigációs blokkhoz szükséges adatokat igyekszem kinyerni a szimulátorból.

Az FSUIPC doksija szerint (FSUIPC4 Offsets Status.pdf) a 034E címen található a COM1 frekvencia. Itt a frekvenciából 4 számjegyet tárol BCD formátumban, ami annyit tesz, hogy 2 byte helyet foglal.

Őszintén szólva itt egy picit szomorú lettem, mert ez annyit jelent, hogy 8.33 -as frekvenciákat ezek szerint az FSX nem képes tárolni. Tekintve, hogy 2018 év végétől már kötelező itthon is a 8.33-as rádió a gépekbe és gyakorlatilag az összes kisebb reptér frekvenciáját a 25kHz-esről 8.33-as elhatárolás szerinti frekikkel látták el ( pl. LHMC 132.200 -> 132.215 ), kezdünk távol kerülni az aktuális valóságtól. No de hátha a Flight Simulator 2020 majd ad erre megoldást :)

Hagyom ezt a 8.33 és 25kHz problémát, ha van rá érdeklődés szívesen összefoglalom egy külön bejegyzésben hogyan is működnek ezek és mik az alapvető különbségek.

Visszatérve a jelenlegi állapothoz: 4 számjegy van tárolva. Egész pontosan a 4 középső számjegy. 132.200 esetén ez 3220-at jelent. Belegondolva logikus döntés ez, a vezető '1' -est teljesen felesleges tárolni, az nem változhat, 25kHz bontás esetén pedig az utolsó sázmjegyet a legtöbb (ha nem minden) 25kHz-es rádió lespórolja. Ez amúgy szabványosan is elfogadott. Pl. a 132.225-ös frekvencia 25kHz-es elhatárolásnál, 132.22 -ként jelenik meg az 5 digites rádión. Nem magyarázom ezt tovább, viszont egyre jobban érik a gondolat bennem, hogy ezt külön részletezzem a 8.33-as felbontással együtt :)

com1_data.jpg

Nézzük inkább a lényeget, hogy lesz a BCD-ből megjeleníthető szám. A fenti képen legalul van az a két byte (binárisan), amit tárol a szimulátor. A feleadat egyszerű: 4 bit határoz meg egy számot, daraboljuk fel a 16 bit adatot 4 bitesekre és már meg is vagyunk. 

Mivel a számokat majd az arduino-ra akarom küldeni, ezért nekem célszerű egy byte tömböt generálni belőle, amivel már az arduinónak nem kell számolgatnia, csak "bután" megjeleníteni.

Ezt az alábbi kóddal oldottam meg a szerver oldalon:

public static byte[] BCDtoByteArray(byte bcd) {       

    byte[] retVal = new byte[2];

    retVal[0] = (byte) (bcd & 0xf0);       

    retVal[0] >>>= (byte) 4;

    retVal[0] = (byte) (retVal[0] & 0x0f);       

    retVal[1] = (byte) (bcd & 0x0f);

    return retVal;

}

 

Ez a kód annyit csinál, hogy a bemenetként kapott byte-ot ketté vágja és egy byte tömbben visszaadja a két értéket a BCD-nek megfelelően.

Ezt a byte-sorozatot már "csak" oda kell dobni az arduinónak, hogy megjelenítse. Megnéztem a standby és a navigációs frekvenciákat, mindegyik ugyanígy működik, csak más-más címről kell beolvasni őket az alábbiak szerint:

COM1 034E
COM1 STBY 311A
NAV1 0350
NAV1 STBY 311E
COM2 3118
COM2 STBY 311C
NAV2 0352
NAV2 STBY 3120

 

 

 

A bejegyzés trackback címe:

https://repszim.blog.hu/api/trackback/id/tr5915065658

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.