Topic: Receiving Davis Vantage weather data with a RTL-SDR dongle

[kobuki]

Did you take a look at the US frequencies in my repo - I altered them from the previous values based on what I saw on SDR (though I found the SDR frequency itself to be a bit unstable and temperature dependent - maybe I should have bought a more expensive one!)
The values I came up with are all equally spaced which makes more sense to me than the slightly randomly spaced previous values!

No, I haven't - thanks for the heads-up. Yes, evenly spaced frequencies do sound better, I might try to use your table first to test. What I think is missing from my code at least is a simple means of frequency shift correction for individual packets. Even though the AFC in the RFM69 should follow them to an extent and most of the time it's working pretty well. The values in my code are from Dekay, who read the frequencies out of a console. But the console probably already uses an algorithm to follow small shifts of the transmitters, that's prolly why the frequency values look a bit random... Maybe on this band it's more important to adapt to individual setups.

[kobuki]

Does the lheijst rtldavis code require Weewx? I not familiar with WeeWx and don't really need it. I just need to see the raw 8-byte packets come though from the ISS. Does WeeWX need to be installed?

AFAIR it puts raw packets to stdout so you can just do whatever you want with it. If you have code already working with raw packets, you're good to go with some stdout parser, I think.

[Storm017]

Nice, sounds interesting.  Whatever solution you choose, let us know.  As a side note, I have an additional RPI running two SDRs, which parse various 433MHz and 915MHz sensors.

