Skip to content

Specific Notes

Jump to bottom
Luke Prior edited this page Jul 31, 2021 · 6 revisions

Sonde Data Uploader Notes

Radiosonde Auto RX

  • For various legacy reasons, the sonde serial numbers passed around within auto_rx have the sonde type prepended (e.g. DFM-1234567, IMET-A1B2C3). When uploaded to SondeHub, these are stripped off. Refer to this block of code in auto_rx to see what is used.

rdzTTGOsonde

  • rdzTTGOsonde uses the decoders from the APRS-Toolchain by OE5DXL while Radiosonde Auto RX uses the RS1729 which can result in differences in decoded values. We have decided to work towards identical core sonde data (time, frame, position) and accept that other values may differ. We recommend checking the ElasticSearch Kibana Interface to check the recorded values if you are developing with the intent to upload to SondeHub.

  • Time values for sonde and device time are only returned to the nearest second due to the difficulty of implementing millisecond accuracy on a mobile device.

  • The precision for all data fields is set on a global amount for all sonde types due to the nature of the code, Radiosonde Auto RX has different precision for each sonde type.

Chase Car Uploader Notes

SondeHub Tracker

Chasemapper

rdzTTGOsonde

Radiosonde Specific Notes

This section describes the various peculiarities of the different radiosondes that SondeHub & Radisonde Auto RX support, and how their telemetry is processed.

Vaisala RS41

  • subtype: The RS41 sonde model (e.g RS41-SG, RS41-SGP, RS41-SGM, RS41-NG) is sent every ~30 frames, extracted in Radiosonde Auto RX here. The subtype reported by the decoder is left at RS41 until this information is obtained, and then latched in.

Graw DFM Sondes

  • serial: The DFM sondes only send their serial number every 30 seconds or so. Until the serial number is obtained, the decoder reports the serial as xxxxxxxx, which causes auto_rx to discard the frame. There are known issues (essentially unresolvable) when multiple DFMs are present on the same frequency, which results in some odd tracks on the tracker.
  • frame: The DFM sondes frame number is only 8-bits long, which rolls over many times during flight. To avoid issues due to this, we convert the supplied date/time into a UNIX timestamp, Radiosonde Auto RX code here.
  • subtype: There is a particular byte within the DFM telemetry that can be used to determine the specific DFM model being received (though Graw have indicated this is not reliable, but it's all we have!). The lookup table between this byte and the model is located here for Radiosonde Auto RX and here for rdzTTGOsonde.

Meteomodem M10/M20

  • frame: Same issues as the DFMs, with a short frame ID. Same solution again (converting datetime to a unix timestamp), with the code here.

Intermet iMet-1 / iMet-4

  • serial: iMet-1 and iMet-4 sondes do not report their serial number in their telemetry! As such, we have to generate a unique serial number based off what little information we do have. At the moment this is performed using a hash function, with the sondes power-on time (current reported datetime minus frame count) and the receive frequency (quantised to 100 kHz) as an input to this. The code that does this is here.
  • datetime: iMet-1 and iMet-4 sondes only provide time-of-date in telemetry, no date. The date from the receiving system is added to the sonde's reported time using this function. Care must be taken that the receivers system time is accurate, otherwise this can result in incorrect timestamps being generated.

Intermet iMet-54

  • datetime: Same issues as the iMet-1/4, and same solution.

Lockheed Martin LMS6 (both 400 MHz and 1680 MHz variants)

  • datetime: Same issues as the iMet-1/4, and same solution.
Clone this wiki locally