Topic: Software Defined Radio with the WS-2902A

[GHammer]

Since you already have a GW1000 and WeeWX works with the Interceptor driver, why are you needing to go the SDR route? Just for fun?

Better resolution, the GW1000 has a fixed reporting period.
SDR gets the data into WeeWX as it is transmitted. Plus, one less box to restart, etc.
And, yes, for the fun of it. Same for owning a PWS to begin with.

[galfert]

Since you already have a GW1000 and WeeWX works with the Interceptor driver, why are you needing to go the SDR route? Just for fun?

Better resolution, the GW1000 has a fixed reporting period.

The way the GW1000 sends data to WeeWX can be controlled by changing the upload frequency to what you want. Sure, you can't exceed in terms of data what the sensors send, but it shouldn't be too much different. It is too bad that WeeWX doesn't have a proper API support for the GW1000 and still relies on the Interceptor driver. If WeeWX used the API like Cumulus MX, Meteobridge, and Weather-Display, then the data would be pretty much live as the sensors send it.

SDR gets the data into WeeWX as it is transmitted. Plus, one less box to restart, etc.
And, yes, for the fun of it. Same for owning a PWS to begin with.

Okay good on ya. I get that SDR is superior to the Interceptor driver. I'm all for fun too.

[steepleian]

If you are using a later version of rtl_433 you must use the switch -M oldmodel

Do you have these sensors working with WeeWX via SDR?
If so, kindly share your SDR stanza

Here you go, the 32B mappings are at the bottom: -

[SDR]
    # This section is for the software-defined radio driver.
   
   
    driver = user.sdr
    path = /usr/local/bin
    cmd = rtl_433 -f 868M -s 1024k -M oldmodel -F json -R 78
   
   
    [[sensor_map]]
       
        outTemp = temperature.71.FOWH65BPacket
        windSpeed = wind_speed.71.FOWH65BPacket
        UV = uv_index.71.FOWH65BPacket
        light = light.71.FOWH65BPacket
        outBatteryStatus = battery.71.FOWH65BPacket
        outHumidity = humidity.71.FOWH65BPacket
        windDir = wind_dir.71.FOWH65BPacket
        windGust = wind_gust.71.FOWH65BPacket
        rain_total = rain_total.71.FOWH65BPacket
        inTemp = temperature.233.FOWH32BPacket
        inHumidity = humidity.233.FOWH32BPacket
        barometer = pressure.233.FOWH32BPacket
        inTempBatteryStatus = battery.233.FOWH32BPacket

Everything works quite happily with WeeWX 4.0.0 and Python 3.7

Ian

[GHammer]

If you are using a later version of rtl_433 you must use the switch -M oldmodel

Do you have these sensors working with WeeWX via SDR?
If so, kindly share your SDR stanza

Here you go, the 32B mappings are at the bottom: -

[SDR]
    # This section is for the software-defined radio driver.
   
   
    driver = user.sdr
    path = /usr/local/bin
    cmd = rtl_433 -f 868M -s 1024k -M oldmodel -F json -R 78
   
   
    [[sensor_map]]
       
        outTemp = temperature.71.FOWH65BPacket
        windSpeed = wind_speed.71.FOWH65BPacket
        UV = uv_index.71.FOWH65BPacket
        light = light.71.FOWH65BPacket
        outBatteryStatus = battery.71.FOWH65BPacket
        outHumidity = humidity.71.FOWH65BPacket
        windDir = wind_dir.71.FOWH65BPacket
        windGust = wind_gust.71.FOWH65BPacket
        rain_total = rain_total.71.FOWH65BPacket
        inTemp = temperature.233.FOWH32BPacket
        inHumidity = humidity.233.FOWH32BPacket
        barometer = pressure.233.FOWH32BPacket
        inTempBatteryStatus = battery.233.FOWH32BPacket

Everything works quite happily with WeeWX 4.0.0 and Python 3.7

Ian

Thanks, but those are not the sensors I'm working with. The sample rate of 1024K produces only data for my WH40, no other sensors. I have to use a 250K sample rate.

Take a look at the file I attached to see the output, etc.

[WA4OPQ]

