Receiving Davis Vantage data with RTL-SDR dongle and program rtldavis

3,012 views
Skip to first unread message

ljm.h...@gmail.com

unread,
Mar 13, 2019, 7:50:29 PM3/13/19
to weewx-development
To all,

In the weewx forum I started a thread about reception of Davis vantage messages with a RTL-SDR dongle.
I have (re)written two programs
1. A modified version of rtldavis which reads the raw messages and print the data to stderr.
2. A weewx-rtld driver which parses the raw data and store the weather data in the weewx database. This driver is not public yet as by now.

Until now we couldn’t find a usefull set of US frequencies. The modified program rtldavis works resonable well for the EU frequencies.
In this thread we will discuss the progress to get a good working program for both EU and US.

Luc Heijst

ljm.h...@gmail.com

unread,
Mar 13, 2019, 8:00:43 PM3/13/19
to weewx-development
Hi Rich,

Some quick analyse to start with.

US band 902 - 928 MHz range 26 MHz = 26,000 kHz
EU band 868.0 - 868.6 MHz range 0.6 MHz = 600 kHz

US frequencies are 501,000 Hz spreaded = 501 kHz
EU frequencies are 6,000 to 27,000 Hz spreaded = 6 to 27 kHz

Proposal for the testprogram.

US step size: 80 kHz, total steps is 325, duration 135 s * 325 = 43,875 s = 12.2 h.
May be the step size of 80kHz is too big to catch all channels, but with a step size of 10 kHz, the program will run for 4 days!

EU step size: 2 kHz, total steps is 300, duration 17 s * 300 = 5100 s = 1.4 h.

Testprogram need startfreq, endfreq and stepfreq as extra parameters

In case we stopped half way, we can continue with a new startfreq, where we ended last time.

Luc

ljm.h...@gmail.com

unread,
Mar 13, 2019, 8:31:45 PM3/13/19
to weewx-development
Hi, it’s me again!

Rich, may be a last quick step to try, before writing a test program.

What you can do is the following:

Take the list of RFM69 frequencies in your spread sheet.
Sort them from low to high.
Subtract from each of the 51 frequencies the value 26062 (Hz)
Use these smaller (and sorted) frequencies in protogol.go

Explanation: the frequencies of the original rtldavis program and the sorted RFM69 frequencies all differ about 26000 Hz from each other.

The sorted hop frequencies differ about 51000 Hz from their ‘neighbour’ frequency, so an offset of 26000 Hz from the good frequency is too much as we have seen.

Test have already shown that the first frequency of rtldavis is good: we received the data of both transmitters. The first RFM69 frequency differs 26062 Hz with the first rtldavis frequency.

Let me know if you like the idea or have any questions.

Cheers, Luc

rich T

unread,
Mar 13, 2019, 9:10:55 PM3/13/19
to weewx-development
Luc

Ok, will run with the new frequencies; will post the results later this evening.  If we need the test program, I have no issues allowing it to run until it is complete.

thanks
Rich

rich T

unread,
Mar 13, 2019, 9:44:51 PM3/13/19
to weewx-development
Hi Luc

Here is approximately 10 minutes worth of data, using the new frequencies.

