Receiving Davis Vantage weather data with a RTL-SDR dongle

[Luc Heijst]

Recently my attention was brought to a SDR tool for receiving wireless sensor data (TFA IT+ KlimaLogg Pro, LaCrosse, WeatherHub). See: https://github.com/baycom/tfrec.

I wrote a weewx driver which parsed and stored the tfrec data of my 9 KlimaLogg sensors. The weewx driver can be found here: https://github.com/matthewwall/weewx-tfrc

After this success I searched for a package that reads the radio data of Vantage Pro weather stations with a (cheap) RTL-SDR dongle and found: the rtldavis package on: https://github.com/bemasher/rtldavis.

With this package were a few problems:

1. The development of the package stopped three years ago.

2. The set of European frequencies appeared not to be useful.

3. The package could only handle one transmitter (at a time).

4. The package is written in GO. Not a big issue, but the GO language is new for me.

With two Vantage Pro2 systems, an anemometer station and a leaf-soil station the challenge was to get this package concurrently working for more than one transmitter (four in my case).

With some modifications of main.go and protocol.go and trial and error I could find a reasonable set of the European frequencies which are used in the frequency hop sequence.

The next step was to get the data of more than one sensor wich each its own hopping timing. 

The last step will be to parse the data packets and store the data in Weewx. This part is easy because this was already done by me via the parsing of the raw meteostick data in the weewx-meteostick driver, see: https://github.com/matthewwall/weewx-meteostick.

The hopping mechanism has some prograss today. The principle is as follows.

1. Wait long enough on a fixed frequency until you have seen at least one message of each transmitter. For the five EU frequencies this process takes 17 seconds or less. For the 51 US frequencies this will take about ten times as much time.

2, Calculate with help of the lastVisitedTimes of all transmitters what the nextVisitTimes (in the near future) will be and how many hops would be needed to get here.

3. Detect the smallest nextVisitTime. This will be of the transmitter which follows first.

4. Calculate the hop channel for this transmitter.

5. Calculate the loopPeriod for this transmitter. In case the signal of this transmitter is missed we don't want to wait too long and miss packets of other transmitters too.

6. Start the hop process and wait for new data.

I combined the weewx-sdr and weewx-meteostick drivers fr this weewx-rtld driver.

The results so far:

The first 1000 messages were read with the new driver.

Average percentage of received signals is 94,8 %, see table.

     ok missed tot  pctGood

     341  19     360  94,7

     335  16     351  95,4

     324  20     344  94,2

    ----  --    ----  ---- 

tot 1000  55 1055  94,8

The FreqError in general varies between -1000 and +1000.

When abs(FreqError) > 10000 the weewx-rtld driver will restart program rtldavis.

For a comparison between the Meteostick and rtld driver data see: http://www.lucdesign.nl/_weewx/bootstrap_rtld/hour.html

There is one challence left: how to get local barometer data in my Raspberry PI? 

I could use a BMP280 pressure/temp sensor... so, more to come.

Cheers, Luc

[Thomas Keffer]

Impressive, Luc. I admire your persistence!

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Luc Heijst]

On Monday, 4 March 2019 10:40:00 UTC-3, Thomas Keffer wrote:

Impressive, Luc. I admire your persistence!

Thanks, Tom! 

When I looked at the rtldavis package I had the feeling it could be done, although I know nothing about radio signals and the rtl-sdr library.

I still have to discover why the frequency errors sometimes have huge differences.

The average frequency errors vary with the temperature of the dongle (i.e. the room temperature of the raspberry pi), which can be explained for cheap rtl-sdr dongles without temperature compensation.

I plan to hook up a pressure sensor (BMP280) to make the weewx_rtld driver complete.

[rich T]

Switch several of my older dongles to this one: https://www.amazon.com/dp/B01HA642SW/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B01HA642SW&pd_rd_w=JtW8R&pf_rd_p=733540df-430d-45cd-9525-21bc15b0e6cc&pd_rd_wg=fH2H2&pf_rd_r=YKVSGSYAFB36QD0YPV4W&pd_rd_r=2faf93c1-3ed6-11e9-936e-01fa71378c68 .  This dongle seems not to drift much at the higher frequencies.

[Luc Heijst]

On Monday, 4 March 2019 20:41:52 UTC-3, rich T wrote:

Switch several of my older dongles to this one: https://www.amazon.com/dp/B01HA642SW/ref=sspa_dk_detail_2?psc=1&pd_rd_i=B01HA642SW&pd_rd_w=JtW8R&pf_rd_p=733540df-430d-45cd-9525-21bc15b0e6cc&pd_rd_wg=fH2H2&pf_rd_r=YKVSGSYAFB36QD0YPV4W&pd_rd_r=2faf93c1-3ed6-11e9-936e-01fa71378c68 .  This dongle seems not to drift much at the higher frequencies.

Thanks, Rich.

When I need another SDR I will buy the combi-set with the 3 antennas.

For testing my driver I better use 'bad quality' SDR's though!

Luc 

[Ruben Navarro Huedo]

Luc: Tell me if you need beta-testing.

I was testing some time ago rtldavis and i hadn't good success.

Now i am receiving my Davis with a Moteino.

Looking for your news ;-)

[Pat]

Impressive! I am using a Moteino and have a 2nd on "standby" as a backup. I have 3 of the RTLSDR, so this could be something fun to try in my spare time when I come across some of that!

[jude mwenda]

Sorry, newbie here without a Davis Pro. Is it because getting the data out into the weewx is inconsistent? or not working?

--

You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Jude Mwenda

[Luc Heijst]

Hi Ruben,

The python and go programs are ready for alpha-testing.

What need to be done is:

• Write installation and user instructions
• Remove personal data from the programs like skins, passwords etc. 
• Create a deliver zip file
• Test the installation
• Currently there is no provision for pressure (barometer) data; we need a pressure sensor and code in the driver to read the sensor data 

Luc

[Ruben Navarro Huedo]

I will wait for it Luc.

[Luc Heijst]

Hi Jude,

There are several ways to read the weather data of Vantage Pro and Vue stations.

• Via a Davis datalogger inserted in the Davis console
• Via a Meteostick
• Via a Moteino module
• Via various other modules I can't come up now

All modules are working fine.

My program adds another way:

