Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese
Ich bin in Sachseneinergehtnochrein hat geschrieben:Hi Robby, kommen nördlich Neustadt runter. Die mußt wohl Du holen!
Vielen Dank dafür! Ging fast auf Anhieb, nur eine nicht initialisierte globale Variable hat sich quer gestellt. Nun aber kann ich es sauber dekodieren!zilog80 hat geschrieben:Ozonsonde aus Uccle, 4 frames. Der dritte frame ist kurz (320), die anderen mit aux-Daten (518).
Da hast Du völlig Recht. Wenn ich den Wert bestimmter Stellen im Codewort kenn, brauche ich nicht den Joker (Fehlerkorrektur) darauf verschwenden!zilog80 hat geschrieben:In den Rohdaten sieht man gut, dass hier die aux-Ddaten um nur ganz wenige bytes die Standard-Framelaenge von 320 ueberschreiten, dann kommt dieser riesige 00-padding-Block. Bei schlechten Empfangsbedingungen in der zweiten Haelfte des Frames kann man sich da leicht mehr Probleme einhandeln als wenn man das gleich alles nullt...
Mir geht es nur um das "Kalibrierdatenfragment".einergehtnochrein hat geschrieben:asg hat geschrieben: 1 Byte Typkennung (z.B. 0x7B: GPS-Position, 0x7A: Meßwerte, 0x79: u.a. Kalibrierdatenfragment)
Bin mir jetzt gar nicht mehr so sicher daß es das ist was Du wissen wolltest...
Finde ich nicht.zilog80 hat geschrieben:Mit dem auskommentierten printf sieht das auch noch etwas unfertig aus... Danke fuer den Hinweis.
Hm, ich auch.zilog80 hat geschrieben:Fuer die rs92 hab ich fuer mich PTU-Daten programmiert
Der Zähler zählt aber nicht, darum "Marker".zilog80 hat geschrieben: Weiss nicht genau, was du mit "Marker" meinst. In den Calib-Daten ab subframe 0x04 sind immer Bloecke zu je 5 byte (Zaehler + 4byte float32). Meinst du den Zaehler als "Marker"?
Schade.zilog80 hat geschrieben: So richtig begeistern konnte ich mich fuer die PTU-Daten bisher leider noch nicht. Dachte, bei der rs41 wird das aehnlich sein, hatte auch was gehoert, bin dem aber bisher nicht weiter nachgegangen.
Willst Du wissen wo und wie das übertragen wird, oder möchtest Du wissen wie die Kalibrierdaten zu interpretieren sind sobald alle Fragmente eingesammelt sind?asg hat geschrieben:Mir geht es nur um das "Kalibrierdatenfragment".
Code: Alles auswählen
0x79 0x28 (...40 Bytes...) cc ccIndeed there were four Graw sondes yesterday, two in the morning, two in the afternoon. Yours must be the afternoon sondes on 402.51 and 405.73. The ones on 402.50 and 405.72 are false detections!andy hat geschrieben:Hello,yersterday 4 Radiosondes from Nuremberg Graw:
Dieser Prozessschritt wird in der Vaisala-SW (Digicora) bei der Vorbereitung mit durchlaufen und sieht dann so aus: Das Gerät misst Temperatur mit einem Pt100; der Luftdruck stammt von einem lokalen Stationsbarometer. Für die Feuchte wird nur ein Offset bei 0 % ermittelt, so dass die Sonden oberhalb der Tropopause auch 0 anzeigen.zilog80 hat geschrieben:Ehrlich gesagt weiss ich garnicht, was bei der Kalibrierung vor dem Start gemacht wird und wie die Werte zu verstehen sind bzw worauf sie sich beziehen.
Werden vor dem Start Werte neu eingestellt oder werden die Werte nur als Referenz genommen, um sie mit den Messwerten der Bodenstation zu verrechnen? Oder beides? Es gibt doch auch noch die Kalibrierung ab Werk, zu der auch die Seriennummer gehoert.
Das steht so im Handbuch:Durango hat geschrieben:Null Prozent Feuchte als Referenz ? Wo hat Robby das her ?… 73 Manfred
Das hat freilich nichts mit der Kalibrierung und der Übertragungsfunktion des Sensor-Rohwertes in die phys. Größe zu tun, sondern ist nur sowas, wie der Exzenter an einem Zeigermesswerk, wo man die Nulllage des Zeigers einstellt.The GC25 Ground Check Set includes desiccant for 0% RH humidity reference.
Code: Alles auswählen
AC01030
AC80011
->zoomSuper, das ist genau die Erklärung die ich gesucht hatte!zilog80 hat geschrieben:Im SEM almanac ist PRN 4 nicht aufgefuehrt, in den brdc ephemerides von heute jedoch schon, allerdings mit SV Health 63 (DEAD).
[...]
ON APPROXIMATELY 18 MAY 2017 SVN38 WILL RESUME TRANSMITTING L-BAND UTILIZING PRN04. AT L-BAND ACTIVATION, SVN38/PRN04 WILL BE UNUSABLE UNTIL FURTHER NOTICE. ADDITIONALLY, NO BROADCAST ALMANACS WILL INCLUDE SVN38/PRN04 UNTIL FURTHER NOTICE.
) habe ich Trottel überhaupt nicht gedacht. Das kommt jetzt natürlich als Abfrage mit in den Code um solche unbrauchbaren Daten auszusondern.Zu Bahnkorrekturen braucht man IMMER Masse, die man ausstoßen kann.Dazu kann Treibstoff mitgefuehrt werden, der irgendwann aufgebraucht ist, und Solarmodule. Auch die Solarmodule nutzen sich jedoch mit der Zeit ab.
Ok, man koennte Energie auch von aussen aufnehmen, war aber dennoch nicht so klar formuliert, das "kann" passt nicht so richtig. Aber Bahnkorrekturen sind ja nicht das einzige, was ich aufzaehlte. Fuer die Stabilisierung/Ausrichtung gibt es neben Steuerduesen eben auch elektrische Methoden. Und dann brauchen die Instrumente eben Energie meist in Form von elektrischer Energie. Die GPS-Satelliten werden am Ende ihrer Lebenszeit in eine hoehere Bahn verschoben, dazu wird Resttreibstoff aufbewahrt. Im Allgemeinen ist es natuerlich am besten, wenn die Lebenszeiten aller Komponenten moeglichst zusammenfallen und keine mit unnoetigen Aufwand ueberdimensioniert ist.ferdimh hat geschrieben: Zu Bahnkorrekturen braucht man IMMER Masse, die man ausstoßen kann.
Na, man kann nicht einfach sagen, die Militaes haben da was entwickelt und dann bemerkt, was die zivile Welt daraus macht. Gerade die Entwickler bei der USAF wussten ziemlich genau, was die Moeglichkeiten waren und dass auch die kuenstliche Verschlechterung (SA) nichts bringt. Aber entscheiden tun am Ende oft andere.ferdimh hat geschrieben: Das wird vermutlich nicht mehr praktiziert, weil die eher unerwartete massive Verbesserung der Empfänger (Theoretische Auflösung von zivilem GPS sind 300 Meter!) durch fette DSPs, die sicher auch nicht am Militär vorbeigegangen ist, das vermutlich einfach nicht mehr erforderlich macht.
ich weiß nicht, was der erste Empfänger kostete, aber der Ansatz war analog und die Synchronisation wackelig. Den korellierenden Ansatz mit viel Rechenleistung gab es halt nicht. Wenn ich das Ding so sauber einraste, dass ich decodieren kann (was schon eine Herausforderung für sich sein dürfte, wenn ich keinen Multi-MHz-DSP habe) werde ich vielleicht 1/3 Chip als Offset akzeptieren. Lass es +/-100m pro Satellit sein, dann kommt bei ungünstiger Konstellation immer noch 300m Fehler raus. Egal wie mans dreht, der relevante Punkt ist "ich treffe damit nicht Bin Ladins Haus". Der P/Y-Code ist halt mittlerweile nicht mehr wirklich genauer, weil die Ionosphäre einfach zu viel Mist macht.Wuerde auch nicht sagen, dass die theoretische Genauigkeit 300m ist, auch wenn das Signal eines Chips etwa so lang ist, kann man Beginn und Ende genauer bestimmen. Ob das schon "fette DSP" ist, weiss icht nicht. Und dann gibt es eben noch die Traegerfrequenz und weitere Moeglichkeiten. Aber sicher war das 1980 noch etwas schwieriger, kostete der erste Empfaenger nicht 250000 dollar?
Ich aber:Wie die ersten analogen Empfaenger gearbeitet haben, weiss ich nicht.