Rich

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ $GOPATH/bin/rtldavis -tr 3  -tf US
21:29:10.210225 rtldavis.go VERSION=0.7
21:29:10.210719 tr=3 actChan=[0 1] maxChan=2 *transmitterId=1 msgIdToChan=[0 1 9 9 9 9 9 9]
21:29:10.210844 idLoopPeriods=[2562500000 2625000000 2687500000 2750000000 2812500000 2875000000 2937500000 3000000000]
21:29:10.211635 BitRate: 19200
21:29:10.211681 SymbolLength: 14
21:29:10.211720 SampleRate: 268800
21:29:10.211754 Preamble: 1100101110001001
21:29:10.211790 PreambleSymbols: 16
21:29:10.211824 PreambleLength: 224
21:29:10.211858 PacketSymbols: 80
21:29:10.211893 PacketLength: 1120
21:29:10.211929 BlockSize: 512
21:29:10.211962 BufferLength: 2048
Detached kernel driver
Found Rafael Micro R820T tuner
21:29:10.911997 main.go:157: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:0}
Exact sample rate is: 268800.001367 Hz
21:29:11.095738 Init loopTimer and wait for messages on channel 0: loopTimer=273465728 idLoopPeriods=2625000000 loopPeriod=136500000000
21:29:25.897283 msg.Data: 88005D19F900E174
21:29:25.897761 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0 0]
21:29:25.898016 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552526965897269565 0] visitCount=1 chLastHops=[0 0]
21:30:33.252094 msg.Data: 590059FF71004A31
21:30:33.252250 init channels, msg.ID=1 msgIdToChan=1 chLastVisits=[1552526965897269565 0]
21:30:33.252452 NEW TRANSMITTER: msg.ID=1 chLastVisits=[1552526965897269565 1552527033252081701] visitCount=2 chLastHops=[0 0]
21:30:33.252570 ALL TRANSMITTERS SEEN: chLastVisits=[1552526965897269565 1552527033252081701] visitCount=2 chLastHops=[0 0]
21:30:33.252615 last seen msg.Data: 590059FF71004A31
21:30:33.252750 Hop to channelIdx: 34 21:30:35.084769 ID=0
21:30:33.253051 main.go:185: Hop: {ChannelIdx:34 ChannelFreq:919415344 FreqError:-17343}
21:30:35.149766 ID:0 packet missed
21:30:35.149959 loopTimer expired; hop to channelIdx: 19 21:30:35.877081 ID=1
21:30:35.150099 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889099 FreqError:-17343}
21:30:35.940124 ID:1 packet missed
21:30:35.940241 loopTimer expired; hop to channelIdx: 45 21:30:37.647269 ID=0
21:30:35.940336 main.go:185: Hop: {ChannelIdx:45 ChannelFreq:924934143 FreqError:-17343}
21:30:37.711705 ID:0 packet missed
21:30:37.711971 loopTimer expired; hop to channelIdx: 41 21:30:38.502081 ID=1
21:30:37.712124 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927124 FreqError:-17343}
21:30:38.565269 ID:1 packet missed
21:30:38.565663 loopTimer expired; hop to channelIdx: 1 21:30:40.209769 ID=0
21:30:38.565899 main.go:185: Hop: {ChannelIdx: 1 ChannelFreq:902858459 FreqError:-17343}
21:30:40.273635 ID:0 packet missed
21:30:40.273816 loopTimer expired; hop to channelIdx: 25 21:30:41.127081 ID=1
21:30:40.273949 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914900513 FreqError:-17343}
21:30:41.189848 ID:1 packet missed
21:30:41.190366 loopTimer expired; hop to channelIdx: 17 21:30:42.772269 ID=0
21:30:41.190675 main.go:185: Hop: {ChannelIdx:17 ChannelFreq:910886047 FreqError:-17343}
21:30:42.835837 ID:0 packet missed
21:30:42.835939 Init channels: wait for messages
21:30:42.836059 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-17343}
21:31:36.586629 msg.Data: 480259FFC1004F9B
21:31:36.586742 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0 0]
21:31:36.586905 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552527096586616956 0] visitCount=1 chLastHops=[0 3]
21:32:47.129415 msg.Data: 590452FF7100DD28
21:32:47.129631 init channels, msg.ID=1 msgIdToChan=1 chLastVisits=[1552527096586616956 0]
21:32:47.129802 NEW TRANSMITTER: msg.ID=1 chLastVisits=[1552527096586616956 1552527167129402876] visitCount=2 chLastHops=[0 0]
21:32:47.129960 ALL TRANSMITTERS SEEN: chLastVisits=[1552527096586616956 1552527167129402876] visitCount=2 chLastHops=[0 0]
21:32:47.130045 last seen msg.Data: 590452FF7100DD28
21:32:47.130222 Hop to channelIdx: 45 21:32:48.336616 ID=0
21:32:47.130518 main.go:185: Hop: {ChannelIdx:45 ChannelFreq:924934143 FreqError:-17205}
21:32:48.401408 ID:0 packet missed
21:32:48.401599 loopTimer expired; hop to channelIdx: 19 21:32:49.754402 ID=1
21:32:48.401731 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889099 FreqError:-17205}
21:32:49.818703 ID:1 packet missed
21:32:49.818871 loopTimer expired; hop to channelIdx: 1 21:32:50.899116 ID=0
21:32:49.818990 main.go:185: Hop: {ChannelIdx: 1 ChannelFreq:902858459 FreqError:-17205}
21:32:50.963015 ID:0 packet missed
21:32:50.963208 loopTimer expired; hop to channelIdx: 41 21:32:52.379402 ID=1
21:32:50.963336 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927124 FreqError:-17205}
21:32:52.442876 ID:1 packet missed
21:32:52.443134 loopTimer expired; hop to channelIdx: 17 21:32:53.461616 ID=0
21:32:52.443318 main.go:185: Hop: {ChannelIdx:17 ChannelFreq:910886047 FreqError:-17205}
21:32:53.524945 ID:0 packet missed
21:32:53.525217 loopTimer expired; hop to channelIdx: 25 21:32:55.004402 ID=1
21:32:53.525401 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914900513 FreqError:-17205}
21:32:55.067686 ID:1 packet missed
21:32:55.067949 loopTimer expired; hop to channelIdx: 39 21:32:56.024116 ID=0
21:32:55.068135 main.go:185: Hop: {ChannelIdx:39 ChannelFreq:921923645 FreqError:-17205}
21:32:56.087431 ID:0 packet missed
21:32:56.087598 Init channels: wait for messages
21:32:56.087772 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-17205}
21:33:47.275313 msg.Data: 58004EFF73002379
21:33:47.275654 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0 0]
21:33:47.275922 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552527227275299525 0] visitCount=1 chLastHops=[0 3]
21:35:01.007125 msg.Data: 59004EFF730066D9
21:35:01.007380 init channels, msg.ID=1 msgIdToChan=1 chLastVisits=[1552527227275299525 0]
21:35:01.007547 NEW TRANSMITTER: msg.ID=1 chLastVisits=[1552527227275299525 1552527301007112212] visitCount=2 chLastHops=[0 0]
21:35:01.007673 ALL TRANSMITTERS SEEN: chLastVisits=[1552527227275299525 1552527301007112212] visitCount=2 chLastHops=[0 0]
21:35:01.007722 last seen msg.Data: 59004EFF730066D9
21:35:01.007871 Hop to channelIdx: 1 21:35:01.587799 ID=0
21:35:01.008022 main.go:185: Hop: {ChannelIdx: 1 ChannelFreq:902858459 FreqError:-16268}
21:35:01.652349 ID:0 packet missed
21:35:01.652457 loopTimer expired; hop to channelIdx: 19 21:35:03.632112 ID=1
21:35:01.652529 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889099 FreqError:-16268}
21:35:03.696333 ID:1 packet missed
21:35:03.696524 loopTimer expired; hop to channelIdx: 17 21:35:04.150299 ID=0
21:35:03.696659 main.go:185: Hop: {ChannelIdx:17 ChannelFreq:910886047 FreqError:-16268}
21:35:04.213245 ID:0 packet missed
21:35:04.213411 loopTimer expired; hop to channelIdx: 41 21:35:06.257112 ID=1
21:35:04.213490 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927124 FreqError:-16268}
21:35:06.320112 ID:1 packet missed
21:35:06.320379 loopTimer expired; hop to channelIdx: 39 21:35:06.712799 ID=0
21:35:06.320516 main.go:185: Hop: {ChannelIdx:39 ChannelFreq:921923645 FreqError:-16268}
21:35:06.777210 ID:0 packet missed
21:35:06.777373 loopTimer expired; hop to channelIdx: 25 21:35:08.882112 ID=1
21:35:06.777452 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914900513 FreqError:-16268}
21:35:08.945314 ID:1 packet missed
21:35:08.945502 loopTimer expired; hop to channelIdx: 26 21:35:09.275299 ID=0
21:35:08.945630 main.go:185: Hop: {ChannelIdx:26 ChannelFreq:915401794 FreqError:-16268}
21:35:09.338050 ID:0 packet missed
21:35:09.338229 Init channels: wait for messages
21:35:09.338358 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-16268}
21:35:57.962967 msg.Data: E8005C4401004E2F
21:35:57.963096 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0 0]
21:35:57.963201 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552527357962953119 0] visitCount=1 chLastHops=[0 3]
21:37:14.882670 msg.Data: E90251440100768A
21:37:14.882929 init channels, msg.ID=1 msgIdToChan=1 chLastVisits=[1552527357962953119 0]
21:37:14.883107 NEW TRANSMITTER: msg.ID=1 chLastVisits=[1552527357962953119 1552527434882658275] visitCount=2 chLastHops=[0 0]
21:37:14.883305 ALL TRANSMITTERS SEEN: chLastVisits=[1552527357962953119 1552527434882658275] visitCount=2 chLastHops=[0 0]
21:37:14.883390 last seen msg.Data: E90251440100768A
21:37:14.883562 Hop to channelIdx: 39 21:37:17.400453 ID=0
21:37:14.883724 main.go:185: Hop: {ChannelIdx:39 ChannelFreq:921923645 FreqError:-20436}
21:37:17.465813 ID:0 packet missed
21:37:17.466069 loopTimer expired; hop to channelIdx: 19 21:37:17.507658 ID=1
21:37:17.466196 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889099 FreqError:-20436}
21:37:17.570448 ID:1 packet missed
21:37:17.570737 loopTimer expired; hop to channelIdx: 26 21:37:19.962953 ID=0
21:37:17.570879 main.go:185: Hop: {ChannelIdx:26 ChannelFreq:915401794 FreqError:-20436}
21:37:20.027660 ID:0 packet missed
21:37:20.027853 loopTimer expired; hop to channelIdx: 41 21:37:20.132658 ID=1
21:37:20.027986 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927124 FreqError:-20436}
21:37:20.195532 ID:1 packet missed
21:37:20.195654 loopTimer expired; hop to channelIdx: 9 21:37:22.525453 ID=0
21:37:20.195733 main.go:185: Hop: {ChannelIdx: 9 ChannelFreq:906872009 FreqError:-20436}
21:37:22.588152 ID:0 packet missed
21:37:22.588338 loopTimer expired; hop to channelIdx: 25 21:37:22.757658 ID=1
21:37:22.588470 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914900513 FreqError:-20436}
21:37:22.821831 ID:1 packet missed
21:37:22.821951 loopTimer expired; hop to channelIdx: 31 21:37:25.087953 ID=0
21:37:22.822032 main.go:185: Hop: {ChannelIdx:31 ChannelFreq:917909607 FreqError:-20436}
21:37:25.151467 ID:0 packet missed
21:37:25.151576 Init channels: wait for messages
21:37:25.151697 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-20436}
21:38:08.652269 msg.Data: 88014E19FB00AD3C
21:38:08.652506 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0 0]
21:38:08.652821 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552527488652254054 0] visitCount=1 chLastHops=[0 3]
21:39:28.760629 msg.Data: 9902700503074EF4
21:39:28.760770 init channels, msg.ID=1 msgIdToChan=1 chLastVisits=[1552527488652254054 0]
21:39:28.760895 NEW TRANSMITTER: msg.ID=1 chLastVisits=[1552527488652254054 1552527568760617025] visitCount=2 chLastHops=[0 0]
21:39:28.761075 ALL TRANSMITTERS SEEN: chLastVisits=[1552527488652254054 1552527568760617025] visitCount=2 chLastHops=[0 0]
21:39:28.761121 last seen msg.Data: 9902700503074EF4
21:39:28.761249 Hop to channelIdx: 26 21:39:30.652254 ID=0
21:39:28.761363 main.go:185: Hop: {ChannelIdx:26 ChannelFreq:915401794 FreqError:-18135}
21:39:30.717071 ID:0 packet missed
21:39:30.717741 loopTimer expired; hop to channelIdx: 19 21:39:31.385617 ID=1
21:39:30.718047 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889099 FreqError:-18135}
21:39:31.450082 ID:1 packet missed
21:39:31.450188 loopTimer expired; hop to channelIdx: 9 21:39:33.214754 ID=0
21:39:31.450257 main.go:185: Hop: {ChannelIdx: 9 ChannelFreq:906872009 FreqError:-18135}
21:39:33.279052 ID:0 packet missed
21:39:33.279576 loopTimer expired; hop to channelIdx: 41 21:39:34.010617 ID=1
21:39:33.279918 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927124 FreqError:-18135}
21:39:34.075313 ID:1 packet missed
21:39:34.075486 loopTimer expired; hop to channelIdx: 31 21:39:35.777254 ID=0
21:39:34.075607 main.go:185: Hop: {ChannelIdx:31 ChannelFreq:917909607 FreqError:-18135}
21:39:35.840951 ID:0 packet missed
21:39:35.841126 loopTimer expired; hop to channelIdx: 25 21:39:36.635617 ID=1
21:39:35.841249 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914900513 FreqError:-18135}
21:39:36.699809 ID:1 packet missed
21:39:36.699979 loopTimer expired; hop to channelIdx: 50 21:39:38.339754 ID=0
21:39:36.700095 main.go:185: Hop: {ChannelIdx:50 ChannelFreq:927443787 FreqError:-18135}
21:39:38.402818 ID:0 packet missed
21:39:38.403082 Init channels: wait for messages
21:39:38.403283 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-18135}
21:40:19.341065 msg.Data: 98006D05011719A5
21:40:19.341182 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0 0]
21:40:19.341281 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552527619341050925 0] visitCount=1 chLastHops=[0 3]
21:41:42.637439 msg.Data: 69006D000100449F
21:41:42.637596 init channels, msg.ID=1 msgIdToChan=1 chLastVisits=[1552527619341050925 0]
21:41:42.637734 NEW TRANSMITTER: msg.ID=1 chLastVisits=[1552527619341050925 1552527702637426766] visitCount=2 chLastHops=[0 0]
21:41:42.637845 ALL TRANSMITTERS SEEN: chLastVisits=[1552527619341050925 1552527702637426766] visitCount=2 chLastHops=[0 0]
21:41:42.637888 last seen msg.Data: 69006D000100449F
21:41:42.638025 Hop to channelIdx: 9 21:41:43.90355 ID=0
21:41:42.638145 main.go:185: Hop: {ChannelIdx: 9 ChannelFreq:906872009 FreqError:-16345}
21:41:43.966882 ID:0 packet missed
21:41:43.967147 loopTimer expired; hop to channelIdx: 19 21:41:45.262426 ID=1
21:41:43.967277 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889099 FreqError:-16345}
21:41:45.326780 ID:1 packet missed
21:41:45.326977 loopTimer expired; hop to channelIdx: 31 21:41:46.46605 ID=0
21:41:45.327180 main.go:185: Hop: {ChannelIdx:31 ChannelFreq:917909607 FreqError:-16345}
21:41:46.529005 ID:0 packet missed
21:41:46.529247 loopTimer expired; hop to channelIdx: 41 21:41:47.887426 ID=1
21:41:46.529456 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927124 FreqError:-16345}
21:41:47.952095 ID:1 packet missed
21:41:47.952507 loopTimer expired; hop to channelIdx: 50 21:41:49.02855 ID=0
21:41:47.952683 main.go:185: Hop: {ChannelIdx:50 ChannelFreq:927443787 FreqError:-16345}
21:41:49.092385 ID:0 packet missed
21:41:49.092520 loopTimer expired; hop to channelIdx: 25 21:41:50.512426 ID=1
21:41:49.092601 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914900513 FreqError:-16345}
21:41:50.576489 ID:1 packet missed
21:41:50.576925 loopTimer expired; hop to channelIdx: 37 21:41:51.59105 ID=0
21:41:50.577118 main.go:185: Hop: {ChannelIdx:37 ChannelFreq:920921021 FreqError:-16345}
21:41:51.654713 ID:0 packet missed
21:41:51.654819 Init channels: wait for messages
21:41:51.654936 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-16345}
21:42:30.029897 msg.Data: 58006DFF7000DAB8
21:42:30.030192 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0 0]
21:42:30.030379 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552527750029884317 0] visitCount=1 chLastHops=[0 3]