• Via a RTL-SDR dongle (it's not new, I combined and modified existent programs)

Luc

[mwall]

On Tuesday, March 5, 2019 at 4:45:23 PM UTC-5, Luc Heijst wrote:

The python and go programs are ready for alpha-testing.

What need to be done is:

• Currently there is no provision for pressure (barometer) data; we need a pressure sensor and code in the driver to read the sensor data 

luc, please do NOT put barometer code into any sdr driver.  reading pressure from the bme or other pi/arduino-specific hardware does not belong in an sdr driver.  it belongs in a separate service.

m

[Luc Heijst]

On Tuesday, 5 March 2019 19:23:31 UTC-3, mwall wrote:

luc, please do NOT put barometer code into any sdr driver.  reading pressure from the bme or other pi/arduino-specific hardware does not belong in an sdr driver.  it belongs in a separate service.

m

Thanks for the explanation, Matthew. What I meant was a provision for reading the barometer code on the same machine as the sdr driver. I did not study yet what and how.

Luc 

[Luc Heijst]

Modified rtldavis package available for download.

OK, for you who can't wait!  

I have put the modified rtldavis package on my github account, see: https://github.com/lheijst/rtldavis

This package reads the raw data packets from the configured stations and output them on stderr.

Comments are welcome.

The weewx-rtldavis driver (not published yet) will read and parse this data and store the values in the weewx database.

More to come.

Luc

[rich T]

Luc

It seems to run about one minute then crashes.  I have a Vantage Pro 2 and using a NESDR SMART dongle.  This is what I get:

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ $GOPATH/bin/rtldavis -tf US 

22:58:59.859978 rtldavis.go VERSION=0.7

22:58:59.860466 tr=1 actChan=[0] maxChan=1 *transmitterId=0 msgIdToChan=[0 9 9 9 9 9 9 9]

22:58:59.860586 idLoopPeriods=[2562500000 2625000000 2687500000 2750000000 2812500000 2875000000 2937500000 3000000000]

22:58:59.861395 BitRate: 19200

22:58:59.861436 SymbolLength: 14

22:58:59.861473 SampleRate: 268800

22:58:59.861507 Preamble: 1100101110001001

22:58:59.861541 PreambleSymbols: 16

22:58:59.861575 PreambleLength: 224

22:58:59.861610 PacketSymbols: 80

22:58:59.861645 PacketLength: 1120

22:58:59.861678 BlockSize: 512

22:58:59.861713 BufferLength: 2048

Detached kernel driver

Found Rafael Micro R820T tuner

22:59:00.529803 main.go:157: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:0}

Exact sample rate is: 268800.001367 Hz

22:59:00.707256 Init loopTimer and wait for messages on channel 0: loopTimer=273432576 idLoopPeriods=2562500000 loopPeriod=133250000000

22:59:25.800501 msg.Data: 5800B5FF7000F778

Reattached kernel driver

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ $GOPATH/bin/rtldavis -tf US 

23:02:15.586937 rtldavis.go VERSION=0.7

23:02:15.587550 tr=1 actChan=[0] maxChan=1 *transmitterId=0 msgIdToChan=[0 9 9 9 9 9 9 9]

23:02:15.587674 idLoopPeriods=[2562500000 2625000000 2687500000 2750000000 2812500000 2875000000 2937500000 3000000000]

23:02:15.588496 BitRate: 19200

23:02:15.588541 SymbolLength: 14

23:02:15.588584 SampleRate: 268800

23:02:15.588618 Preamble: 1100101110001001

23:02:15.588652 PreambleSymbols: 16

23:02:15.588687 PreambleLength: 224

23:02:15.588721 PacketSymbols: 80

23:02:15.588756 PacketLength: 1120

23:02:15.588790 BlockSize: 512

23:02:15.588825 BufferLength: 2048

Detached kernel driver

Found Rafael Micro R820T tuner

23:02:16.287362 main.go:157: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:0}

Exact sample rate is: 268800.001367 Hz

23:02:16.464612 Init loopTimer and wait for messages on channel 0: loopTimer=272713344 idLoopPeriods=2562500000 loopPeriod=133250000000

23:02:19.621126 msg.Data: E900B5430000CAB3

Reattached kernel driver

Thanks 

Rich

[Luc Heijst]

Hi Rich,

The two messages you received should have 0 as second digit (the transmitter id: which should be in the range 0-7), but they are 8 and 9. Those messages. should not have passed the crc check.
Another thing: I could not test the program with the US frequencies, so one or more frequency might be wrong.
The original driver started with a random frequency channel, but mine always starts with channel 0.
I will have to add more debug logging to get an idea what is happening.
More to come.
Luc

[Luc Heijst]

Hi Rich,

The ‘8’ message can be declared, it is channel 0 with the battery-low bit set. The ‘9’ message should be channel 1 with also the battery-low bit set.
The program logs all received messages, so also from Vantage Pro and Vue systems in the neigbourhood.

Luc

[Luc Heijst]

Hi Rich,

On Monday, 11 March 2019 02:24:29 UTC-3, Luc Heijst wrote:

The ‘8’ message can be declared, it is channel 0 with the battery-low bit set. 

 I found the problem for the array out of bound violation.

Fixed bug where battery-low bit wasn't filtered out (commit 24adb68)

Luc

[rich T]

Hi Luc

The battery-low bug is now corrected. I'm capturing packets, does not look like I'm capturing everything.  According to the 6312 operational description, for the US version, it hops through 51 channels between 902 and 928 MHz.  Below is what I captured so far.

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ $GOPATH/bin/rtldavis  -tf US

19:27:55.285951 rtldavis.go VERSION=0.7

19:27:55.286440 tr=1 actChan=[0] maxChan=1 *transmitterId=0 msgIdToChan=[0 9 9 9 9 9 9 9]

19:27:55.286567 idLoopPeriods=[2562500000 2625000000 2687500000 2750000000 2812500000 2875000000 2937500000 3000000000]

19:27:55.287358 BitRate: 19200

19:27:55.287399 SymbolLength: 14

19:27:55.287438 SampleRate: 268800

19:27:55.287473 Preamble: 1100101110001001

19:27:55.287509 PreambleSymbols: 16

19:27:55.287543 PreambleLength: 224

19:27:55.287577 PacketSymbols: 80

19:27:55.287611 PacketLength: 1120

19:27:55.287645 BlockSize: 512

19:27:55.287679 BufferLength: 2048

Detached kernel driver

Found Rafael Micro R820T tuner

19:27:56.037530 main.go:157: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:0}

Exact sample rate is: 268800.001367 Hz

19:27:56.223448 Init loopTimer and wait for messages on channel 0: loopTimer=272712384 idLoopPeriods=2562500000 loopPeriod=133250000000

19:29:35.108539 msg.Data: E900B0440100C057

19:30:05.354302 msg.Data: E800B044010085F7

19:30:05.354701 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0]

19:30:05.354902 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552347005354288715] visitCount=1 chLastHops=[0]

19:30:05.355025 last seen msg.Data: E800B044010085F7

19:30:05.355217 Hop to channelIdx: 19 19:30:07.916788 ID=0

19:30:05.355792 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889094 FreqError:-7468}

19:30:07.980858 ID:0 packet missed

19:30:07.981076 loopTimer expired; hop to channelIdx: 41 19:30:10.479288 ID=0

19:30:07.981254 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927605 FreqError:-7468}

