Weathex WxR-301D decoding about rs HOT 28 CLOSED

The problem is the huge bandwidth, I guess a lowpass filter is needed for the FM audio.
Also there is the option "-b" that can handle the noise better.
Try

$ sox test.wav -t wav - lowpass 4000 | ./weathex_decoder -b
 (0x893753FD)  [ 5945]  00:39:49  alt: 24066.4  lat: 2.6839  lon: 101.6088   [OK]
 (0x893753FD)  [ 1852]  00:39:52  alt: 23264.7  lat: 2.6841  lon: 101.6082   [NO]
 (0x893753FD)  [ 5949]  00:39:53  alt: 24089.5  lat: 0.0627  lon: 101.6080   [NO]
 (0x893753FD)  [ 5950]  00:39:54  alt: 24094.4  lat: 2.6842  lon: 101.6079   [NO]
 (0x893753FD)  [ 5951]  00:39:55  alt: 24100.9  lat: 2.6843  lon: 101.6077   [OK]
 (0x893753FD)  [ 5952]  00:39:56  alt: 24107.2  lat: 2.6843  lon: 101.6076   [OK]
 (0x893753FD)  [ 5956]  00:40:00  alt: 24130.9  lat: 2.6846  lon: 101.6068   [OK]
 (0x893753FD)  [ 5957]  00:40:01  alt: 24137.5  lat: 2.6847  lon: 101.6066   [OK]
 (0x893753FD)  [ 5958]  00:40:02  alt: 24143.1  lat: 2.6847  lon: 101.6064   [OK]
...

So for live decoding that would be

rtl_fm -M fm -s 64k -f 401.1M -d 1 | sox -t raw -r 64k -e s -b 16 -c 1 - -r 48000 -t wav - lowpass 4000 2>/dev/null | ./weathex_decoder -b

Probably it can be tweaked a little more, but rtl_fm is a lightweight demodulator, the IF lowpass filter is rather simple, so the FM output for digital processing might not be as good as the one from sdrsharp I guess.

from rs.

[OK]/[NO] is the checksum check. [NO] indicates a checksum error.
Yes, weak signals will have more bit errors.
Since rtl_fm needs rtl-sdr data stream, it would be difficult to compare to sdrsharp. Either you split the incoming antenna signal or you could make an baseband IQ recording and manipulate rtl_fm to except an IQ recording as input.

from rs.

Yes, that is the correct serial number, I think it is manufacturing date + 4 digit running number.

(0x89375820) [ 7173] 01:44:19 alt: 1155.6 lat: 2.6801 lon: 101.2480 [OK]

The above serial number = 2302105632. My friend who has one of the recovered unit will send me the recording and the pics. I will update this here.

from rs.

I've uploaded the wav file produced by one of the radiosonde (recorded and uploaded by 9W2RUT/Weerut) with the photo of the transmitter and available in the following folder:
https://drive.google.com/file/d/1bIe-rtMmwmsGbreBT0A1lIp6JxrZm-X6/view?usp=sharing

The link shows the picture with SN:2302105671, do you have the link to the folder?

Sorry, my bad. I thought I was sharing a folder. Here it is again.

https://drive.google.com/drive/folders/1oSpRXeGuZl2me88LejJ0Ku8h-Q8GnMMP?usp=sharing

This is from recovered sonde where Weerut turn it on just to capture the transmission.

The recording from 2023-07-27 has SN:2302104573, so it is a different sonde, right?

Yes, totally different sonde. The recording above before we recover any sondes.

Another question, the IQ recordings in https://drive.google.com/drive/folders/1snChoyRlFxEk9rMcO7fuqf-TK0BBeWw- have only the recording (local) time in the filename. Is the date (Aug 7, 2023) the date of the recording? Is it possible for you to receive a WxR just before 00Z, and record maybe from 23:59Z to 00:01Z? (FM audio would be ok). Don't know if it is high enough. At 00:11:20Z it was at 11136m altitude.

My house is quite a distance from the launch site, so I couldn't get the initial transmission. However, I'll ask my friend who live nearby the launch site and they could probably capture the initial transmission. Will update you again hopefully with tonight if it is okay for you, that will be around 12:00Z (8PM our time)?

On the question about date, I believe it is the same date when I uploaded the file. Sorry, I've removed the files from my local storage since they're quite big.

from rs.

I don't know much about the Weathex, I think there are two variants. What decoder do you use,
https://github.com/rs1729/RS/tree/test/weathex
or uaii20220812_405400.c from
https://github.com/rs1729/RS/tree/test/uaii2022
?

If you have the FM audio output (e.g. from sdrsharp), you can decode like in this video:
https://www.youtube.com/watch?v=Uw4H-1a9n8U
or on linux/pulseaudio:

