New RS41 SN: X.....

[73-de-LZ]

I am afraid there is some issue with the decoding of those new Vaisala RS41 and SN starting with X....
For example Poprad today: https://radiosondy.info/sonde.php?sondenumber=X0345025
The reports on sondehub are also only by stations, different than DL9RDZ and radiosonde_auto_rx.
https://sondehub.org/#!mt=Mapnik&mz=10&qm=3h&mc=48.16792,21.4975&f=X0345025&q=X0345025&box=aboutbox

[dl9rdz]

I don't have any X.... here for testing, but you can give dev2025-02-05 a try. Mimicking oe5dxl's code. But completely un-tested.

Would be great if someone could have a close look if in particular sats and time stamp are right.

[73-de-LZ]

Unfortunately i had no time to apply my mods as i have to update remotely with option to get back on custom fw, but as the 2nd X sonde fly tonight i got this from data tab of old 20231212 version:
400.600 MHz, Type: RS41
...
ID: X0345024
QTH: nan,nan h=nanm
Frame# 8586, Sats=0, 1970-01-01 00:00:00
Burst-KT=30600 Launch-KT=65535 Countdown=30367 (vor 18s)

[pavolgaj]

Is it possible to make an OTA update to this dev20250205 version? I couldn't see it on the update web page of my TTGO...

[dl9rdz]

OTA from any newer dev2... version should work (I updated mine this way, so yes...)

OTA from the older master or devel versions: no, too many breaking changes like different flash layout, different file system (LittleFS vs SPIFFS), etc.

[dl9rdz]

Unfortunately i had no time to apply my mods as i have to update remotely with option to get back on custom fw, but as the 2nd X sonde fly tonight i got this from data tab of old 20231212 version: 400.600 MHz, Type: RS41 ... ID: X0345024 QTH: nan,nan h=nanm Frame# 8586, Sats=0, 1970-01-01 00:00:00 Burst-KT=30600 Launch-KT=65535 Countdown=30367 (vor 18s)

For the old version, this is to be expected. Sats, Time and location are sent in different dubframes. location decoding should be exactly the same in another subframe, so I am pretty sure I might have gotten this right in the update. time and sats decoding is completely different, so that's why I asked that it would be great if someone can double check...

[pavolgaj]

OTA from any newer dev2... version should work (I updated mine this way, so yes...)

OTA from the older master or devel versions: no, too many breaking changes like different flash layout, different file system (LittleFS vs SPIFFS), etc.

I use the latest master version...

[73-de-LZ]

SP7THR-15 | X0345021 | 2025-02-06 11:58:08 | 48.7271 | 20.7422 | 142 | 28 | 15441 | Clb=4.9m/s p=112.8hPa t=-53.2C h=1.5% 400.600MHz Type=RS41-SGP rdzTTGOsonde

FB!

[73-de-LZ]

Stuck on that:

ArduinoIDE output.txt

[73-de-LZ]

OTA from any newer dev2... version should work (I updated mine this way, so yes...)

OTA from the older master or devel versions: no, too many breaking changes like different flash layout, different file system (LittleFS vs SPIFFS), etc.

Would you be so kind to share which libraries and their versions are used to compile dev2. After so many ties on Arduino IDE and mess it totally, i finally succeed to compile some old versions without errors, but on dev2 have no any luck, all kind of errors. With Platformio was OK, but the output files are a bit different than those of ArduinoIDE. I would like to have firmware and FS updates for OTA at the Platformio output the same as those of Arduino IDE. Please help.

[dl9rdz]

I have stopped using Arduino IDE (one of the reasons was that the file system uploader was not available for Arduino IDE v2, and Arduino IDE v1 was already pretty old. This may have changed now as I just saw that a LittleFS uploader is now available for v2, but anyway). Development for the dev2 branch is just using Platformio. What I also like is that the (incremental) compile is much faster than compiling with ArduinoIDE.

Also, the process for generating the binary images has changed. For devel and master, this used to use Arduino IDE (or its cli), but now this is also Platformio for dev2. In particular, the logic to generate the fonts partition (which is separate from the code partition, also to save space on OTA updates) exists only in platformio (as extension in scripts/pio-build-extension.py)

[73-de-LZ]

Thanks, now i get it. Platformio is really preferred and now i see the scripts to generate OTA update files, i will just have to modify them to suit my env. GL and 73!

[darksidelemm]

OK - Issue with this version!

The time within the new position/datetime block appears to be provided as UTC, not GPS time.

