Topic: Software Defined Radio with the WS-2902A

[StephenR0]

I have a WS-2902A and like it very much.  I looked at the ObserverIP, but I didn't want to fight yet another proprietary device.  So, I decided to explore using a software defined radio to receive the signal from the WH65B (the sensor array for the WS-2902A).  I also bought a WH25 to get indoor temperature, humidity, and barometric pressure.  I have it working pretty well at this point.  So, I thought I'd describe the pieces of it in case anyone was interested in doing this, too.

o Setup a Raspberry Pi.  You might find these helpful.  Of course, you could use some other kind of Linux capable hardware.

https://thisdavej.com/create-a-lightweight-raspberry-pi-system-with-raspbian-lite/
https://github.com/weewx/weewx/wiki/Raspberry-Pi

o Get an rtl-sdr device.  I'm using a cheap dongle from Ebay, but I've removed the case and glued heatsinks to the two hot chips.  The first two have provisions to sink the heat to the case.

https://www.amazon.com/dp/B011HVUEME
https://www.amazon.com/dp/B01GDN1T4S
https://www.ebay.com/sch/i.html?_nkw=DAB+FM+DVB-T+RTL2832U+R820T2+SDR&_sop=15

o Install rtl_433.  You'll need to build it from master to get support for the WH65B.

https://github.com/merbanan/rtl_433
https://github.com/merbanan/rtl_433/blob/master/BUILDING.md

o Install WeeWX using setup.py.  This puts WeeWX in /home/weewx instead of /etc

http://weewx.com/docs/setup.htm

o Install weewx-sdr.  Until my issues are resolved, you'll have to do some editing.  I can describe this further if anyone gets this far.

https://github.com/matthewwall/weewx-sdr
https://github.com/matthewwall/weewx-sdr/issues/34
https://github.com/matthewwall/weewx-sdr/issues/33

These are the general steps and some pointers to get you started.  You probably should be familiar with the Linux command line and hopefully enjoy this kind of thing. 

[WA4OPQ]

Thanks for the info. I look forward to attempting this in the future.
At present my applications and needs require the ObserverIP, but I'm glad when I give it a go I will have a good starting point.

[galfert]

I'm currently using an ObserverIP and although it works it still it isn't the best direct method. I'm just not a fan of the screen scraping from a technical standpoint. I think I too might give this a shot. The neat thing is that I can just tinker with the added components and it doesn't affect my existing configuration.

Can you give us any details on the different RTL-SDR adapters you referenced. How do they compare? Which is best if price was not a concern? I'm referring to a higher priced one that you may not have mentioned. Is one of them capable of greater distance because of antenna differences or anything else?

Keep us posted on any changes or improvements.

Thanks!

[StephenR0]

This is the first one that I ordered.

https://www.amazon.com/gp/product/B011HVUEME

It has a temperature compensated oscillator, so it doesn't need calibrated.  In addition, it has a mode where it can be used in the shortwave frequency range, although I haven't tried that.  As I mentioned before, it has some heat conductive foam in it to sink the heat to the relatively large aluminum case.  I think it's a good option for playing with an rtl-sdr.  But when I put together the Pi, I needed to get something to leave in place there.  I decided to try one of the cheap Ebay dongles.

https://www.ebay.ca/itm/332757268565

It does need calibrated and the tuner and dsp chips can warm up some.  Apparently, this mostly affects higher frequencies.  But I decided to take the plastic case off and use some heatsink plaster to glue some ram heatsinks that I had laying around on those chips.  I don't know if that's strictly necessary, though.  Calibration consists of figuring out the actual offset of the dongle from the real frequency when it warms up.  I used the local weather radio station with HDSDR to determine that.  You only have to do that once.  Then you can include that on the command line in rtl_433 as the -p parameter.  It comes with an antenna that seems to work, even though it's not exactly the right length.  I'm experimenting with lengthening it to half wave which is about six and one eighth inches at 915mhz.  That's about the limit of my experience so far.  I'm sure the Nooelec dongle is good, too.  In terms of a better SDR device, I'm pretty convinced that the SDRplay is pretty good.

