Author Topic: Receiving Davis Vantage weather data with a RTL-SDR dongle (Read 10739 times)

Lucas · « **on:** February 27, 2019, 08:23:35 PM »

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 my 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 of the rtldavis package and (some more) trial and error I could find a reasonable set of EU frequencies which are used in the hop sequence.
The next step was to get the data of more than one sensor with each its own hopping timing.
The last step will be to parse and store the rtldavis data packets in a Weewx driver. This part is easy because the analyzing of the unknown parts of the raw data was already done by me via the development of the weewx-meteostick driver, see: https://github.com/matthewwall/weewx-meteostick.
Recently we detected an error in the parsing of the digital temperatures for temperatures below zero degrees Fahrenheit (-17.8 degrees Celsius).
I live in Suriname where the coldest temperature of the last five years was 20.2 C (68.4 F), so this change in the raw protocol was not detected by me.

OK, back to the subject.
The hopping mechanism has some progress 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 got it working but the 25 percent of missed messages is way too high. Some work left to do I guess...

When this driver Is finished there is still one challence: how do I get local barometer data in my Raspberry PI? Any suggestions for cheap hardware?

More to come.

Cheers, Luc

vreihen · « **Reply #1 on:** February 27, 2019, 08:51:00 PM »

Bosch BMP-280 i2c barometer module, imported as an additional sensor using the provisions in weewx. Had to do this for my Acu-Rite weewx/SDR setup.....

Lucas · « **Reply #2 on:** February 28, 2019, 04:19:20 AM »

Very nice! I found the sensor for a couple of Euros in the Netherlands (ordering directly from Suriname is not easy; as a test I recently ordered some products from China of which none until now are delivered....)

Could you please share with us how you setup the hardware for the pressure sensor and which weewx driver you used?

Luc

vreihen · « **Reply #3 on:** February 28, 2019, 07:44:15 AM »

There are plenty of tutorials online for hooking up i2c modules to a Raspberry Pi.

I cobbled together a Q&D external shell script and file-based weewx extra sensor driver, and will selfishly refuse to share it out of embarrassment that I wrote such an ugly hack. There are others who have done similar things and did share, but I don't have bookmarks handy.

Given that Acu-Rite SmartHUB users are facing their day of reckoning this very day (Acu-Rite is shutting down their server on 2/28/2019) and weewx/SDR is their only long-term hope, I may be inclined to write a *proper* BMP-280 extra sensor driver for weewx if someone else hasn't already shared one by now.....

Lucas · « **Reply #4 on:** February 28, 2019, 10:45:34 AM »

Don’t be embarrased!
My program skills are from the seventees and still I can’t get ridd of my old techniques. I wrote plenty of ugly pieces of code and met Matthew Wall at the weewx forum when coding for ws28xx, KlimaLogg, Meteostick and Meteotemplate upload, who was so friendly to convert my hundreds lines of ugly code to a handfull lines of todays coding....

vreihen · « **Reply #5 on:** February 28, 2019, 06:06:05 PM »

Somebody else's less-ugly code:

https://groups.google.com/forum/#!topic/weewx-development/3LCx5b4mveM

kobuki · « **Reply #6 on:** March 01, 2019, 04:44:28 AM »

Hi Luc, nice to see you're active in the field again. I also stumbled upon that SDR-based receiver some time ago, and it would be a feat to make it work reliably. You could try to implement the packet capture algo using eg. my WxReceiver sketch for the Arduino-compatibles. It's not a big deal and using that it's possible to make enhancements, like calculating the next hop in the sequence directly, instead of waiting on a fixed one, speeding up station resync a lot. The SDR method might have less problems with skewed frequencies, too. It would be nice to see some progress.

Lucas · « **Reply #7 on:** March 01, 2019, 09:02:03 PM »

Hi Kobuki, yes I’m back. I got some progress today with the driver. The missed count is now about 10% (scanning 3 transmitters and ignoring the 4th), the same numbers are generally seen with the Meteostick.
Where can I find your WxReceiver sketch? I will then have a look at the resync logic.
Cheers, Luc

Lucas · « **Reply #8 on:** March 02, 2019, 11:23:08 AM »

Well, I think I've got it working folks!

The first 1000 messages are 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

Channel 0: ISS (1)
Channel 1: anemometer with solar radiation sensor
Channel 2: leaf-soil station