ljm.h...@gmail.com

unread,
Mar 14, 2019, 2:06:52 AM3/14/19
to weewx-development
Rich,

What we have learned from the log:
- the frequency of channel 0 in the table is about 17000 Hz too low
- the data could be read with this big frequency offset
- the data of none of the other selected channels could be read
- selected were channels 34,19,45,41,1,25,17,26,9,50,25,37 (may be more, I just checked the log quickly).

So, next step will be the test program. Can I send you the program by private mail? If yes, drop a mail to ljm.heijst at gmail.com.

Thanks for testing,

Luc

rich T

unread,
Mar 14, 2019, 8:40:00 AM3/14/19
to weewx-development
Luc

Glad to help. During the evening I noticed the offset would drop to around -7000 Hz on certain channels.

Rich

ljm.h...@gmail.com

unread,
Mar 14, 2019, 8:48:24 AM3/14/19
to weewx-development
On Thursday, 14 March 2019 09:40:00 UTC-3, rich T wrote:
During the evening I noticed the offset would drop to around -7000 Hz on certain channels.

Yes, that are the temperature influences I was talking about. 

rich T

unread,
Mar 15, 2019, 8:10:22 PM3/15/19
to weewx-development
Luc

Used a NESDR Smart dongle with 868/900MHz antenna.  The dongle's PPM was -47.5 (-750Hz) The ISS has a low battery indication (new batteries arriving tomorrow). Here are the results for the first US band 902 - 928 MHz test:

20:17:41.673497 TESTFREQ 24: Frequency 902920000 (freqError=-7771): OK, msg.data: E005574402002B76
20:39:56.745993 TESTFREQ 35: Frequency 903360000 (freqError=587): OK, msg.data: 500362FF7100DEF7
21:09:09.506517 TESTFREQ 49: Frequency 903920000 (freqError=-7921): OK, msg.data: 500049FF71001974
21:32:26.080181 TESTFREQ 60: Frequency 904360000 (freqError=5446): OK, msg.data: 60034B000000C149
22:27:18.920785 TESTFREQ 85: Frequency 905360000 (freqError=-17643): OK, msg.data: 80088120B9005FD2
23:01:29.478740 TESTFREQ 101: Frequency 906000000 (freqError=-23787): OK, msg.data: F83F780F5C82E476
23:20:08.758227 TESTFREQ 110: Frequency 906360000 (freqError=-12959): OK, msg.data: E0054C4401007B9D
00:15:27.221107 TESTFREQ 135: Frequency 907360000 (freqError=-8369): OK, msg.data: 80044C207B002EED
00:18:57.347731 TESTFREQ 137: Frequency 907440000 (freqError=6199): OK, msg.data: 5004AEFF730023D7
01:14:15.811477 TESTFREQ 162: Frequency 908440000 (freqError=-8622): OK, msg.data: E007324402008A62
02:08:07.147511 TESTFREQ 187: Frequency 909440000 (freqError=-5901): OK, msg.data: 500675FF7300D148
02:32:22.656936 TESTFREQ 198: Frequency 909880000 (freqError=3984): OK, msg.data: 500785FF71008236
03:27:46.244250 TESTFREQ 223: Frequency 910880000 (freqError=-4474): OK, msg.data: 600C6A000100D67B
04:22:59.563153 TESTFREQ 248: Frequency 911880000 (freqError=-14314): OK, msg.data: 8009662279005870
04:26:34.817307 TESTFREQ 250: Frequency 911960000 (freqError=1040): OK, msg.data: 80096E229B00AB63
05:16:30.403769 TESTFREQ 273: Frequency 912880000 (freqError=-7099): OK, msg.data: E005764401003FDF
05:19:37.466300 TESTFREQ 275: Frequency 912960000 (freqError=4898): OK, msg.data: 500563FF710065C6
06:13:08.292103 TESTFREQ 300: Frequency 913960000 (freqError=-8602): OK, msg.data: A8043B403900F53A
07:07:50.879619 TESTFREQ 325: Frequency 914960000 (freqError=-4283): OK, msg.data: 88046621E90035F3
07:31:17.706919 TESTFREQ 336: Frequency 915400000 (freqError=4785): OK, msg.data: E8067544000074A2
08:00:38.152655 TESTFREQ 350: Frequency 915960000 (freqError=-9044): OK, msg.data: 880068222B0037C9
09:18:39.816797 TESTFREQ 386: Frequency 917400000 (freqError=-18224): OK, msg.data: A80673653B0051B2
09:21:28.940016 TESTFREQ 388: Frequency 917480000 (freqError=514): OK, msg.data: E8037544010064C4
10:11:50.208276 TESTFREQ 411: Frequency 918400000 (freqError=-8900): OK, msg.data: 88027B22D9008692
10:15:17.772593 TESTFREQ 413: Frequency 918480000 (freqError=3669): OK, msg.data: E80063440300D04A
11:05:28.706191 TESTFREQ 436: Frequency 919400000 (freqError=-12103): OK, msg.data: 8805922589001DF4
11:08:28.081048 TESTFREQ 438: Frequency 919480000 (freqError=6868): OK, msg.data: 580373FF7200EBF5
12:02:06.583627 TESTFREQ 463: Frequency 920480000 (freqError=-6150): OK, msg.data: 5800BAFF710010A7
12:24:52.381782 TESTFREQ 474: Frequency 920920000 (freqError=-11314): OK, msg.data: A8008C912B00EB75
12:54:43.561832 TESTFREQ 488: Frequency 921480000 (freqError=-6578): OK, msg.data: 5800CFFF7100EE97
13:18:05.277492 TESTFREQ 499: Frequency 921920000 (freqError=6728): OK, msg.data: E800D1440100AA91
14:12:01.710155 TESTFREQ 524: Frequency 922920000 (freqError=-16066): OK, msg.data: 8000BD292B00DE3C
14:14:43.147971 TESTFREQ 526: Frequency 923000000 (freqError=839): OK, msg.data: 9000E903032F60B7
15:03:44.854921 TESTFREQ 549: Frequency 923920000 (freqError=-9857): OK, msg.data: A00171272B00A6F2
15:06:28.849723 TESTFREQ 551: Frequency 924000000 (freqError=3908): OK, msg.data: 60087A6C0200FF83
15:06:49.348428 TESTFREQ 552: Frequency 924040000 (freqError=-4130): OK, msg.data: 9002880E03081D86
15:55:02.461872 TESTFREQ 574: Frequency 924920000 (freqError=-4796): OK, msg.data: 8002842C2A009DE0
15:58:12.087871 TESTFREQ 576: Frequency 925000000 (freqError=6972): OK, msg.data: 5004D1FF7300B54C
16:00:12.523126 TESTFREQ 577: Frequency 925040000 (freqError=-881): OK, msg.data: E000CF4401001E2E
16:51:40.332463 TESTFREQ 601: Frequency 926000000 (freqError=-10249): OK, msg.data: 5003D0FF7100C24E
17:14:44.087914 TESTFREQ 612: Frequency 926440000 (freqError=-15864): OK, msg.data: 50009AFF71002AAB
17:44:30.147888 TESTFREQ 626: Frequency 927000000 (freqError=-10788): OK, msg.data: 60009B0683007BF3

I believe 41 frequencies were captured.  Tonight I'm rerunning the test with the offset included.

Rich






Paul Anderson

unread,
Mar 16, 2019, 11:32:40 AM3/16/19
to weewx-development
Hi Luc and Rich,
Been following your work and ran the test program on my U.S, Davis Vantage Pro 2.
 Used a RTL-SDR.com  dongle RTL2832 dongle has <1 PPM temperature compensated oscillator (TCXO)
