RTLDavis Driver --- Stretch vs Buster

[rich T]

Currently I’m running the RTLDavis driver for about a year now on a RPI with Stretch as the OS with no issues.  I decided to install the RTLDavis driver on a RPI with Buster as the OS, but the driver seems to be having issues. I installed driver IAW the instructions found at https://github.com/lheijst/rtldavis

When I start the driver, I get the following:

pi@raspberrypi:~ $ $GOPATH/bin/rtldavis -tr 1 -tf US
22:24:33.805278 rtldavis.go VERSION=0.12
22:24:33.806647 tr=1 fc=0 ppm=0 gain=0 ex=0 maxmissed=51 actChan=[0] maxChan=1
22:24:33.807837 BitRate: 19200
22:24:33.807900 SymbolLength: 14
22:24:33.808431 SampleRate: 268800
22:24:33.808640 Preamble: 1100101110001001
22:24:33.808683 PreambleSymbols: 16
22:24:33.809030 PreambleLength: 224
22:24:33.809271 PacketSymbols: 80
22:24:33.809494 PacketLength: 1120
22:24:33.809703 BlockSize: 512
22:24:33.809896 BufferLength: 2048
Found Rafael Micro R820T tuner
22:24:34.231572 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
Exact sample rate is: 268800.001367 Hz
22:24:34.408971 GetTunerGain: 0 Db
22:24:34.409069 SetFreqCorrection 0 ppm Successful
Allocating 1 zero-copy buffers
22:24:34.415381 Init channels: wait max 135 seconds for a message of each transmitter
22:26:50.228986 Init channels: wait max 135 seconds for a message of each transmitter
22:26:50.229203 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
22:29:06.042898 Init channels: wait max 135 seconds for a message of each transmitter
22:29:06.043182 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
22:31:21.857356 Init channels: wait max 135 seconds for a message of each transmitter
22:31:21.857498 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
22:33:37.670725 Init channels: wait max 135 seconds for a message of each transmitter
22:33:37.670963 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
22:35:53.484568 Init channels: wait max 135 seconds for a message of each transmitter
22:35:53.484698 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
22:38:09.297676 Init channels: wait max 135 seconds for a message of each transmitter
22:38:09.297810 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
22:40:25.111236 Init channels: wait max 135 seconds for a message of each transmitter
22:40:25.111951 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
22:42:40.925341 Init channels: wait max 135 seconds for a message of each transmitter

Is anyone running this driver on RPI OS Buster?

There is a conversation about this @ https://groups.google.com/forum/#!topic/weewx-user/dUZ0OlEgQpg

Thanks

Rich

[Patrick Mendiuk]

Rich,

I tried running the driver on two different RPi 3B+ running Buster with no transmitter visible.  I have a Davis Envoy right beside the RTL-SDR that's receiving from my ISS without issue.  I just tried Stretch with the same RPi and it found the transmitter in about 37 sec.

Thanks,

Patrick

[rich T]

Patrick

This evening I'm going to install the driver on a different RPI w/stretch. I'm 99.9 percent sure the driver will work on that RPI. Just want to make sure in my head that I did not hose up the installation.

Rich

[rich T]

Patrick

I believe there is an issue with RTLDavis driver when running on a RPI w/Buster.  I installed the driver on a RPI w/stretch and it found the transmitter within a minute. Rebooted several times and transmitter was found. Here is general information about the RPI w/stretch:

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=Debian

pi@raspberrypi:~ $ go version
go version go1.7.4 linux/arm

Now I reinstalled the RTLDavis running RPI w/Buster, and it is waiting for the transmitter to be seen. Here is general information about the RPI w/Buster:

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian

pi@raspberrypi:~ $ go version
go version go1.11.6 linux/arm

Besides the OS,  it's using the latest version of golang. Wondering if that is causing the issue.

Rich

[Patrick Mendiuk]

Rich,

It's been working reliably for me with stretch and go1.7.4 linux/arm.  It worked just once for me with buster. 

Patrick

[Lucas Heijst]

Rich,

I updated most of my RPIs to raspbian buster.

Only the systems with rtlsdr got problems, so for those two systems I installed the latest version of raspbian stretch.

Until now I didn’t find any solutions for raspbian buster on the internet.

Luc

[rich T]

Luc

First let me say, the driver works great when running on Raspbian Stretch. I believe I been running the driver almost a year now without any issues. I did just noticed there are USB issues with RTLSDR running Raspbian Buster on RPI4, does that translate to RPI3s.

Issue seems to be that the SDR or driver does not hear the ISS at all.  If I run RPI3 w/stretch in the same location, it hears the ISS within a minute. Eventually, I would like to run the driver as a "stand alone" but first I would need to learn some "golang" programming.

Rich

[rich T]

Just installed RTL_433 on the RPI3 Raspbian Buster and it works fine. I have the latest RTL-SDR software package (librtlsdr0-0.6-1) installed and the latest USB Libraries installed:

libusb-0.1-4 ver 2:0.1.12-32
libusb-1.0-0 ver 2:1.0.22-2
libusb-1.0-0-dev ver 2:1.0.22-2

Rich

[Steve Wormley]

I actually just ran across this trying to get rtldavis working. It appears that the new zero-copy code in the packaged version of librtlsdr is the problem. I compiled a local copy without zero-copy support and pointed LD_LIBRARY_PATH at it to not use the system librtlsdr and all is well.