Definitely! The RTL-SDR arrives on Monday. The plan to first run it with the rtldavis software ( at https://github.com/lheijst/rtldavis) and see if I can see some packets and test out the range. If that goes well, work on integrating it with our other sensors. I'm not familiar with GoLang so there's going to be a bit of a learning curve there.

Does the lheijst rtldavis code require Weewx? I not familiar with WeeWx and don't really need it. I just need to see the raw 8-byte packets come though from the ISS. Does WeeWX need to be installed?

You could run the code without weewx.

Code: [Select]

pi@DavisSDR:~ $ $GOPATH/bin/rtldavis -tf US -tr 1
16:38:19.648869 rtldavis.go VERSION=0.12
16:38:19.649371 tr=1 fc=0 ppm=0 gain=0 ex=0 maxmissed=51 actChan=[0] maxChan=1
16:38:19.650560 BitRate: 19200
16:38:19.650639 SymbolLength: 14
16:38:19.650680 SampleRate: 268800
16:38:19.650715 Preamble: 1100101110001001
16:38:19.650751 PreambleSymbols: 16
16:38:19.650784 PreambleLength: 224
16:38:19.650821 PacketSymbols: 80
16:38:19.650858 PacketLength: 1120
16:38:19.650895 BlockSize: 512
16:38:19.650934 BufferLength: 2048
Found Rafael Micro R820T tuner
16:38:20.067024 Hop: {ChannelIdx:0 ChannelFreq:902419338 FreqError:0}
Exact sample rate is: 268800.001367 Hz
16:38:20.250897 GetTunerGain: 0 Db
16:38:20.250992 SetFreqCorrection 0 ppm Successful
16:38:20.255118 Init channels: wait max 135 seconds for a message of each transmitter
16:38:31.504826 TRANSMITTER 0 SEEN
16:38:31.505383 Hop: {ChannelIdx:19 ChannelFreq:911952597 FreqError:2}
16:38:34.067642 E002BE7000004438 2 0 0 0 0 msg.ID=0
16:38:34.067909 Hop: {ChannelIdx:41 ChannelFreq:922991108 FreqError:-34}
16:38:36.630171 5002BEFF7000A0A6 3 0 0 0 0 msg.ID=0
16:38:36.630514 Hop: {ChannelIdx:25 ChannelFreq:914963100 FreqError:-28}
16:38:39.193117 A001BE8A39005B64 4 0 0 0 0 msg.ID=0
16:38:39.193308 Hop: {ChannelIdx:8 ChannelFreq:906433342 FreqError:-103}
16:38:41.755159 8001BE15C90029A5 5 0 0 0 0 msg.ID=0
16:38:41.755349 Hop: {ChannelIdx:47 ChannelFreq:926001611 FreqError:-10}
16:38:44.316892 E001BE70010099DB 6 0 0 0 0 msg.ID=0
16:38:44.317081 Hop: {ChannelIdx:32 ChannelFreq:918475353 FreqError:-10}
16:38:46.880965 5001BEFF71007D45 7 0 0 0 0 msg.ID=0
16:38:46.881154 Hop: {ChannelIdx:13 ChannelFreq:908942094 FreqError:-5}
16:38:49.442879 6000BE008100243A 8 0 0 0 0 msg.ID=0
16:38:49.443065 Hop: {ChannelIdx:36 ChannelFreq:920482355 FreqError:33}
16:38:52.004698 8000BE15C90083F4 9 0 0 0 0 msg.ID=0
16:38:52.004880 Hop: {ChannelIdx:22 ChannelFreq:913457849 FreqError:-61}
16:38:54.568438 E002AD700200A221 10 0 0 0 0 msg.ID=0
16:38:54.568630 Hop: {ChannelIdx:3 ChannelFreq:903924589 FreqError:16}
16:38:57.130347 5001ACFF7300EDE8 11 0 0 0 0 msg.ID=0
16:38:57.130535 Hop: {ChannelIdx:29 ChannelFreq:916970102 FreqError:-39}
16:38:59.692292 4002A8FFC100AB20 12 0 0 0 0 msg.ID=0
16:38:59.692474 Hop: {ChannelIdx:44 ChannelFreq:924496359 FreqError:-61}
16:39:02.255687 8002A815C900FB49 13 0 0 0 0 msg.ID=0


[amino1958]

Did you take a look at the US frequencies in my repo - I altered them from the previous values based on what I saw on SDR (though I found the SDR frequency itself to be a bit unstable and temperature dependent - maybe I should have bought a more expensive one!)
The values I came up with are all equally spaced which makes more sense to me than the slightly randomly spaced previous values!

No, I haven't - thanks for the heads-up. Yes, evenly spaced frequencies do sound better, I might try to use your table first to test. What I think is missing from my code at least is a simple means of frequency shift correction for individual packets. Even though the AFC in the RFM69 should follow them to an extent and most of the time it's working pretty well. The values in my code are from Dekay, who read the frequencies out of a console. But the console probably already uses an algorithm to follow small shifts of the transmitters, that's prolly why the frequency values look a bit random... Maybe on this band it's more important to adapt to individual setups.

Aaah...  Maybe that's what my problem was. I too was using the frequency table from Dekay's research. Is this what you are using?  [edit: I took a look at your repo and it looks like the answer is yes]

Code: [Select]

#define DAVIS_FREQ_TABLE_LENGTH 51
const unsigned int8 FRF[DAVIS_FREQ_TABLE_LENGTH][3] =
{
  {0xE3, 0xDA, 0x7C},
  {0xE1, 0x98, 0x71},
  {0xE3, 0xFA, 0x92},
  {0xE6, 0xBD, 0x01},
  {0xE4, 0xBB, 0x4D},
  {0xE2, 0x99, 0x56},
  {0xE7, 0x7D, 0xBC},
  {0xE5, 0x9C, 0x0E},
  {0xE3, 0x39, 0xE6},
  {0xE6, 0x1C, 0x81},
  {0xE4, 0x5A, 0xE8},
  {0xE1, 0xF8, 0xD6},
  {0xE5, 0x3B, 0xBF},
  {0xE7, 0x1D, 0x5F},
  {0xE3, 0x9A, 0x3C},
  {0xE2, 0x39, 0x00},
  {0xE4, 0xFB, 0x77},
  {0xE6, 0x5C, 0xB2},
  {0xE2, 0xD9, 0x90},
  {0xE7, 0xBD, 0xEE},
  {0xE4, 0x3A, 0xD2},
  {0xE1, 0xD8, 0xAA},
  {0xE5, 0x5B, 0xCD},
  {0xE6, 0xDD, 0x34},
  {0xE3, 0x5A, 0x0A},
  {0xE7, 0x9D, 0xD9},
  {0xE2, 0x79, 0x41},
  {0xE4, 0x9B, 0x28},
  {0xE5, 0xDC, 0x40},
  {0xE7, 0x3D, 0x74},
  {0xE1, 0xB8, 0x9C},
  {0xE3, 0xBA, 0x60},
  {0xE6, 0x7C, 0xC8},
  {0xE4, 0xDB, 0x62},
  {0xE2, 0xB9, 0x7A},
  {0xE5, 0x7B, 0xE2},
  {0xE7, 0xDE, 0x12},
  {0xE6, 0x3C, 0x9D},
  {0xE3, 0x19, 0xC9},
  {0xE4, 0x1A, 0xB6},
  {0xE5, 0xBC, 0x2B},
  {0xE2, 0x18, 0xEB},
  {0xE6, 0xFD, 0x42},
  {0xE5, 0x1B, 0xA3},
  {0xE3, 0x7A, 0x2E},
  {0xE5, 0xFC, 0x64},
  {0xE2, 0x59, 0x16},
  {0xE6, 0x9C, 0xEC},
  {0xE2, 0xF9, 0xAC},
  {0xE4, 0x7B, 0x0C},
  {0xE7, 0x5D, 0x98}
};


 

[mcrossley]

I think my old brain may have been playing tricks on me!

It was the EU frequencies I tweaked as I had switched from US to EU by then, sorry - the modified version is in the /Examples/RelayRxTx folder

But yes those were the frequencies I was using when I had US transmitters.

Both ran perfectly well - I last power cycled my EU frequency Arduino because I was reorganising my study after it had been running for 18 months without an issue.

That is through three brick walls in the house, a brick garage and about 100' to the ISS (less to my wind transmitter).

EDIT:  I found tuning the antenna length quite critical to the best reception.

[amino1958]

I think my old brain may have been playing tricks on me!

It was the EU frequencies I tweaked as I had switched from US to EU by then, sorry - the modified version is in the /Examples/RelayRxTx folder

But yes those were the frequencies I was using when I had US transmitters.

Both ran perfectly well - I last power cycled my EU frequency Arduino because I was reorganising my study after it had been running for 18 months without an issue.

That is through three brick walls in the house, a brick garage and about 100' to the ISS (less to my wind transmitter).

EDIT:  I found tuning the antenna length quite critical to the best reception.

Yes... I just saw that in your code. I'm disappointed 

[kobuki]

Why? He said both ran perfectly well.

[amino1958]

Well... I used the same frequencies and had issues with packet loss and range. And based on what you said earlier "Note that I haven't sorted out the US band yet (it was hindered by the lack of a US transmitter that I do have now, finally) - it means that you need some freq. tweaking to make it 100% work, otherwise it skips about every other packet. "
I'm assuming that you are having issues using the same US frequencies, correct?

I was hoping that he had tweaked the US frequencies to get it to work properly but he had done it for the EU frequencies and not the US. It's quite possible that it's an antenna tuning issue although I am using COTS 900MHz antennas so there's not much to tune there.

[kobuki]

I think Mark tuned for the US band first, then later he started using the EU band, but I'm a bit confused about this after reading his posts. @mcrossley, could you please clarify?

In any case, I still plan to fix the US band Soon(TM).

[amino1958]

I checked his freq table, yours and mine and all three are the same as the original. Am I missing something?

[kobuki]

It was long ago when we discussed the freq. tuning, but I think he only nudged the values in place via runtime config and didn't touch the table itself. I'll get to the bottom of this, too, eventually.

[amino1958]

Thanks! Let me know if there's anything I can do to help. I'm going to try out the RTL-SDR approach as soon as the hardware arrives, but regardless of whether it works for me or does not, I'd still like to figure out why the RFM69 approach using the US frequencies did not work out as expected.

[mcrossley]

I think Mark tuned for the US band first, then later he started using the EU band, but I'm a bit confused about this after reading his posts. @mcrossley, could you please clarify?

In any case, I still plan to fix the US band Soon(TM).

Correct, I had my RFM69 working for at least a couple of years against my two US frequency transmitters. I then switched to EU frequency boards.

I now have two US frequency ISS boards kicking around and either looking for a home or the bin if my wife has her way!

BTW, I am using using a 1/4 wave straight wire antenna - tuned with a pair of side snips until too short then add a new one! I found the best length a little bit different from the calculated value.

[kobuki]

BTW, I am using using a 1/4 wave straight wire antenna - tuned with a pair of side snips until too short then add a new one! I found the best length a little bit different from the calculated value.

Yeah, the theoretical dipole or monopole has no thickness and is directly connected to the power source, has an infinite ground plane or a counterpoise. In real life, you have traces connecting the antenna, very minimal ground plane, wire insulation and some small, random thickness. These all contribute to the actual impedance of the antenna, and it tends to be shorter than the theoretical length. But yes, those small wires cut to size are pretty good for what they are.

[amino1958]

Correct, I had my RFM69 working for at least a couple of years against my two US frequency transmitters. I then switched to EU frequency boards.

Do you happen to recollect what sort of range you got with the US transmitters and the packet loss?

[amino1958]

Just a quick update on this thread so far....

Quite impressed with the RTL-SDR on my preliminary testing with US frequencies.

Using Luc's code verbatim (https://github.com/lheijst/rtldavis) with an RTL-SDR V3 dongle (https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/) and a Abracon APAMS-118 900 MHz  antenna (digikey# 535-12911-ND) running on an RPI3B+  ......

I'm getting a LOS range of 500ft with very little packet loss. I can't get any statistics at this time but it looks like the  8-byte packets are consistently coming in every 2-3 seconds as expected.

Next step is to modify the code to broadcast these packets via UDP on the Local Area Network.

[Storm017]

Just a quick update on this thread so far....

Quite impressed with the RTL-SDR on my preliminary testing with US frequencies.

Using Luc's code verbatim (https://github.com/lheijst/rtldavis) with an RTL-SDR V3 dongle (https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/) and a Abracon APAMS-118 900 MHz  antenna (digikey# 535-12911-ND) running on an RPI3B+  ......

I'm getting a LOS range of 500ft with very little packet loss. I can't get any statistics at this time but it looks like the  8-byte packets are consistently coming in every 2-3 seconds as expected.

Next step is to modify the code to broadcast these packets via UDP on the Local Area Network.

Looks like you get decent range.  I been using Luc's code for a couple years and don't have any issues.

[mcrossley]

To follow up on this I still have a US frequency ISS lying around so I had a go at the US frequencies. Applying the same principle that Davis would pick nice round numbers and the channel gaps would be consistent I came up with the following set of frequencies.

Now they may need adjusting for however your oscillator is calibrated, but you should only have to add a constant offset to each channel. The channel gap is 501750 Hz

On my test RFM69 every channel has an REI of 0 +/-1, better than that in reality as 95+% have values 0 and -1 (1 REI = 61Hz)

Code: [Select]

static const __attribute__((progmem)) FRF_ITEM FRF_US[FREQ_TABLE_LENGTH_US] =
{
  // Mark Crossley update 24/11/2021
  {0xE3, 0xD9, 0xAE}, // 911400100
  {0xE1, 0x97, 0xAA}, // 902368600
  {0xE3, 0xF9, 0xCB}, // 911901850
  {0xE6, 0xBC, 0x42}, // 922940350
  {0xE4, 0xBA, 0x77}, // 914912350
  {0xE2, 0x98, 0x8F}, // 906382600
  {0xE7, 0x7C, 0xEE}, // 925950850
  {0xE5, 0x9B, 0x40}, // 918424600
  {0xE3, 0x39, 0x1F}, // 908891350
  {0xE6, 0x1B, 0xB2}, // 920431600
  {0xE4, 0x5A, 0x21}, // 913407100
  {0xE1, 0xF8, 0x00}, // 903873850
  {0xE5, 0x3A, 0xEA}, // 916919350
  {0xE7, 0x1C, 0x98}, // 924445600
  {0xE3, 0x99, 0x75}, // 910396600
  {0xE2, 0x38, 0x39}, // 904877350
  {0xE4, 0xFA, 0xB0}, // 915915850
  {0xE6, 0x5B, 0xEC}, // 921435100
  {0xE2, 0xD8, 0xC9}, // 907386100
  {0xE7, 0xBD, 0x27}, // 926954350
  {0xE4, 0x3A, 0x04}, // 912905350
  {0xE1, 0xD7, 0xE3}, // 903372100
  {0xE5, 0x5B, 0x06}, // 917421100
  {0xE6, 0xDC, 0x5E}, // 923442100
  {0xE3, 0x59, 0x3B}, // 909393100
  {0xE7, 0x9D, 0x0B}, // 926452600
  {0xE2, 0x78, 0x73}, // 905880850
  {0xE4, 0x9A, 0x5A}, // 914410600
  {0xE5, 0xDB, 0x79}, // 919428100
  {0xE7, 0x3C, 0xB5}, // 924947350
  {0xE1, 0xB7, 0xC7}, // 902870350
  {0xE3, 0xB9, 0x91}, // 910898350
  {0xE6, 0x7C, 0x08}, // 921936850
  {0xE4, 0xDA, 0x94}, // 915414100
  {0xE2, 0xB8, 0xAC}, // 906884350
  {0xE5, 0x7B, 0x23}, // 917922850
  {0xE7, 0xDD, 0x44}, // 927456100
  {0xE6, 0x3B, 0xCF}, // 920933350
  {0xE3, 0x19, 0x02}, // 908389600
  {0xE4, 0x19, 0xE7}, // 912403600
  {0xE5, 0xBB, 0x5C}, // 918926350
  {0xE2, 0x18, 0x1D}, // 904375600
  {0xE6, 0xFC, 0x7B}, // 923943850
  {0xE5, 0x1A, 0xCD}, // 916417600
  {0xE3, 0x79, 0x58}, // 909894850
  {0xE5, 0xFB, 0x96}, // 919929850
  {0xE2, 0x58, 0x56}, // 905379100
  {0xE6, 0x9C, 0x25}, // 922438600
  {0xE2, 0xF8, 0xE5}, // 907887850
  {0xE4, 0x7A, 0x3E}, // 913908850
  {0xE7, 0x5C, 0xD1}  // 925449100
};


[amino1958]

Mark... I'm wondering...

As mentioned above, the RTL_SDR (US Freq) I setup is working exceptionally well with very little packet loss and a LOS range of 500ft+

Could we not use the RTL-SDR frequencies as a guide ?

I have ordered a Moteino to try out but it wont be here for another week.

Here are the US freq used by the RTL-SDR:

Code: [Select]

p.channels = []int{
// Thanks to Paul Anderson and Rich T for testing the US frequencies
902419338, 902921088, 903422839, 903924589, 904426340, 904928090, // US freq per 20190326
905429841, 905931591, 906433342, 906935092, 907436843, 907938593,
908440344, 908942094, 909443845, 909945595, 910447346, 910949096,
911450847, 911952597, 912454348, 912956099, 913457849, 913959599,
914461350, 914963100, 915464850, 915966601, 916468351, 916970102,
917471852, 917973603, 918475353, 918977104, 919478854, 919980605,
920482355, 920984106, 921485856, 921987607, 922489357, 922991108,
923492858, 923994609, 924496359, 924998110, 925499860, 926001611,
926503361, 927005112, 927506862, 
}
}
// Both NZ and US use the same hop sequence
p.ChannelCount = len(p.channels)
p.hopIdx = rand.Intn(p.ChannelCount)
p.hopPattern = []int{
0, 19, 41, 25, 8, 47, 32, 13, 36, 22, 3, 29, 44, 16, 5, 27, 38,
10, 49, 21, 2, 30, 42, 14, 48, 7, 24, 34, 45, 1, 17, 39, 26, 9,
31, 50, 37, 12, 20, 33, 4, 43, 28, 15, 35, 6, 40, 11, 23, 46, 18,
}
p.reverseHopPatrn = []int{
0, 29, 20, 10, 40, 14, 45, 25, 4, 33, 17, 47, 37, 7, 23, 43, 13,
30, 50, 1, 38, 19, 9, 48, 26, 3, 32, 15, 42, 11, 21, 34, 6, 39,
27, 44, 8, 36, 16, 31, 46, 2, 22, 41, 12, 28, 49, 5, 24, 18, 35,
}
}

 

