rtldavis question

[Ryan Stasel]

Hi All,

Realize this isn't support for rtldavis, but I'm trying to get the weewx rtldavis driver up and going. I've not been able to get it to find the station on any channel. I'm using this fork of rtldavis. https://github.com/lheijst/rtldavis

This is the RTL stick I'm using. https://www.amazon.com/gp/product/B00VZ1AWQA/

Anyone have any thoughts? 

Thanks! 

-Ryan Stasel

[Ryan Stasel]

Forgot. Here's my command for looking for ISS (Vantage Vue)

$GOPATH/bin/rtldavis -tr 1 -tf US -startfreq 902000000 -endfreq 928000000 -stepfreq 40000

[Steve Wormley]

Did you compile librtlsdr as mentioned in the documentation or did you use the one that your operating system bundled?

If you used the OS one, was there a message in the startup about Allocating ... zero-copy buffers 

If so then that's probably the root of your problems, you'll need to compile it yourself and install it or use LD_LIBRARY_PATH. For whatever reason rtldavis doesn't work with Zero Copy, and I'm too lazy to find out why.

Also, you'll want to do a PPM test on the stick, using Kalibrate-rtl or at least rtl_test -p. With a close to correct PPM value and no zero copy the current versions should work without needing to scan.

Personally I also recommend setting gain to a fixed value instead of letting the automatic stuff work, once I got it working I tried various gain values to minimize missed packets.

-Steve

[Ryan Stasel]

Yup! "Allocating 1 zero-copy buffers".

not sure how to use kalibrate-rtl. rtl_test -p seems to be giving me +-5PPM? not sure how long to let it run to figure that out. 

Do I need to recompile rtldavis post compiling librtlsdr? 

Thanks! 

[Steve Wormley]

I couldn't actually get Kalibrate to work where I am I just mention it because it's apparently recommended. 15-20 minutes should be good for rtl_test, the average should stabilize. The Zero copy stuff is in the dynamically loaded library so there's no need to recompile rtldavis, just make sure it no longer says anything about zero-copy when it starts.

-Steve

[Ryan Stasel]

Okay, so let it stabilize then use that value for the PPM offset?

Kalibrate doesn't seem to really give me much.

pi@raspi-server-misc:~/kalibrate-rtl $ kal -c 26

Found 1 device(s):

  0:  Generic RTL2832U OEM

Using device 0: Generic RTL2832U OEM

Found Rafael Micro R820T tuner

Exact sample rate is: 270833.002142 Hz

[R82XX] PLL not locked!

kal: Calculating clock frequency offset.

Using GSM-900 channel 26 (940.2MHz)

Tuned to 940.200000MHz (reported tuner error: 0Hz)

I did compile librtlsdr, but still seeing the warning. Removed OS level one (apt remove librtlsdr-dev) and it still says it's allocating a zero-buffer. 

Hmm... 

[Steve Wormley]

Yes, let it stabilize and use that number in rtldavis -p 

You need to remove the original librtlsdr not the -dev version. dev is only used to compile, the one without -dev is used when it runs. The problem is that will remove the pre-compiled rtl-sdr tools as well. The other option is to do

"export LD_LIBRARY_PATH=/home/user/rtl-sdr-build/src" before running rtldavis  for whatever directory has the librtlsdr.so file in it from the newly compiled version.

[Ryan Stasel]

Ahhh, on this it's "librtlsdr0". Because of course. Alright, that did it! 

$GOPATH/bin/rtldavis -tr 1 -tf US -startfreq 902000000 -endfreq 928000000 -stepfreq 40000

10:04:26.329924 rtldavis.go VERSION=0.13

10:04:26.330593 tr=1 fc=0 ppm=0 gain=0 ex=0 maxmissed=51 actChan=[0] maxChan=1

10:04:26.330677 TEST: startFreq=902000000 endFreq=928000000 stepFreq=40000

10:04:26.331648 BitRate: 19200

10:04:26.331694 SymbolLength: 14

10:04:26.331731 SampleRate: 268800

10:04:26.331763 Preamble: 1100101110001001

10:04:26.331793 PreambleSymbols: 16

10:04:26.331824 PreambleLength: 224

10:04:26.331855 PacketSymbols: 80

10:04:26.331886 PacketLength: 1120

10:04:26.331921 BlockSize: 512

10:04:26.331956 BufferLength: 2048

Found Rafael Micro R820T tuner

10:04:26.739106 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0 Transmitter:0}

Exact sample rate is: 268800.001367 Hz

10:04:26.920176 GetTunerGain: 0 Db

10:04:26.920240 SetFreqCorrection 0 ppm Successful

10:04:26.924968 Init channels: wait max 135 seconds for a message of each transmitter

That also seems to have made rtl_test work better. ha. 

Will let that run and then add to rtldavis. 

Thanks! Will post back when I have an answer to the "can I find my station" one way or the other. =)

Thanks Steve! 

[Ryan Stasel]

Okay, that seems to have worked. 

$GOPATH/bin/rtldavis -tr 1 -tf US -ppm 1 -startfreq 902000000 -endfreq 928000000 -stepfreq 40000