This thread has been around for a while, but I'm glad I found it.
I'm starting on the SDR path so this info is priceless.
My ultimate goal is a solar powered station reporting through ham radio APRS/CWOP for use in areas without internet.
I'm looking for the best way to use the least power. The GW-1000 is said to use 1 amp, many SDRs use between 100-300 mA.
I've just ordered an ADS-B SDR that is said to use 90% less power.
I'll set up a test bed soon and have some real power numbers, but I'll be busy configuring the SDR next week.
I'll let you know what I find.

[StephenR0]

In a past exchange, Ecowitt has told me that the GW1000 draws 5ma minimum.  They didn't mention a maximum, but I think we're looking at negligible power requirements.

[WA4OPQ]

I'll need to get measuring current right away.  5mA is a huge difference and would make it the logical choice.
Thanks for the nudge, I'll get a measurement test jig going this week.

[WA4OPQ]

I won't be going the SDR route, it turns out the GW-1000 is pretty efficient.  SDRs run about 200mA.
The GW-1000 draws 80mA, less than half a watt, to do a microprocessor, WiFi and a 915MHz SDR.
Great engineering.

[cyclogensis]

Any reason this should not work with the WS-2902B? Is the "head unit" still the same?
I have a RTL-SDR I am playing with and using the RTL_433
finding it tricky to see and get the 915MHz signal

[StephenR0]

Actually, rtl_433 has nothing to do with the console.  It just reads the sensor array, the WH65B.  But there's no reason that it shouldn't work.

[cyclogensis]

Ahh! I see it! It seems my house had a deadspot where my antenna was..
This is awesome! Finally access to my own data!

[cmeyer]

I think the main reasons the SDR route is interesting for weewx:

• you get the data as it's received, which the GW1000 sadly doesn't support w/ custom servers
• you control how each sensor is mapped, which the GW1000 also can't do. This is especially interesting if you have multiple different wind sensors, or other sensors w/ overlapping data which the GW1000 won't let you prioritize.
• let's you pull in data from sensors the GW1000 for some reason refuses to. For example I've put one of those stand-alone indoor barometers outdoors, so pressure readings aren't influenced by doors/windows, etc

[mostlychris]

Reviving this thread again..or keeping it alive. I have a WH65B as well as a WH25. I can put my SDR on my raspberri pi anywhere in my house with multiple walls in between and completely out of line of sight. The WH25 updates every 1 minute and 4 seconds as it should. It doesn't miss a beat. The WH65B will work once or twice but stops.

Is it possible there is some issue other than RF related that is causing this? Also, why does it report both WH65B and WH24 from that sensor package? I'm pulling my hair out on this one!

UPDATE: I got the WH65B it to work briefly by adjusting the antenna. The SDR is closer than the display unit by a long shot. It was working sporadically for less than an hour. The RSSI reported using '-M level' is -12 for the entire time it was working. I just suddenly stopped with no other changes. The display unit is still receiving fine.


 [ You are not allowed to view attachments ]

[StephenR0]

When I was running with a similar configuration, I found that the console could receive from the WH65B much easier than the SDR.  But since I was able to put the unit pretty close to the sensor array, I didn't have any problems.  Additionally, I experimented with different antenna configurations.  But now I'm running with a GW1000.  My unit is one of the earlier ones.  The later versions have been reworked for even greater reception distance.  I find the GW1000 to be a much better option.  It uses much less power than any computer with an SDR.  And it receives from a much greater distance.  Just my two cents.

[galfert]

Also, why does it report both WH65B and WH24 from that sensor package? I'm pulling my hair out on this one!

Because the WH65 and WH24 put out an identical signal. The WH65 replaces the WH24 in the product design cycle. The consoles like the GW1000 that are able to pick up both the WH65 and WH24 need a configuration change set by the user to indicate if they are using the older WH24 because there is no way to differentiate them via RF. It is important for the user to manually set if they have the WH65 or the WH24 because even though the RF broadcast is the same there is a difference in how wind is calculated. The WH24 counts 1 revolution and the WH65 has more precision by counting half revolutions...essentially two ticks per revolution on the WH65 versus 1 tick per revolution on the WH24. Other than that difference the RF broadcast the the same. There are some other sensor differences between the WH65 and WH24 in the the WH65 uses newer and better digital temperature and humidity sensors and the wind vane has better dampening for better wind direction indication...but none of these changes affect the RF broadcast.
 

