rdz_ttgo_sonde
rdz_ttgo_sonde copied to clipboard
dl9rdz
DFM Decoding of Temperature, Humidity and Pressure
Sorry for a newbie question: is there any particular reason why the T, H, P data from DFM sondes cannot be decoded while this is possible with others? Is it because no one has decrypted it yet or an ESP32 performance or memory issue?
I would have to defer to @dl9rdz for a complete answer but I don't believe there are any technical reasons against the feature being implemented. The main concerns would be with the limited space left on the ESP32 however this can and is being worked on through the creation of optional features.
The program didn't really have much need to decode weather information from sondes as it was primarily used for chasing however with the addition of SondeHub support we have seen more people using them as a cheaper alternative to an auto_rx station.
The code to decode this information exists and can be found here: https://github.com/einergehtnochrein/ra-firmware/tree/master/src/dfm, https://github.com/rs1729/RS/tree/master/dfm, and https://github.com/oe5hpm/dxlAPRS/blob/master/src/sondemod.c#L2522.
I'm sure if someone were to create a functional PR that didn't use too much space the addition would be considered.
Exactly right, meteo data never has been a priority for me. T for DFM could easily be added. Not sure about H, P though. If I see it correctly no other software is decoding them.
Your point is well taken. I realize that most of the current users are electronics nerds who want to collect the PCBs. On the other hand suddenly many people become more interested in science and particularly climatology and climate change. Although most software out there may not collect T, H and P, your's could set the standard as it is so rapidly evolving and runs on an tiny MCU instead of a whole single board computer like the RPI. This may be an interesting school project one day for the next generation.
Although most software out there may not collect T, H and P, your's could set the standard as it is so rapidly evolving and runs on an tiny MCU instead of a school single board computer like the RPI.
While it could be easy enough to add temperature decoding I don't believe anyone knows how to extract the humidity and pressure values from the data so even if we wanted it wouldn't be possible without first figuring that out. This isn't the place for it but you would need to collect high-quality data samples from DFM sondes with matching reference truth data. You could then work on determining the correct algorithm to extract this data where it could then be added.
Hi,
I've received some more information on this and the technical reason programs cannot decode the humidity and pressure values are the lack of calibration values transmitted by the sonde. When it comes to other sondes like the RS41 they transmit calibration values that are needed to get accurate readings. We can get a fairly reasonable value for temperature but humidity and pressure are too complex with the values.
Thank you for looking into it and consider temperature. I didn't know that calibration for H and P was an issue. Thought the sondes are only calibrated once at launch. Regarding measurements to sniff out the code I could donate a functioning sonde to Hans or you Luke. My programming skills are too limited.
Today's update should add decoding of temperature. Only tested locally with a recovered DFM-09 (with plausible values). Not tested with PS15 nor DFM17 (I don't have any)
Fantastic, will test it locally. Could also send you a DFM-09P with a pressure sensor. If you agree to your work address or a Packstation / PO Box if you like. Let me know ...
I can confirm the battery and temperature results perfectly match auto rx and are being uploaded to SondeHub!
So for DFM, we are now at feature parity in terms of decodable fields, when it comes to RS41 we are pretty much minus XDATA (https://github.com/projecthorus/radiosonde_auto_rx/blob/master/demod/mod/rs41mod.c#L1066).
The readme can be updated to show DFM temp support.
I can also confirm that T decoding renders plausible values. Still hoping for H and P. Maybe one day.