Closed darksidelemm closed 5 years ago
Here is a clear IQ-recording of RS92-NGP from North America, no PTU sensor, GPS not fixed, just powered on. https://www.file-upload.net/en/download-13555747/gqrx_20190331_151637_1675998330_93750_fc.raw.html The frequency in 0x00 is offset 160000(0). The modulation index is approx 4.5 times the mod.index of RS92-SGP, and so the bandwidth. Looks a bit like everything is scaled by 1680/400.
Updated rs92mod.c, for L-band use option --ngp.
And here a weak signal at 1680 MHz https://www.file-upload.net/en/download-13548601/gqrx_20180216_130150_1679999000_93750_fc.raw.html With almanac some OK-frames: [ 8947] (N1213084) (2018-02-16) Fri 13:02:58.360 lat: 43.3378 lon: -78.7580 alt: 12463.2 (d:2.3) vH: 80.0 D: 86.1° vV: -7.4 # [0000] [ 8955] (N1213084) (2018-02-16) Fri 13:03:06.360 lat: 43.3382 lon: -78.7501 alt: 12413.4 (d:2.3) vH: 81.8 D: 85.7° vV: -6.7 # [0000] [ 8958] (N1213084) (2018-02-16) Fri 13:03:09.360 lat: 43.3383 lon: -78.7471 alt: 12393.8 (d:2.3) vH: 80.6 D: 85.5° vV: -6.6 # [0000] [ 8960] (N1213084) (2018-02-16) Fri 13:03:11.360 lat: 43.3385 lon: -78.7451 alt: 12382.2 (d:2.3) vH: 80.7 D: 85.6° vV: -6.2 # [0000]: fq 1680000 [ 8965] (N1213084) (2018-02-16) Fri 13:03:16.360 lat: 43.3383 lon: -78.7406 alt: 12478.9 (d:2.9) vH: 80.6 D: 85.6° vV: -6.4 # [0000] [ 8966] (N1213084) (2018-02-16) Fri 13:03:17.360 lat: 43.3384 lon: -78.7397 alt: 12473.0 (d:2.9) vH: 80.6 D: 85.5° vV: -6.3 # [0000] [ 8967] (N1213084) (2018-02-16) Fri 13:03:18.360 lat: 43.3385 lon: -78.7387 alt: 12466.9 (d:2.9) vH: 80.7 D: 85.4° vV: -5.6 # [0000] [ 8968] (N1213084) (2018-02-16) Fri 13:03:19.360 lat: 43.3385 lon: -78.7377 alt: 12459.9 (d:2.9) vH: 81.2 D: 85.6° vV: -6.4 # [0000] [ 8969] (N1213084) (2018-02-16) Fri 13:03:20.360 lat: 43.3386 lon: -78.7367 alt: 12455.3 (d:2.9) vH: 81.3 D: 85.6° vV: -6.0 # [0000] [ 8971] (N1213084) (2018-02-16) Fri 13:03:22.360 lat: 43.3387 lon: -78.7347 alt: 12442.6 (d:2.9) vH: 81.1 D: 85.5° vV: -6.0 # [0000]
Support for RS92-NGP sondes now seems to be working OK, at least when using a whitelist of channels. Closing this issue.
Have seen two L-band RS92 from San Diego on sondehub! For the decoder-command, do you make a difference between 400MHz and 1680MHz RS92? There is the "--ngp" option to calculate the transmitted frequency right for L-band. (Also the modulation index is approx 1680/400 times the modulation index of RS92-SGP.) It is not really relevant for json-output, but the console output would show the right frequency.
Yep! When running on the 1680 MHz band, it uses a very wide (200 kHz) FM bandwidth by default, to target the LMS6 sondes. However there is also a 'ngp_tweak' option, which narrows that back down to about 28 kHz to specifically target the RS92-NGP sondes.
I'm not using the --ngp option at the moment, as I don't currently take the sonde frequency from the decoder, instead using whatever frequency the SDR is running on.
The --ngp is only interesting for the -v output on the console. How far would you be able to receive these L-band radiosondes, if you don't track the radiosonde with a directional antenna?
Don't know! Definitely not as far as the 400 MHz sondes. I did some analysis on the Packet-error-rate vs Eb/N0 performance for the LMS6 400 / 1680 MHz sondes - the 1680 MHz sonde decode chain performs about 13db worse due to the much wider bandwidth (and some from baud rate differences). There will be similar (though not as severe) performance degradation from the wider bandwidth of the RS92-NGP sondes.
So yes, I suspect the most reliable way to track them will be with a directional antenna. auto_rx does support driving a rotator :-)
What is a good omnidirectional L-band antenna? Maybe a collinear, works for ADS-B 1090 MHz.
I think FM-decoding is not as good as IQ-decoding for RS92-NGP, the higher modulation index helps for IQ-decoding, whereas the higher bandwidth is more sensible to noise when the signal is FM-demodulated first.
At the moment I'm using fsk_demod as a 'frontend' for the RS92-NGP decode chain, to help deal with frequency offsets. Seems to work OK. fsk_demod falls over on the very high modulation index LMS6-1680 signal though, still need to figure out what's going on there.
Not sure about an omni for L-band. Possibly using one of the QFH's from a RS92 (with the associated preamp chain) would work, like this: https://rfhead.net/archives/665
I am the station uploading the San Diego RS92-NGP. Probably not the best place for this but I am using http://www.thingiverse.com/thing:2627680 (feed_support.stl) which is LHCP. The QFH on the RS92 is RHCP for GPS. The antenna beamwidth is wide enough I just leave it in a fixed direction. I also use a Nooelec SAWbird GOES for my LNA before the RTL-SDR. Along with this software it works great. I'll try out the options mentioned above to fix the posted freq.
Hi! Don't worry about making those changes - it won't change the posted frequency, as I'm using the frequency from the SDR for that.
Are you just using the whitelist to scan for the frequency?
I am whitelisting the only frequency I have ever seen my station use. (1680MHz). Would be nice to come up with an FFT scan just to pick up the deviation in frequency. Most are fairly dead on, but every now and then some have been hard to decode unless I shift down 20KHz or so, doesn't seem to drift during the flight, just serial number to serial number deviation.
OK, that is interesting in itself. 20 kHz offset is enough that the detector stage will probably fail, and even the 'experimental' decode stage (Which should handle maybe +/- 20 kHz of drift) is going to be on edge.
Getting the scanning working nicely is a challenge for the 1680 MHz band due the wide signals.
If you run auto_rx.py with the -v option, it will show you all the command lines its using. You should see one for rtl_power, something like: rtl_power -f 400400000:403500000:800 -i20 -1 -c 20% -p 0 -d 0 -g 26.0 log_power.csv
IT might be worth having a play with the frequency step parameter ('800' above), and have a look at the log_power.csv output. There is a script in auto_rx/utils/ called plot_rtl_power.py which you can run with: python utils/plot_rtl_power.py log_power.csv and it will plot the output (requires numpy and matplotlib).
Hopefully by twiddling the frequency step, and then the snr_threshold value in the advanced section of the config file, it should be possible to make the peak detect function work correctly for these sondes. Unfortunately without access to a sonde it's pretty difficult for me to do this!
I am the station uploading the San Diego RS92-NGP. Probably not the best place for this but I am using http://www.thingiverse.com/thing:2627680 (feed_support.stl) which is LHCP. The QFH on the RS92 is RHCP for GPS. The antenna beamwidth is wide enough I just leave it in a fixed direction. I also use a Nooelec SAWbird GOES for my LNA before the RTL-SDR. Along with this software it works great. I'll try out the options mentioned above to fix the posted freq.
The --ngp option gives the right frequency for L-band rs92ngp on the console. It is not included in the JSON-output. However if you have the audio-recording or raw data, you could check what the frequency was supposed to be. I guess the frequency steps for the L-band rs92 are 4 times the frequency steps at 400 MHz, so probably more then 20 kHz. The frequency is not transmitted in every frame. The output using ./rs92mod -v --vel --ecc --ngp ... would be something like
[ 8960] (N1213084) (2018-02-16) Fri 13:03:11.360 lat: 43.3385 lon: -78.7451 alt: 12382.2 (d:2.3) vH: 80.7 D: 85.6° vV: -6.2 # [0000]: fq 1680000
when the frame contains frequency data.
I think the L-band lms6 has circular polarization. But the rs92ngp? Isn't the rs92ngp just a scaled rs92sgp? just a short dipole wire?
This is a tracking issue for adding support for the Vaisala RS92-NGP, which is the 1680 MHz version of the RS92-SGP.
The RS92-NGP has an identical telemetry format to the RS92-SGP, however the GFSK modulation has a wider deviation. As a result, the FM demodulator bandwidth for both the detection and demodulation steps have to be widened, which results in poorer decode performance.
There is also the issue of frequency drift, which while negligible on the 400 MHz RS92-SGPs, is likely to impact reception of the 1680 MHz sondes. The current assumption of sonde transmissions being on 10 kHz frequency steps may not hold true for a detected 1680 MHz sonde.
There is currently code to widen the detection and decode bandwidth in the master branch, which is enabled if the scan/decode frequency is > 1 GHz.
Users in the vicinity of RS92-NGP launches are encouraged to have a go at running auto_rx. It would be worth looking at the spectrum with something like gqrx or sdr# to determine the 'actual' sonde frequency, to compare with auto_rx's estimation.
auto_rx settings that may need to be tweaked for RS92-NGP detection to work include: