Radiosonde Support - Meteolabor SRS-C50

[hb9eue]

Hi, nice project!

Lot's of C50 sondes flying by my home. I see there is code to decode the CSC50 sondes within the c34 directory, but it is not used and I have not managed to figure out how to include this.
But I see that those sondes are being decoded by other receivers, probably using https://github.com/oe5hpm/dxlAPRS

So is there a simple way to incluse C50 decoding?

-Benoit-

[darksidelemm]

Not simply, no.
I don't think @rs1729 has spent much effort on the C50 decoder. It appears to use 2400 baud AFSK, so it doesn't really fit in with his other combined decoder effort (which is performing really well!). This also means the decoder performance is going to be a lot worse than with the other sondes that use 'straight' FSK (RS92, RS41, etc...)

I know that the sonde detector (dft_detect) can detect them, but it's currently turned off to save CPU time.

Do you know where C50 sondes are commonly launched from?

[hb9eue]

Yes, as far as I can tell they seem to get launched from Payerne, Switzerland.
http://radiosonde.eu/RS00-D/RS03B05-D.html
Right now on it's way: https://www.aprsdirect.com/details/main/sid/2236249 and a couple of others drifted past all over the day.

[darksidelemm]

OK. Well yes, it looks like dxlAPRS supports them. I had a bit of a look trying to figure out how they are calculating an ID from the telemetry (as it doesn't appear to contain a serial number, kind of like the iMet sondes), but the dxlAPRS codebase is extremely difficult to read. If you have more information on what's going on, that would help...

I'll leave this issue open as a place to put more information on this sonde type.

[rs1729]

I don't think @rs1729 has spent much effort on the C50 decoder.

Yes, that's right.
C50 is similar to C34, but its output power is much lower, difficult to get a good signal, in particular since it is AFSK.
Also the C34 was used much more frequently, and then they used the RS41 more and more, so it looked like they go with RS41 instead and use the C50 only with special instruments.

The C50-data comes in smaller packets, so with a weak signal you have the same problems as with DFM if you collect the data that belong together.

Maybe you can make C50 optional, for users that know they can receive the C50.

[rs1729]

Added json-output to c50dft.c.
The decoder performance is rather poor, so in order to get complete frames, a strong signal is needed.
dft_detect does not differentiate between C34 and C50, but since there is a little difference in the idle time between bytes, the c50-decoder should only decode C50, hopefully, otherwise the NMEA-coordinates go wrong.

I don't have much audio recordings, even less good recordings of strong signals (only 1), so I don't know much about other pck_id's. I think the lower id's are PTU data in a float-format?! And 0x6_ could be the aux-instruments. But I don't know if there is something useful for sonde_id or frame_count.
With fewer different packets it is easier to get a complete json-frame anyway.

@darksidelemm:
Since the humidity is not as accurate as temperature, maybe the humidy-output on sondehub could be integers between 0 and 100. For temperature the units are °C, should relative humidity be in "%"?
And did you read rs1729/RS#7 (comment) ?
Don't know if Viproz is still active.
As far as I know customers can use the Airprime GPS with custom sentences, and it looks like the new M10 pulls similar informations from the X1110 to produce a trimble-compatible output. In the firmware you can even find the week rollover calculation...

[darksidelemm]

@hb9eue Could you perhaps provide a longer recording from a flight? This would help!

@rs1729 It's probably possible. It would be simple to just round it to an integer before uploading... Will have a look at that.

[hb9eue]

I'll try to record one (i/q data I suppose) when I manage to catch another one flying by.
I have just started using auto_rx a couple of days ago so I don't know yet how frequently they fly by.

[darksidelemm]

FM demodulated signals are OK for this purpose. auto_rx won't indicate detection of C50 sondes at the moment. I could probably add that to the testing branch, but will need to check the impact on CPU time.

…

On Fri., 10 May 2019, 18:47 hb9eue, ***@***.***> wrote: I'll try to record one (i/q data I suppose) when I manage to catch another one flying by. I have just started using auto_rx a couple of days ago so I don't know yet how frequently they fly by. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#170 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH57E4ATAQWTCDFMFEUEEDPUU4UJANCNFSM4HLQ3JGQ> .

[pit711]

I'll try to record one (i/q data I suppose) when I manage to catch another one flying by.
I have just started using auto_rx a couple of days ago so I don't know yet how frequently they fly by.

you can check here how often we have decode, just chose SRS-C50 from the list left side
https://radiosondy.info/adv_search.php

[darksidelemm]

Hi @pit711 , do you know how the other sonde decoders generate a callsign from the C50 sonde telemetry? I've tried to figure this out from the dxlAPRS code but came up short...

[einergehtnochrein]

do you know how the other sonde decoders generate a callsign from the C50 sonde telemetry?

C50 sends individual data frames of seven bytes length, preceded by two bytes of preamble (00 FF). First byte is the frame ID, the next four bytes contain the payload, followed by two bytes of checksum. Depending on the ID, the 32-bit payload must be interpreted as either an integer or a single precision float, both in big endian format.

ID=100 (0x64): This is the serial number. A C50 labeled "2937" sends "0x00000B79". I think it is the dxlAPRS decoder that prints this as "SC500B79". The real number is decimal though!

Some other ID codes:
ID=2: Temperature [float, °C] of the reference point of the thermocouples (resistive thermometer)
ID=3: THE Temperature [float, °C] (thermocouple)
ID=4: Temperature [float, °C] near humidity sensor (thermocouple)
ID=5: Temperature [float, °C] measured in an air duct at the top of the sonde housing (thermocouple)
ID=6: Temperature [float, °C] of the air intake of an ozone sonde
... tired of typing :-)

