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 On Tuesday, 26 May 2020 08:55:35 UTC-3, Paul Anderson wrote: > > 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 > > On Sunday, May 24, 2020 at 3:04:43 PM UTC-4, Lucas Heijst wrote: >> >> 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 >> >> On Sunday, 24 May 2020 13:54:00 UTC-3, Paul Anderson wrote: >>> >>> 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 >>> >>> On Saturday, May 16, 2020 at 1:43:20 PM UTC-4, Lucas Heijst wrote: >>>> >>>> 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: >>>>> >>>>> 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. >>>>> >>>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/e787dfb3-3b67-4d9b-b029-b3df35538df0%40googlegroups.com.