[mostlychris]

Also, why does it report both WH65B and WH24 from that sensor package? I'm pulling my hair out on this one!

Because the WH65 and WH24 put out an identical signal. The WH65 replaces the WH24 in the product design cycle. The consoles like the GW1000 that are able to pick up both the WH65 and WH24 need a configuration change set by the user to indicate if they are using the older WH24 because there is no way to differentiate them via RF. It is important for the user to manually set if they have the WH65 or the WH24 because even though the RF broadcast is the same there is a difference in how wind is calculated. The WH24 counts 1 revolution and the WH65 has more precision by counting half revolutions...essentially two ticks per revolution on the WH65 versus 1 tick per revolution on the WH24. Other than that difference the RF broadcast the the same. There are some other sensor differences between the WH65 and WH24 in the the WH65 uses newer and better digital temperature and humidity sensors and the wind vane has better dampening for better wind direction indication...but none of these changes affect the RF broadcast.

Ok. So I should just ignore anything from WH24? I am sending data to MQTT based on topic/unit model, which will allow me to ignore. Alternatively, is there a setting in rtl_433 that I can set? I definitely see differences in reported rain level between the two.

[StephenR0]

When I was trying to get the WH65B support into rtl_433, there was some difficulty distinguishing between the WH65B and the WH24.  The word from Fine Offset was:

For the WH65B, the rain cup each count is 0.01inch ( 0.254mm) while WH24 is 0.3mm.

They wouldn't engage in an extended dialog and there was some conflict around wind speed factor that I couldn't resolve.  In the end, it was decided not to change anything until there was better information.  It's possible that there are still issues with rtl_433's WH24 factors.

[galfert]

Okay yes I forgot that the rain gauge is also different between WH24 and WH65.

This presents as a problem to users with the new WH65 sensor array that want to use their old display consoles that came with the WH24. They can get around the compatibility issues simply by entering in some calibration adjustments to account for the difference in wind and rain sensors. Essentially you can imagine the user of an older model that uses the WH24 and then the sensor array stops working. They then upgrade to a new model with its own new display. But their old display still works and they notice wrong reading for the wind and rain. By simply making these calibration adjustments they can fool the old display to continue to work and serve as a secondary display. In some cases the user may upgrade the sensor array instead of buying a complete new station....enter the same calibration adjustments and they have upgraded for less cost. The point being that to the old display console it has no idea that the new WH65 is not at WH24 because they broadcast in the same exact way, but the sensors just measure/count differently.

[mostlychris]

For those following along, I am getting better results with 1) A loop antenna as mentioned by @StephenR0; 2) Changed out the SDR with an exact duplicate but I don't think that matters much; 3) Set a -2 ppm; 4) Set the starting freq as 914.95 instead of right on 915.

I got the ppm idea as the thing would receive for a little bit and then stop. Thought it might be drifting. A -2 ppm is not much at all and these are TXCO stable. What I *think* I am seeing is that the decode for the WH65B is finiky on the window of data it gets. If it is not super close in freq with an RSSI worse than -9 or so it doesn't work well. I am now running at a constant -12.1 RSSI after doing all of the above. In fact, it hasn't moved from that value at all. My WH25 doesn't seem to suffer from any of these issues and it has an RSSI of between -0.10 and -0.14.

[Jai Soone]

While it is true that both the WH24 and the WH65B use a family code of 0x24, rtl_433 tries to distinguish between them based on the fact that the WH65B uses longer pre and post ambles than does the the original WH24. It actually uses the size of the post amble for this distinction. Thus, in generating appropriate output one sees in the code:

