Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
0x04 - 15.11.2014
Zweiter Start im November, mit morgendlichem, dichten Nebel aber später immer noch extrem freundlichen Wetters mit annehmbaren Bedingungen. Ziel sollte erreichen eines Tag-/Nachtfloats sein, was auch mehr als gelungen ist. Außerdem APRS- und DominoEX16-Test.
- Start: Käseschenke bei Kraftsdorf, Thüringen, JO50XU um 10:07 Uhr MEZ
- Stromversorgung: 1 AA-Lithium Zelle 1.5 V (Energizer)
- Effizienterer Schaltregler an der Nutzlast, erwartete Batterielebensdauer: 60 Stunden!
- Gewichtsoptimierung Thermoisolation (ca. 3.5 g Ersparnis)
- Aussendung aller 30 Sekunden:
- Sekunde 1: APRS mit DK3SB-4 auf 144.800 MHz
- Sekunde 2: APRS mit DK3SB-4 auf 434.075 MHz
- Sekunde 3-12: DominoEX16 auf 434.075 MHz
- Ballon: Qualatex 36-Zoll-Foil-Ballon, silber
- Auftrieb ('free lift'): 2 g
Zur Premiere von DominoEX gabs die passende Verpflegung:
Ein APRS-Frame sieht so aus:
fm DK3SB-4 to APRS via WIDE1-1 ctl UI pid F0 !5055.41N/01152.77EO/A=001043 uTrak 0x04
Die jetzt im Mode 'DominoEX16' ausgesendeten Zeilen bleiben im Format zur früheren RTTY-Aussendung gleich:
$$0x04,1369,210034,+5409.7318,+01220.9288,5335,09,1412,-22*2404
- 0x04 : Identifier des Fluges
- 1369 : lfd. Nr. der Aussendung, bei 1 beginnend (ergibt halbiert etwa die Anzahl der Minuten seit Einschalten)
- 210034 : Uhrzeit in UTC (HHMMss)
- +5409.7318,+01220.9288: geografische Position in Breite und Länge, Format GGmm.mmmm
- 5335: Höhe über Meeresspiegel (nicht über Grund!) in Metern
- 09: Anzahl GPS-Satelliten
- 1412: Batteriespannung im mV
- -22: Temperatur
- 2404: Prüfsumme
Probleme/Erkenntnisse
Die Betriebsart DominoEX16 versprach viele Vorteile:
Schneller, damit weniger Sendezeit (Batterieschonend!) und trotzdem noch störsicherer als RTTY bzw. bei schwachen Signalen besser zu dekodieren.
Aber nicht alles klappt auf Anhieb und schnell bemerkten wir einen Implementierungsfehler: Die Symbolrate der Daten wird aus dem internen Prozessor-Oszillator gewonnen, während der HF-Takt aus dem temperaturkompensierten Quarz-Oszillator kommt: Das brachte Probleme bei der kohärenten Demodulation mit (dl-)fldigi. DominoEX16 ist definiert aus 18 Tönen mit einem Abstand in Hz, der exakt gleich der Symbolrate (15.625 Hz) ist. Durch die unterschiedlichen Quellen für Sendefrequenz (=TCXO) und Symboltakt (=prozessorinterner Oszillator) laufen die beiden Werte unterschiedlich auseinander und die Bedingungen für eine saubere Dekodierung sind deshalb nicht erfüllt.
Wir fanden heraus, dass der MultiPSK-Dekoder deutlich toleranter gegenüber diesem
Problem ist, und nutzten diesen um die Aussendungen der Nutzlast zu dekodieren.
Schlussfolgerung: Prozessortakt und Sendefrequenzaufbereitung müssen unbedingt aus der gleichen Frequenzquelle gespeist werden.