https://www.sdrplay.com/

It's more money and I don't think it works with rtl_433.  But I do think it's a well engineered device for what it is.  But the cheap dongles should be enough for what we're doing.  Again, I'm not an expert on these things.  There's lots of youtube videos about this, though.

[Bushman]

Those SDRPlay ones are nice - but spendy!  I've got a Nooelec and it is just fine.

[Stenella]

Wish I would have found this thread earlier! Did not know there was a way to pull the data directly instead of the redirect method on the ObserverIP.

As per the instructions in the OP, I can now pull data directly from the WH65B (Osprey) sensor array and WH31B temp/humidity sensors! Adding a 3dB gain antenna has resulted in far more reliable communication than I had with the ObserverIP.

I am unable to find the WH32B temp/humidity/pressure sensor. it does not show  up as a recognized type in the rtl_433 supported protocols nor does it appear when doing a scan of the 915Mhz spectrum while removing/reinserting the batteries. Has anyone gotten this to work? are you using another sensor for barometric pressure?

[StephenR0]

Well!  I must say, I'm quite impressed with your progress.    I had wondered how well the WS-2000 sensors would work with rtl_433.  I'm using a WH25B from Ambient Weather to get indoor temperature, humidity, and barometric pressure.

https://www.ambientweather.com/amws1000bth.html

I wasn't aware of the WH32B when I bought my WS-2902A.  The WH25 is supported in rtl_433 with some recent tweaks.

https://groups.google.com/forum/#!topic/rtl_433/nsZsA7Boggw

I'm glad to see that the WH31B seems to work.  Can you tell me what rtl_433 reports it to be?

As far as the WH32B goes, I'm sure that rtl_433 can support it with some work.  I was in a similar situation when I tried to see the WH65B signals.  rtl_433 didn't report anything either.  After some research, I was able to capture the raw signals in the manner described at the bottom of this page.

https://github.com/merbanan/rtl_433

Now, you will probably need more switches than -a -t.  At least the frequency will need to be specified, -f 915000000.  If you're using one of the cheap SDR dongles, you might want to determine the ppm error and specify that, -p <ppm_error>.  You will certainly need to somehow make sure that you're only capturing the WH32B signals.  I have had quite a bit of trouble getting the visual SDR tools to see the signals put out by these devices.  They seem to be quite faint.  And they transmit only about once a minute.

Once you are able to capture some raw signals, those captures need to be made available to the rtl_433 developers.  The process for this is described in the rtl_433 wiki on github.

https://github.com/merbanan/rtl_433/wiki/Adding-a-new-remote-device

I had never done this before, but I managed to stumble through the process.    The rtl_433 developers are quite knowledgeable and once they see the samples, they can tell an amazing amount about what they are.  In my case, we needed to take a couple of runs at it.  At first, they thought it was the same as the WH24 sensor array.

https://github.com/merbanan/rtl_433_tests/pull/234

After I had some experience comparing the data from rtl_433 and my WS-2902A console, I realized that there were some differences.

https://github.com/merbanan/rtl_433/issues/844

At that point, the WH65B was fully supported.  I don't think the WH32B will be nearly as difficult to support as the WH65B was.  I expect that the protocol will be very similar to the WH25.  But the rtl_433 developers are very able to sort it out.  Please feel welcome to PM me or post if you like.  I'll certainly do what I can to help.

[thorn]

I have one of the cheap SDRs, I have used one for the ADS-B aircraft squawks and it works well.  It picks up FM stations well too.

So, I setup one up on my Linux box using gqrx and I see 3 signals, one could be my slowly 16yo failing Davis station in the back and the other is a WH25B temp sensor inside and I have a  WS-2902 in the front. The large wide signal is the WH25B. I guess the small one every few seconds is the Davis? And the smaller wide signal the WS-2902? I'm going to put it on a laptop and take it out closer to the stations to see what is what.