19:30:10.542739 ID:0 packet missed

19:30:10.542895 loopTimer expired; hop to channelIdx: 25 19:30:13.041788 ID=0

19:30:10.543004 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914899597 FreqError:-7468}

19:30:13.104798 ID:0 packet missed

19:30:13.105144 loopTimer expired; hop to channelIdx: 8 19:30:15.604288 ID=0

19:30:13.105284 main.go:185: Hop: {ChannelIdx: 8 ChannelFreq:906369839 FreqError:-7468}

19:30:15.668319 ID:0 packet missed

19:30:15.668493 Init channels: wait for messages

19:30:15.668653 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-7468}

19:31:48.985088 msg.Data: E900B0440100C057

19:32:16.043823 msg.Data: 8800B01B090021B9

19:32:16.044035 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0]

19:32:16.044467 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552347136043811689] visitCount=1 chLastHops=[0]

19:32:16.044633 last seen msg.Data: 8800B01B090021B9

19:32:16.044806 Hop to channelIdx: 19 19:32:18.606311 ID=0

19:32:16.044975 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889094 FreqError:-7438}

19:32:18.670405 ID:0 packet missed

19:32:18.670632 loopTimer expired; hop to channelIdx: 41 19:32:21.168811 ID=0

19:32:18.670829 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927605 FreqError:-7438}

19:32:21.232390 ID:0 packet missed

19:32:21.232813 loopTimer expired; hop to channelIdx: 25 19:32:23.731311 ID=0

19:32:21.232959 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914899597 FreqError:-7438}

19:32:23.794997 ID:0 packet missed

19:32:23.795275 loopTimer expired; hop to channelIdx: 8 19:32:26.293811 ID=0

19:32:23.795414 main.go:185: Hop: {ChannelIdx: 8 ChannelFreq:906369839 FreqError:-7438}

19:32:26.357017 ID:0 packet missed

19:32:26.357146 Init channels: wait for messages

19:32:26.357303 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-7438}

19:34:02.864249 msg.Data: E900B0440100C057

19:34:26.733503 msg.Data: 9800B000010BB06D

19:34:26.733814 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0]

19:34:26.734119 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552347266733489378] visitCount=1 chLastHops=[0]

19:34:26.734244 last seen msg.Data: 9800B000010BB06D

19:34:26.734435 Hop to channelIdx: 19 19:34:29.295989 ID=0

19:34:26.734706 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889094 FreqError:-7374}

19:34:29.360022 ID:0 packet missed

19:34:29.360341 loopTimer expired; hop to channelIdx: 41 19:34:31.858489 ID=0

19:34:29.360563 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927605 FreqError:-7374}

19:34:31.921954 ID:0 packet missed

19:34:31.922129 loopTimer expired; hop to channelIdx: 25 19:34:34.420989 ID=0

19:34:31.922259 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914899597 FreqError:-7374}

19:34:34.483916 ID:0 packet missed

19:34:34.484082 loopTimer expired; hop to channelIdx: 8 19:34:36.983489 ID=0

19:34:34.484211 main.go:185: Hop: {ChannelIdx: 8 ChannelFreq:906369839 FreqError:-7374}

19:34:37.047917 ID:0 packet missed

19:34:37.048025 Init channels: wait for messages

19:34:37.048152 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-7374}

19:36:16.741424 msg.Data: E900B04402009504

19:36:37.422803 msg.Data: 5800B0FF72002D5F

19:36:37.422920 init channels, msg.ID=0 msgIdToChan=0 chLastVisits=[0]

19:36:37.423022 NEW TRANSMITTER: msg.ID=0 chLastVisits=[1552347397422796464] visitCount=1 chLastHops=[0]

19:36:37.423066 last seen msg.Data: 5800B0FF72002D5F

19:36:37.423157 Hop to channelIdx: 19 19:36:39.985296 ID=0

19:36:37.423241 main.go:185: Hop: {ChannelIdx:19 ChannelFreq:911889094 FreqError:-7361}

19:36:40.050020 ID:0 packet missed

19:36:40.050186 loopTimer expired; hop to channelIdx: 41 19:36:42.547796 ID=0

19:36:40.050307 main.go:185: Hop: {ChannelIdx:41 ChannelFreq:922927605 FreqError:-7361}

19:36:42.611586 ID:0 packet missed

19:36:42.611863 loopTimer expired; hop to channelIdx: 25 19:36:45.110296 ID=0

19:36:42.611986 main.go:185: Hop: {ChannelIdx:25 ChannelFreq:914899597 FreqError:-7361}

19:36:45.173847 ID:0 packet missed

19:36:45.174103 loopTimer expired; hop to channelIdx: 8 19:36:47.672796 ID=0

19:36:45.174242 main.go:185: Hop: {ChannelIdx: 8 ChannelFreq:906369839 FreqError:-7361}

19:36:47.735760 ID:0 packet missed

19:36:47.735926 Init channels: wait for messages

19:36:47.736178 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902355835 FreqError:-7361}

Thanks

Rich

[Luc Heijst]

Hi Rich,

As the hopping is not working for the US frequencies, I believe the frequencies in the program and/or the hopping sequence are wrong.
I will do some research on the internet to try to find better values.
The problem with the internet is that faulty stuff is copied over and over without being looked at seriously and it hides the spare good stuff.

Luc

[rich T]

Hi Luc

No problem, I figured there was a slight issue.  Right now I'm just scanning for activity between 902 to 928 MHz.  Going to let SDRsharp run for a day or two and just record the hits over a certain dB level. In theory, I should see the frequencies that is being transmitted by the Davis.

Rich

[Luc Heijst]

Hi Rich,

Great! I judt started with the use of RTL-SDR dongles and know very little of the ins and outs. I tried to find my EU frequences with SDRsharp, but didn’t know how to use the program in the way you plan to do.
I changed my two RTL dongles yesterday and the rtldavis program showed an average jump of +9000 Hz of the frequency errors for all of my 4 davis channels.
The other RTL dongle is used by weewx-tfrc which reads the data of my 9 Klimalogg temp/hum sensors. After the switch the signal quality of one of the sensors dropped a lot while for the other 8 the values remain the same.

Luc

[rich T]

Hi Luc

The plugin that I'm using for scanning can be downloaded from here.  http://www.freqmgrsuite.com/  It seems to work fine but like you, I'm learning how to properly use the plugin. As for the SDR dongle, I'm using one of the originals.

Rich

[Luc Heijst]

Hi Rich,