I'm fairly confident in this now, as i've just updated auto_rx with the latest rs41mod decoder, which does not do any kind of conversion of UTC<->GPS time, and the 'time_received' timestamps are only a few seconds after the packet datetime.
e.g.

{"software_name": "radiosonde_auto_rx", "software_version": "1.8.1-beta6", "uploader_callsign": "diehard", "uploader_position": "48.2888,18.5993", "uploader_antenna": "VINNANT SCANNER VHF-UHF", "time_received": "2025-02-08T11:57:08.236873Z", "datetime": "2025-02-08T11:57:06.000000Z", "manufacturer": "Vaisala", "type": "RS41", "serial": "X0335478", "subtype": "RS41-SGP", "frame": 5012, "lat": 48.94591, "lon": 20.49659, "alt": 13901.45972, "temp": -51.9, "humidity": 1.8, "pressure": 142.87, "vel_v": 3.65051, "vel_h": 2.67244, "heading": 106.64696, "sats": 5, "batt": 2.6, "frequency": 400.60015, "burst_timer": 65535, "ref_position": "GPS", "ref_datetime": "UTC", "rs41_mainboard": "RSM425", "rs41_mainboard_fw": "20701", "snr": 23.7, "tx_frequency": 400.6, "user-agent": "Amazon CloudFront", "position": "48.94591,20.49659", "upload_time_delta": -0.497, "uploader_alt": 0.0}

As per our convention for sondehub, we report the time provided, and also report what we think it is. In this case, the time provided does appear to be UTC, and auto_rx is currently reporting it as such.

In your code, you have a 'conversion' back to GPS time right before uploading to sondehub, which results in data becoming 'misaligned'. If you please remove this conversion, and report the time as being UTC that would be appreciated!
In the case of the rs1729 decoders, a isUTC flag is set if time is obtained from the new position/datetime block.

Some examples of data for the same frame (note that dxlAPRS-SHUE has the same issue):