After 5 min warm up rtl_test -p showed cumulative PPM: 0
Here are the results for the US band 902 - 928 MHz test:
Looks like 68 frequencies were captured? Some must be bad as I think we only want 51?
$GOPATH/bin/rtldavis -tr 1 -tf US -startfreq 902000000 -endfreq 928000000 -stepfreq 40000


12:05:12.931583 TESTFREQ 24: Frequency 902920000 (freqError=-1089): OK, msg.data: 800000738500B115
12:05:41.118438 TESTFREQ 25: Frequency 902960000 (freqError=1906): OK, msg.data: A00000328500AE80
12:58:51.477901 TESTFREQ 49: Frequency 903920000 (freqError=29606): OK, msg.data: 80000070C500E589
13:22:08.049315 TESTFREQ 60: Frequency 904360000 (freqError=12748): OK, msg.data: E000006505000456
14:17:00.904831 TESTFREQ 85: Frequency 905360000 (freqError=-715): OK, msg.data: 500000FF7500485B
14:22:36.596902 TESTFREQ 88: Frequency 905480000 (freqError=-855): OK, msg.data: E000006505000456
15:09:50.719534 TESTFREQ 110: Frequency 906360000 (freqError=26478): OK, msg.data: 9000000005003151
15:13:38.781187 TESTFREQ 112: Frequency 906440000 (freqError=3062): OK, msg.data: 8000006A85006CE7
15:15:28.968434 TESTFREQ 113: Frequency 906480000 (freqError=-5089): OK, msg.data: 600000FFC50079DA
16:02:58.523355 TESTFREQ 135: Frequency 907360000 (freqError=-1728): OK, msg.data: C00000047500955C
16:02:58.525352 TESTFREQ 136: Frequency 907400000 (freqError=6929): OK, msg.data: C00000047500955C
16:04:17.965477 TESTFREQ 137: Frequency 907440000 (freqError=6929): OK, msg.data: 500000FF7500485B
16:06:03.030503 TESTFREQ 138: Frequency 907480000 (freqError=-1742): OK, msg.data: 400000FFC5004CD2
16:57:25.756451 TESTFREQ 162: Frequency 908440000 (freqError=-1525): OK, msg.data: 500000FF7500485B
16:57:41.131232 TESTFREQ 163: Frequency 908480000 (freqError=875): OK, msg.data: 8000006BC500561B
17:49:06.408230 TESTFREQ 187: Frequency 909440000 (freqError=28537): OK, msg.data: 8000006DC500E4BB
18:00:51.103917 TESTFREQ 193: Frequency 909680000 (freqError=11774): OK, msg.data: C00000047500955C
18:11:11.237742 TESTFREQ 198: Frequency 909880000 (freqError=-2301): OK, msg.data: E000006505000456
18:40:57.322258 TESTFREQ 212: Frequency 910440000 (freqError=-5508): OK, msg.data: 500000FF7500485B
18:52:34.331178 TESTFREQ 218: Frequency 910680000 (freqError=7340): OK, msg.data: 500000FF7500485B
19:02:13.462738 TESTFREQ 223: Frequency 910880000 (freqError=736): OK, msg.data: 8000007245009071
19:02:13.464493 TESTFREQ 224: Frequency 910920000 (freqError=-2353): OK, msg.data: 8000007245009071
19:55:16.035833 TESTFREQ 248: Frequency 911880000 (freqError=26039): OK, msg.data: 500000FF7500485B
19:57:01.096119 TESTFREQ 249: Frequency 911920000 (freqError=593): OK, msg.data: C00000047500955C
19:58:51.284135 TESTFREQ 250: Frequency 911960000 (freqError=27251): OK, msg.data: 500000FF7500485B
19:59:11.782803 TESTFREQ 251: Frequency 912000000 (freqError=-6736): OK, msg.data: 500000FF7500485B
20:46:36.307858 TESTFREQ 273: Frequency 912880000 (freqError=-3067): OK, msg.data: 8000007745007B81
20:47:50.621221 TESTFREQ 274: Frequency 912920000 (freqError=4663): OK, msg.data: E000006505000456
20:49:43.372121 TESTFREQ 275: Frequency 912960000 (freqError=17203): OK, msg.data: E000006505000456
20:50:01.309265 TESTFREQ 276: Frequency 913000000 (freqError=-3303): OK, msg.data: 80000077C5006019
21:43:14.231848 TESTFREQ 300: Frequency 913960000 (freqError=-2635): OK, msg.data: 500000FF7500485B
21:44:43.921493 TESTFREQ 301: Frequency 914000000 (freqError=45): OK, msg.data: E000006505000456
21:51:15.987745 TESTFREQ 304: Frequency 914120000 (freqError=24336): OK, msg.data: 500000FF7500485B
22:35:46.157460 TESTFREQ 325: Frequency 914960000 (freqError=1673): OK, msg.data: 8000007AC5002248
22:59:12.992657 TESTFREQ 336: Frequency 915400000 (freqError=9315): OK, msg.data: E000007805000564
23:28:33.459265 TESTFREQ 350: Frequency 915960000 (freqError=4902): OK, msg.data: 8000007C45008B70
23:52:46.393871 TESTFREQ 361: Frequency 916400000 (freqError=17857): OK, msg.data: C00000047500955C
00:46:35.230736 TESTFREQ 386: Frequency 917400000 (freqError=-619): OK, msg.data: C00000047500955C
00:49:24.360163 TESTFREQ 388: Frequency 917480000 (freqError=637): OK, msg.data: E000007D0500EE94
00:50:10.486491 TESTFREQ 389: Frequency 917520000 (freqError=-7660): OK, msg.data: A00000F775007046
01:37:34.897589 TESTFREQ 411: Frequency 918400000 (freqError=-3584): OK, msg.data: E000007D0500EE94
01:41:02.463375 TESTFREQ 413: Frequency 918480000 (freqError=3373): OK, msg.data: 500000FF7500485B
01:42:39.840615 TESTFREQ 414: Frequency 918520000 (freqError=-3730): OK, msg.data: 8000007CC50090E8
02:31:13.454254 TESTFREQ 436: Frequency 919400000 (freqError=-697): OK, msg.data: E000007D0500EE94
02:34:12.833575 TESTFREQ 438: Frequency 919480000 (freqError=6030): OK, msg.data: C00000047500955C
02:34:35.896333 TESTFREQ 439: Frequency 919520000 (freqError=-856): OK, msg.data: 800000854500F6B3
02:41:07.966804 TESTFREQ 442: Frequency 919640000 (freqError=22278): OK, msg.data: E000007D0500EE94
03:25:40.663092 TESTFREQ 463: Frequency 920480000 (freqError=-275): OK, msg.data: 80000088C500AF7A
03:26:39.599498 TESTFREQ 464: Frequency 920520000 (freqError=1975): OK, msg.data: 600000FFC50079DA
03:48:26.559736 TESTFREQ 474: Frequency 920920000 (freqError=27548): OK, msg.data: E000007D0500EE94
04:18:17.783966 TESTFREQ 488: Frequency 921480000 (freqError=-8099): OK, msg.data: 8000008C050065EE
04:29:49.673752 TESTFREQ 494: Frequency 921720000 (freqError=5216): OK, msg.data: 500000FF7500485B
04:39:28.815406 TESTFREQ 499: Frequency 921920000 (freqError=-2355): OK, msg.data: 8000008A8500CCD6
05:23:02.638014 TESTFREQ 519: Frequency 922720000 (freqError=-430): OK, msg.data: 8000008A4500DA82
05:33:25.340112 TESTFREQ 524: Frequency 922920000 (freqError=1704): OK, msg.data: 9000000005003151
05:38:43.098795 TESTFREQ 527: Frequency 923040000 (freqError=-564): OK, msg.data: C00000047500955C
06:27:19.258381 TESTFREQ 549: Frequency 923920000 (freqError=27268): OK, msg.data: E000007D0500EE94
06:28:13.076492 TESTFREQ 550: Frequency 923960000 (freqError=2164): OK, msg.data: 500000FF7500485B
06:30:03.274780 TESTFREQ 551: Frequency 924000000 (freqError=29429): OK, msg.data: E000007D0500EE94
06:30:23.777042 TESTFREQ 552: Frequency 924040000 (freqError=-5957): OK, msg.data: E000007D0500EE94
07:18:36.941811 TESTFREQ 574: Frequency 924920000 (freqError=-1264): OK, msg.data: 500000FF7500485B
07:18:36.943822 TESTFREQ 575: Frequency 924960000 (freqError=5393): OK, msg.data: 500000FF7500485B
07:19:35.879817 TESTFREQ 576: Frequency 925000000 (freqError=5398): OK, msg.data: E000007D0500EE94
07:21:36.319616 TESTFREQ 577: Frequency 925040000 (freqError=-2662): OK, msg.data: 80000090050053EC
08:13:04.197004 TESTFREQ 601: Frequency 926000000 (freqError=-1132): OK, msg.data: E000007D0500EE94
08:14:21.072311 TESTFREQ 602: Frequency 926040000 (freqError=2596): OK, msg.data: A0000078850074EC
09:05:54.058956 TESTFREQ 626: Frequency 927000000 (freqError=28377): OK, msg.data: 500000FF7500485B
09:17:31.048838 TESTFREQ 632: Frequency 927240000 (freqError=-9307): OK, msg.data: 500000FF7500485B