data = data_make(
   "model",            "",                 DATA_STRING, type == MODEL_WH24 ? _X("Fineoffset-WH24","Fine Offset WH24") : _X("Fineoffset-WH65B","Fine Offset WH65B"),
.
.
.

Whether or not this code actually works, have no idea.

[mostlychris]

While it is true that both the WH24 and the WH65B use a family code of 0x24, rtl_433 tries to distinguish between them based on the fact that the WH65B uses longer pre and post ambles than does the the original WH24. It actually uses the size of the post amble for this distinction. Thus, in generating appropriate output one sees in the code:

data = data_make(
   "model",            "",                 DATA_STRING, type == MODEL_WH24 ? _X("Fineoffset-WH24","Fine Offset WH24") : _X("Fineoffset-WH65B","Fine Offset WH65B"),
.
.
.

Whether or not this code actually works, have no idea.

Interesting. From some limited testing, I was getting a lot more of the WH65 readings when I was closer to the sensors. As I'm farther away now with a lower signal I am seeing more WH24. It would make sense that maybe it's missing part of the pre/post amble and calling it WH24. Of course, I have no idea what I'm talking about so it could all be coincidence.

[Jai Soone]

While it is true that both the WH24 and the WH65B use a family code of 0x24, rtl_433 tries to distinguish between them based on the fact that the WH65B uses longer pre and post ambles than does the the original WH24. It actually uses the size of the post amble for this distinction. Thus, in generating appropriate output one sees in the code:

data = data_make(
   "model",            "",                 DATA_STRING, type == MODEL_WH24 ? _X("Fineoffset-WH24","Fine Offset WH24") : _X("Fineoffset-WH65B","Fine Offset WH65B"),
.
.
.

Whether or not this code actually works, have no idea.

Interesting. From some limited testing, I was getting a lot more of the WH65 readings when I was closer to the sensors. As I'm farther away now with a lower signal I am seeing more WH24. It would make sense that maybe it's missing part of the pre/post amble and calling it WH24. Of course, I have no idea what I'm talking about so it could all be coincidence.

The preamble is used for bit syncing. Fine offset just sends alternating zeros and ones for this (i.e. 0xaaaaaaa...) For these sensors, rtl_433 just needs to see the last eight bits of the preamble before encountering the 16 bit byte sync pattern of ox2dd4. Thus one sees in the code:

uint8_t const preamble[] = {0xAA, 0x2D, 0xD4}; // part of preamble and sync word

The 17 byte payload immediately follows the "sync word". I would have guessed that, having established byte sync, the entire postamble would be seen. I believe there is an rtl_433 option to dump out the entire bit pattern to see what is being passed down to this decoder function. While the comment:
    // Validate package, WH24 nominal size is 196 bit periods, WH65b is 209 bit periods
indicates a definite size, the actual code is a bit more lenient (wishy washy) in its length test:
    // Classification heuristics
    if (bitbuffer->bits_per_row[0] - bit_offset - sizeof(b) * 8 < 8 )
        if (bit_offset < 61)
            type = MODEL_WH24; // nominal 3 bits postamble
        else
            type = MODEL_WH65B;
    else
        type = MODEL_WH65B; // nominal 12 bits postamble

[Jai Soone]

Interestingly, like the new sensors from Fine Offset that don't have channel dip swicthes, rtl_433 outputs what it documents with the comment line in the code of:
- I: 8 bit Sensor ID, set on battery change
 with the formatting argument:
         "id",               "ID",               DATA_INT, id,

Hopefully this value is unique for each device and remains stable throughout the life of each battery. Use the "ID" that you know to be associated with each device rather than what rtl_433 guesses the device to be, to determine if a given transmission is for the WH24 or the WH65.

[mostlychris]

I do have a couple of questions.  How far from your antenna is your WH65B?  Did the outage coincide with rain and wet weather by any chance?

Edit:  Never mind about the rain.  If your consoles see the WH65B, it can't be that.

I have been chasing the stability issue of the WH65B reporting since starting to use an SDR to gather data. With the addition of a loop antenna it was quite stable in the same closet where my display unit is showing full bars all the time. However, it started having issues this morning so I moved it to the window 30 feet from the sensor unit. It was reporting fine while there..until it started raining. In this graph of RSSI values (using -M level) I can see exactly when it started raining at the first blue bar. The second two bars are when it started raining really hard. The last bar is when it stopped raining. The fluctuation in RSSI values throughout the morning could be related to humidity levels.

 [ You are not allowed to view attachments ]

I read somewhere, maybe even in this thread, that there is a potential issue of condensation or moisture getting into the antenna section or something like that? It seems that rtl_433 cannot decode the WH65 at anything less than an RSSI value of weaker than -12.2 or so. When it rains, the transmit signal drops considerably from the sensor unit and then all bets are off.