When I look at the frequencies used in file DavisRFM69.h (see: https://github.com/kobuki/VPTools/blob/master/DavisRFM69.h), I believe all the US frequencies in protocol.go are 26300 Hz too low.

BTW. The EU frequencies in the same DavisRFM69.h file seem not useful for my EU Davis transmitters.

It took a while to find the conversion formula for those three byte numbers in the DavisRFM69.h file.

The formula is:

Frequency (Hz) = (HEX) Frequency DavisRFM69.h * 32,000,000 / (2^19)

Example: {0xE3, 0xDA, 0x7C}, = HEX: E3DA7C = Dec: 14932604. Frequency in Hz is: 14932604 * 32000000 / 61.03515625 = 911413818.4

Luc

[rich T]

Hi Luc

Looking through the capture log from early this morning until now, looks like it logged six frequencies.  Ruling out one of since it constantly around -3db, most likely my smoke detector.  I need to readjust the bandwidth while scanning for these frequencies. I'm wondering if the Davis is using all 51 frequencies per station Id or approximately 6 frequencies per station Id.  Your right about the info on the net, found three different transceivers which the Davis can use. 

Rich 

[Luc Heijst]

Hi Rich,

The US, AU and NZ Davis models hop with 51 different channel frequencies. The EU Davis models hop with only 5 different channel frequencies.
For the first transmitter (with id=0) the hop period is 2.5 + 1/16 second, i.e. 2.5625 seconds.
One channel is this revisited after 51 * 2.5625 seconds (130.7 seconds).

During the init phase I notised long periods before your station message was received on the channel 0.

For EU models this period is much shorter, 5 * 2.5625 is 12.8 seconds.

You might try the following US frequencies.
902381897, 902883656, 903385415, 903887174, 904388933, 904890692,
905392451, 905894210, 906395969, 906897728, 907399487, 907901246,
908403005, 908904764, 909406523, 909908282, 910410042, 910911801,
911413560, 911915319, 912417078, 912918837, 913420596, 913922355,
914424114, 914925873, 915427632, 915929391, 916431150, 916932909,
917434668, 917936427, 918438186, 918939945, 919441704, 919943463,
920445222, 920946981, 921448740, 921950499, 922452258, 922954017,
923455776, 923957535, 924459294, 924961053, 925462813, 925964572,
926466331, 926968090, 927469849,

Replace the US ones in file protocol.go and recompile the program, then start program rtldavis to see if these frequencies are better.
BTW The US hopping sequence is OK.

Luc

[Luc Heijst]

Rich,

I was just thinking abouth the battery-low indication of your station and the other station in the neighboorhood where we have received the data from.

Are the days short in the region where you live? If so, the supercapacitor which suplies the power at night might have unsufficient voltage and then the lithium battery comes in to deliver extra power. When the battery power is low, you get the warning.

But also the power of the tranmitter of your Davis weather station will be low. That might be the reason you won’t see them with your scan tool.

Luc

[rich T]

Hi Luc

Yes I will give those frequencies a try.  I tried the formula provided and I could not get the same result, which was driving me crazy.  Here is what I think, but could be wrong.

FSTEP = FXOSC/2^19

FSTEP = 0.00006103515

I don't see where FSTEP gets converted to Hz.

Rich

[rich T]

Luc

The closest Davis station is about 2 miles away. It is most likely the battery in the ISS, since it is the original (I guess it is time to replace the battery).  I replaced the supercap about six years ago. It could be a possibility why I don't see all the frequencies, but the my reception averages 95% to 100%.

Rich

[Luc Heijst]

Rich,

FSTEP = 32MHz / (2^19) = 61.xxx Hz. So the formula is: freq from table * 61.xxx

After translating the table I did another step. I calculated the difference between each two frequencies. As they were close to each other, but all different, I thought the frequencies might differ each the same number of Hz. And so I did for my table. If those frequencies won’t work, we can use the ones without my ‘correction’.

Luc

[Luc Heijst]

As the ID of the second station is 1, it could be from an anemometer kit.
I, for example, have set my ISS to 0, my anemometer station to 1, and my leaf-soil station to 2.
But a reception range of 2 miles? It’s way above Davis specifications!

[Luc Heijst]

I forgot to tell one more thing about the frequencies. In the RFM69 table the frequencies are sorted in the sequence they are transmitted.
In the rtldavis program the frequencies are sorted from low to high and the frequency order used for the hopping comes from the hop table.

h.ChannelIdx = p.hopPattern[p.hopIdx]
h.ChannelFreq = p.channels[h.ChannelIdx]

[rich T]

 Luc

Will use the frequencies you provided tonight when I get back into the area. My ISS is located approximately 50 feet from the console and is set as Id 0. Only additional sensor I have is the UV sensor, which I just recently added.

Rich

[Luc Heijst]

Rich,

You can read both transmitters simultanious with option -tr 3.

AFAIK, the Davis console (and the weewx Vantage driver) won’t show the UV data when it is not coming from the same transmitter as the ISS.

Anyhow, the rtldavis driver will read the data. I have my solar sensor mounted on the same pole as my anemometer. On a high location, while my ISS is at 1.5 m above groud level as advised. An other advantage of the rtldavis driver will be a five to ten time smaller resolution of temperature, leaf wetness and soil moistness.

Luc

[rich T]

Hi Luc

I re-compiled the code with the frequencies you provided and here is what I get:

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ $GOPATH/bin/rtldavis  -tf US

17:53:20.344708 rtldavis.go VERSION=0.7

17:53:20.345197 tr=1 actChan=[0] maxChan=1 *transmitterId=0 msgIdToChan=[0 9 9 9 9 9 9 9]

17:53:20.345320 idLoopPeriods=[2562500000 2625000000 2687500000 2750000000 2812500000 2875000000 2937500000 3000000000]

17:53:20.346105 BitRate: 19200

17:53:20.346146 SymbolLength: 14

17:53:20.346184 SampleRate: 268800

17:53:20.346216 Preamble: 1100101110001001

17:53:20.346249 PreambleSymbols: 16

17:53:20.346282 PreambleLength: 224

17:53:20.346315 PacketSymbols: 80

17:53:20.346350 PacketLength: 1120

17:53:20.346385 BlockSize: 512

17:53:20.346419 BufferLength: 2048

Found Rafael Micro R820T tuner

17:53:20.758912 main.go:157: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

Exact sample rate is: 268800.001367 Hz

17:53:20.940735 Init loopTimer and wait for messages on channel 0: loopTimer=273064896 idLoopPeriods=2562500000 loopPeriod=133250000000

17:55:34.192393 ID:0 packet missed

17:55:34.192703 Init channels: wait for messages

17:55:34.193092 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

17:57:47.443103 ID:0 packet missed

17:57:47.443399 Init channels: wait for messages

17:57:47.443576 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:00:00.694699 ID:0 packet missed

18:00:00.694871 Init channels: wait for messages

18:00:00.695034 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:02:13.945499 ID:0 packet missed

18:02:13.945600 Init channels: wait for messages

18:02:13.945712 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:04:27.196393 ID:0 packet missed

18:04:27.196494 Init channels: wait for messages

18:04:27.196609 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:06:40.448300 ID:0 packet missed

18:06:40.448578 Init channels: wait for messages

18:06:40.448853 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:08:53.699277 ID:0 packet missed

18:08:53.699556 Init channels: wait for messages

18:08:53.699750 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:11:06.950125 ID:0 packet missed

18:11:06.950282 Init channels: wait for messages

18:11:06.950434 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:13:20.201020 ID:0 packet missed

18:13:20.201119 Init channels: wait for messages

18:13:20.201224 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:15:33.451275 ID:0 packet missed

18:15:33.451373 Init channels: wait for messages

18:15:33.451568 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:17:46.702804 ID:0 packet missed

18:17:46.702904 Init channels: wait for messages

18:17:46.703019 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:19:59.953423 ID:0 packet missed

18:19:59.953521 Init channels: wait for messages

18:19:59.953629 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:22:13.205513 ID:0 packet missed

18:22:13.205786 Init channels: wait for messages

18:22:13.205979 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:24:26.457365 ID:0 packet missed

18:24:26.457797 Init channels: wait for messages

18:24:26.458104 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:26:39.708999 ID:0 packet missed

18:26:39.709160 Init channels: wait for messages

18:26:39.709310 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

18:28:52.959658 ID:0 packet missed

18:28:52.959891 Init channels: wait for messages

18:28:52.960037 main.go:185: Hop: {ChannelIdx: 0 ChannelFreq:902381897 FreqError:0}

Thanks

Rich

On Sunday, March 3, 2019 at 2:33:07 PM UTC-5, Luc Heijst wrote:

Recently my attention was brought to a SDR tool for receiving wireless sensor data (TFA IT+ KlimaLogg Pro, LaCrosse, WeatherHub). See: https://github.com/baycom/tfrec.

I wrote a weewx driver which parsed and stored the tfrec data of my 9 KlimaLogg sensors. The weewx driver can be found here: https://github.com/matthewwall/weewx-tfrc

After this success I searched for a package that reads the radio data of Vantage Pro weather stations with a (cheap) RTL-SDR dongle and found: the rtldavis package on: https://github.com/bemasher/rtldavis.

With this package were a few problems:

1. The development of the package stopped three years ago.

2. The set of European frequencies appeared not to be useful.

3. The package could only handle one transmitter (at a time).

4. The package is written in GO. Not a big issue, but the GO language is new for me.

With two Vantage Pro2 systems, an anemometer station and a leaf-soil station the challenge was to get this package concurrently working for more than one transmitter (four in my case).

With some modifications of main.go and protocol.go and trial and error I could find a reasonable set of the European frequencies which are used in the frequency hop sequence.

The next step was to get the data of more than one sensor wich each its own hopping timing. 

The last step will be to parse the data packets and store the data in Weewx. This part is easy because this was already done by me via the parsing of the raw meteostick data in the weewx-meteostick driver, see: https://github.com/matthewwall/weewx-meteostick.

The hopping mechanism has some prograss today. The principle is as follows.

1. Wait long enough on a fixed frequency until you have seen at least one message of each transmitter. For the five EU frequencies this process takes 17 seconds or less. For the 51 US frequencies this will take about ten times as much time.

2, Calculate with help of the lastVisitedTimes of all transmitters what the nextVisitTimes (in the near future) will be and how many hops would be needed to get here.

3. Detect the smallest nextVisitTime. This will be of the transmitter which follows first.

4. Calculate the hop channel for this transmitter.

5. Calculate the loopPeriod for this transmitter. In case the signal of this transmitter is missed we don't want to wait too long and miss packets of other transmitters too.

6. Start the hop process and wait for new data.

I combined the weewx-sdr and weewx-meteostick drivers fr this weewx-rtld driver.

The results so far:

The first 1000 messages were read with the new driver.

Average percentage of received signals is 94,8 %, see table.

     ok missed tot  pctGood

     341  19     360  94,7

     335  16     351  95,4

     324  20     344  94,2

    ----  --    ----  ---- 

tot 1000  55 1055  94,8

The FreqError in general varies between -1000 and +1000.

When abs(FreqError) > 10000 the weewx-rtld driver will restart program rtldavis.

For a comparison between the Meteostick and rtld driver data see: http://www.lucdesign.nl/_weewx/bootstrap_rtld/hour.html

There is one challence left: how to get local barometer data in my Raspberry PI? 

I could use a BMP280 pressure/temp sensor... so, more to come.

Cheers, Luc

[Luc Heijst]

Hi Rich,

We need another approach. As I said before, the frequencies of RFM69 didn’t work for my EU transmitter either.
Note: the lowest and highest frequencies in the RFM69 table were not modified by me, so that can’t be a cause here.

I plan to write a testprogram as follows.
1. Start with a frequency in the lower US band.
2. Start the init proces to see if any messages can be read. When you configure both of your sensors with parameter -tr 7 this process may take less time.
3a. When a message is read succesful; continue right away. This frequency is (more or less) good.
3b. When a timeout occurred; this frequency is no good. Also continue.
4. Increase the frequency with a certain amount. The amount must be small enough not to miss any good frequencies.
5a. When the increased frequency is bigger than the max frequency (at the end of the US band), we are ready to analyse the logging.
5b. If not, continue with step 2.

The logfile will show a list with evenly spreaded frequencies and for each frequency a true or false message received.
With this info we create our first new hopping list. The program will show for each received message a frequency error for that channel.
With the frequency error data we can fine-tune each channel frequency.

Note: On my test site the rtldavis program will function normaly with maximum frequency errors of + and - 10,000 Hz.

What do you think?

Luc

[rich T]

Luc

The approach sounds like a good way to proceed. Currently running option -tr 3 and receiving the same results. Do you think we should move this to weewx-development group?

Rich

[Luc Heijst]

Hi Rich,

Both transmitters work with the same sets of frequencies, so it is likely they both fail or succeed at a given frequency.

It is a good idea to start a tread in weewx-development, which I just did, so we can continue from there.

Luc

[Luc Heijst]

New test function in program rtldavis

To all,

The rtldavis program has now an embedded frequency test function.

With this function the frequencies can be detected used by Davis Vantage weather stations.

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

Warning: For the US, AU and NZ bands this test will take a long time!

-stepfreq 10000: 4 days!

-stepfreq 20000: 2 days!

-stepfreq 40000: 24 h

-stepfreq 80000: 12 h

Below the output of the test for the EU frequency band

============================================================

My command was: $GOPATH/bin/rtldavis -tr 15 -startfreq 868000000 -endfreq 868600000 -stepfreq 2000

Note: I used -tr 15 because I have 4 transmitters, but you will get better results to do the test with just one sensor.

$GOPATH/bin/rtldavis -tr 1 -startfreq 868000000 -endfreq 868600000 -stepfreq 2000

08:33:08.507848 TESTFREQ 1: Frequency 868000000: NOK

08:33:25.009595 TESTFREQ 2: Frequency 868002000: NOK

...

08:39:11.631768 TESTFREQ 23: Frequency 868044000: NOK

08:39:28.132553 TESTFREQ 24: Frequency 868046000: NOK

08:39:42.645072 TESTFREQ 25: Frequency 868048000 (freqError=3999): OK, msg.data: F20AF7FF80C09F85

08:39:56.081804 TESTFREQ 26: Frequency 868050000 (freqError=335): OK, msg.data: F269FFFFC0C0E084

08:40:12.582245 TESTFREQ 27: Frequency 868052000: NOK

08:40:29.083291 TESTFREQ 28: Frequency 868054000: NOK

...

08:42:08.090752 TESTFREQ 34: Frequency 868066000: NOK

08:42:24.591295 TESTFREQ 35: Frequency 868068000: NOK

08:42:31.260564 TESTFREQ 36: Frequency 868070000 (freqError=-1309): OK, msg.data: E000007A05006B04

08:42:31.643522 TESTFREQ 37: Frequency 868072000 (freqError=7117): OK, msg.data: 83016F31190076D3

08:42:34.643106 TESTFREQ 38: Frequency 868074000 (freqError=5597): OK, msg.data: F2498A5000C091F9

08:42:44.073708 TESTFREQ 39: Frequency 868076000 (freqError=2658): OK, msg.data: 500000FF7500485B

08:42:45.392137 TESTFREQ 40: Frequency 868078000 (freqError=1285): OK, msg.data: E3006F120100D6D6

08:42:48.081458 TESTFREQ 41: Frequency 868080000 (freqError=-310): OK, msg.data: F229FFFFC0C0F1EC

08:42:55.757607 TESTFREQ 42: Frequency 868082000 (freqError=-2895): OK, msg.data: 51006AFF73009624

08:42:56.886751 TESTFREQ 43: Frequency 868084000 (freqError=-4454): OK, msg.data: A00000733D0013B9

08:43:08.883213 TESTFREQ 44: Frequency 868086000 (freqError=-6600): OK, msg.data: A1016A0003006AF3

08:43:25.389468 TESTFREQ 45: Frequency 868088000: NOK

08:43:41.890787 TESTFREQ 46: Frequency 868090000: NOK

...

08:53:52.563306 TESTFREQ 83: Frequency 868164000: NOK

08:54:09.069653 TESTFREQ 84: Frequency 868166000: NOK

08:54:24.140318 TESTFREQ 85: Frequency 868168000 (freqError=-8497): OK, msg.data: F2498A5040C09C35

08:54:37.578287 TESTFREQ 86: Frequency 868170000 (freqError=142): OK, msg.data: F229FFFFC0C0F1EC

08:54:54.079549 TESTFREQ 87: Frequency 868172000: NOK

08:55:10.580273 TESTFREQ 88: Frequency 868174000: NOK

...

08:56:49.587907 TESTFREQ 94: Frequency 868186000: NOK

08:57:06.089362 TESTFREQ 95: Frequency 868188000: NOK

08:57:16.139749 TESTFREQ 96: Frequency 868190000 (freqError=-2123): OK, msg.data: F209CEFFC0C0A305

08:57:16.757656 TESTFREQ 97: Frequency 868192000 (freqError=6352): OK, msg.data: 51006BFF710086F2

08:57:19.888636 TESTFREQ 98: Frequency 868194000 (freqError=5415): OK, msg.data: 43007CFFC30025D3

08:57:23.001305 TESTFREQ 99: Frequency 868196000 (freqError=4096): OK, msg.data: E000007A05006B04

08:57:29.577161 TESTFREQ 100: Frequency 868198000 (freqError=2329): OK, msg.data: F22A00FF40C04F05

08:57:29.881575 TESTFREQ 101: Frequency 868200000 (freqError=-1211): OK, msg.data: 41006BFFC100827B

08:57:33.652214 TESTFREQ 102: Frequency 868202000 (freqError=-2126): OK, msg.data: 83007C315B003757

08:57:35.814617 TESTFREQ 103: Frequency 868204000 (freqError=-1629): OK, msg.data: 500000FF7500485B

08:57:47.390072 TESTFREQ 104: Frequency 868206000 (freqError=-5924): OK, msg.data: E3007C12030030CF

08:58:03.891633 TESTFREQ 105: Frequency 868208000: NOK

08:58:20.393632 TESTFREQ 106: Frequency 868210000: NOK

08:58:36.909603 TESTFREQ 107: Frequency 868212000: NOK

...

09:08:47.506290 TESTFREQ 144: Frequency 868286000: NOK

09:09:04.007169 TESTFREQ 145: Frequency 868288000: NOK

09:09:05.635746 TESTFREQ 146: Frequency 868290000 (freqError=-7983): OK, msg.data: F209CEFF40C0B89D

09:09:22.136064 TESTFREQ 147: Frequency 868292000: NOK

09:09:38.637292 TESTFREQ 148: Frequency 868294000: NOK

...

09:11:34.191784 TESTFREQ 155: Frequency 868308000: NOK

09:11:50.692624 TESTFREQ 156: Frequency 868310000: NOK

09:11:50.881275 TESTFREQ 157: Frequency 868312000 (freqError=-885): OK, msg.data: C1012A0003005B77

09:11:54.386142 TESTFREQ 158: Frequency 868314000 (freqError=6129): OK, msg.data: E3011D120300B5F8

09:11:57.651033 TESTFREQ 159: Frequency 868316000 (freqError=3815): OK, msg.data: F20AFCFF40C097CE

09:12:01.928609 TESTFREQ 160: Frequency 868318000 (freqError=1144): OK, msg.data: 80000032AD0014C7

09:12:04.005218 TESTFREQ 161: Frequency 868320000 (freqError=261): OK, msg.data: 81012AFFC300E850

09:12:08.134538 TESTFREQ 162: Frequency 868322000 (freqError=-1843): OK, msg.data: 53001DFF73000E3C

09:12:11.071864 TESTFREQ 163: Frequency 868324000 (freqError=-4239): OK, msg.data: F269FFFFC0C0E084

09:12:14.740295 TESTFREQ 164: Frequency 868326000 (freqError=-6620): OK, msg.data: E000007A05006B04

09:12:31.241327 TESTFREQ 165: Frequency 868328000: NOK

09:12:47.741935 TESTFREQ 166: Frequency 868330000: NOK

...

09:26:16.450669 TESTFREQ 215: Frequency 868428000: NOK

09:26:32.969307 TESTFREQ 216: Frequency 868430000: NOK

09:26:38.131148 TESTFREQ 217: Frequency 868432000 (freqError=-7484): OK, msg.data: E107438001005467

09:26:39.130943 TESTFREQ 218: Frequency 868434000 (freqError=5775): OK, msg.data: F2498A5040C09C35

09:26:40.856634 TESTFREQ 219: Frequency 868436000 (freqError=3331): OK, msg.data: 600000FFC50079DA

09:26:42.632321 TESTFREQ 220: Frequency 868438000 (freqError=1783): OK, msg.data: 83012C328B00A44A

09:26:51.255188 TESTFREQ 221: Frequency 868440000 (freqError=-153): OK, msg.data: 51064EFF7100C07C

09:26:52.567413 TESTFREQ 222: Frequency 868442000 (freqError=-1852): OK, msg.data: F229FFFFC0C0F1EC

09:26:53.668192 TESTFREQ 223: Frequency 868444000 (freqError=-4517): OK, msg.data: 800000333D003B1C

09:26:56.381746 TESTFREQ 224: Frequency 868446000 (freqError=-5883): OK, msg.data: E3034F1201000F4A

09:27:12.883597 TESTFREQ 225: Frequency 868448000: NOK

09:27:29.383883 TESTFREQ 226: Frequency 868450000: NOK

...

09:55:02.188634 TESTFREQ 37: Frequency 868548000: NOK

09:55:18.689354 TESTFREQ 38: Frequency 868550000: NOK

09:55:25.403823 TESTFREQ 39: Frequency 868552000 (freqError=3727): OK, msg.data: 800000348D00A081

09:55:27.188215 TESTFREQ 40: Frequency 868554000 (freqError=6680): OK, msg.data: F269FFFFC0C0E084

09:55:38.218456 TESTFREQ 41: Frequency 868556000 (freqError=3304): OK, msg.data: E000007A05006B04

09:55:38.508171 TESTFREQ 42: Frequency 868558000 (freqError=2961): OK, msg.data: 810430FFC300B80B

09:55:40.626282 TESTFREQ 43: Frequency 868560000 (freqError=1118): OK, msg.data: F2498A5080C08A61

09:55:43.380402 TESTFREQ 44: Frequency 868562000 (freqError=-2209): OK, msg.data: E3032812010007B5

09:55:51.030007 TESTFREQ 45: Frequency 868564000 (freqError=-3799): OK, msg.data: 500000FF7500485B

09:55:51.633061 TESTFREQ 46: Frequency 868566000 (freqError=-4811): OK, msg.data: E10333800300F976

09:56:08.134940 TESTFREQ 47: Frequency 868568000: NOK

09:56:24.635754 TESTFREQ 48: Frequency 868570000: NOK

...

10:00:15.650909 TESTFREQ 62: Frequency 868598000: NOK

10:00:32.151288 TESTFREQ 63: Frequency 868600000: NOK

10:00:32.151760 TEST REACHED ENDFREQ

10:00:32.152009 Test reached endfreq; test ended

The test can be refined by using a smaller stepFreq for one of the detected frequency bands like:

$GOPATH/bin/rtldavis -tr 1 -startfreq 868315000 -endfreq 868321000 -stepfreq 500

12:31:03.070259 TESTFREQ 1: Frequency 868315000 (freqError=-523): OK, msg.data: 800000330D003E89

12:31:15.883647 TESTFREQ 2: Frequency 868315500 (freqError=2514): OK, msg.data: E00000080500DD6C

12:31:28.694940 TESTFREQ 3: Frequency 868316000 (freqError=2540): OK, msg.data: 50000021650035BD

12:31:41.508008 TESTFREQ 4: Frequency 868316500 (freqError=1646): OK, msg.data: A000007A3D008D28

12:31:54.320391 TESTFREQ 5: Frequency 868317000 (freqError=1261): OK, msg.data: 800000330D003E89

12:32:09.696444 TESTFREQ 6: Frequency 868317500: NOK

12:32:19.944829 TESTFREQ 7: Frequency 868318000 (freqError=460): OK, msg.data: 500000396500DF7F

12:32:32.758386 TESTFREQ 8: Frequency 868318500 (freqError=-110): OK, msg.data: A000007B3D00BA18   <== pick this frequency for the p.channels list in protocol.go

12:32:45.569193 TESTFREQ 9: Frequency 868319000 (freqError=-1030): OK, msg.data: 800000330D003E89

12:32:58.382205 TESTFREQ 10: Frequency 868319500 (freqError=-1063): OK, msg.data: E00000090500EA5C

12:33:11.193817 TESTFREQ 11: Frequency 868320000 (freqError=-1940): OK, msg.data: 500000396500DF7F

12:33:24.007724 TESTFREQ 12: Frequency 868320500 (freqError=-2365): OK, msg.data: A000007A3D008D28

12:33:36.818709 TESTFREQ 13: Frequency 868321000 (freqError=-2779): OK, msg.data: 800000330D003E89

12:33:36.818921 TEST REACHED ENDFREQ

12:33:36.819006 Test reached endfreq; test ended

============================================================

Luc

[rich T]

Luc

I get an error when trying to running the program.  I have the latest main.go file.

pi@raspberrypi:~ $ cd $GOPATH/src/github.com/lheijst/rtldavis

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ git submodule init

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ git submodule update

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ go install -v .

github.com/lheijst/rtldavis

# github.com/lheijst/rtldavis

./main.go:212: undefined: channelFreq

./main.go:216: undefined: channelFreq

./main.go:218: undefined: channelFreq

pi@raspberrypi:~/work/src/github.com/lheijst/rtldavis $ $GOPATH/bin/rtldavis -tr 1 -tf US -startfreq 902000000 -endfreq 928000000 -stepfreq 40000

flag provided but not defined: -startfreq

Usage of /home/pi/work/bin/rtldavis:

  -ex int

    extra loopPeriod time in msec

  -tf string

    transmitter frequencies: EU or US (default "EU")

  -tr int

    transmitters to listen for: tr1=1, tr2=2, tr3=4, tr4=8, tr5=16 tr6=32, tr7=64, tr8=128 (default 1)

  -u log undefined signals

  -v log extra information to /dev/stderr (default true)

Thanks

Rich

[L.J.M. Heijst]

Rich,

Sorry about that. fixeded in commit d38de5f 

Luc

--  You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/ZjDVbSmwmZY/unsubscribe. To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

---

This email has been checked for viruses by Avast antivirus software. www.avast.com

[rich T]

Luc

Thanks...issue is fixed.

Rich

[Phil Green]

Hi Luc,
I have tried the GO program on a couple of Linux machines following your instructions. However I don’t receive anything. The dongle I have works fine on other programs. If I tune into the 868MHz band I can see the brief transmissions from my Vantage Vue. The dongle is detected using lsusb and the program runs without any errors.
In your instructions

Create ~/profile

sudo nano ~/.profile
export GOROOT=/usr/lib/go
export GOPATH=$HOME/work
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
source ~/.profile

I already have a .profile file, do I put the export lines and the source line in the file?

If I just run them from the command line then the program runs, (but only on that login, not on future retarts) however if I put them in the .profile file, my login on the machine doesn’t login me in so I have to restore the machine. I am running under Mac Parallels.

Does your program automatically work out the frequency offset on the dongle?
Regards
Phil

[Luc Heijst]

Hi Phil,

My instructions are nor clear, sorry.

Add the following 3 lines at the ens of your .profile file.

export GOROOT=/usr/lib/go 
export GOPATH=$HOME/work 
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin 

Then save the file.

To activate the changes in the profile right away, type command:

source ~/.profile 

The program doesn't run at its own on future restarts.

I have set a cronjob for program weewx (with the weewx-rtld driver installed) which will start program rtldavis.

crontab -e

Add at the end:

@reboot /home/weewx/util/init.d/weewx.debian restart

The weewx-rtld driver can be found here: https://github.com/lheijst/weewx-rtld

Beware: the first action is to get program rtldavis collecting the raw data. Without this raw data the weewx-rtld program is useless.

After each successful data collection program rtldavis reports the frequency-offset between the RTL-SDR dongle and the Davis transmitter of that message.

Program rtldavis has an option to preset an overall frequency correction: -fc xxx (in Hz) for all configured transmitters (often there is only one transmitter).

Please report the output of program rtldavis to get more information what is happening.

Luc

[Phil Green]

Hi Luc,

Thanks for the prompt response.

Yes, I have now sorted the configuration of GO.

However, I am still not receiving anything.

I will attach the command line capture of both no offset and +27000 offset according to my device if I calibrate it will a known signal.

I have also attached a screenshot of the spectrum using an SDR program with the +27kHz offset.

Please advise on your suggestions.

Thanks

Phil

[Phil Green]

Forgot to say the screenshot of the spectrum is one burst from the weather station at the lowest frequency range.

[Luc Heijst]

On Sunday, 17 March 2019 16:02:23 UTC-3, Phil Green wrote:

However, I am still not receiving anything.

Hi Phil,

I'm sitting here with a blush on my face. 

I have modified program rtldavis to work with EU frequencies and multi Davis transmitters while I don't know almost nothing about RTL-SDR (both hardware and software).

I have had a similar situation on my Raspberry PI (i.e. not receiving any data packets) after I had uninstalled librtlsdr0

The reason why I uninstalled librtlsdr0 was the error: "rtlsdr.go:503: undefined reference to `rtlsdr_set_bias_tee'".

After I installed librtlsdr0 again, the data packets were received normally.

I'm afraid this won't much any help for you. I'm sorry.

Luc

[rich T]

I believe v3 versions and up have built in Bias tees which is set by the software (true or false) depending if you want to use the bias tee.

Rich

[Phil Green]

So what to I have to do to make it work?
Or is it something in the program which you can fix?

Regards
Phil

[Luc Heijst]

On Sunday, 17 March 2019 17:30:17 UTC-3, Phil Green wrote:

So what to I have to do to make it work?
Or is it something in the program which you can fix?

Sorry, I can't think of anything you can do. 

[rich T]

Luc

I Followed your instructions to install the driver, but when I get to step 2., I receive a 404 error.  Is the Link correct?

Installation

1) install pre-requisites