[pit711]

btw, i recorded a C50 last week, maybe useful wav audio file to play

SRSC50.zip

[darksidelemm]

Thanks for the information!

[rs1729]

Somewhere I read that the instruments on the radiosonde also have their serial numbers in the ID=0x6y range? (and there are other ID=0x6y in the sample above)
So ID=0x64 is the serial number of the radiosonde?
In the SRCSC50.zip sample it would be 2468!?
Then I would add this to the json-output, e.g.

( 2468 ) 2019-07-18 11:11:50 lat: 47.16974 lon: 9.10421 alt: 24984.2 # 00000
{ "id": "C50-2468", "datetime": "2019-07-18T11:11:50Z", "lat": 47.16974, "lon": 9.10421, "alt": 24984.2 }

The 0x64 is not transmitted every second, I guess that's only a problem if there would be another C50 on the same frequency.

UPDATE:
So 2468=0x09A4:
https://radiosondy.info/sonde_archive.php?sondenumber=SC5009A4

[einergehtnochrein]

Correct, the C50 in the wav file has serial number 2468.

There is an NFC device in the C50 with a 256-byte NDEF file. Several ID codes are used to transmit constants fro that file, one of them being the 16-bit serial number. The other ID codes I know of are (to the best of my knowledge):

ID=0,1: Voltage at terminals CU,R2 (float, µV), see schematic
ID=2: Temperature [float, °C] of the reference point of the thermocouples (resistive thermometer)
ID=3: THE Temperature [float, °C] (thermocouple)
ID=4: Temperature [float, °C] near humidity sensor (thermocouple)
ID=5: Temperature [float, °C] measured in an air duct at the top of the sonde housing (thermocouple)
ID=6: Temperature [float, °C] of the air intake of an ozone sonde
ID=7: Cell current of the ECC ozone sonde (not sure...)
ID=16: relative humidity (float, percent)
ID=17: Indicator for humidity sensor heating (float!), 0=off, 1=on
ID=18: Oscillator frequency of the 555 (yeah, still alive!) on the sensor boom (float, Hz)
ID=20: GPS date
ID=21: GPS time
ID=22: GPS latitude (int)
ID=23: GPS longitude (int)
ID=24: GPS altitude (int, 0.1m) above geoid
ID=27: GPS HDOP and sats (int), value is 10000 * HDOP + #satellites (with HDOP rounded to two decimal places)
ID=60: Data from external device via UART. Can only appear for sonde type 229, but has never been used in a "normal" ozone sonde.
ID=100: Serial number, 16 bits
ID=102: Sonde type (228=C50, 229=C50+AUX). Can't find the list of C34 type codes, but I have them somewhere...
ID=103,104,105,106: 16-bit constants from NDEF file, but no idea what they mean
ID=107: Very likely the firmware version of the MSP430 which sits on the sensor boom.
ID=108: Firmware version of the main processor (TM4C1230E6)
ID=110: Battery voltage (int, millivolts)
ID=111: RF detector voltage (int, millivolts). This is a simple diode peak detector near the antenna connector.
ID=115: State machine (enum, 8 bits): 6=start preparation, 7=in flight (ascending), 8=in flight (descending), 9=just landed (transitional state), 10=landed
ID=116: Error status bits (bit field, 32 bits, bit set when condition exists): Bit0=No GPS fix, Bit1=Format error in message from GPS module, Bit2=CRC error in message from GPS module, Bit5=Lost a TX frame due to TX queue full, Bit6=Lost a TX frame due to access conflict to TX queue, Bit7=Battery voltage below 2.5V, Bit8=Error writing to EEPROM. Bit13=I2C communication error between main CPU and sensor boom (MSP430)
ID=119: GPS VDOP (int). Value transmitted is 100*VDOP, so you get two decimal places.

[rs1729]

Yes, I have seen somewhere that there are a lot of temperature values...
I was looking for a good recording to see if there is velocity data, but still can't see it...

OK, added serial number to (json-)output in c50dft.c

The C50 is difficult to receive, low power. @darksidelemm would probably want to have a nice IQ-recording. Though detection should be similar to imet4. However, if more radiosonde types are to be detected, it is easier to get false positives. So maybe C50 should be optional for users close to Switzerland.
The meisei-radiosondes get detected as imets... The imet4 needs a header and a serial number.

