SondeHub (not only) open minor issues

[dl9rdz]

• Temperatures are reported to SondeHub with 5 decimal digits, which does not make much sense. autorx seems to be using 1 decimal digits, which is the right thing to do
• The TTGO has two concurrent tasks (Arduino loop and radio task), both using the same data structure for sonde data. If the loop task is slow (in particular during SondeHub uploads), the radio task may already be updating data. So when we intent do process data of frame x, we might actually already be using data of frame x+1 (or partial data, as data for example for RS41 is updated after each internal data block has been decoded.
• The frequency import removes entries that are no longer reported within time and distance range. This may include "removing" the currently active receiver (which does not affect the reception itself, as a running receiver keeps running), but the displayed freuquency is reset to 400.000)
• EDIT: Additional item for RS41: On ID change, we clear the calibration data and update all data that are directly obtained from the new frame with the new ID. But this may leave parts of old data in some fields such as temperature that are not necessarily updated. To fix: clear all data.

[LukePrior]

• Temperatures are reported to SondeHub with 5 decimal digits, which does not make much sense. autorx seems to be using 1 decimal digits, which is the right thing to do

The difference between us and auto rx is that each individual decoder outputs the fields to a set amount of decimal digits which is then uploaded. This allows for different accuracies depending on the decoder, as we use a universal value we need to choose the highest value.

I've had a look at the RS41 decoder in auto_rx and can see that it is only using 1 decimal place and considering we only decode temperature for RS41 changing this to 1 makes sense. This is the same for humidity so that should also be updated for the same reason.

I can't help with the other two issues.

[dl9rdz]

Ok, we could the rounding in the sonde-specific decoder as well. Should temp decoding be added later to other decoders, then we can individually decide about the precision that makes sense or is consistent with autorx.

The second item is on my TODO list. Its not trivial (while keeping memory use miniml) but I should change the architecture slightly. In practice currently the main effect is that frames might be skipped and then the next frame is duplicated. I have never seen partially updated values. This also explains the observation of duplicated time stamps with Chasemapper.

The last item is easy to fix, never deactivate the sonde currently in use by the decoder...

[eben80]

• The TTGO has two concurrent tasks (Arduino loop and radio task), both using the same data structure for sonde data. If the loop task is slow (in particular during SondeHub uploads), the radio task may already be updating data. So when we intent do process data of frame x, we might actually already be using data of frame x+1 (or partial data, as data for example for RS41 is updated after each internal data block has been decoded.

I've seen identical frame numbers with different location data between auto_rx and ttgo yes, but the vast majority of the time they are consistent for me.

[LukePrior]

Ok, we could the rounding in the sonde-specific decoder as well. Should temp decoding be added later to other decoders, then we can individually decide about the precision that makes sense or is consistent with autorx.

Sounds good here is the breakdown:

RS92

• lat: 5
• lon: 5
• alt: 5
• vel_h: 5
• vel_v: 5
• heading: 5
• temp: 1
• humidity: 1
• pressure: 2

RS41

• lat: 5
• lon: 5
• alt: 5
• vel_h: 5
• vel_v: 5
• heading: 5
• batt: 2
• temp: 1
• humidity: 1
• pressure: 2

DFM

• lat: 5
• lon: 5
• alt: 5
• vel_h: 5
• vel_v: 5
• heading: 5
• batt: 2
• temp: 1

M10/20

• lat: 5
• lon: 5
• alt: 5
• vel_h: 5
• vel_v: 5
• heading: 5
• batt: 2
• temp: 1
• humidity 1

MP3-H1

• lat: 5
• lon: 5
• alt: 5
• vel_h: 5
• vel_v: 5
• heading: 5
• temp: 1
• humidity: 1

So it seems the values at least for the sondes we decode are identical so we can simply change temp/humidity from 3 to 1.

[dl9rdz]

The TTGO has two concurrent tasks (Arduino loop and radio task), both using the same data structure for sonde data. If the loop task is slow (in particular during SondeHub uploads), the radio task may already be updating data. So when we intent do process data of frame x, we might actually already be using data of frame x+1 (or partial data, as data for example for RS41 is updated after each internal data block has been decoded.

Actually it turned out that this should not be a real problem for RS41 under normal circumstances, as we start decoding the next RS41 frame only after it has been fully received. However, there was a 1s delay that block the main loop after each sondehub upload. With that delay, the data indeed is already replaced by the next frame. Fixed with the latest commits.

[dl9rdz]

should be all fine for now