1.a) install weewx
    http://weewx.com/docs.html

1.b) install golang
    eg: on raspberry pi:
    sudo apt-get install golang

2) download the driver

wget -O weewx-sdr.zip https://github.com/matthewwall/weewx-rtldavis/archive/master.zip

Thanks

Rich 

[Luc Heijst]

Hi Rich,

No it is not! I decided to keep the rtldavis program and the weewx driver for it in one place. Sorry!

The right link is: https://github.com/lheijst/weewx-rtldavis/archive/master.zip

I will change the readme.

Luc

[rich T]

Luc 

Trying to run the as a standalone driver but it crashes within 10 seconds.

pi@raspberrypi:/home/weewx $ sudo PYTHONPATH=bin python bin/user/rtldavis.py --cmd="/home/pi/work/bin/rtldavis -tf US -tr 1"

data: ['19:26:26.232530 rtldavis.go VERSION=0.9\n']

data: ['19:26:26.232825 tr=1 fc=0 ex=0 actChan=[0] maxChan=1\n']

data: ['19:26:26.233278 BitRate: 19200\n']

data: ['19:26:26.233301 SymbolLength: 14\n']

data: ['19:26:26.233315 SampleRate: 268800\n']

data: ['19:26:26.233328 Preamble: 1100101110001001\n']