[rs1729]

Temperature is no problem, would go with id=0x3, but for relative humidity, I have never seen something different from (exact) 0.0%. All my samples are above 18km, so it should be somewhere close to zero. Probably it is set to zero at a certain point?
Does someone have recordings from below 10km?

@einergehtnochrein
about the serial number, 16 bit doesn't sound like much space for serial numbers. Is it in the firmware that way? Could the upper 16 bit be used for something else?

[einergehtnochrein]

about the serial number, 16 bit doesn't sound like much space for serial numbers. Is it in the firmware that way? Could the upper 16 bit be used for something else?

Indeed a very limited range of possible serial numbers, but this is how they chose to implement it. The EEPROM with the configuration data uses a 16-bit field for the serial number, and when it is transmitted, the upper 16 bits are filled with zeroes.

I've never recorded the audio of a C50 flight, but I have a couple of log files of the decoded frames. For testing my receiver I recreate the audio from such log files, and I have put one of these files (~100 MiB) here:
https://transferxl.com/08vvFQYFn5dSL4
(The link is valid for 7 days only)

This is the final descent part of a C50+O3. It landed in a swamp, we had a lot of snow, it was getting dark, and I almost failed to find my way back out...

[rs1729]

Thanks!
I think the reconstructed audio is more like C34 where there is a bit of idle between lead_out and next lead_in.
The Payerne sounding
http://weather.uwyo.edu/cgi-bin/sounding?region=europe&TYPE=TEXT%3ALIST&YEAR=2017&MONTH=12&FROM=1212&TO=1212&STNM=06610
looks similar, the data on the way down should be a bit different anyway.
Very dry above 6800m. Your recording shows increased humidity around 6000m, maybe the response time on the way down at -40C. And it doesn't crop above 100% (later on the ground).
The published sounding data shows rel.hum. 1% - 3% between 8-30km, always > 0. Above 35km it goes up to 10%, probably not reliable.

So maybe id=16 is only approximate and they calculate the humidity with 555-freq and the different temperatures and consider response time etc.

Will add temperature and humidity to the decoder (--ptu option).

16bit-SN could be enough, since the C50 is only used by a few stations, I think not even on a daily basis, Payerne has also the RS41.

[darksidelemm]

How many stations fly these sondes?

I'll have to look into how much time it adds to the detect step.

[rs1729]

As far as I know:
Only Payerne. And occasionly 1 or 2 other stations in Switzerland, Wetzikon?
Maybe Lindenberg will use it for special soundings, like they did with C34?

[einergehtnochrein]

I think the reconstructed audio is more like C34 where there is a bit of idle between lead_out and next lead_in.

Correct, the tool was originally done for C34, so uses an inter-byte space slightly different from C50.

And it doesn't crop above 100%

Yes, from firmware analysis I found the value range is 0...110 !

So maybe id=16 is only approximate and they calculate the humidity with 555-freq and the different temperatures and consider response time etc.

Very well possible. The C50 spends quite some effort to come up with the final temperature values, but maybe humidity requires post-processing only the receiver station can do.

16bit-SN could be enough, since the C50 is only used by a few stations, I think not even on a daily basis, Payerne has also the RS41.

The times of the C50 in Payerne are over before they really began:
https://www.gruan.org/gruan/editor/documents/meetings/icm-10/doc/doc_715_SiteReport_PAY_2017.pdf

There was a bunch of C50's launched by probably the Swiss army in May, sometimes six or more a day. Often they would launch another one on the same frequency when the previous sonde was still in the air. It was difficult to catch them...

Other occasional launch sites are Wetzikon (home of the manufacturer Meteolabor) and some place near Wil where the university ETH maintains an educational facility.

[capriole86]

Hello Sonde Hunting Friends :)
Since some months I am into this and totally hoocked. I am so speechless about all the tools and platforms that are available and made in spare time. So I want to say thank you all and see, where I can contribute my part. Therefor I get in touch with you now.

I am more interestet in Hunting the sonds and therefor get more/longer information about theyr Position.

So fare I found just RS41 er sondes solo and with Ozon Pump. Recently I saw on radiosondy.info that there are some SRS-C50 Sondes detected. But as just some German Receavers are decoding and uploading them there is not that much Information available about the Positions. And so far I did not managed to to Recieve and decode one of the sonds by my selfe.

How do I actibate the srs-c50 sonde detection/decoding in my auto-rx? Or what kind of System can or should I use to do so?

Thank you for your Support and all the best
:)

[darksidelemm]

It's not as simple as 'activating' support. It needs to be thoroughly tested before being enabled.
So far support hasn't been added because of the relatively small number of these sondes launched.

[gmke]

currently there are two sondes flying with start place Frauenfeld (CH).

[gmke]

again two sondes flying out of Frauenfeld. I can see them clearly in my spectrum but no decode.