{"software_name": "radiosonde_auto_rx", "software_version": "1.8.1-beta6", "uploader_callsign": "HA5SZI", "uploader_position": "47.5504,19.1252", "uploader_antenna": "NA", "time_received": "2025-02-08T11:57:08.189523Z", "datetime": "2025-02-08T11:57:06.000000Z", "manufacturer": "Vaisala", "type": "RS41", "serial": "X0335478", "subtype": "RS41-SGP", "frame": 5012, "lat": 48.94591, "lon": 20.49659, "alt": 13901.45972, "temp": -51.9, "humidity": 1.8, "pressure": 142.87, "vel_v": 3.65051, "vel_h": 2.67244, "heading": 106.64696, "sats": 5, "batt": 2.6, "frequency": 400.600025, "burst_timer": 65535, "ref_position": "GPS", "ref_datetime": "UTC", "rs41_mainboard": "RSM425", "rs41_mainboard_fw": "20701", "snr": 10.4, "tx_frequency": 400.6, "user-agent": "Amazon CloudFront", "position": "48.94591,20.49659", "upload_time_delta": -0.67, "uploader_alt": 114.0}
{"software_name": "rdzTTGOsonde", "software_version": "dev20250205", "uploader_callsign": "SP7THR-15", "time_received": "2025-02-08T11:57:07.000Z", "manufacturer": "Vaisala", "serial": "X0335478", "datetime": "2025-02-08T11:57:24.000Z", "lat": 48.94591, "lon": 20.49659, "alt": 13901.45996, "frequency": 400.6, "vel_h": 2.67244, "vel_v": 3.65051, "heading": 106.64696, "rssi": -112.5, "frame": 5012, "type": "RS41", "sats": 5, "subtype": "RS41-SGP", "temp": -51.9, "humidity": 1.8, "pressure": 142.87, "burst_timer": 65535, "batt": 2.6, "uploader_antenna": "SLIM JIM ANTENNA FOR 433 MHZ + LNA SPF5189Z", "uploader_position": "50.567,22.074", "user-agent": "Amazon CloudFront", "position": "48.94591,20.49659", "upload_time_delta": -17.088, "uploader_alt": 168}
{"software_name": "rdzTTGOsonde", "software_version": "dev20250205", "uploader_callsign": "SP9RUT", "time_received": "2025-02-08T11:57:07.000Z", "manufacturer": "Vaisala", "serial": "X0335478", "datetime": "2025-02-08T11:57:24.000Z", "lat": 48.94591, "lon": 20.49659, "alt": 13901.45996, "frequency": 400.6, "vel_h": 2.67244, "vel_v": 3.65051, "heading": 106.64696, "rssi": -109.0, "frame": 5012, "type": "RS41", "sats": 5, "subtype": "RS41-SGP", "temp": -51.9, "humidity": 1.8, "pressure": 142.87, "burst_timer": 65535, "batt": 2.6, "uploader_antenna": "Diamond X30", "uploader_position": "49.6862,21.174", "user-agent": "Amazon CloudFront", "position": "48.94591,20.49659", "upload_time_delta": -17.119, "uploader_alt": 305}
{"software_name": "radiosonde_auto_rx", "software_version": "1.8.1-beta6", "uploader_callsign": "diehard", "uploader_position": "48.2888,18.5993", "uploader_antenna": "VINNANT SCANNER VHF-UHF", "time_received": "2025-02-08T11:57:08.236873Z", "datetime": "2025-02-08T11:57:06.000000Z", "manufacturer": "Vaisala", "type": "RS41", "serial": "X0335478", "subtype": "RS41-SGP", "frame": 5012, "lat": 48.94591, "lon": 20.49659, "alt": 13901.45972, "temp": -51.9, "humidity": 1.8, "pressure": 142.87, "vel_v": 3.65051, "vel_h": 2.67244, "heading": 106.64696, "sats": 5, "batt": 2.6, "frequency": 400.60015, "burst_timer": 65535, "ref_position": "GPS", "ref_datetime": "UTC", "rs41_mainboard": "RSM425", "rs41_mainboard_fw": "20701", "snr": 23.7, "tx_frequency": 400.6, "user-agent": "Amazon CloudFront", "position": "48.94591,20.49659", "upload_time_delta": -0.497, "uploader_alt": 0.0}
{"software_name": "dxlAPRS-SHUE", "software_version": "1.1.2", "uploader_callsign": "OE3JTB", "uploader_position": "47.97182,15.61041", "uploader_antenna": "DiamondX50", "time_received": "2025-02-08T11:57:08.272825Z", "manufacturer": "Vaisala", "subtype": "RS41-SGP", "type": "RS41", "serial": "X0335478", "datetime": "2025-02-08T11:57:24.000000Z", "frame": 5012, "alt": 13901.4, "ref_datetime": "GPS", "ref_position": "GPS", "lat": 48.945907, "lon": 20.496589, "vel_v": 3.65, "vel_h": 2.7, "heading": 106.6, "temp": -51.85, "pressure": 142.87, "humidity": 4.3, "tx_frequency": 400.6, "burst_timer": 65535, "batt": 2.6, "sats": 5, "frequency": 400.6, "user-agent": "Amazon CloudFront", "position": "48.945907,20.496589", "upload_time_delta": -1.047, "uploader_alt": 1313.0}

[dl9rdz]

Hi, Thanks for pointing this out. Should be fixed in today’s version. The sats count might need an update as well, but probably we will still have to see and find a consensus on how to interpret the data…. 73, Hansi

…

On 8 Feb 2025, at 12:23, Mark Jessop ***@***.***> wrote: In your code, you have a 'conversion' back to GPS time right before uploading to sondehub, which results in data becoming 'misaligned'. If you please remove this conversion, and report the time as being UTC that would be appreciated!

[darksidelemm]

Thanks for that!

Yes, the sat count still needs a bit of work. I suspect we won't know for sure on that one until one of these sondes has been recovered and more detailed investigations can be made.

[darksidelemm]

OK, new information obtained from a reputable source, that I've been given permission to share!

• The byte after the seconds field in the position/time packet is fractional seconds, in units of 0.01 seconds.
• Refer the following information for the location of bitfields for used SVs in the new 'gps status' packet:

These changes have been implemented in rs1729's decoder.
You can find the addition of fractional seconds here: https://github.com/rs1729/RS/blob/d8fee89f15605ba8c321e9ee3bbcde5cfc8e2f52/demod/mod/rs41mod.c#L1147
and the calculation for the numSVs here: https://github.com/rs1729/RS/blob/d8fee89f15605ba8c321e9ee3bbcde5cfc8e2f52/demod/mod/rs41mod.c#L1178

Note that @rs1729 is also summing bits from the bytes in between the galileo and beidou section, which we are assuming is likely glonass, but so far these have all been observed to be zero, so it's likely glonass support has been turned off in the GNSS receiver (I could think of a few good reasons for that...)