Open tolip-ydob opened 4 years ago
Thanks! That a really good analysis so far!
You can just drop the codes into a BitBench to try and document the decoding.
I'll try to verify the checksum soon.
The two checksums are:
There is now some preliminary support, the basic output should work. All values need testing and conversion to unit values still.
I like Bitbench To add a bit more detail to the WDIR_H nibble in your example. change "WDIR_H:4h" to "?2b WDIR_H:1b ?1b" edit #1 to your BitBench example
Wow, on the basic output support. That was quick. Thank you.
I'll pull, build, and test.
compiles, runs, and decodes the packets very reliably Well done.
It was nearly the same as EcoWitt WH40 (and AmbientWeather WH31E).
The wind dir you mention above is currently wrong and all the values need careful testing and we need to figure out the units.
north is hex 00, decimal 00 compass degrees east is hex 5a, decimal 90 south is hex b4, decimal 180 west is hex 1 0e, decimal 270
The WDIR_H shows up as a 2 right before the five fffff the five fffff might have a 'start bit' in front of it or it is used for something else.
on that bitbench link you posted I changed WDIR_H:4h to ?:2b WDIR_H:1b ?:1b
I thought the link I posted included the changes. My ASCII art shows it as a single bit, a "2" in hex.
Today is predicted 15MPH winds, I'll walk it outside and guestimate how much wind the trees are stealing. My Ambient WH25 is up a 9m tall treestump on a short pole and it is not possible to make a side by side comparison at this time.
if you change in your Bitbench example WDIR_LO:8h to WDIR_LO:8d it makes more sense visually I don't know how to add the 9th bit using Bitbench 9 bits binary displayed in decimal as compass degrees.
Thanks. I'll fix the wdir bit together with wind speed, gust, and lux once the correct units for those are known.
More clues
Ambient says Light : 31093.6 lux
Ecowitt says lux : 4929 lux : 4727 lux : 4603
I got the cups on the Ecowitt to rotate in the wind but the Abmient up the pole was a blur and my testing on the ground was not close enough to compare. I'll try and solicit input from a weewx user, it supports both the WS68 and rtl_433 seperately.
Thanks again for the work done so far! :-)
lux might be tricky due to the high dynamic range. Some lux fields are encoded not as just a number but as mantissa and exponent. So we might need some samples for different scales.
I have some questions about support for this device (Ecowitt WS68BN). Since this is still open, I hope this is the right place. I have been able to make this work a bit, but I suspect I'm missing something.
I'm using a Nooelec version of the radio if that helps. This radio works fine listening to my Acurite rain gauge. But when restart it to listen to the 915 band, I can't seem to get consistent results. I'm testing with the device about 18" from the receiver antenna.
So, some quick questions.
pi@weatherradio:~ $ sudo dpkg -l rtl-433
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii rtl-433 20.11-1 armhf Decode 433.9 Mhz data
Is there something obvious I'm doing wrong? I'm willing to learn how to help if the device needs more work to be supported, as I notice it's not on the landing README.md as a supported device.
pi@weatherradio:~ $ rtl_433 -F json -C customary -f 915e6
rtl_433 version unknown inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pi/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
New defaults active, use "-Y classic -s 250k" for the old defaults!
Registered 145 out of 175 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 ]
Detached kernel driver
Found Rafael Micro R820T tuner
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Sample rate set to 1000000 S/s.
Tuner gain set to Auto.
Tuned to 915.000MHz.
Allocating 15 zero-copy buffers
WARNING: Undeclared field "battery_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
WARNING: Undeclared field "lux_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
WARNING: Undeclared field "wind_avg_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
WARNING: Undeclared field "wind_max_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
{"time" : "2022-04-26 12:46:59", "model" : "EcoWitt-WS68", "id" : 1404, "battery_raw" : 74, "battery_ok" : 1, "lux_raw" : 10, "wind_avg_raw" : 0, "wind_max_raw" : 0, "wind_dir_deg" : 74, "data" : "00 210", "mic" : "CRC"}
WARNING: Undeclared field "battery_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
WARNING: Undeclared field "lux_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
WARNING: Undeclared field "wind_avg_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
WARNING: Undeclared field "wind_max_raw" in [113] "Ambient Weather WH31E Thermo-Hygrometer Sensor, EcoWitt WH40 rain gauge"
{"time" : "2022-04-26 12:51:56", "model" : "EcoWitt-WS68", "id" : 1404, "battery_raw" : 74, "battery_ok" : 1, "lux_raw" : 13, "wind_avg_raw" : 0, "wind_max_raw" : 0, "wind_dir_deg" : 79, "data" : "00 400", "mic" : "CRC"}
Since this is from 2020-01 the 20.11 version (2020-11) should have the decoder.
You need to check that 915M has the signal: https://triq.org/rtl_433/ANALYZE.html#verify-a-transmission
If you have a sample which looks good and should be the WS68 but does produce an ouput then upload here as zip.
I guess nobody figured out the scaling for wind and lux. This needs someone to test and document raw readings compared to expected values.
I'd be willing to work on the decoders, I can code. I'm familiar with how radio works, but the tools are confusing me. Certainly not an expert. I apologize for any of this that should be obvious, I'll figure it out eventually.
I just tried this to grab a capture, but something seems off when I upload to the triq.org. I suspect I'm either not understanding how it works, or am missing some command line args? Notably, the Y axis does not show banded around 915Mhz, but rather is centered on 0. I don't think I'm using it right, though I'm going to keep digging on this. I also can't seem to get gqrx to do much for me either, though I suspect that's just being not familiar with the app itself. I attached a 60 second capture if it might be useful which should have a success case at ~5 seconds in, and then there should be one that didn't get recorded ~21 seconds as well (the LED blinked, no event showed up). That's assuming I did this right. I'm actually watching for events with a second receiver on my pi so I can tell if the 60 second window would have at least something to help understand.
pete@darp7:~$ rtl_433 -w file_915_2.cu -T 60 -f 915 -S unknown
rtl_433 version unknown inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/pete/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 145 out of 175 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 ]
Detached kernel driver
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
[R82XX] PLL not locked!
Tuned to 915.000000.
Allocating 15 zero-copy buffers
^CSignal caught, exiting!
Reattached kernel driver
The spectrogram app reads the Y-axis from the filename, don't change the meta data parts.
And… -f 915
should be -f 915M
, right? ;)
OK, I can't seem to upload a zip file right now, but am getting useful data now. My mistake, yes, I forgot the M so it clearly was not correct. With the right filename, and running rtl_433 -A, I can see results. You can see it on my google drive too, see below. I see events, with some spaced every ~16 seconds, but not consistently. And of those events, not all can be decoded.
Is it possible the device is just defective?
https://drive.google.com/file/d/13TMPlEfvULbwP4EcHRblh0b3iMzRYPa1/view?usp=sharing
Sorry, this seems to be the only way to share.
Drop the file (use an extension of .cu8) on https://triq.org/pdv/ and you see it's empty, noise only. Best to try a GUI like Gqrx, SigDigger, CubicSDR, or SDRangel to locate the signal, then record.
Thanks, I'm going to try to figure one of those guis out today. However, while the web seems to show it's empty, running it through rtl_433 -A shows lots of stuff, which I thought meant there is something to decode in there. But yeah, the picture just looks like noise. Anyway, I'm waiting on a second usb device now as I'm using the existing one for the 433 Mhz band to track rainfall (it's supposed to rain this week). That new device arrives today, and I'll see which gui I can figure out.
Thank you
Detected FSK package @55.340027s
Analyzing pulses...
Total count: 57, width: 14.42 ms ( 3604 S)
Pulse width distribution:
[ 0] count: 1, width: 4108 us [4108;4108] (1027 S)
[ 1] count: 9, width: 112 us [108;132] ( 28 S)
[ 2] count: 18, width: 76 us [68;84] ( 19 S)
[ 3] count: 21, width: 40 us [40;48] ( 10 S)
[ 4] count: 4, width: 216 us [200;240] ( 54 S)
[ 5] count: 4, width: 156 us [148;160] ( 39 S)
Gap width distribution:
[ 0] count: 14, width: 124 us [116;152] ( 31 S)
[ 1] count: 18, width: 44 us [40;48] ( 11 S)
[ 2] count: 17, width: 76 us [72;88] ( 19 S)
[ 3] count: 1, width: 404 us [404;404] ( 101 S)
[ 4] count: 5, width: 180 us [164;204] ( 45 S)
[ 5] count: 1, width: 316 us [316;316] ( 79 S)
Pulse period distribution:
[ 0] count: 1, width: 4244 us [4244;4244] (1061 S)
[ 1] count: 11, width: 272 us [236;320] ( 68 S)
[ 2] count: 16, width: 120 us [116;124] ( 30 S)
[ 3] count: 20, width: 176 us [152;212] ( 44 S)
[ 4] count: 5, width: 84 us [80;88] ( 21 S)
[ 5] count: 2, width: 376 us [360;396] ( 94 S)
[ 6] count: 1, width: 484 us [484;484] ( 121 S)
Pulse timing distribution:
[ 0] count: 1, width: 4108 us [4108;4108] (1027 S)
[ 1] count: 22, width: 116 us [108;136] ( 29 S)
[ 2] count: 35, width: 76 us [68;88] ( 19 S)
[ 3] count: 40, width: 40 us [40;48] ( 10 S)
[ 4] count: 6, width: 212 us [196;240] ( 53 S)
[ 5] count: 8, width: 156 us [148;172] ( 39 S)
[ 6] count: 1, width: 404 us [404;404] ( 101 S)
[ 7] count: 1, width: 316 us [316;316] ( 79 S)
Level estimates [high, low]: 1418, 28
RSSI: -10.6 dB SNR: 17.0 dB Noise: -27.7 dB
Frequency offsets [F1, F2]: 12548, 1613 (+47.9 kHz, +6.2 kHz)
Guessing modulation: No clue...
view at https://triq.org/pdv/#AAB0240801100C0074004C002800D4009C0194013C8195A393B292B3A3B2B2B2B2C1D1D3A2C2A655+AAB0150801100C0074004C002800D4009C0194013C9392A555+AAB01A0801100C0074004C002800D4009C0194013CD393B2B1C3A2A19555+AAB0140801100C0074004C002800D4009C0194013CB2A455+AAB0160801100C0074004C002800D4009C0194013CC1B3B3D555+AAB0130801100C0074004C002800D4009C0194013CA755+AAB0210801100C0074004C002800D4009C0194013CA1A2B1B1B2B1A3B1B3A3B2A3A392B455+AAB0180801100C0074004C002800D4009C0194013CA1A2B3A391B355
Sorry, you are right, there is data. I didn't zoom in enough ;) And it even work well, I guess?
$ rtl_433 -A /Users/zany/Desktop/file_915.00M_1000k.cu8
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @5.507236s
model : EcoWitt-WS68 id : 1404
Battery Raw: 83 Battery : 1 lux : 2907
Wind Speed: 14
Wind Gust : 20
Wind dir : 209
Extra Data: 14 212 Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @22.006456s
model : EcoWitt-WS68 id : 1404
Battery Raw: 83 Battery : 1 lux : 6867
Wind Speed: 32
Wind Gust : 56
Wind dir : 238
Extra Data: 32 212 Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @38.478748s
model : EcoWitt-WS68 id : 1404
Battery Raw: 83 Battery : 1 lux : 3267
Wind Speed: 33
Wind Gust : 56
Wind dir : 226
Extra Data: 14 212 Integrity : CRC
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time : @54.979542s
model : EcoWitt-WS68 id : 1404
Battery Raw: 83 Battery : 1 lux : 9284
Wind Speed: 29
Wind Gust : 41
Wind dir : 61
Extra Data: 3c 212 Integrity : CRC
That's the problem, when I run it to be read, I only see two of those events returned with JSON content. Is the decoder just broken, or is it something else? If that file has content ever 16 seconds, then it's working to some degree, but not reporting data that can be consumed it seems.
Also, how did you get that output? When I run -A, I see a lot more raw data, and not what you have there. Is there a filter or config I'm missing?
I had a look and we didn't change the decoder in some time. But we made general improvements to the receiving and demodulation. I guess the signal is just on the border to profit from those enhancements.
If you got the time then compile a fresh rtl_433 from source: https://triq.org/rtl_433/BUILDING.html#linux-mac-os-x It will be likely a month or three until a new version is ready and arrives in the Debian repos.
Ok, finally got the new radio and am testing against the latest master, which seems to be working reliably. I guess the dpkg version was just a hair too old. Thank you very much for the help. It's working for me now, and I'm going to see if I can't figure out the UV numbers now that I have them.
I lied, it's not doing much now. I'm going to try to move the antenna around a bit, and then try to replace it by return/exchange. Honestly, I'm picking up several different 915M devices from the neighborhood consistently. I am able to see a meat thermometer which I get 100% of the time, which I believe is my neighbor. Probably farther away, a small weather device which gives me temp/pressure/humidity, but I only see this every minute or two. This leads me to believe the device is not behaving correctly rather than my radio setup being incorrect. I'm actually seeing about 10 other devices, but they seem to be too far away as I can only see bits and pieces when I run with -vv, though I maybe reading that wrong.
Is there a way to get RSSI or some other signal quality indicator for decoded data? I have to believe now that given the intermittent nature, that it's trying to send, but the signal out is too under powered to go anywhere. So, maybe a broken antenna or amplifier on device?
Yes, there is RSSI with -M level
.
The recommended options would be: -Y autolevel -Y minmax -Y magest -M level -M noise -M time:usec -C si
I suggest you put the Ecowitt under a metal baking sheet or put it 300 feet away and rerun the experiment.
OK, I didn't see the level so thank you. Right now, based on the latest observations, this is a combination of a noise and antenna placement problem. My radio knowledge stems from SW for the most part, so while I know what a lot of this means, I'm by no means an expert. Moving the antenna around changes the noise value a lot, I get as high as -18 and have seen as low as -30 with a 2 foot delta in placement (not that simple, but I'm just moving it around my desk right now so it's also wild changes in location). Right now, with inconsistent results, rtl_433 reports
Current noise level -28.3 dB, estimated noise -27.7 dB
I don't know if that's an issue though. I don't know what too high for noise would look like in this case.
The RSSI for my device is really high though. Whether I see a result does have something to do with antenna placement and orientation. In my office, if I move it by a few inches here and there, it changes how often I get results. But they are always the really high RSSI (note about noise above). So, is there a good RP-SMA 900Mhz capable antenna? I'm going to dig around amazon and see what I can find. I tried an small unused Wifi module antenna, but that didn't seem to help. I'm not sure it's suited for 900Mhz though. I'm also going to move the RPi upstairs with a more direct line of site and play around with antenna placement this afternoon up there to see if it gets better. I also have this on USB extensions, high quality USB 3 versions to move the radios away from the RPi. Finally, I get the same results using my Ubuntu laptop AND the RPi's, so I don't think it's just the pi.
Anyway, for my device I get these results but very inconsistently in time. RSSI and Signal to Noise always seems to be that high. I just don't get one every 16 seconds.
time : 2022-04-29 08:02:23.112517
model : EcoWitt-WS68 id : 1404
Battery Raw: 83 Battery : 1 lux : 1077 Wind Speed: 6 Wind Gust : 10 Wind dir : 78
Extra Data: 00 210 Integrity : CRC
Modulation: FSK Freq1 : 915.0 MHz Freq2 : 915.0 MHz
RSSI : -0.2 dB SNR : 27.2 dB Noise : -27.4 dB
I get 100% from this device. If I had to guess, it's about 200 feet away in my neighbors yard. He has a lot of grill/smoker equipment. By moving the antenna, I can make this device be seen 100% and 0% of the time with very little delta in location.
time : 2022-04-29 08:09:43.263725
model : Acurite-01185M id : 0
channel : 0 Battery : 1 Integrity : CHECKSUM
Modulation: ASK Freq : 915.0 MHz
RSSI : -22.1 dB SNR : 7.7 dB Noise : -29.7 dB
Maybe this is as simple as a better antenna?
The 7.7 dB SNR is really tight, about 9 to 15 dB would be good. And seeing better than 20+ dB noise is a clean band to me (the RTL-SDR bottoms out around -30 practically and -42 theoretically). The only advice (esp. with a Raspi) that comes to mind: always use an USB extension cord.
Or maybe play with fixed gains. IIRC your WS68 signal looked somewhat clipped.
Also if you can grab a signal that won't decode (-S unknown
) maybe a peak with Audacity can show what's wrong.
Or if you have Sigrok Pulseview installed look at the demod from rtl_433 with rtl_433 -W thefile.sr thefile.cu8
I have tried, I don't think there is an unknown signal when I don't see results. No combination of runs with -S results in a saved file to investigate. I have been experimenting with antenna placement and isolation and currently have the unit isolated with a 5 USB extension and the antenna placed about 3 feet from the pi. This plus moving the unit upstairs did very little to help. However, when I modify your -Y options upstairs, and run the following command, I am getting consistent results.
rtl_433 -f 915M -Y minmax -Y magest -M level -M noise -M time:usec -C si
Every 16.5 seconds without fail. Running
rtl_433 -f 915M -Y autolevel -Y minmax -Y magest -M level -M noise -M time:usec -C si
I'm going to let this run for a bit and see what happens. Using autolevel seems to be netting me units from very far away with much worse signal numbers, but I never get my units values. Not using autolevel seems to fix this. I'll have to dig into using specific fixed gain values like you suggest above as a way to tune this to work more reliably. Need to figure out how to do that next I suppose. While I still miss events, I'm only missing about 10%, rather than the 100% or 90% in previous attempts.
The numbers look really good anyway. What are the Freq1 and Freq2 values though? They tend to move over time, from 914.9 to 915.1 in increments of .1. That seems weird, but I suspect there is a perfectly logical reason.
time : 2022-04-29 12:08:30.672563
model : EcoWitt-WS68 id : 1404
Battery Raw: 83 Battery : 1 lux : 5663 Wind Speed: 10 Wind Gust : 15 Wind dir : 83
Extra Data: 28 210 Integrity : CRC
Modulation: FSK Freq1 : 914.9 MHz Freq2 : 915.0 MHz
RSSI : -0.3 dB SNR : 24.4 dB Noise : -24.6 dB
This would be the first report that autolevel
is worse than with fixed levels. I was actually planning on making it the default.
Could it be that the signal is too strong and clipping?
The freq values are rough estimates for the two (FSK) frequencies. The -Y minmax
is the default for 868M and above, maybe try the 433M default of -Y classic
?
I wondered about that. The RSSI and SNR are really big numbers honestly for a small device sitting 50 feet away. But again, my familiarity with those are limited to what I remember about cellular back when I worked on base stations for Motorola, so I didn't know if that might be true. There doesn't seem to be a way to reduce signal strength on the device though.
I'll try the classic shortly. Need to finish my real job so I can play with my toys.
Thank you.
If you are up to try even more things: replace the stock osmocom rtlsdr with https://github.com/librtlsdr/librtlsdr/ It has some improvments to gain and AGC.
Interesting, what if any options should I modify in my command line when I do that?
My plan is to keep testing to see what works the best without having two Pi's scattered around the house. I'm hoping I can make this work with a single device and two USB dongles, but I'm having mixed results at the moment. Going to try a location that isn't my office with 3 computers, a WiFi router, and a variety of other electronics.
Both version of rtlsdr are compatible. Just make sure the librtlsdr one is found first. Usually /usr/local/lib (where the new one goes) is searched before /usr/lib (where the old one is).
OK, learned a lot more. The librtlsdr makes this worse, not better. I can verify I'm using it with ldd and LD_LIBRARY_PATH, so I know I'm linked to the new one (master, not development), and when I use it, I get NO results at all for my devices. I do see my neighbors devices though, so it's clearly doing a better job of hearing lower quality signals. Using a master build of rtl_433 linked against the system library versions seems to work.
I thought I had zero'd in on noise being a factor, where I would never see results if the noise level was greater than ~-29, but I got a few results with a noise at -22 just now, so I don't know if that's related. It is far more likely to get results when noise <=-30 though.
time : 2022-04-29 18:32:57
model : EcoWitt-WS68 id : 1404
Battery Raw: 83 Battery : 1 lux : 210 Wind Speed: 8 Wind Gust : 20 Wind dir : 115
Extra Data: 00 a00 Integrity : CRC
Modulation: FSK Freq1 : 914.9 MHz Freq2 : 915.0 MHz
RSSI : -0.3 dB SNR : 31.8 dB Noise : -32.1 dB
Another interesting tidbit is that I realized I don't see my other 915 Mhz device unless the same conditions are met. They are not colocated, but spread out over the backyard.
time : 2022-04-29 18:35:57
model : FineOffset-WH31L id : 59652
Battery : 1.000 State : noise Flags : 405b Strike Count: 0 Integrity : CRC
Modulation: FSK Freq1 : 914.9 MHz Freq2 : 915.0 MHz
RSSI : -0.2 dB SNR : 31.6 dB Noise : -31.8 dB
I'm testing with two different radios, but get the same results with both.
Not sure how much this helps.
It might also be a problem with hitting frequencies dead center. Perhaps try -f 915.1M
and -f 914.8M
Interesting, I'll give that a shot today.
Edit: It didn't change much. 915.1 and 914.8 was less reliable. The values 914.9 and 915.0 seem to behave about the same with 914.9 being a tad less reliable. I'm getting about 90% of my results now it seems and I've gone back to just 915M.
Although as I watch now, I missed about 3 in a row.
Also, I don't seem to be able to change the values for windspeed from metric to SI. It's reporting between 20 and 40 for the average right now, which seems high for what I'm looking at. Is it likely these are metric and for some reason -C isn't doing what I expect it to? Or do I just not know how to estimate windspeed? I've tried both si and customary for the -C conversion option.
[Unit]
Description=rtl_433 for 433 mhz senders
Wants=network-online.service
After=syslog.service network-online.service
[Service]
Type=exec
#ExecStart=/bin/bash -c '/usr/bin/rtl_433 -C si -F json -f 915M -Y minmax | mosquitto_pub -h 172.24.1.12 -t rtl-433/915 -l'
ExecStart=/usr/bin/rtl_433 -f 915M -Y minmax -C customary -c /etc/rtl_433/service.conf
Restart=always
RestartSec=30s
SyslogIdentifier=rtl_433
StandardOutput=syslog
StandardError=syslog
[Install]
WantedBy=default.target
OK, just a last comment, I seem to have this wrangled now. I can get consistent results, though I still don't know exactly why. I'm using latest master from rtl-433 and -Y minmax in a room about 75 feet from the unit. Noise is not high, but not super low, RSSI is good, but not great, and yet this is the best location for results. It's a third radio though, so maybe the one I have been using had some issues? Oh well, it works now, so I'm happy.
Also, for anyone interested in this unit, I would ignore the lux values, as they are not well calibrated. I get a range of about 9k in full sun (early May here, so we're close to highest for the sun elevation) to 0 as it gets dark. It sits about 1500 in clouds. That range is just not too valuable, and if you, like me, want to use lux to figure out when it's really dark (and it shouldn't be, say a bad storm), then this unit isn't going to be terribly useful as the cloudy to dark range is way too small, and with visibility in my backyard, it reports a value of 0.
Also, I haven't been able to work out the actual values for UV sensor. Their range for display doesn't seem to match well with what's sent, and treating the output as high/low order bits or some such doesn't seem to match to other units when I use my VEML sensor from Adafruit. I'm going to ignore it, and put up a more reliable one I can control with a micro.
Thanks for all the help, hopefully something came out of this that makes the project better. I love it, I'm online with 4 unique sensors now at both 433 and 915 and think this is super cool.
Thanks for the feedback! Can you collect some raw values with the expected approximate readings? We still don't have a unit factor for wind. For UV it might be that it's a mantissa and scale (i.e. not just plain 16 bit reading).
I'll try to do that this weekend.
I think the wind speed is KM by default. Multiplying by .62 gets me close to local wind speed readings here. I thought about the UV too, but nothing I do gets to a value that makes a lot of sense. They display the 0-11 scale, and it seems the sensor results are blocky, So somehow, the device might be mapping to 0-11 from some unknown raw value. I dunno, nothing I do makes a lot of sense of the numbers, so I've chosen to ignore it for now. Given the lux value being so overly scaled to bright, I'm not sure how much I trust the UV sensor in this case.
I take it back, I went and looked at using bit shifts again for the UV data, and went looking at some of the datasheets for easy to get UV sensors, and if you do the following, the numbers actually fit the VEML6070 ranges for a medium integration time.
uint16_t c = (a << 8) | b;
Where a is the first uint16_t and b is the second. It's very bright out right now, but the sun is going down a bit, and the first uint16_t is going down as expected. The values are still relatively high (28 420), but not extreme and is close to web values from weather sites. Using the equation, I get a value of 7588 which is roughly in the range of the second column of the third table of values and is close to 4.something, but that's a bit high for the current value of 3.4 which I'm getting from the web. I would think the VEML6070 is tad expensive for a unit like this, so maybe it's a cheaper i2c solution.
Not sure this is the same sensor. I don't think this is an analog sensor, as it seems to be reporting both a high and low order value over i2c. I'm going capture data for a few days and compare to real world just to see. I'm also going to look into other i2c UV sensors and see if one has ranges similar.
EDIT Nope, I was wrong. I forgot why those numbers didn't make sense. They are hex values, not decimal. The numbers actually fit a bit better for the 4T integration time in the third table though as the result right now of 7712 gets me closer to the decimal for my location (2.0). Maybe that's it?
What do you mean with a and b? We already have int lux = (b[4] << 8) | b[5];
https://github.com/merbanan/rtl_433/blob/master/src/devices/ambientweather_wh31e.c#L324
edit: so the lux_raw value is actually okay and just the I2C LSB+MSB raw from the sensor and we'd need a table?
I'm referring to extra
sprintf(extra, "%02x %02x%01x", b[13], b[16], b[17] >> 4);
Though I am wondering as you have 3 uint8_t values, I assumed it was two. Maybe I didn't look at this the right way. What if the combination of b[16] and b[17] isn't exactly right?
Anyway, for now, the UV data is the same type of data I believe, high and low bytes from the UV sensor, but what comes out is raw hex. I think Lux is fine, if not overly weighted to brightness. If you want to use it know how dark it is, the lux sensor is pretty useless. But if you want to know the brightness difference between partly cloudy and sunny, it gives you a lot of precision.
I really want the UV values, so I do the same calculation and comparing it to the i2c data sheet I have (VEML6070), it does seem to be similar. Not perfect, and the data isn't linear. For that reason, I'm not convinced I'm right. But I can't make it fit any other scale and haven't found an i2c sensor data sheet that might match the output.
Also, I'm pretty convinced now that the windspeed is sent in KPH. It almost no wind right now, but I'm getting between 5 and 10 raw from the sensor.
Those "extra" values are the unknown fields just before and after the checksum at the end. I assumed we are talking about the "lux_raw" field (byte 4 and 5). Is there a brightness reading (lux, unknown scaling) and then a UV reading also? I would say that only the first of the "extra" bytes has a proper value as the last two are after the checksum and likely trailing garbage.
The device has a UV sensor built in. That's what I want to use. I'm going to hack up that decoder a bit. I'd like to know the raw values for b[8], b[9], b[13], b[14]. I wonder if UV is hidden in there. You clearly have CRC right, so what are B[16] and b[17]? They don't seem to be garbage, as they aren't random, but clearly structured. They don't make sense, but they do seem to be specific values.
Also, b[1] isn't in the decode. That seems to be consistent with other devices in that file. Is that expected?
I'm going to dump all the bytes not decoded to extra without modification so I can watch them over time. Hoping to start that effort in a little while and let it run today while I can compare to observed easily enough. I assume it won't be a big challenge to just modify the sprintf to print all those bytes directly without impacting anything else.
This should work to dump the raw bytes:
decoder_log_bitrow(decoder, 0, __func__, b, 18*8, "raw values");
Thanks, that's a big help.
Now I just gotta wait for a sunnier day to compare. I think b[13] and b[14] are somehow related to the UV value. I think it has to be both because b[14] gets close to 250 but it's very cloudy/rainy today, so I would expect any combined value to be low, and if both are part of the UV result, then I can see why b[13] is consistently 0 at this time. If true, then a cheap analog sensor maybe the root here, with maybe 12 bit resolution? Or it's a true i2c returning two values as high and low order bytes? Either way, I'm oscillating between 100 and 250 right now, which seems like a lot and I can't compare with anything ATM.
Ok, b[13] is the whole number part of the UV value, reported as index from 0 to 11. It's sent multiplied by 10. My guess then is, that b[14] or a subset of b[14] more likely is the 1's place, and to get to an index value of 7.2, you take b[13] and 4 bits from b[14]. I just can't figure out which bits. There isn't a bit pattern that doesn't exceed 9 in any 4 bits over a large number of readings. That index also just seems to be random data somehow.
I'm probably still looking at this wrong, lack of familiarity with small byte protocols such as this. Why send the tens place in one byte, and the rest in another when it all fits in one byte? I do think b[13] is the index value, but I have to believe the actual number includes data from elsewhere and I just don't know where.
Can you retest with current git master? A lot has changed. If not working, are you able to work on a PR?
I'd like to point out that I tried many times to attach a .zip, .gz, or .tar file to this post. I did manage to get github to format this post properly.