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/5730576c-4e29-4144-8aec-33f36074a385%40googlegroups.com.