10:25:53.676933 rtldavis.go VERSION=0.13

10:25:53.677734 tr=1 fc=0 ppm=1 gain=0 ex=0 maxmissed=51 actChan=[0] maxChan=1

10:25:53.677879 TEST: startFreq=902000000 endFreq=928000000 stepFreq=40000

10:25:53.678935 BitRate: 19200

10:25:53.679040 SymbolLength: 14

10:25:53.679127 SampleRate: 268800

10:25:53.679212 Preamble: 1100101110001001

10:25:53.679298 PreambleSymbols: 16

10:25:53.679382 PreambleLength: 224

10:25:53.679466 PacketSymbols: 80

10:25:53.679550 PacketLength: 1120

10:25:53.679633 BlockSize: 512

10:25:53.679719 BufferLength: 2048

Found Rafael Micro R820T tuner

10:25:54.084867 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0 Transmitter:0}

Exact sample rate is: 268800.001367 Hz

10:25:54.266167 GetTunerGain: 0 Db

10:25:54.327851 SetFreqCorrection 1 ppm Successful

10:25:54.332697 Init channels: wait max 135 seconds for a message of each transmitter

Produced what looks like the best channel being:

11:19:11.995552 TESTFREQ 24: Frequency 902920000 (freqError=-116): OK, msg.data: 50008CFF730070F7

I am now running (that channel +_ 5000, or 5khz with 500hz steps):

$GOPATH/bin/rtldavis -tr 1 -tf US -ppm 1 -startfreq 902915000 -endfreq 902925000 -stepfreq 500

18:29:33.846484 rtldavis.go VERSION=0.13

18:29:33.847151 tr=1 fc=0 ppm=1 gain=0 ex=0 maxmissed=51 actChan=[0] maxChan=1

18:29:33.847234 TEST: startFreq=902915000 endFreq=902925000 stepFreq=500

18:29:33.848279 BitRate: 19200

18:29:33.848327 SymbolLength: 14

18:29:33.848363 SampleRate: 268800

18:29:33.848398 Preamble: 1100101110001001

18:29:33.848434 PreambleSymbols: 16

18:29:33.848468 PreambleLength: 224

18:29:33.848502 PacketSymbols: 80

18:29:33.848537 PacketLength: 1120

18:29:33.848571 BlockSize: 512

18:29:33.848605 BufferLength: 2048

Found Rafael Micro R820T tuner

18:29:34.255854 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0 Transmitter:0}

Exact sample rate is: 268800.001367 Hz

18:29:34.436639 GetTunerGain: 0 Db

18:29:34.498418 SetFreqCorrection 1 ppm Successful

18:29:34.503303 Init channels: wait max 135 seconds for a message of each transmitter

Once I have that, I should be able to pluginto the rtldavis driver for weewx and be good to go?

Thanks! 

[Steve Wormley]

The thing is, you didn't really need to do any of that. The channel it found was accurate for the default channel map so all you needed to do was run:

$GOPATH/bin/rtldavis -tr 1 -tf US -ppm 1

And it should start spitting out data after a minute or two. Then update the weewx.conf with the full path(I don't know if it would understand GOPATH) and the -ppm 1 set 'transceiver_frequency' to US and it should be happy.

so, roughly:

cmd = /home/myuser/go/bin/rtldavis -ppm 1

transceiver_frequency = US

iss_channel = 1

fix rain_bucket_type if appropriate

[Ryan Stasel]

Thanks! Will take a look. There are lots of NAK’s (NOKs?) during initial scan. So good to know! Thanks!

On May 13, 2020, at 18:41, Steve Wormley <wor...@wormley.com> wrote:



--
You received this message because you are subscribed to the Google Groups "weewx-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/ca68316c-a58d-4b3b-945d-11fb5b1aee8f%40googlegroups.com.

[Ryan Stasel]

That worked perfectly, thank you! 

[Lucas Heijst]

Ryan and Steve,

Currently I am testing modified versions of rtldavis and weewx_rtldavis.

I have adapted the improvements of the freqError calculation in Steve Wormley’s fork.

Also I adapted his -noafc and -v options.

Recently I changed the way the frequency correction was used. The old (and wrong) way was to use the found frequency error as correction for the next hop. When a system has more than one transmitter this might lead to unstable communication. In all cases it did not have a positive effect.

The current release use the frequency correction on the same channel and for the same transmitter as the freqErrorrs were detected.

Two days ago there was at night a huge amount of time-out messages of one of my four Davis stations.

Somehow the timing of that station was changed.

After some research of the received or timed-out data I changed the timing of the hop sequence. The ‘handling window’, that is the period between the expected moment of the next signal and the moment of the time-out, was increased from 10 ms to 300 ms. 

The original idea for the small 10 ms window was a minimal disturbance of the timing of the next signal (of another transmitter). With only one transmitter active there was no such problem. This change is a huge improvement for systems with more than one transmitter to be handled. E.g. my ISS-1 station with the wind sensor via an anemometer kit and a leaf-soil station.

Also the handling of the New Zealand frequencies is prepared. The actual NZ-frequencies will be set via a PR.

Luc