sox -t pulseaudio default -t wav - 2>/dev/null | ./weathex_decoder

With rtl_fm I'm not sure about WFM (have no WFM signal to test), assuming 64k bandwidth, maybe something like

rtl_fm -M fm -s 64k -f 405400000  | sox -t raw -r 64k -e s -b 16 -c 1 - -r 48000 -t wav - 2>/dev/null | ./weathex_decoder

if the signal is at 405400 kHz.
(and there are additional options for gain and ppm/offset)

If you don't get any output, try to save the rtl_fm output to a file and look if there is a signal:

rtl_fm -M fm -s 64k -f 405400000  | sox -t raw -r 64k -e s -b 16 -c 1 - -r 48000 test.wav

or save the raw rtl_fm output (raw 16 bit signed), but remember the sample rate (here 64k).

from rs.

Hi,

Thanks for the quick reply. Currently I am using the weathex decoder (the 1st link) and this works great. I have another script that convert the output into gpx format and load it to Viking software to display the track.

I will try the suggestions you gave above for the next sonde launch tomorrow morning. BTW, I am from Malaysia and starting early of the week, our auto_rx doesn't work anymore and trying to find another mean of tracking the sondes. We've 6 sites that do the launch daily in the morning and evening.

Regards, Mohd.

from rs.

Hi,

Couldn't seems to decode when I'm using rtl_fm + sox this morning, eventhough I can clearly hear the signal from the wav. Here is the recording from rtl_fm + sox.

rtl_fm -M fm -s 64k -f 401.1M -d 1 | sox -t raw -r 64k -e s -b 16 -c 1 - -r 48000 -t wav test.wav

https://drive.google.com/file/d/1AEk2c3xPotBubuFGHr4o-ECHhoIJmeKT/view?usp=sharing

here is recording from sdrsharp:
https://drive.google.com/file/d/1YgeEpVoEt65BAMl7pmxU0xm0E1A11AyP/view?usp=sharing

The one from sdrsharp can easily decoded with weathex decoder. For now, we're going to do this manually, your decoder really helps us. Thanks for the good work done.

from rs.

Thanks a lot, I'll test this on live feed tonight. Will update you later.

from rs.

Hi, this works great. Thanks a lot for the help. I'm going to play around with the rtl_fm, it seems with a strong signal, we can decode most of the packets but with a bit faint signal, we're getting [NO]. But, we're there! I think we can close the issue.

from rs.

@mmisnan can we get an IQ recording when one is in the air?

from rs.

@mmisnan can we get an IQ recording when one is in the air?

Hi, sure, I've uploaded the IQ recording into the following gdrive folder:

https://drive.google.com/drive/folders/1snChoyRlFxEk9rMcO7fuqf-TK0BBeWw-?usp=sharing

Let me know if you've any problem accessing the above folder.

from rs.

Hi @darksidelemm, @rs1729

As of today, we've managed to recover quite a number of WxR-301D. Will it be helpful if we send out the recovered units to you guys?

from rs.

If you could make some pictures, in particular of the labels (S/N:... DATE: ..., MODEL) etc.
And if you have recordings for these, even better.

I believe the S/N is (up to) 10 decimals? The decoder outputs the 8 hex nibbles of the 4 raw bytes.

from rs.

There is a new version
https://github.com/rs1729/RS/blob/test/weathex/weathex301d.c

Together with
https://github.com/rs1729/RS/blob/master/demod/iq_svcl/iq_dec.c
you can also decode IQ data.

E.g.

./iq_dec --FM --IFbw 64 --lpFM --wav --iq 0.0 08-11-21_401100000Hz.wav | ./weathex301d -b

or

./iq_dec --FM --IFbw 64 --lpFM --wav --iq `python -c "print float(401101000-401675998)/2400000.0"` 09-25-19_401675998Hz.wav | ./weathex301d -b

IF-bandwidth of 60k is a bit too narrow, does not give good results. For 2.4M baseband the next IF-bandwidth would be 75k, i.e. it does not decimate to 64k. I'm not sure if 64k is good enough, you could test if you record 2048k baseband or 1024k. You can also test rtl_fm with e.g. 60k, 64k and 68k. Maybe rtl_fm is fine with 64k.

from rs.

Hi @darksidelemm, @rs1729

As of today, we've managed to recover quite a number of WxR-301D. Will it be helpful if we send out the recovered units to you guys?

Yes., if you could mail one out to me that would be quite useful!
Email me at vk5qi at rfhead.net

from rs.

If you could make some pictures, in particular of the labels (S/N:... DATE: ..., MODEL) etc. And if you have recordings for these, even better.