[kobuki]

Could we not use the RTL-SDR frequencies as a guide ?

Most likely not, IIRC the SDR frequencies are shifted using an unknown formula to make the reception work. In other words, the numbers don't directly represent the actual frequencies. This was the biggest challenge in fixing the original code the current implementation is derived from.

[mihec]

I just noticed this thread - I apologize for breaking the conversation. I am very interested in this receiver. I have few dongles to use which I originally used for flightradar24.
I downloaded the GIT sources from both (lheijst and bemasher) but am unable to receive the packets. The dongle is recognized by the rtldavis binary but no packets received. I suppose I should use a proper antenna? Right now I have a 1090 MHz one which probably does not let 868 MHz (EU) through? Is there any specific requirement for antenna or just to be tuned to 868 MHz?
I'm using rtldavis on Linux at the moment but plan to move to RPi if this works well for me.
Thanks.

[vreihen]

If the USB dongle that you are using was sold to be used as an ADS-B receiver for FlightRadar24 and similar services, it may have internal filters to filter out frequencies other than 1090 Mhz.  I bought a pair of them at one point that were pre-tuned for two different frequencies, intended for a DIY small airplane navigation system.  One of the services was also selling a branded antenna line filter to limit the input frequency at one point.....

[mihec]

That was the issue. I used a high quality dongle with an on board filter. I now use a cheaper version without a filter and it works
The next thing is to decode the packages to get °C and km/h ...
Thanks, vreihen.
Just to be clear: if I use the dongle, I don't need a Davis receiving console nor the WL Live? Just a RPi and the dongle and weewx?

[Storm017]

Just to be clear: if I use the dongle, I don't need a Davis receiving console nor the WL Live? Just a RPi and the dongle and weewx?

You don't need to use a console; but if you want pressure, indoor temperature, and indoor humidity you would need a BME280 sensor or equivalent.

[amino1958]

Can anyone tell me if the RTL_SDR or RFM69 software will work with (or can be configured for) a Davis Repeater? Looking at the Repeater manual, it looks like it is a store and forward repeater and has a "Repeater ID". So I would assume that it operates at the same frequency and uses the same 8-byte packet format. However I have searched far and wide and cannot find any information on where in the packet is this Repeater ID stored. Any advise would be greatly appreciated since I plan on using the RTL-SDR with an ISS but now we have to place it farther away (> 500ft) and will need a Repeater to help get the signal through. Thanks!