Now, you will probably need more switches than -a -t.  At least the frequency will need to be specified, -f 915000000.  If you're using one of the cheap SDR dongles, you might want to determine the ppm error and specify that, -p <ppm_error>.  You will certainly need to somehow make sure that you're only capturing the WH32B signals.  I have had quite a bit of trouble getting the visual SDR tools to see the signals put out by these devices.  They seem to be quite faint.  And they transmit only about once a minute.

[WA4OPQ]

This is interesting. I've always believed that the 2902 transmits every 14 seconds, as indicated by it's LED pulse.
I have an old SDR stashed away somewhere, I guess I'm going to have to go look for it. Curiosity is getting to me.

[StephenR0]

I think it's more like 16 seconds.  A minor point. 

[kbellis]

I'm going to put it on a laptop and take it out closer to the stations to see what is what.

Very interesting! Let us know what you discover.

[thorn]

I'm not getting anything when I'm close to the station. There's something in my garage is giving off the narrow signal, it gets very strong there. But near the station nothing and also nothing at the Davis station.  But there is a signal or 2 that is wide every minute. I have a couple of the 432MHz remote temperature devices and I see them. I'm not sure what the other signals are coming from. I'm really far from any neighbors.

Could the 900HMz (33cm band) devices be spread spectrum? Or really wide?

Very interesting! Let us know what you discover.

[Mandrake]

I'm not getting anything when I'm close to the station. There's something in my garage is giving off the narrow signal, it gets very strong there. But near the station nothing and also nothing at the Davis station.  But there is a signal or 2 that is wide every minute. I have a couple of the 432MHz remote temperature devices and I see them. I'm not sure what the other signals are coming from. I'm really far from any neighbors.

Could the 900HMz (33cm band) devices be spread spectrum? Or really wide?

Very interesting! Let us know what you discover.

 I believe that the Davis is spread spectrum frequency hopping so may be harder to pin down.

[GHammer]

Well!  I must say, I'm quite impressed with your progress.    I had wondered how well the WS-2000 sensors would work with rtl_433.  I'm using a WH25B from Ambient Weather to get indoor temperature, humidity, and barometric pressure.

I have a 2902A and have had a wee bit of unreliable WiFi, so looked at this as a reliable method of getting the data into weewx.
I have a WS-2000 console (great display) that came with the WH32B sensor, so I purchased the WH25B from Ambient.

My question for you is, what device numbers do you use for the WH65B and WH25B with rtl_433 as I don't find the 65B listed.
I used this command which from the supported device list says it should be the WH25B, but I get the WH65B output.

Code: [Select]

rtl_433 -f 915M -s 2400000 -R 78 -F json

{"time" : "2019-02-06 11:48:05", "model" : "Fine Offset WH65B", "id" : 172, "temperature_C" : 2.700, "humidity" : 57, "wind_dir_deg" : 113, "wind_speed_ms" : 0.382, "gust_speed_ms" : 1.020, "rainfall_mm" : 1317.244, "uv" : 540, "uvi" : 1, "light_lux" : 30116.000, "battery" : "OK", "mic" : "CRC"}
{"time" : "2019-02-06 11:48:21", "model" : "Fine Offset WH65B", "id" : 172, "temperature_C" : 2.700, "humidity" : 57, "wind_dir_deg" : 104, "wind_speed_ms" : 0.637, "gust_speed_ms" : 1.020, "rainfall_mm" : 1317.244, "uv" : 540, "uvi" : 1, "light_lux" : 31713.000, "battery" : "OK", "mic" : "CRC"}

[galfert]

This information will probably not help solve the SDR pickup of the indoor themo-hygrometer-barometer but it is a good FYI with caution.

WH65B = WS-2902-ARRAY (outdoor sensor array)
WH25B = WS-1000-BTH (old themo-hygrometer-barometer)
WH32B = new version of WH25B (new themo-hygrometer-barometer)

If you have both a WH32B and a WH25B (also called WS-1000-BTH) you must only use one or the other as they provide the same functionality. If you power both up you'll cause a random pickup of one or the other. The WH32B just has newer sensor. You don't need one if you have the other.

