Unsere Receiver empfangen weltweit alle Frequenzen auf denen Flug-Positionsdaten gesendet werden. Mit Ausnahme von ACARS (die in dem Flugfrequenz-Bereich sendet) werden alle Positionsmeldungen im Hochfrequenz-Bereich nahe der Gigahertz gesendet. Da Grafikchips ideal für paralleles, sehr schnelles verarbeiten von binären Datenströmen sind, werden bei uns die Receiver-Rohdaten von der  <GPU> demoduliert, dekodiert und eventuelle CRC-Fehler korrigiert.
Bestandteil der Radarbox ist neben den Funk-Receivern unser GPS-Receiver mit folgender technischen Ausstattung:
 

Durch den 10Hz-Update und unserer GPU-Dekodierung lokalisieren wir 20% mehr ADS-B-Flieger als alle andere SDR-Receiver, wir sehen sie früher und länger, weil wir fehlende oder unrhythmische  <Zonen-Information> in Positions-Frames durch eigene - GPS-basierende - ersetzen können. Da wir für garantiert richtige Positionsdaten Tracking-Daten aufzeichnen, können wir sowohl die Spur als gepunktete Linie hinter dem Flugzeugsymbol als auch den Forecast-in-Minuten als größer gepunktete Linie vor dem Symbol zeigen. Für alle der hier genannten Daten und Prozeduren gibt es leider bisher keine definierte Export-Schnittstelle an andere Map-Systeme.

Beim 1090 MHz ADS-B Receiver werden nur Frames berücksichtigt, die Positionsdaten beinhalten, also Mode A und Mode C sowie die Downloadformate DF05, DF11, DF16 und alle > DF18 werden überlesen.
Mit dem ACARS-Receiver werden in Europa bis zu 4 Frequenzen gescannt:
 

alle demodulierten ASCII-Frames werden als Text mit bestimmbarer Verweildauer auf dem jeweiligen
Radarbild dargestellt.

Mit dem 978 MHz Receiver UAT (nur in USA) werden aus allen Downlinkformaten die Koordinaten, Höhe und Geschwindigkeit extrahiert
und auf dem Radarbild wie ADS-B Flieger gezeigt.

 

Die vom  869,5MHz s&f-Receiver empfangenen Positionsdaten werden auf dem Radarbild wie alle anderen Flieger gezeigt, optional mit Textkonserven.
Mehr in der kompletten Hard- und Soft-Softwarebeschreibung

Beim FLARM (868,4 MHz) Receiver haben wir seit Beginn der Positionsdaten-Verschlüsselung sinkende Frameraten, das allein
ist für die Sicherheit negativ, weil in freien Frequenzen (wie 868,4) die Sendeleistung - und damit die Reichweite - von der Datenmenge pro Stunde anhängt. Wer wenig sendet, kann mit mehr Watt senden als der der viel sendet. Da in der Elektronik dieses Transceiver variable Sende-
Watt nicht vorgesehen sind, wird jetzt  wegen Verschlüsselungs-Berechnungen leider sehr wenig gesendet und das auch noch mit viel zu wenig Power. Dieses Problem wird noch größer, weil das alles in einer technischen Umgebung von High-Tech-Transceiver aus der <IoT>- und Drohnen-Welt statt findet, deren Leistungsmerkmal gerade in der Sendeleistungs-Optimierung liegt.
Neben den physikalischen Problemen noch ein paar Worte zu den Verschlüsselungs-Akrobaten vom 868,4MHz Transceiver:
In der ersten Stufe der Verschlüsselungs-Entwicklung mussten Sender
und Empfänger den selben Schlüssel haben, in der zweiten Stufe wurde
der Schlüssel eine Variable, die sich während der Verschlüsselung ändert,
das bedeutete dann aber auch, das Sender und Empfänger einen
gemeinsamen externen (nicht im Frame enthaltenen) Wert zur Ver- und
Ent-Schlüsselung benutzen. Da die Uhrzeit zu nehmen war jetzt nicht
der große intelligente Aufwand, weil im Sender und Empfänger UTC-Zeit sendende GPS-Receiver enthalten sind, macht jedoch erst Sinn, wenn
die Uhren synchronisierbar sind.
Die dafür notwendige GPS-Hardware ist aber nicht verbaut, man
kann wohl davon ausgehen, daß der Hersteller das weiß.
Trotzdem eine kurze Beschreibung des Effektes:
Bei der Dekodierung ergeben sich durch die Verschlüsselung mit minütlich generierten128-Bit-Keys Entschlüsselungsfehler, weil kein Empfänger (auch der originale 868,4MHz Receiver) weiß, wann die
neue Minute beim Sender angefangen hat. Da unser GPS-Receiver
neben der Positionszeit auch das Ping-per-second Signal sendet, wissen wir, das bei allen 868,4MHz Transceivern die Minute zwischen 12 und
120 Millisekunden später/früher anfangen kann. Weil sich bei  der Ent-schlüsselung mit falschem Key unmögliche Daten ergeben, landen diese Frames bei uns im Fehler-Log, beim Hersteller wahrscheinlich unter schützenwertes Datengeheimnis.
Bisher haben wir nach jedem Pflicht-Hardware-Update dieser
Transceiver unseren Dekodierungs-Algorithmus angepasst, bei diesen
Anpassungen wurden wir von unseren Usern in Kanada und Italien
unterstützt, die uns massenweise mit generierten Fehler-
protokollen per Mail versorgt hatten und wir mittels Algorithmus
-Scanner die neue Keyvarianten entdeckten. Nach einem Jahr der Scannerei war klar, ab letzten März-Sonntag und ab dem
letzten Oktober-Sonntag wechseln jeweils die Basiskeys aus denen
dann die minütlichen gerechnet werden. Weniger kompliziert:
es gibt einen Sommerzeit-Key und einen Winterzeit-Key.
 Wir beschreiben diese leidige Verschlüsselungs-Arie hier, weil
wir einfach zeigen wollen, wie  armselig die Verschlüsselung
durchgeführt wurde und wie absurd Kaufentscheidungen ausfallen können, nämlich hin zum zufriedenen
Blindflug,
 dabei weisen wir natürlich gerne auf unseren short&far-Transceiver
mit mehrfacher Framerate und vielfacher Reichweite hin.