Radiosonde Support - Lockheed Martin LMS6

[darksidelemm]

This is a tracking issue for adding support for the Lockheed Martin LMS6 radiosonde.

There is support in the upstream RS repo for detection and decoding the LMS6, however the following should be noted:

• The 400 MHz LMS6 sonde is known to drift fairly considerably, which will impact detection and decode performance.
• It is unknown of the bandwidth of the 1680 MHz version of the LMS6 is different to that of the 400 MHz version. Also unknown is now much it drifts. IQ recordings of one of these in the wild would be useful.

[rs1729]

I think the LMS6 (1680MHz) has the same modulation and coding as the Mk2a. Here https://www.youtube.com/watch?v=-0Ydq9Ole48 in the comments-section "devnulling" had a recording (not available on dropbox anymore). Bandwidth approx 175 kHz Perhaps he can provided more IQ-recordings.

[darksidelemm]

Ouch. 175 kHz bandwidth will make a common detection step very difficult.

[darksidelemm]

I can confirm that the 1680 MHz telemetry is the same as the MK2A, and is at 9600 baud. I've got a FM demodulated sample here: https://rfhead.net/sondes/samples/lms6_1680.wav This can be decoded using: cat lms6_1680.wav | ./mk2a -i

Not sure how to proceed from here. Does the MK2A telemetry include a unique ID we can use? Can a MK2A detector be included in dft_detect?

[rs1729]

Do you know the serial number of your sample?

I have seen serial numbers of LMS6-403 and it is easy to find in the data. This LMS6 should be easy to include.

But I don't know much about the 1680MHz-version. The two bytes before the counter seem constant but a bit short for a serial number, maybe not unique anyway. The end of the (2452)4D-subframe is repeating every 16 frames in which every frame is sent twice. Someone told me it is config-data including the serial number. But I don't have enough information to compare.

I have a dft-version for testing, though some samples don't work well with the -b option (which is the default for dft), timing or baud rate may be unstable and problematic.

[rs1729]

Added Mk2a/LMS6-1680 to dft_detect tip: use ./mk2a with option --crc

[darksidelemm]

The sample was e-mailed to me - I'll ask about the serial number.

I've also had big problems decoding using fsk_demod too, so yes, I think there's something odd with the symbol rate timing.

[rs1729]

Most of the recordings have 9616 baud similar to M10, everything fine. One of the recordings has some bits that are kind of too short, but I don't think it is at lead-in/out. Don't know how it was recorded.

[darksidelemm]

My guess is 9616 baud is a result of some division from the source clock.

Anyway, according to the guy that recorded that sample: sonde id: 7108232 serial: 88012452

hex(7108232) '0x6c7688'

Packet contents of: 24 52 4d 31 **76 88** 00 b5 00 39 0d 03 ba 28 19 f2 5b 03 bb 30 09 fa ac 1f fc a1 0d bb 29 1d fc a4 11 f5 54 03 ba 2a 03 ba 15 03 ba 29 03 ba 1d 00 00 00 33 99 d0 96 1f 26 26 ee 55 82 07 ff 1f 88 26 ee 01 3a ac 24 52 54 31 **76 88** 00 b5 00 61 14 bd 2c 6d ff e1 d7 d2 15 87 9f 51 ba 47 a4 82 00 05 21 56 00 02 7c 00 00 f8 ff ff 5c 00 38 05 02 21 0f 14 00 84 4d 02 15 1c f0 54 46 05 21 0f 14 00 7c ab 61 38 1c e9 ba 5a 1d 1e 0f 14 00 90 65 26 58 1c e5 57 13 0c 1f 0f 14 00 7d ac 42 0e 1c ef 7a 96 19 21 0f 14 00 86 fa 97 3c 1c e8 c1 d4 31 af

So it does look like those 2 bytes you identified are from the sonde ID. The lower 2 bytes of the ID. Can't find any of the other numbers in the packet.

Those 2 bytes are probably enough for a unique ID, at least for the number of sondes we might expect to be in the air at any one time. At least it's something to start with!

[rs1729]

Yes, the last two bytes are there, and the full ID is in one of the 8/16 config-subblocks at the end, the 2 least significant bytes followed by 2 most significant bytes. Maybe the two bytes at the beginning were the ID of the Mk2a. I believe the config-blocks are new to the lms6-1680, which could have longer IDs, and maybe for compatibility reasons they didn't change/extend the old ID-field.

