Fewer TTGO receivers for DFMs than for RS41 on Sondehub? #403
-
|
Recently, the Bundeswehr has launched series of DFMs at the ALTENGRABOW (ALTMARK) and GRAFENWÖHR military training areas, in which the following was noticed. Otherwise fewer DFMs will come into the reception area. The DFMs are registered by SIGNIFICANTLY fewer receiving stations with rdzSonde than is the case with RS41. Interestingly, radiosondy.info lists significantly more receiving stations that have received DFM than Sondehub. It seems as if Sondehub somehow treats the incoming data more "critically" and therefore discards a lot of it. I once had the opportunity to observe my own live map during a flight: the probe was imported correctly in the frequency import, it was also decoded and the track was drawn. At radiosondy I am listed as the recipient of this probe, but not at Sondehub. It is clearly visible in a double combination DFM/RS41 from Meppen that flew on November 23rd, 2023 (yesterday): D21069154/U1320563. Let's look at the Grafana data of the RS41 at Sondehub: Unfortunately, at Radiosondy you cannot filter how many TTGOs were among the recipients: The DFM17 connected to the RS41 looks like this during probe lift: You can observe the same thing with D18081308, D18082041 and D18082206 from November 11th, 2023 from TÜP Altmark: Much less receiver for probe hub than for an RS41. I have the impression that it has something to do with the "scan hack" (see: #370 (comment) ), If this is the case, mostly of ALL rdzSonde-Receivers must have activated the "ScanHack". My scan time was temporarily set to 15 Seconds, that didn't change anything. Might it be necessary to make the time even longer? 73 Steffen, DG0MG |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
As mentioned over here: #421 I expect a lot of DFM telemetry from rdz_ttgo_sonde stations are getting dropped due to uploads failing the z-check criteria (the main one being a minimum of 10 packets uploaded at once). Since the time between uploads is hard-coded to 15 seconds, there's a good chance that packets might be dropped resulting in less than 10 packets being uploaded. Without being able to see the responses from the upload request (we respond with a non-200 status code, and a descriptive message), I can't be sure this is the case, but it's pretty likely. |
Beta Was this translation helpful? Give feedback.
As mentioned over here: #421 I expect a lot of DFM telemetry from rdz_ttgo_sonde stations are getting dropped due to uploads failing the z-check criteria (the main one being a minimum of 10 packets uploaded at once).
Since the time between uploads is hard-coded to 15 seconds, there's a good chance that packets might be dropped resulting in less than 10 packets being uploaded.
Without being able to see the responses from the upload request (we respond with a non-200 status code, and a descriptive message), I can't be sure this is the case, but it's pretty likely.