I have an RS485 wind speed trandmitter (SEN0483) connected to DFR0845: Active Isolated RS485 to UART Signal Adapter Module which is connected to an ESP32. I am not receiving an accurate reading from the wind speed transmitter.
I understand the maximum speed is 32.4 m/s (117 km/h) and that the raw value from the sensor needs to be multipled by 3.6 or 0.036 to convert to either m/s or km/h. I find that I need to multiply by 0.7 or 0.007 approximately to get an accurate figure (based on comparison to Bureau of Meteorology wind speed figures). This means the speed is effectively limited to about 6.3 m/s or 22.8 km/h. I am using ESPhome with their standard modbus library for communication.
Has anyone experienced anything similar with their DFrobot units? I have asked a similar question on their forum.
I would be a little careful of comparing wind/rain to any BOM data as they can be very local. Location of the anemometer can also affect its readings. There are official guides to ideal height and how far away from buildings etc. eg. sometimes you can get local wind tunnels running down the side of a building.
Its sounds like your getting some data so the comms sounds ok.
edit: Not sure where this comes from
the example on the wiki shows you would get a ā4 digit/2Byteā hex value where the left byte is the most significant.
there example is 0025 which would be 37 when converted to decimal.
That decimal value is now divided by 10 to give m/s => 3.7
3.7 m/s connected to Km/h would be (3.7 * 60 (to mins) * 60 (to hrs)) / 1000 (to Km)
so 3.7 * 3600 / 1000
or 3.7 * 3.6 => 13.32 Km/h
Thanks for the reply Michael - I think the communications are OK (that took a long time to get sorted, replacing the standard cables with twisted pair and using a termination resistor - thatās another story). The location is a bit tricky - itās about 10m above the ground, above a lane and near a tree that gets whipped around by the wind - so agree itās bound to be different to whatever the BOM is reporting locally. Iām not sure that the location fully accounts for the difference Iām seeing. Using the DFrobot multiplier I would be reporting 100km/h winds when the Bureau is reporting 20km/h. I could make the unit a metre higher which might help a bit.
Edit: Apologies my maths was out - so using 3.6 gives me 1000 km/h, which is definitely wrong.
Can you show your workings inc the hex from the sensor ?
e,g,
From Sensor : 0x005A
To Dec : 90
Divide by 10 to give m/s : 9.0
Mul. 3.6 to give K/h 9.0 * 3.6 = 32.4 Km/hr
Thanks Michael, here is an extract from the log below. Decimal is 226, which is 22.6m/s and then multiply by 3.6, which equates to 81.36km/h. My conclusion is that the sensors are badly calibrated - I have two and theyāre doing exactly the same thing.
\[19:03:48.831\]\[VV\]\[modbus:054\]: Modbus received Byte 2 (0X2)
\[19:03:48.833\]\[VV\]\[modbus:054\]: Modbus received Byte 3 (0X3)
\[19:03:48.837\]\[VV\]\[modbus:054\]: Modbus received Byte 2 (0X2)
\[19:03:48.843\]\[VV\]\[modbus:054\]: Modbus received Byte 0 (0X0)
\[19:03:48.845\]\[VV\]\[modbus:054\]: Modbus received Byte 226 (0Xe2)
\[19:03:48.850\]\[VV\]\[modbus:054\]: Modbus received Byte 124 (0X7c)
\[19:03:48.853\]\[VV\]\[modbus:054\]: Modbus received Byte 13 (0Xd)
\[19:03:48.860\]\[V\]\[modbus_controller:081\]: Modbus response queued
\[19:03:48.861\]\[V\]\[modbus:178\]: Clearing buffer of 6 bytes - parse succeeded
\[19:03:48.866\]\[V\]\[modbus_controller:088\]: Process modbus response for address 0x0 size: 2
\[19:03:48.871\]\[V\]\[modbus_controller:251\]: data for register address : 0x0 :
\[19:03:48.875\]\[D\]\[modbus_controller.sensor:025\]: Sensor new state: 226.00
\[19:03:48.879\]\[V\]\[sensor:079\]: āWind Speedā: Received new state 226.000000
\[19:03:48.883\]\[VV\]\[sensor.filter:015\]: Filter(0x3ffbf554)::input(226.000000)
\[19:03:48.889\]\[VV\]\[sensor.filter:288\]: LambdaFilter(0x3ffbf554)::new_value(226.000000) ā 81.360001
\[19:03:48.891\]\[VV\]\[sensor.filter:025\]: Filter(0x3ffbf554)::output(81.360001) ā 0x3ffbf574
\[19:03:48.908\]\[VV\]\[sensor.filter:015\]: Filter(0x3ffbf574)::input(81.360001)
\[19:03:48.908\]\[VV\]\[sensor.filter:045\]: MedianFilter(0x3ffbf574)::new_value(81.360001)
\[19:03:48.908\]\[VV\]\[sensor.filter:073\]: MedianFilter(0x3ffbf574)::new_value(81.360001) SENDING 81.360001
\[19:03:48.908\]\[VV\]\[sensor.filter:025\]: Filter(0x3ffbf574)::output(81.360001) ā 0x3ffbf7e0
\[19:03:48.908\]\[VV\]\[sensor.filter:015\]: Filter(0x3ffbf7e0)::input(81.360001)
\[19:03:48.915\]\[VV\]\[sensor.filter:201\]: SlidingWindowMovingAverageFilter(0x3ffbf7e0)::new_value(81.360001)
\[19:03:48.916\]\[VV\]\[sensor.filter:220\]: SlidingWindowMovingAverageFilter(0x3ffbf7e0)::new_value(81.360001) SENDING 81.360001
\[19:03:48.921\]\[VV\]\[sensor.filter:022\]: Filter(0x3ffbf7e0)::output(81.360001) ā SENSOR
\[19:03:48.924\]\[D\]\[sensor:131\]: āWind Speedā: Sending state 81.36000 km/h with 1 decimals of accuracy
Kinda look ok to me (apart from you knowing it actual value is wrong)
from you trace
[19:03:48.831][VV][modbus:054]: Modbus received Byte 2 (0X2)
[19:03:48.833][VV][modbus:054]: Modbus received Byte 3 (0X3)
[19:03:48.837][VV][modbus:054]: Modbus received Byte 2 (0X2)
[19:03:48.843][VV][modbus:054]: Modbus received Byte 0 (0X0)
[19:03:48.845][VV][modbus:054]: Modbus received Byte 226 (0Xe2)
[19:03:48.850][VV][modbus:054]: Modbus received Byte 124 (0X7c)
[19:03:48.853][VV][modbus:054]: Modbus received Byte 13 (0Xd)
0x02 0x03 0x02 0x00 0xE2 0x7C 0x9D
the CRC of 0x7C9D seems to match what I think they are using, which would indicate the baud and comms should be ok.
Based on the wiki, the 00E2 ā 226 (dec) ā 22.6 m/s ā 81.36 Km/hr, which is what your math got.
So accepting you know approx how fast the wind was, I can onnly assume some of the documentation is wrong (or some calibration is wrong).
What would be interesting is an estimate wind speed if you spin by hand.
i would expect that if you measure the diameter at the cups, then that should be the distance per revaluation.
So if its not too much trouble it would be interesting to see if that aligns.
I did not really like the wiki as some of the terms are wrong, e.g. the sometimes used the term ādirectionā rather then speed.
Hi Jane.
That 10 metres above sea level would be a bit hard with a land based AWS as most are I believe would be the case. Would mean digging a hole.
I think that statement would be based on a ship or sea based anemometer as the speed is stated in Knots. There is a funny system here where if the wind is over water it is knots and if over land is km/hr. Confusing what.
Cheers Bob
Oh I agree, Bob. The metres above sea level bit is less important for troubleshooting this than the average wind speed over 10 mins. Since Stuartās results are very out of sync with the weather forecast, I wanted to see if the average over 10 mins aligns better.
Thanks Jane - I have a few different sensors configured. The log I posted is almost instantaneous. I have used an error correction algorithm to smooth out the peaks and troughs, which Iāve now removed. I also have a sensor that averages wind speeds over 10 minutes and a gust speed maximum over 10 minutes. The average isnāt that different to the instantaneous figure. Itās still unrealistically high.
One thing that really puzzles me about the wiki is the reference to āParameter Range 0-324 Default Value: noneā. This seems to imply to me that each increment should be 0.1m/s to a maximum of 32.4m/s. The raw values that I am seeing from the sensor max out at about 3600, which is why if I apply the recommended 3.6 multiplier the maths gives me speeds over 1000km/h as mentioned earlier. Something is wrong with either the sensor or the documentation. Itās difficult to figure out which.
Hi Stuart
Google āWind speed measureā and you will find lots of commercial hand held units down as low as a bit over $20.Could be a useful investment in your situation even just for checking every so often. I wouldnāt think at your stage absolute accuracy is not mandatory as long as both instruments are in the same ball park.
Could save you a lot of hair pulling.
Cheers Bob
An update for everyone. I think Iāve found the problem. I was reading address 0 and not address 1 for the device. Address 0 seems to be a pulse count measure and and Address 1 appears to be the 0 to 324 parameter. Thank you for all of your help. If anyone is interested in an esphome configuration for these dfrobot wind speed and direction sensors please let me know. Hopefully thatās it on this issue.
I spoke too soon. Here is an example of the data at each of the only two registers on the wind speed sensor. Iāve verified this on the esp32 and now the raspberry pi. Very frustrating. Register 1 only reads up to about 5.4km/h so is not useful at all.
Hi Stuart.
I donāt suppose that by some chance the registers are reading speed directly in km/hr. Is register 0 direction and register 1 speed. In that case 2386 might be 238.6Āŗ and 11 might be km/hr or the other way, 2386 = 23.86km/hr and 11 = 110Āŗ. Either way would sound reasonable. Maybe the calc are done before you get it. If I looked at the product page I might find out which registers are which but havenāt got time at the moment.
Cheers Bob
Just put my specs on. Looks like register 0 is speed. If you applied your calc to that number does it make sense?? maybe reg 1 is direction?? has to be direction reported somewhere.
Maybe you need one of those cheap hand held things to sort this out.
The second register either has multiple devices with their own slave addresses (and is using 1 for 0x1000 instead of 8) or the code is measuring something else as the second register, which would indicate that it is not the SEN0823.
In fact, this looks more like the values you would get from the SEN0822:
Thanks Bob - I think 0 is speed and 1 may be direction. I have two different dfrobot sensors one for wind speed and the other for direction (both modbus). Iāll reply to Janeās very helpful response below shortly. Iām hoping I might get a response from dfrobot directly on their forum this week and if thereās no joy there Iāll try a manual calibration with a handheld device. I have found a few on google.
Hi Jane - thank you for your very detailed reply. Iām using ESPHomeās standard modbus implementation. I do have SEN0482 and SEN0483. I think you may be right. I could be reading from the wrong device and what Iām seeing is possibly the value in degrees minus the decimal point in reg0. Iāll do some more testing and see what I can do. If thatās right it should be a very simple fix.