24 52 4d 31 **76 88** 00 78 00 39 0d 03 ba 4b 19 f2 0f 03 bb 3a 09 fa 87 1f fc 3f 0d bb 01 1d fc d0 11 f5 a7 03 ba 61 03 ba 5f 03 ba 82 03 ba 7b 19 f8 62 **76 88 00 6c** 00 0d 6a 07 79 13 71 5d 9a cb 42 38 01 11 bf [OK]

The lms6-403 has a new encoding, frame data is still similar, but this could have been the opportunity to make some changes.

[rs1729]

I believe I have only one recording of a Mk2a and it is very short, only a few frames, but it looks like it also has the full ID in the same range (7e6). Perhaps the legacy goes even further back, else why wouldn't they put the upper 1-2 bytes in front? (Or maybe it is actually a lms6-1680...) For differentiating radiosondes on the same day or week, the lower 16 bit should be unique, but for a radiosonde-archive it is a bit short. (i think the dxlaprs-m10-sn-"hash" had some issues... why make it shorter anyway?)

Ok, I made a new version with ID-output (option -v): mk2a_lms1680.c As long as the ID is only 16 bit, the output is hex. And it has json-output, though only frames with full ID and of course crc-OK are allowed. So if frames are ok, every frame is output twice, that does not require book keeping. I hope that's ok?!

[darksidelemm]

The JSON output looks good! I'll have to do some twiddling with the time to produce a full date from just the HH:MM:SS, but i've already got a way of doing that from the iMet sondes (just adding on the current date is unsafe around 0000Z). The repeated frames are probably going to cause problems unfortunately, so probably best to inhibit outputting the data if the frame number is the same as the previous outputted frame.