I believe the S/N is (up to) 10 decimals? The decoder outputs the 8 hex nibbles of the 4 raw bytes.

Hi @rs1729

I've uploaded the wav file produced by one of the radiosonde (recorded and uploaded by 9W2RUT/Weerut) with the photo of the transmitter and available in the following folder:

https://drive.google.com/file/d/1bIe-rtMmwmsGbreBT0A1lIp6JxrZm-X6/view?usp=sharing

Thanks for the updated code, will update all the devices currently used to track the balloon. Will play around with the iq decoder too.

from rs.

Hi @darksidelemm, @rs1729
As of today, we've managed to recover quite a number of WxR-301D. Will it be helpful if we send out the recovered units to you guys?

Yes., if you could mail one out to me that would be quite useful! Email me at vk5qi at rfhead.net

I've contacted you via email, hopefully you can receive it within this week.

from rs.

I've uploaded the wav file produced by one of the radiosonde (recorded and uploaded by 9W2RUT/Weerut) with the photo of the transmitter and available in the following folder:

https://drive.google.com/file/d/1bIe-rtMmwmsGbreBT0A1lIp6JxrZm-X6/view?usp=sharing

The link shows the picture with SN:2302105671, do you have the link to the folder?

The recording from 2023-07-27 has SN:2302104573, so it is a different sonde, right?

Another question, the IQ recordings in
https://drive.google.com/drive/folders/1snChoyRlFxEk9rMcO7fuqf-TK0BBeWw-
have only the recording (local) time in the filename. Is the date (Aug 7, 2023) the date of the recording?
Is it possible for you to receive a WxR just before 00Z, and record maybe from 23:59Z to 00:01Z? (FM audio would be ok). Don't know if it is high enough. At 00:11:20Z it was at 11136m altitude.

from rs.

Thanks for the recording and picture.

12Z is not so interesting, I'm more interested in the datetime wrap-around at 00Z, I guess that would be 8 AM local?
There is no hurry, whenever it suits.

EDIT:
I see there are more pictures and infos:
https://groups.google.com/g/radiosonde_auto_rx/c/TrSU9nBn1C8

from rs.

Thanks for the recording and picture.

12Z is not so interesting, I'm more interested in the datetime wrap-around at 00Z, I guess that would be 8 AM local? There is no hurry, whenever it suits.

Sure, will try to have someone recording it tomorrow and will share again.

from rs.

Thanks for the recording and picture.

12Z is not so interesting, I'm more interested in the datetime wrap-around at 00Z, I guess that would be 8 AM local? There is no hurry, whenever it suits.

EDIT: I see there are more pictures and infos: https://groups.google.com/g/radiosonde_auto_rx/c/TrSU9nBn1C8

My friend Weerut managed to do recording today at around 00Z. File as per in folder:

https://drive.google.com/drive/folders/1oSpRXeGuZl2me88LejJ0Ku8h-Q8GnMMP?usp=sharing

or direct file link:

https://drive.google.com/file/d/18z-cdHZa99_uURawhelSJrTCfV12FKcs/view?usp=drive_link

Hope the above helps.

from rs.

Thanks!

from rs.

Probably shouldn't close this just yet? Still more to find out!

from rs.

Probably shouldn't close this just yet? Still more to find out!

Woppsy, sorry. Reopening back.

from rs.

I had the idea to add support for the WxR-301D temperature sensor to the code, but now I see that the latest sondes in Malaysia are different from the ones we have seen last year in Germany. At least the bit rate and sync sequence are different, 4800 bit/s now, and 5000 bit/s last year.
In the code I can see that support for the old version was once there, and is now commented out.

Can I assume that the 4800 bit/s version is the final production standard, and the versions we have seen during UAII2022 were all engineering samples?

So far I haven't yet decoded the new recordings, so I can't say if there is also a difference in the way they send PTU data...

Attached is the label of a sonde found last year near Berlin. Production date 2022.06, and the serial number is eight digits instead of ten. It's here on my desk, and happily sending at 5000 bit/s...

from rs.

I have no idea which one is newer. The S/N in Malaysia seems to have a bit more information, but the WFM modulation/bandwidth is out of date for both. On the other hand I would expect the PN9 sequence in the newer version. There is a small difference in bitrate and also an offset-difference (or difference in subheader for the two subframe) in the data, but there is not much data in the transmitted frames, positional data seems to be the same.

The main reason for two decoders was the different bitrate.
Don't know why the call both "WxR-301D".

from rs.

It would be interesting to see if there are any hardware changes in the new version as well. The version flown during the intercomparison had quite an excessive BOM and did not seem well optimized for large scale manufacturing...

from rs.

I'll have one in the post soon, I'll take plenty of pictures.

from rs.