So why would anyone buy a WH25B if you already had a WH32B? What am I missing? Is there a radio transmission difference when it comes to SDR use? With my WS-2000 or my ObserverIP they both accept either the WH25B (WS-1000-BTH) or the WH32B being powered on without needing to do anything to these consoles. I upgraded from the WH25B to the WH32B when I added the WS-2000-C console. I had been using the WH25B (WS-1000-BTH) long before with the ObserverIP. Now the ObserverIP has accepted the WH32B wih no problem.

[StephenR0]

I have a 2902A and have had a wee bit of unreliable WiFi, so looked at this as a reliable method of getting the data into weewx.
I have a WS-2000 console (great display) that came with the WH32B sensor, so I purchased the WH25B from Ambient.

My question for you is, what device numbers do you use for the WH65B and WH25B with rtl_433 as I don't find the 65B listed.
I used this command which from the supported device list says it should be the WH25B, but I get the WH65B output.

Code: [Select]

rtl_433 -f 915M -s 2400000 -R 78 -F json

The -R 78 switch covers both the WH65B and the WH25B.  You should see both kinds of messages in the output.  Now, the WH25B only transmits every one minute and four seconds.  So you're going to have to wait a little bit to see output.  Also, I don't use the -s switch which means that my sample rate is the default 250000 Hz.  I'm not sure if that would have an effect or not.

[StephenR0]

So why would anyone buy a WH25B if you already had a WH32B? What am I missing? Is there a radio transmission difference when it comes to SDR use? With my WS-2000 or my ObserverIP they both accept either the WH25B (WS-1000-BTH) or the WH32B being powered on without needing to do anything to these consoles. I upgraded from the WH25B to the WH32B when I added the WS-2000-C console. I had been using the WH25B (WS-1000-BTH) long before with the ObserverIP. Now the ObserverIP has accepted the WH32B wih no problem.

I don't have a WH32B, so I can't verify that rtl_433 works with that device.  But Stenella mentioned that it didn't show any output.  That could easily be.  When I was first trying to get the WH65B working with rtl_433, it was very similar to the WH24 sensor array for which there was already code in rtl_433.  But rtl_433 ignored the WH65B packets because of a timing check.  Once this was relaxed, the packets were received.  Later this timing difference was used to distinguish between the WH65B and the WH24 because there are differences in the data.  You can read more detail about this in links in my earlier post (reply #3).

[GHammer]

I have a 2902A and have had a wee bit of unreliable WiFi, so looked at this as a reliable method of getting the data into weewx.
I have a WS-2000 console (great display) that came with the WH32B sensor, so I purchased the WH25B from Ambient.

My question for you is, what device numbers do you use for the WH65B and WH25B with rtl_433 as I don't find the 65B listed.
I used this command which from the supported device list says it should be the WH25B, but I get the WH65B output.

Code: [Select]

rtl_433 -f 915M -s 2400000 -R 78 -F json

The -R 78 switch covers both the WH65B and the WH25B.  You should see both kinds of messages in the output.  Now, the WH25B only transmits every one minute and four seconds.  So you're going to have to wait a little bit to see output.  Also, I don't use the -s switch which means that my sample rate is the default 250000 Hz.  I'm not sure if that would have an effect or not.

So, using a slightly different frequency and moving the antenna about 2 feet result in good data from both the 65B and the 25B.
Not a faulty dongle at all. Faulty placement of the antenna.

This:

Code: [Select]

rtl_433 -M utc -p 39.741 -R 78 -f 914980000 -F jsonProduces this:

Code: [Select]

{"time" : "2019-02-06 22:53:44", "model" : "Fine Offset Electronics, WH25", "id" : 107, "temperature_C" : 17.300, "humidity" : 34, "pressure_hPa" : 1006.400, "battery" : "OK", "mic" : "CHECKSUM"}
{"time" : "2019-02-06 22:53:57", "model" : "Fine Offset WH65B", "id" : 172, "temperature_C" : 3.500, "humidity" : 89, "wind_dir_deg" : 107, "wind_speed_ms" : 0.191, "gust_speed_ms" : 0.510, "rainfall_mm" : 1317.752, "uv" : 0, "uvi" : 0, "light_lux" : 0.000, "battery" : "OK", "mic" : "CRC"}
Every 16 seconds for the 65B and every 60 seconds for the 25B.