I'm going to figure out how to integrate this into auto_rx at least in a manually-initiated sense, as I suspect I'm going to have to make a lot of changes to peak detection for it to work on these 1680 MHz sondes (plus that's a massive pain to test without having a few sondes available). Given the transmit frequencies seem to be fairly consistent for each launch site (1676 MHz or 1680 MHz), just using the auto_rx whitelist function might be good enough. Doing this will then allow the US guys to have a play!

[darksidelemm]

Oh and the reason behind the shorter 'dxlaprs' callsign for the M10 (and the DFMs to some extent) is for output into APRS, where there is a maximum callsign length of 9 characters. Given you need to also fit some identifying information about what the sonde type is in the callsign, that limits things even further! In the case of these LMS6s, i'll probably have to use something like: LMS6XXXXX where XXXXX are the lower 5 nibbles of the ID.

[rs1729]

ok, json output now only if frame number increases/changes (or sonde_id). assuming the decoder is not receiving two lms-sondes in parallel.

(aprs: still there are hash functions producing more random output (if full input is given). anyway, please, no aprs-callsign algorithms in the decoder.)

[rs1729]

Don't know if the gps week is in the config data, however if it is not transmitted every frame, it is not so helpful.

I guess it would be easier for you, if the gps tow (time of week) or the day of week is included in json. If you have a good field name, e.g. "weekday": 0..6 ?

[darksidelemm]

I can work with just the time OK. Already solved the problem for the iMets, so that can be applied to the mk2a telemetry.

I've done a preliminary implementation, but I'm away for a week or so can't do much testing.

On Tue., 28 May 2019, 19:07 rs1729, notifications@github.com wrote:

Don't know if the gps week is in the config data, however if it is not transmitted every frame, it is not so helpful.

I guess it would be easier for you, if the gps tow (time of week) or the day of week is included in json. If you have a good field name, e.g. "weekday": 0..6 ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/projecthorus/radiosonde_auto_rx/issues/151?email_source=notifications&email_token=AAH57E7IZ3Q7Y7PBGT5S2QLPXTY5JA5CNFSM4HATQDKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWLPD3Y#issuecomment-496431599, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH57E7W2PQVWFMN2T5MKD3PXTY5JANCNFSM4HATQDKA .

[darksidelemm]

Initial MK2A support has now been added in the testing branch as of https://github.com/projecthorus/radiosonde_auto_rx/pull/187

I can't really optimise the peak detection stuff for 1680 MHz sondes without having one unfortunately. I suspect widening the search step will work OK, but I'm not sure by how much.

[rs1729]

Oh and the reason behind the shorter 'dxlaprs' callsign for the M10 (and the DFMs to some extent) is for output into APRS, where there is a maximum callsign length of 9 characters.

If you prefix "ME" for M10, you still have 7 characters. Year+Month are in one byte, 1 nibble each, i.e. 2 characters. Then there is the '2'. Then there are 5 digits serial number in 1+17 bits. Don't know what will hapen in year 2020, the serial number might be unique modulo 10 years. But if you discard the middle '2', you could even represent the actual serial number without bit mangling, only the year has to be represented in hex.

But you are right, the code is no fun to read, from time to time there are strangely familiar names, constansts or expressions, or everything is base 10..., but for the aprs-names it might be easier to analyze the result as in the case of dfm...

LMS6: We talked about gps tow before. I want to include an option to provide the gps-week manually, then the full date could be calculated. (Maybe I look through the config-data again, maybe it is hidden somewhere like the full ID in the 1680-case.)

[darksidelemm]

Good idea on the M10 serial number... I'll have a look into how I can do this on the python side.

I don't mind if you add a TOW option, but I'd be worried about it breaking across week boundaries. At the moment I can handle being supplied just HH:MM:SS pretty well, as I assume the data is 'live' and apply the current UTC date. I do have to be careful with times around 00:00Z (i.e. if the payload telemetry is 00:00:xx and the system time is 23:59:xx), but I've already got algorithms to deal with this this for the iMet sondes, and that applies well to the LMS6.

[rs1729]

I considered 2 situations for week-rollover, when gpstime < time_elapsed_since_startup ( "first fix" could occur after week rollover) and gpstime < gpstime_start, where gpstime_start is the first gpstime with valid crc. If you don't need this for json, I can pospone more testing...

Perhaps a field "gpstow" is the cleaner solution for json-output , then you can calculate the date later, just need the current gps-week. ~~Maybe gpstow/seconds is enough (not milliseconds)? (truncated, not rounded)~~ In milliseconds.

[rs1729]

M10: Example data 310 2 11329: .. 02 08 3a 31 25 .. 3 a -> 2013/10 (year/month) 0x2531 & 0x1FFFF = 1329 0x2531 >> 13 = 1 0x2531 -> 01 0010100110001 -> 1 1329 The essential data is in the last 3 bytes, the last 2 belong together: 31 25: 0x2531. Will see if there will be something new next year. The M10gtop I know had a "2" at ">>13".

[rs1729]

... I assume the data is 'live' and apply the current UTC date. I do have to be careful with times around 00:00Z (i.e. if the payload telemetry is 00:00:xx and the system time is 23:59:xx), but I've already got algorithms to deal with this this for the iMet sondes, and that applies well to the LMS6.

Ok, the gps-time/data is some 18sec ahead UTC, but there is some latency probably until you get the data? Do you have a time-window in which the telemetry has to be submitted?

[darksidelemm]

The GPS time being ahead isn't really a big issue - the big thing is that all stations need to be uploading consistent data (i.e. same position/telemetry for a given timestamp). Packets can arrive at the server out-of-order or delayed, as long as there is consistency in the time <-> position/telemetry relationship. I don't have any problems with how this works at the moment - it's been working well for quite a while now, with many separate stations uploading telemetry for the same sonde in some cases.

[K4KDR]

>>Both the 400 MHz and 1680 MHz decode chains have not been optimised, as I don't yet have access to a high-SNR sample to experiment with

Hello! Saw the above comment in your post today ref. Release v1.1.3.

I've tracked a good number of 400 MHz LMS-6's here in the U.S. and recovered a couple. Lots of fun plotting the track on Google Earth:

https://twitter.com/scott23192/status/841468153561518080

Glad to send you a recording; is audio ok or would an IQ .wav be more helpful?

-Scott, K4KDR

[darksidelemm]

Hi Scott,

400 MHz sondes are actually working pretty well - I'm using the fsk_demod chain for those, and that seems to be performing pretty close to optimal as it is. It's the 1680 MHz sondes that are a challenge with their huge bandwidth (170 kHz!!) I've got one of those in the mail.

That said, being able to verify the decoder is performing as it should would still be useful. To this this, I'd suggest the following:

• Configure a SDR and a LMS6 such that the LMS6 signal is strong - as high a SNR as you can manage without overloading the SDR.
• Capture an IQ recording with a sample rate of maybe 100 kHz, for about 2-3 minutes.
• Send me that recording :-)

I'll then be able to add that to my existing set of sonde samples which I use to do PER vs Eb/N0 measurements (as was done here: https://github.com/projecthorus/radiosonde_auto_rx/blob/master/auto_rx/test/notes/2019-03-02_performance_baseline.md )

[K4KDR]