Thanks
Paul



kobuki

unread,
Mar 16, 2019, 11:37:52 AM3/16/19
to weewx-development
"Explanation: the frequencies of the original rtldavis program and the sorted RFM69 frequencies all differ about 26000 Hz from each other."

It's worth noting that there are too many unknown variables here. Questions:
 - Do we know that the original rtldavis author used a frequency offset calibrated device, ie. his frequencies are correct?
 - Do you all use calibrated (or at least offset corrected) SDR radios? If not, you need to determine the offset and apply it.
 - Does the RFM69 Arduino/Moteino code work for your stations? If so, then the RFM69 frequencies are correct, and the original rtldavis frequencies are most likely incorrect.

Since I've multiple reports (including the original RFM69 code author, Dekay) that the RFM69 frequencies for US are working, I'm positive they should work for a calibrated SDR stick, too.

rich T

unread,
Mar 16, 2019, 11:43:55 AM3/16/19
to weewx-development
Paul

Yes, the Vantage Pro 2 hops between 51 frequencies.  I'm 12 hours in with the second 24 hr test (ppm offset included in test range).  My station batteries should arrive today, so going to run additional 24 hr test with brand new batteries.

Rich

kobuki

unread,
Mar 16, 2019, 11:51:07 AM3/16/19
to weewx-development
Looking at your log, I see some frequency errors that are quite large at 25-30 kHz (more than the required FSK bandwidth for original equipment), and a lot of the errors are larger than 10kHz, while the bulk of them are way under 10kHz. The packets with high offset errors are most likely neighboring frequencies catched while tuned to another neighbor. Or the chosen reception bandwidth is too wide to catch the desired frequency and the receiver auto-corrects to some degree while reporting a false frequency. I think the reception bandwidth should be narrower for the test to work. The original receivers use 25 kHz bandwidth. I think the testing frequency sweep should be taking this into consideration.

kobuki

unread,
Mar 16, 2019, 12:20:21 PM3/16/19
to weewx-development
I've made a small spreadsheet using the original RFM69 US frequency table. It can be observed that the 51 hopping frequencies are about 502 kHz apart when sorted in increasing order. This is about 2 times the used carrier bandwidth. There are only sub-kHz fluctuations in the differences between neighboring frequencies. These frequencies have been collected from the SPI bus of the radio receiver IC in a console configured for the US band, and then converted to literal frequencies, then into a data array required for programming the RFM69 chips. They're not perfectly uniform because the firmware of the console applies a small correction when tuning onto them - however, these very small errors should be handled in any receiver and pose no problem at all. I'm still of the opinion that one can just use the table in the RFM69 code without frequency testing and scanning. All errors are most likely attributable to the frequency error and temperature skew of cheaper SDR sticks which are not properly calibrated or at least manually offset corrected to a certain degree.

kobuki

unread,
Mar 16, 2019, 12:21:28 PM3/16/19
to weewx-development
A typo fix: ... This is about 20 times the used carrier bandwidth ...

kobuki

unread,
Mar 16, 2019, 1:16:20 PM3/16/19
to weewx-development
Re-doing what others have done in this and the other thread in weewx-user, I can conclude that the Golang rtldavis frequencies are most likely wrong. If we take the original SPI-sniffed Davis frequency values as a standard, the rtldavis frequencies are off by -26,3 kHz or -28,75 ppm on average, with almost negligible deviation. Thus I think the original author forgot to offset-correct the frequencies in the source. They are probably spot on with his own SDR stick, though.

ljm.h...@gmail.com

unread,
Mar 16, 2019, 2:18:26 PM3/16/19
to weewx-development
Hi Paul,

The idea is to first get a raw list of US hop frequencies.
The second step is to correct the found frequency with the reported freqError.
Then we look at the sorted list of ‘corrected’ frequencies and calculate the differences between each two adjacent frequencies, so we will detect any likely missed frequencies.
At last interpolate values for the ‘missed’ frequencies.
When all frequencies are more or less right, we can add them to the program and start the normal hopping proces.
At last we will use the average freqError per channel to fine-tune the frequency list.

Luc

kobuki

unread,
Mar 16, 2019, 2:34:19 PM3/16/19
to weewx-development
You're on the wrong path, guys. I'd suggest paying more attention to the subject instead of doing wild experiments and inform yourselves using available and proven information. Paul's frequencies are waaay off. Even if corrected with the error value, they have nothing to do with the original Davis frequencies. The frequency sweep WILL find bogus frequencies, because the SDR stick is not a precise narrowband receiver. The chips are originally made for digital terrestrial and analog radio reception for several hundred kHz to low MHz bandwidths.