22:24:34.409069 SetFreqCorrection 0 ppm Successful

Allocating 1 zero-copy buffers  <-- broken

I've read things about zero copy expecting a 16k buffer which rtldavis doesn't use, but it could be a number of things like a bad interaction with the go library.

Well, mostly well. Eventually the frequency correction code wanders off far enough to cause it to eventually start failing 100% of the time. Disabling that gets me to well above 95% packet success for long periods. Not sure if this is also a librtlsdr problem or something else.

[Lucas Heijst]

On my two systems which use librtlsdr-dev (tfrec and rtldavis) I still run Raspbian Stretch. 

The tfrec package (https://github.com/baycom/tfrec) won't even compile without errors in Raspbian Buster. 

The rtldavis package runs flawless with the error correction activated.

The error correction of the 5 frequency bands (EU-model) run well between a range of -1000 to +1400. PctGood varies between 85 and 95%, about 5% better than meteostick (MSTK).

On the attached graphs you can see the correlation of the frequency errors with the temperature.

Luc

[Steve Wormley]

One problem that I seemed to have was the code looked to correct the next hop based on the error for the current channel, in my case I was testing 2 transmitters with wildly different frequency errors(one seems to run about -9000 and one about -1000, I'm sure I need some more PPM adjustments) so it took the error from Transmitter 1 and applied it on the hop to Transmitter 2 and vice versa, eventually it diverged and they both stopped being useful. I modified my local copy to only apply error corrections for the same transmitter and channel they were originally recorded on(and if it can't guess which transmitter is up next it defaults to 0 correction) and they seem to be much more stable even with the high correction values. Looks like I'm running about 97% right now. Will have to let it run for a day or 2 and see how it does.

[Lucas Heijst]

Good catch, Steve!

I changed my program accordingly to do the same. 

Currently we have less radio-reception due to the massive rain (already 72 mm in the last 13 hours and still counting...).

With four transmitters in the neighbourhoud of which three are read by the rtldavis program the PctGood values will be less than with one or two transmitters.

I will let the modified program run for a few days to see the results.

Luc 

[Lucas Heijst]

The results of the modified rtldavis go-program looks promising!

The frequency corrections are now applied for the right transmitters and frequentions.

The result is a better overall percentage of percentage good messages.

The frequency errors per channel are now stored for one transmitter at a time.

Each two days the data of the next transmitter is logged. 

This plot show the frequency error of sensor 0 (the ISS station).

Luc

[Lucas Heijst]

Steve,

Thanks for your advice. My weewx-rtld is now running on Raspbian Buster!

I had to put 'blacklist dvb_usb_rtl28xxu' in file /etc/modprobe.d/blacklist.conf

and added in weewx section [Rtldavis] in weewx.conf:

    # set the library path to the local build librtlsdr

    ld_library_path = /home/weewx/librtlsdr/build/src

Cheers,

Luc

On Saturday, 25 April 2020 00:00:02 UTC-3, Steve Wormley wrote:

[Paul Anderson]

Luc,

Long time since we spoke, hoping all is well with you.

Trying rtl-davis again after  long while. One note is that I just set up on new clean P13 Buster install as noticed earlier by you and Steve it fails to see any Transmitters.

Had read earlier in a sdr forum that this was fixed in a new Raspbian kernel module update. Just to try I ran  rpi-update which installed the latest kernel and modules,and can confirm that  rtl-davis now sees both my transmitters with no need to apply Steves Blacklist fix.

Question would like to try the fix for the Transmitter Frequency auto correction that you and Steve are using.Wonder if it's ready for a commit? Or maybe a diff?

Thanks,

Paul

[Lucas Heijst]

Paul,

My version is still in test. The way the frequency correction is calculated is still experimental.

I have sent you my version in a personal mail.

Luc

[Paul Anderson]

Hi Luc,

Thanks for your experimental version to test, as a test I ran it over night with frequency correction enabled and it performed very well. Signal quality graph showed all most all % good RX were reported at above 95%.

As a comparison I just finished running the released version over night and the results seem almost identical, really can not see any meaning full difference from just looking at the graph. So all I can say is not sure if experimental does a better job of  frequency correction or not.  Certainly does not seem any worse :)

Paul

[Lucas Heijst]

Hi Paul,

My experimental version has two different changes.

1. changed the receiveWindow from 10 to 300 ms.

2. changed the frequency correction algoritm.

1.

Due to unknown reasons until now the timing of the signals of my second Vantage Pro2 station suddenly changed.

As a result a huge drop in the number of received messages was seen. See graph weekrx-20200518.png.

By increasing the receiveWindow (that is the period before a time-out is triggered), the reception was back to the usual 95%.

2.

Even without any applied frequency corrections, the overall reception of two of my four Davis stations was about 95 %.

For some combinations of Davis transmitters and/or (not calibrated) rtlsdr devices the frequency error may become to big.

For frequency corrections bigger than +/- 20 kHz the weewx rtldavis.py program raises a WeeWxIOError.

The old frequency correction algoritm used the average of the last 10 frequency errors as the new frequency correction.

The new frequency correction algoritm is based upon a weighted average of the last 10 frequency errors (the newest frequency error has 10 times more influence than the eldest one).

As you can see in graph weekfreqerror-20200526.png the frequency corrections now operate in a smaller band.

The percentage good received messages remains the same.

Luc