Thanks for letting me this could be done, and so easily!

[GHammer]

So why would anyone buy a WH25B if you already had a WH32B? What am I missing? Is there a radio transmission difference when it comes to SDR use? With my WS-2000 or my ObserverIP they both accept either the WH25B (WS-1000-BTH) or the WH32B being powered on without needing to do anything to these consoles. I upgraded from the WH25B to the WH32B when I added the WS-2000-C console. I had been using the WH25B (WS-1000-BTH) long before with the ObserverIP. Now the ObserverIP has accepted the WH32B wih no problem.

I don't have a WH32B, so I can't verify that rtl_433 works with that device.

I have both and the WH32B was not working with rtl_433. Since the 32B was already connected to the 2000 console, I'm counting on it to always prefer the 32B over the 25B, and if not, I'll cross that bridge when the toll is due.

[StephenR0]

This:

Code: [Select]

rtl_433 -M utc -p 39.741 -R 78 -f 914980000 -F jsonProduces this:

Code: [Select]

{"time" : "2019-02-06 22:53:44", "model" : "Fine Offset Electronics, WH25", "id" : 107, "temperature_C" : 17.300, "humidity" : 34, "pressure_hPa" : 1006.400, "battery" : "OK", "mic" : "CHECKSUM"}
{"time" : "2019-02-06 22:53:57", "model" : "Fine Offset WH65B", "id" : 172, "temperature_C" : 3.500, "humidity" : 89, "wind_dir_deg" : 107, "wind_speed_ms" : 0.191, "gust_speed_ms" : 0.510, "rainfall_mm" : 1317.752, "uv" : 0, "uvi" : 0, "light_lux" : 0.000, "battery" : "OK", "mic" : "CRC"}
Every 16 seconds for the 65B and every 60 seconds for the 25B.

Thanks for letting me this could be done, and so easily!

Since you're probably at the point where you're trying to glue everything together with the weewx-sdr driver, I should show you my [SDR] section in weewx.conf.

Code: [Select]

[SDR]
    # This section is for the software-defined radio driver.

    # The driver to use
    driver = user.sdr
    path = /usr/local/bin
    cmd = rtl_433 -q -U -F json -p 39.741 -R 78 -f 914980000
    [[sensor_map]]
        outTemp = temperature.89.FOWH65BPacket
        outHumidity = humidity.89.FOWH65BPacket
        windDir = wind_dir.89.FOWH65BPacket
        windSpeed = wind_speed.89.FOWH65BPacket
        windGust = wind_gust.89.FOWH65BPacket
        rain_total = rain_total.89.FOWH65BPacket
        # uv.89.FOWH65BPacket
        UV = uv_index.89.FOWH65BPacket
        radiation = light.89.FOWH65BPacket
        outTempBatteryStatus = battery.89.FOWH65BPacket
        inTemp = temperature.21.FOWH25Packet
        inHumidity = humidity.21.FOWH25Packet
        pressure = pressure.21.FOWH25Packet
        inTempBatteryStatus = battery.21.FOWH25Packet
    [[deltas]]
        rain = rain_total

You'll have to substitute your id values (the middle numbers above) for the ones that I've used.  The uv.89.FOWH65BPacket value is put out by rtl_433, but isn't used by weewx.  For testing, I don't run weewx as a service.  I run weewx directly in an ssh window like this:

./bin/weewxd weewx.conf

while in the weewx top level directory.  This way I can see the messages that it puts out.

I should also mention that under rare circumstances rtl_433 doesn't return a value for light_lux.  This results in Packet.get_float(obj, 'light_lux') not being a float.  This causes the conversion to watts per square meter to fail and weewx dies.  This is in sdr.py in the weewx-sdr driver.  I'm testing a fix for this, but since it occurs so rarely, I won't be confident of it for a couple of weeks at least.