Sorry for the slow reply! Glad to get a recording to you but I just saw your tweet ref. having an LMS-6 in hand. So, are you good on being able to create a sample LMS-6 recording on your own now or should I put one together when possible? Thanks! -Scott

[darksidelemm]

I only have a 1680 MHz LMS6, so a recording from a 400 MHz version would be great!

On Tue., 9 Jul. 2019, 09:29 K4KDR, notifications@github.com wrote:

Sorry for the slow reply! Glad to get a recording to you but I just saw your tweet ref. having an LMS-6 in hand. So, are you good on being able to create a sample LMS-6 recording on your own now or should I put one together when possible? Thanks! -Scott

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/projecthorus/radiosonde_auto_rx/issues/151?email_source=notifications&email_token=AAH57E3PRWN7D6A5LAWV5CLP6PIE7A5CNFSM4HATQDKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZOV42Y#issuecomment-509435499, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH57E333B23HU7GGDPLY6DP6PIE7ANCNFSM4HATQDKA .

[K4KDR]

Ahh, very good. Didn't know from that twitter pic. I'll be glad to get a file to you.

[K4KDR]

Please let me know if the file linked to below is useful. To reduce upload size (limited internet speed here) it's the "IF" version of the IQ .wav recording from HDSDR. So, only the 15k of selected RF bandwidth is in the recording, not the entire spectrum. I manually adjusted levels, etc., to not overwhelm the SDR with a signal from the other room, so please let me know if the resulting +/- 25db SNR is of use to you. Looks like a pretty clean waveform to me. Sample rate is 250KHz; I'm not setup to go as low as 100KHz. Please let me know if I can do anything else to assist! Here is the URL:

https://www.qsl.net/k/k4kdr//iq/lms6/HDSDR_20190710_021401Z_401011kHz_IF.wav

[darksidelemm]

Yep, that file works well! I've been able to produce a Packet Error Rate (PER) curve using that file, and my existing testing scripts: https://rfhead.net/sondes/plots/fsk_demod_lms6-400.png

You can see that the decode chain performs about the same as the RS41 decode chain. Maybe 0.5-1dB lower performance, but that could be from many things. Still, I'd say that's good enough for now, and it's not worth spending much time on further optimization!

Thanks for the help!

[K4KDR]

Great! Glad that was helpful.

[darksidelemm]

I was also able to get some high-SNR samples of a 1680 MHz LMS6, thanks to a donation from a radiosonde hunter in the US. Due to the wide signal bandwidth, the recording has to be correspondingly high (in this case, I'm using a 500 kHz sample rate).

As expected, decode performance is worse - almost exactly as expected due to the increased noise bandwidth due to the wider signal (170 kHz vs 10 kHz, which equals about a 12dB degradation in performance): https://rfhead.net/sondes/plots/per_lms6.png

I haven't yet managed to get fsk_demod working with this signal yet - something to do with the high oversampling rate I'm using (~52x), and how the frequency estimator is operating. Still trying a few things, so I might be able to get it working eventually, but for now the FM demodulation is working.

[rs1729]

Do yo have the L-band IQ-samples for download/testing?

[darksidelemm]

Yep! It's available here: https://rfhead.net/sondes/samples/lms6-1680_500k_float.bin

Note: 500 kHz sample rate, floating-point samples, with the signal centred at roughly 0 Hz. These can be converted to complex signed-16-bit using csdr by running:

$ cat lms6-1680_500k_float.bin | csdr convert_f_s16 > out_file.bin

I've been able to run these through Viproz's 'hacked' version of rtlfm ( https://github.com/Viproz/rtl-sdr - allows for data to be provided via stdin) using the command:

$ cat lms6-1680_500k_float.bin | csdr convert_f_s16 | ./tsrc - - 3.2000 | csdr convert_s16_f | csdr shift_addition_cc -0.25000 2>/dev/null | csdr convert_f_u8 | ./rtl_fm_stdin -M fm -f 401000000 -F9 -s 200000  2>/dev/null| sox -t raw -r 200000 -e s -b 16 -c 1 - -r 48000 -b 8 -t wav - highpass 20 2>/dev/null |../mk2a_lms1680 --json

Note that i'm running this from within the auto_rx/test directory, with all the various binaries built previous using the auto_rx/build.sh script. I've also put the hacked rtl_fm binary into the auto_rx/test/ directory as rtl_fm_stdin. There's a lot of resampling, type conversion and shifting going on to get the signal at the right frequency, and at the right sample rate for rtl_fm to be happy.

[darksidelemm]

Closing this now that support seems fairly stable.