Channel 3: ISS (2) : not active read by the driver, but the signals occasionally are received.
See logging: "undefineds:[0 0 0 66 0 0 0 0]" means: 66 undefined messages received on channel 3.

The FreqError in general varies between -1000 and +1000.
When abs(FreqError) > 10000 the weewx-rtld driver will restart program rtldavis.

We are now in the stage of long term testing and fine-tuning to try to decrease the missed signal values even more.

More to come...

Cheers, Luc

Part of the weewx logging:
====================================================

Mar 2 12:52:47 pi35 rtld[3931]: rtldavis: info:
12:52:47.097718 Hop to channelIdx: 3 12:52:47.476433 ID=2

Mar 2 12:52:47 pi35 rtld[3931]: rtldavis: chan:
12:52:47.097823 main.go:163: Hop: {ChannelIdx: 3 FreqError:-84}

Mar 2 12:52:47 pi35 rtld[3931]: rtldavis: data:
12:52:47.476707 F269FFFFC0C0E084 msg.ID=2 LeafSoil
- packets:998 [340 334 324] missed:50 [19 16 20]
inits:0 undefineds:[0 0 0 66 0 0 0 0] ex(ms):0

Mar 2 12:52:47 pi35 rtld[3931]: rtldavis: info:
12:52:47.476869 Hop to channelIdx: 4 12:52:48.679153 ID=0

Mar 2 12:52:48 pi35 rtld[3931]: rtldavis: chan:
12:52:47.476980 main.go:163: Hop: {ChannelIdx: 4 FreqError:-1558}

Mar 2 12:52:48 pi35 rtld[3931]: rtldavis: data:
12:52:48.680635 E000007805000564 msg.ID=0 Rain
- packets:999 [341 334 324] missed:50 [19 16 20]
inits:0 undefineds:[0 0 0 66 0 0 0 0] ex(ms):0

Mar 2 12:52:48 pi35 rtld[3931]: rtldavis: info:
12:52:48.680801 Hop to channelIdx: 2 12:52:49.722434 ID=1

Mar 2 12:52:49 pi35 rtld[3931]: rtldavis: chan:
12:52:48.680918 main.go:163: Hop: {ChannelIdx: 2 FreqError:165}

Mar 2 12:52:49 pi35 rtld[3931]: rtldavis: data:
12:52:49.722370 C1053800030024BE msg.ID=1 Unknown(0xC)
- packets:1000 [341 335 324] missed:50 [19 16 20]
inits:0 undefineds:[0 0 0 66 0 0 0 0] ex(ms):0

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

kobuki · « **Reply #9 on:** March 02, 2019, 12:18:51 PM »

Just got back. But it seems you won't need a new packet capture algo for hopping. Did you need to change the SDR code to follow the hopping sequence? Nice progress btw.

Is the code available somewhere to test? Or are you planning to release it?

Lucas · « **Reply #10 on:** March 02, 2019, 04:32:24 PM »

Hi Kobuki,

I didn't touch the SDR code of the rtldavis package. Some minor changes on protocol.go (i.e. the EU frequency table) bust most changes are done in main.go.
Currently the program is only available for the EU frequencies but I plan to make US frequencies available via a parameter.
The parsing of the raw code is not finished yet. I will tie the rtl receiver part to the weewx-meteostick parsing part.
The original rtldavis program has automatic frequency adjustment, but I think it does more harm than good.

The program will be available for testing when I have finished the above.

Luc

kobuki · « **Reply #11 on:** March 02, 2019, 05:00:00 PM »

Nice. I'm in the EU (with 2 Davis transmitters on EU frequencies) and have several SDR dongles so I can do some testing if you want.

Oh, and just an idea. I know the weewx-meteostick (and my fork of it) pretty well, and I'd suggest a simple way to tie it with the SDR solution. Create a daemon program from rtldavis that creates a simple TCP listening port where the weewx-meteostick can connect for packet data. For this, the daemon would need to emit meteostick-compatible output (possibly with some fake data to keep the output valid), and also some additional code in weewx-meteostick to be able to connect to a TCP port instead of opening a serial port. Or as another way of soing something similar, the weewx-meteostick driver could start the rtldavis program and use its stdout to gather packet data in a similar manner. Just ideas.

Lucas · « **Reply #12 on:** March 02, 2019, 05:13:48 PM »

Yes, the last option is where I'm going for.. Similar to my new Weewx-tfrc driver which reads the radio signals of klimaLogg (and other) sensors directly via a rtl-sdr dongle.