EDIT:  See Reply #26 for an update on this.

[GHammer]

Since you're probably at the point where you're trying to glue everything together with the weewx-sdr driver, I should show you my [SDR] section in weewx.conf.

Code: [Select]

[SDR]
    # This section is for the software-defined radio driver.

    # The driver to use
    driver = user.sdr
    path = /usr/local/bin
    cmd = rtl_433 -q -U -F json -p 39.741 -R 78 -f 914980000
    [[sensor_map]]
        outTemp = temperature.89.FOWH65BPacket
        outHumidity = humidity.89.FOWH65BPacket
        windDir = wind_dir.89.FOWH65BPacket
        windSpeed = wind_speed.89.FOWH65BPacket
        windGust = wind_gust.89.FOWH65BPacket
        rain_total = rain_total.89.FOWH65BPacket
        # uv.89.FOWH65BPacket
        UV = uv_index.89.FOWH65BPacket
        radiation = light.89.FOWH65BPacket
        outTempBatteryStatus = battery.89.FOWH65BPacket
        inTemp = temperature.21.FOWH25Packet
        inHumidity = humidity.21.FOWH25Packet
        pressure = pressure.21.FOWH25Packet
        inTempBatteryStatus = battery.21.FOWH25Packet
    [[deltas]]
        rain = rain_total

You'll have to substitute your id values (the middle numbers above) for the ones that I've used.  The uv.89.FOWH65BPacket value is put out by rtl_433, but isn't used by weewx.  For testing, I don't run weewx as a service.  I run weewx directly in an ssh window like this:

./bin/weewxd weewx.conf

while in the weewx top level directory.  This way I can see the messages that it puts out.

I should also mention that under rare circumstances rtl_433 doesn't return a value for light_lux.  This results in Packet.get_float(obj, 'light_lux') not being a float.  This causes the conversion to watts per square meter to fail and weewx dies.  This is in sdr.py in the weewx-sdr driver.  I'm testing a fix for this, but since it occurs so rarely, I won't be confident of it for a couple of weeks at least.

Thanks for the conf entries and the explanation of the method.

I see that you are not using utc times with your command line. It's in every example on weewx_sdr. Those are examples though and you are live, so I'll leave the utc out.

I won't worry about the raw UV value as long since I have the UV Index and Light. That is what I currently show on my website.

The no value halt is concerning though, since it is random. However, I will get things configured and run it this way unless it does hit the rare failure. Then I'll just comment out the SDR and return to Interceptor until a fix is arrived at for light_lux.

In all, I'm extremely pleased to stumble upon this method of getting the data into WeeWX as the Interceptor method was not the easiest thing I've done. My router and both the 2902A and 2000 console do not play well together. I had to build an AP on my server for the console. dnsmasq and hostapd are kind of opaque for many things past a simple setup.

In comparison, with some expert assistance, this is nearly a piece of cake.
I thank Matthew and you for the method and the assistance!

[StephenR0]

It's been pointed out that I should update my version of rtl_433 to fix the -U switch. 

If you run into the problem, let me know and I'll send you my fix to try.

Oh, and if you get an error, save the text to a file in case it's something new so we can figure out what happened.

[GHammer]

Will do.
The switches are a moving target with rtl_433 I guess.
-q is no longer used, quiet by default. Now you use -v to get verbosity.

I will look for any error and keep any logs that result.

Just finished upgrading to 3.9.1 on WeeWX, now installing the SDR driver.

[GHammer]

Oh, and if you get an error, save the text to a file in case it's something new so we can figure out what happened.

As promised. Doesn't seems to affect any functionality, WeeWX runs, data is captured, etc.
When I use the driver directly or when WeeWx starts, I see this logged:

Code: [Select]

Feb  6 22:22:16 weewx1 upowerd[1536]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-5/1-5:1.0


[StephenR0]

Is this a Raspberry Pi?  It doesn't look like Weewx specifically.  Hmmmmm...

Let's see how this seems to affect things.