data: ['19:26:26.233340 PreambleSymbols: 16\n']

data: ['19:26:26.233354 PreambleLength: 224\n']

data: ['19:26:26.233368 PacketSymbols: 80\n']

data: ['19:26:26.233382 PacketLength: 1120\n']

data: ['19:26:26.233396 BlockSize: 512\n']

data: ['19:26:26.233409 BufferLength: 2048\n']

data: ['Found Rafael Micro R820T tuner\n']

data: ['19:26:26.624188 {ChannelIdx:0 ChannelFreq:902355835 FreqError:0}\n']

data: ['Exact sample rate is: 268800.001367 Hz\n']

data: ['19:26:26.807179 Init channels: wait max 133 seconds for a message of each transmitter\n']

data: []

err: []

Rich

[Luc Heijst]

On Monday, 18 March 2019 20:32:15 UTC-3, rich T wrote:

Trying to run the as a standalone driver but it crashes within 10 seconds.

Rich,

The standalone driver is very limited in its functions. It is there because each driver should have a stand-alone section.

In the standalone version the received data from rtldavis is not parsed and the program ends as soon as the buffer is empty.

There is a typo in the code for the err: data, but that should not change anything.

Something else:

Sometime rtldavis stopped with reading and outputting data (this happend once a day or less). I could not detect the cause so far and therefore weewx-rtld checks if the rtldavis process is stalled.

The 'rtldavis process is stalled' timeout is currently 45 seconds. When this timeout is exceeded, weewx-rtld will end with a WeeWxIOError message and restart itself after 1 minute.

I realize this 45 sec timeout is too short for the US version, because the US init can take 133 seconds.

I will extend this timeout to 150 seconds.

if int(time.time()) - time_last_received > 150:

raise weewx.WeeWxIOError("rtldavis process stalled")

Luc

[Luc Heijst]

On Monday, 18 March 2019 20:32:15 UTC-3, rich T wrote:

Trying to run the as a standalone driver but it crashes within 10 seconds.

Rich,

Although the standalone version is very limited in its functions, the 'show-packets' option should not end after 10 seconds.

It now runs as long as process rtldavis is active.

Fixed in commit 762ad49

Luc 

[Luc Heijst]

To all,

Some progress with the rtldavis program and the weewx-rtldavis driver.
See this thread in the weewx development forum: https://groups.google.com/forum/m/#!topic/weewx-development/jhGleLxu-p0

Luc