Consider this: the Davis uses a bandwidth of 25 kHz and an FSK deviation of 19.8 kHz (double-sided). Hopping slots are allocated 502 kHz apart. If you skip when sweeping by 40 kHz, no way in life will you find the proper frequencies, ever. I guess the SDR FSK decoder code is not very well tuned to the task at hand, and while I admit I haven't programmed any SDR task, even though I know the theory behind it.

To re-iterate: there is no need to "find" the proper frequencies, they are available in the RFM69 Arduino code. You do need to find and fix your offset on your sticks before starting rtlsdr, though. Or use precise ~1ppm devices. Your scanned frequencies will be local to your setup, they most probably will not work reliably for anyone else!
Message has been deleted

kobuki

unread,
Mar 16, 2019, 3:19:23 PM3/16/19
to weewx-development
Luc,

Please don't use all caps. It's rude and is considered shouting per internet standards. Thanks. Since I have a lot of experience with these transmitters and receivers, I'm trying to help here. No need for the tone.

And, I was talking about the US frequency scan and the relation between the Arduino code table and the one in rtldavis, not the EU frequencies. Please read my messages again. Although the EU frequencies should be the same for both the Arduino code and the rtlsdr code. There is no difference in the transmitters. If one works with a given set of frequencies, so will the other. You're set out to ignore established facts and others' valuable research and their time spent with it. I'm not trying to tell anyone what to do, but I'd like to point that out and try to keep you from doing the hard work already done by others - that is what I meant by wrong path. I haven't myself sniffed the frequency tables, but I'm using the frequencies with success for years for the EU band. And those sniffed frequencies ARE the correct ones, according to multiple reports I have received during the years.

So, in my opinion the culprit is most probably the FSK code itself or the stick's imprecise tuning. These are the 2 ones to consider first and foremost. The first is obviously wrong as the frequencies are shifted by a constant (possibly the original author's ppm error on his SDR radio). It can be easily fixed. The second - I have no experience in coding the FSK decoder part so I can't possibly work on that right now.

If you do intend to do the scanning to verify the facts (which is a completely normal thing to do in a research), please consider the radio parameters I mentioned in my earlier posts.

As soon as I have the necessary time, I'll test code thoroughly, you can count on me.

On Saturday, March 16, 2019 at 8:02:01 PM UTC+1, ljm.h...@gmail.com wrote:
On Saturday, 16 March 2019 15:34:19 UTC-3, kobuki wrote:
You're on the wrong path, guys.

HI KOBUKI,

I SUGGEST YOU FIRST INSTALL THE RTLDAVIS PROGRAM AN INSERT YOUR FREQUENCIES IN THE EU TABLE.
THEN RUN THE PROGRAM AND TELL US WHAT WE ARE DOING WRONG.

LUC 

ljm.h...@gmail.com

unread,
Mar 16, 2019, 3:25:04 PM3/16/19
to weewx-development
On Saturday, 16 March 2019 16:19:23 UTC-3, kobuki wrote:
As soon as I have the necessary time, I'll test code thoroughly, you can count on me.

Thanks in advance, kobuki 

kobuki

unread,
Mar 16, 2019, 4:15:25 PM3/16/19
to weewx-development
Alright, another bit of info which might be useful. Back a couple of years ago when analyzing the Davis packet structure, coding, FSK parameters, etc., I did a very simple test in SDR#. I set it on the center of the EU band, zoomed around +-500 kHz into view and observed the small sausages originating from the transmitters around the house. They were all over the place until I learned to correct the offset of my SDR stick (since then I purchased a 1ppm one). After I found applied the proper offset of my stick (used Kalibrate, but there are better tools now), the spots started to appear within about 5 kHz of their expected frequencies (I'm fine with that precision, it's a cheap stick, not a calibrated VNA). I calculated the frequencies from the Davis Arduino code table. For me it alone confirms that the frequencies are right and well known. Thus they can be used for rtldavis, too, as is. For anyone in the mood, I suggest trying this simple method out to re-verify the frequencies.

Of course I'm eager to try your code as well, soon.

ljm.h...@gmail.com

unread,
Mar 16, 2019, 4:44:35 PM3/16/19
to weewx-development
kobuki,

As I stated earlier: I do not know any ins and outs of the RTL-SDR hardware and/or programs.

I came across program tfrec and without any modifications this program read the temperatures and humidities of my TFA KlimaLogg sensors.
For this purpose I bought two RTL-SDR dongles and ordered a third one in China (not delivered yet).

Later I came across program rtldavis and I tried to get the program working. The original EU frequencies were NOT working here.
With the set I found by trial and error I can read three (or four if I want) of my Davis transmitters at once. These EU frequency set has no constant offset with the EU RFM69 frequencies BTW.
I can't explain why this is working and the RFM69 frequencies not. 
To my knowledge, the main.go program doesn't do anything special. It just calls the SetCenterFreq with help of the the gortlsdr package to the rtl-sdr driver, see code below.

// SetCenterFreq sets the center frequency.
func (dev *Context) SetCenterFreq(freqHz int) (err error) {
i := int(C.rtlsdr_set_center_freq((*C.rtlsdr_dev_t)(dev),
C.uint32_t(freqHz)))
return libError(i)
}

