DFM17 -> DFM09 mis-identification

[darksidelemm]

We're beginning to see many DFM17 launches mis-identified as DFM09 by the various decoders out there (all seem to be behaving consistently... I think).

The method that we currently use to identify DFM sub-types is known to be flawed, as changes in sensor configuration can result in the maximum channel ID field that we use for identification to change.

We have reliable information that DFM09 sondes have not been manufactured since early 2023, and that the highest DFM09 serial number is around the 22033000 area (presumably programmed in 2022).

So, the consequences of a mis-detection are:

• Incorrect identification of subtype on the receiving software and tracker
• Incorrect calculation of sensor temperature due to using a different Rf value (refer line 862 in dfm09mod.c).

Right now I think it prudent to focus efforts on ensuring any newly manufactured (2023 and newer) are not mis-identified. Trying to solve the problem for old radiosondes is going to be difficult.

Things that we can do to solve this problem:

• As an interim step - for DFM telemetry submitted to SondeHub that has a serial number > 22033000 and is identified as a DFM09, change the sub-type to DFM17.
  • We may wish to add some kind of flag to the telemetry to indicate that has been modified on ingest. We may also want to send a message back to the client.
  • We may also want to remove any temperature fields, as we know that the calculations are likely to be very incorrect if the sonde has been mis-identified.
• Update decoding software to correct DFM09 detections with serials > 22033000 to DFM17. There are also other ways detection might be improved, e.g. using FSK polarity. Decoding software that will need to be updated includes:
  • RS decoders (used in auto_rx, which will require a new auto_rx version)
  • rdz_ttgo_sonde
  • dxlAPRS (it's possible the correction could be done in dxlAPRS-SHUE)

[darksidelemm]

The testing branch of auto_rx now has an update DFM demodulator which implements the corrections mentioned above.

SondeHub should also now be re-categorising incoming incorrectly identified telemetry. In this case, the return code will be 202, and a new "warnings" field will be added.