lui · « **Reply #13 on:** March 10, 2019, 09:31:44 AM »

Quote from: Lucas on March 02, 2019, 05:13:48 PM

Yes, the last option is where I'm going for.. Similar to my new Weewx-tfrc driver which reads the radio signals of klimaLogg (and other) sensors directly via a rtl-sdr dongle.

Found your driver yesterday and tried it but no success until know. I specified sensor map and also tried log unknown sensors. When I start tfrec by itself it works.

I also have a Davis Vantage Pro 2 and also have some different sdr dongles. Would be great if it will work.

kobuki · « **Reply #14 on:** March 10, 2019, 09:53:33 AM »

Which driver are you using? I think Luc haven't released his yet.

EDIT: ah, tfrec is something unrelated to the VP2, never mind.

Lucas · « **Reply #15 on:** March 10, 2019, 06:36:34 PM »

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

kobuki · « **Reply #16 on:** March 10, 2019, 06:48:09 PM »

Ah, cool, thanks for the update! I'll try to test it tomorrow on a Pi3.

Lucas · « **Reply #17 on:** March 14, 2019, 12:16:46 PM »

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

kobuki · « **Reply #18 on:** March 14, 2019, 01:57:41 PM »

Very interesting, but we already know all the frequencies. What are the possible use cases of this new functionality?

Lucas · « **Reply #19 on:** March 14, 2019, 02:23:13 PM »

Hi kubuki,

Maybe I don't understand how it works, but the frequencies used in RFM69.h don't work in rtldavis.

For EU the frequencies I use are (and the program use these with success):
868078500, 868199000, 868318500, 868438500, 868560000,

While the (sorted) frequencies of RFM69 are:
868066711, 868181885, 868297119, 868412292, 868527466,

The differences in Hz are:
11789, 17115, 21381, 26208, 32534,

I can't explain why these differences. Can somebody help?

Luc

kobuki · « **Reply #20 on:** March 14, 2019, 03:09:28 PM »

Ah, I get it. In the original Arduino code the frequencies are stored in their transmit order, ie. in a quasi-random, but fixed order. In the Golang code, the transmit frequencies are stored sorted by their increasing frequency value, and an index table is used to tell the actual transmit order. If you re-order the sorted frequency list using these indices, you essentially get the same frequency ordering as seen in the Arduino C code. TBH, I don't quite understand why the original author of the Golang code had to use this indirection but he did.

Lucas · « **Reply #21 on:** March 14, 2019, 03:39:47 PM »

kobuki,

The reordering is not the problem, but the actual frequencies.
AFAIK the RFM69 frequencies have to be converted to 'real' frequencies with the following formula.

RFM69 frequency * 32,000,000 / 2^19 = 'real' frequency in Hz
or
RFM69 frequency * 61.03515625 = 'real' frequency in Hz

Example for smallest EU frequency in RFM69.h file:

{0xD9, 0x04, 0x45} => 0xD90445 = 14222405

14222405 * 61.03515625 = 868066711.4 Hz

The rtldavis program uses 868078500 Hz instead of this 868066711.4 Hz, a difference of 11788,6 Hz

Luc

kobuki · « **Reply #22 on:** March 14, 2019, 05:34:32 PM »

Quote from: Lucas on March 14, 2019, 03:39:47 PM

{0xD9, 0x04, 0x45} => 0xD90445 = 14222405
14222405 * 61.03515625 = 868066711.4 Hz

Yes, this is how you do it. The correct frequencies (using the values required in the RFM69) are in the Arduino source. We use them since years with success for the EU band. Small differences are corrected by the AFC in the RFM69 module. The SDR on the other hand needs the real frequency and I think the Golang code also applies a correction, so nothing to worry about.

Lucas · « **Reply #23 on:** March 15, 2019, 04:58:46 AM »

The program can handle frequency offsets of + and - 3 kHz.

De differences with the RFM69 frequencies of 11 to 32 kHz are too much!

kobuki · « **Reply #24 on:** March 15, 2019, 06:44:29 AM »

Quote from: Lucas on March 15, 2019, 04:58:46 AM

De differences with the RFM69 frequencies of 11 to 32 kHz are too much!

No, they are not. Unless you experience severe packet loss, there is no need to worry about that. And as I said - it should be perfectly safe to use the frequencies converted from the Arduino source.

News:

Author Topic: Receiving Davis Vantage weather data with a RTL-SDR dongle (Read 10739 times)