See the results on my website (http://www.lucdesign.nl/_weewx/rtld/index.html) where I show the differences between values measured by the meteostick dongle and weewx-meteostick versus a RTL-SDR dongle with programs rtldavis and weewx-rtld.

Luc

ljm.h...@gmail.com

unread,
Mar 16, 2019, 4:50:04 PM3/16/19
to weewx-development
kobuki,

May be here is the difference...

Below are the outputs of rtldavis at startup. Do you notice anything special at these settings?

Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.699861 BitRate: 19200
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.699886 SymbolLength: 14
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.699901 SampleRate: 268800
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.699987 Preamble: 1100101110001001
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.700006 PreambleSymbols: 16
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.700020 PreambleLength: 224
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.700032 PacketSymbols: 80
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.700046 PacketLength: 1120
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.700059 BlockSize: 512
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: 15:20:37.700072 BufferLength: 2048
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: Found Rafael Micro R820T tuner
Mar 15 15:20:38 pi36 rtld[7801]: rtldavis: info: Exact sample rate is: 268800.001367 Hz

Luc

kobuki

unread,
Mar 16, 2019, 4:55:10 PM3/16/19
to weewx-development
"With the set I found by trial and error I can read three (or four if I want) of my Davis transmitters at once. These EU frequency set has no constant offset with the EU RFM69 frequencies BTW."

Ah, OK. A misunderstanding - I was talking about the US frequencies which are stored in the Golang code and the RFM69 code too. I can't tell anything about the EU ones, since they are not in the Golang code.

kobuki

unread,
Mar 16, 2019, 5:00:21 PM3/16/19
to weewx-development
Bitrate is OK, but the preamble is off, it should be 0xAAAA (alternating 1 and 0). If a bit is a symbol here, then PreambleSymbols and PacketSymbols look right. I'm not sure what the length values mean here. At the very least, they're not the reciprocal of the bit rate.

ljm.h...@gmail.com

unread,
Mar 16, 2019, 5:03:28 PM3/16/19
to weewx-development
On Saturday, 16 March 2019 17:55:10 UTC-3, kobuki wrote:
 I can't tell anything about the EU ones, since they are not in the Golang code.

For the EU frequencies (and more), see my fork of rtldavis on github: https://github.com/lheijst/rtldavis 

Luc

nls

unread,
Mar 16, 2019, 5:06:39 PM3/16/19
to L.J.M. Heijst, weewx-development
OK, thanks. I'll try to look into this in the upcoming week, but so far I have been deterred by my work... Believe me, I'd rather indulge myself in this new code than anything else. Things are being a bit hard for me since I don't have US transmitters, only EU ones, so I'll only be able to test those.

ljm.h...@gmail.com

unread,
Mar 16, 2019, 5:30:53 PM3/16/19
to weewx-development
On Saturday, 16 March 2019 18:00:21 UTC-3, kobuki wrote:
Bitrate is OK, but the preamble is off, it should be 0xAAAA (alternating 1 and 0).

With a preamble of "1010101010101010", no messages were received. Neither with my set frequencies, nor with the RFM69 frequencies.

if tf == "EU" {
p.channels = []int{ 
// 868072000, 868192000, 868312000, 868432000, 868552000, // original set that worked
// 868073575, 868192150, 868312125, 868433150, 868553825, // ok trial-error set
868078500, 868199000, 868318500, 868438500, 868560000, // best trial-error set
// 868066711, 868181885, 868297119, 868412292, 868527466, // RFM69 EU frequencies
}

nls

unread,
Mar 16, 2019, 5:49:47 PM3/16/19
to L.J.M. Heijst, weewx-development
That's not exactly good news... If you get less than 16 bits of alternating 0 and 1 values, that's still better. Well, the decoder sems to handle the packets themselves when a reception does occur, but I'd rather see it decode every single bit properly, including the preamble. A fixed set of 0xAA or 0x55 values is pretty standard for an FSK preamble, btw. That aside, if the bad preamble were the only problem, we wouldn't complain, would we.

ljm.h...@gmail.com

unread,
Mar 16, 2019, 8:50:06 PM3/16/19
to weewx-development
On Saturday, 16 March 2019 17:44:35 UTC-3, ljm.h...@gmail.com wrote:
With the set I found by trial and error I can read three (or four if I want) of my Davis transmitters at once. These EU frequency set has no constant offset with the EU RFM69 frequencies BTW.

I found a correlation formula between the RFM69 frequencies and my EU trial-and-error frequency set.

rtldavis frequency = (RFM69 frequency -40000000) * 1,048319523

These calculated rtldavis frequencies DO work!

Excel gave the following equation: y = 1.0439x - 4E+07, but the factor was not precise enough.

The results:

RFM69 rtldavis
868066711 868078500
868181885 868199238
868297119 868320041
868412292 868440779
868527466 868561518

Luc

nls

unread,
Mar 16, 2019, 8:58:37 PM3/16/19
to L.J.M. Heijst, weewx-development
Wow. So the offset is progressively getting worse by increasing frequency? Interesting find. Sounds like some calculation mishap in the demodulator code. Now, that's one part no one is very familiar with, except for the original author who abandoned the code... Maybe something similar is happening in the US band.

ljm.h...@gmail.com

unread,
Mar 16, 2019, 9:27:13 PM3/16/19
to weewx-development
Kobuki,

Yes, when I create a scatterplot of the two sets US frequencies they appear as (almost) a straight line.
May be we can do a correlation for a few found frequencies with a low frequency error.

And I agree with you that somewhere in the rtldavis software an error is made. The challenge is to find out where and what.

Luc

Message has been deleted

rich T

unread,
Mar 16, 2019, 10:38:48 PM3/16/19
to weewx-development

Luc

Here is a comparison of test frequencies between both of the stations. 

Rich

Test Freq Comparision.png

Greg Troxel

unread,
Mar 17, 2019, 7:56:28 PM3/17/19
to ljm.h...@gmail.com, weewx-development
ljm.h...@gmail.com writes:

> I found a correlation formula between the RFM69 frequencies and my EU
> trial-and-error frequency set.
>
> rtldavis frequency = (RFM69 frequency -40000000) * 1,048319523
>
> These calculated rtldavis frequencies DO work!
>
> Excel gave the following equation: y = 1.0439x - 4E+07, but the factor was
> not precise enough.
>
> The results:
>
> RFM69 rtldavis
> 868066711 868078500
> 868181885 868199238
> 868297119 868320041
> 868412292 868440779
> 868527466 868561518

It would be interesting to really understand what's going on. It seems
like the "RFM69 frequencies" are what is programmed into the
transmitter, and I wonder if that is the intended transmit frequency or
if there is some IF involved. It would be interesting to also sniff the
RFM69 receive chip frequencies at the console.

And, to measure the actual frequencies with test equipment, or something
that can be relied upon to be reaosnably accurate because of
calibration.

When I saw the formula above, I suspected a 40 MHz IF and was suspicious
of the 1.048ish factor. But I wonder what that would look like if it
were fit with different assumptions about the base formula.

Overall, something seems wrong in code somewhere, as a change of 12 kHz
offset to a 35 kHz offset over 500 kHz does not seem plausible.

I'll try to run this and see if I can spot anything.

nls

unread,
Mar 17, 2019, 8:07:51 PM3/17/19
to Greg Troxel, L.J.M. Heijst, weewx-development
As mentioned earlier, the frequencies were sniffed in original VP2 consoles (you can find the posts about that in wxforum threads). They're the GFSK center frequencies, no IF. The "RFM69 frequencies" just mean the ones programmed into the firmware of small Arduino clone based receivers using an RFM69 transceiver module. Also noted that with a simple SDR receiver the packets are appearing at the expected frequency. It's possibly a simple overlook with handling frequencies or frequency correction in the SDR demodulator code. I think any help or ideas come handy.

Greg Troxel

unread,
Mar 18, 2019, 8:05:27 AM3/18/19
to nls, L.J.M. Heijst, weewx-development
nls <nls...@gmail.com> writes:

> As mentioned earlier, the frequencies were sniffed in original VP2 consoles
> (you can find the posts about that in wxforum threads). They're the GFSK
> center frequencies, no IF. The "RFM69 frequencies" just mean the ones
> programmed into the firmware of small Arduino clone based receivers using
> an RFM69 transceiver module. Also noted that with a simple SDR receiver the
> packets are appearing at the expected frequency. It's possibly a simple
> overlook with handling frequencies or frequency correction in the SDR
> demodulator code. I think any help or ideas come handy.

If I follow then, the RFM69 list matches both the VP2 console sniffing
and the Arduino RFM69 code, and those arduino projects are known to
work. And the RFM69 frequencies have been confirmed with SDR code not
involving rtldavis. So it is clear that there is a bug in the rtldavis
code and of course somebody needs to find it. Is that right?

I will have a look.

nls

unread,
Mar 18, 2019, 8:09:02 AM3/18/19
to Greg Troxel, L.J.M. Heijst, weewx-development
Yes, you summed up correctly. All things point to the fact