Erroneous modbus values

OK need some assistance as to root cause


We have a weather station 2 wire 485 ...19200 8N1 to serial to fiber converter point to point using MM fiber 850nM to endpoint PC on that side we have 2 wire 485 to 232 into computer the registers are signed 16 bit input registers and it populates the data once a second with updated wind speed info, the master(our pc) polls once every 5 seconds and takes that value and displays actual wind speed in the gui , it also takes all the reading it gathers into a sql table and generates a 5 min average from the data set, however there is a feature that displays the "max gust" speed , so it will show the highest recorded value for a given minute and hold that value until a greater value is obtained or the average subsides to the new value....... so that's the setup... here is the problem..... the data is good for actual speed and 99.8 percent of the time the max speed is good too but randomly it will capture AND show our customer a 11000+ km/h value..... or similar erroneous data ... how could this happen?

Well the weather station uses transducers for windspeed, so we have ruled out birds or debris hitting the physical equipment (which can cause this) so next we look to the slave device and choose another data set for wind speed (there are multiple to choose from) but the problem follows.... so as the master our software cannot influence data we receive from a slave we only display it but don't modify.

So what I'm left with is can variation in current cause a register to skew a value? Or can the fiber cause corruption in the register(in transmission too fast)

If it doesnt/can't fall into these two then my only recourse is to RMA the hardware to vendor and I am trying to avoid...

Any input or suggestions welcomed

Thanks in advance
 
It seems that your Modbus communications is not the issue here. If you are successfully reading values (regardless of what the values are) Modbus communication is working correctly. Modbus has built-in error checking for corrupted packets, so it is impossible for noise, voltage/current spikes, wiring, etc. to cause the master to receive an erroneous register value.

I recommend completely ruling out your master by using a 3rd party Modbus master tool such as the ICC Modbus Master Tool to log the data. This will allow you to confirm if the slave is indeed sending erroneous values or if your master may somehow be causing the erroneous values.

If the problem persists, you should work with the vendor of the weather station to determine the cause of the issue and find a solution. If the vendor determines that it is a hardware issue, then you would RMA the hardware.
 
Out of curiosity, is this a hardware/Windows software package, where all the serial comm hardware is used to connect the hardware sensing end to Windows application software? Or is the Windows app a custom app that just uses any hardware as field input values?
 
Out of curiosity, is this a hardware/Windows software package, where all the serial comm hardware is used to connect the hardware sensing end to Windows application software? Or is the Windows app a custom app that just uses any hardware as field input values?
It's a data acquisition server, gathers weather data , logs to sql table, pushed to web interface, its a physical com on the server but the port is managed by the custom acquisition software
 
What is the vendor and model of the weather station you're using? Can you share documentation that includes the Modbus register list?

Could the spikes simply be the wind blowing in the opposite direction, causing a negative wind speed value, and your acquisition software is interpreting the value as an unsigned integer instead of a signed?

What units are used for the wind speed natively on the weather station? Is it km/h or is it mph and your acquisition server is doing a conversion?
 
Lufft ws501. It uses ultrasonic transducer technology for wind measurement, we read m/s (native on device) and the customer can convert to any value they like knot/kmh/mph/ms in our software
 
Update...

From the manufacturer support team




**it seems that the wind measurement of the WS501 was generating an error code for a short time (in Modbus value 32765) and this will not be sorted out in the averaging so this is the reason for the high wind speed value.

This type of error value for a short time can happen for example if the precipitation event like strong rain with big rain drops will cover min. one ultrasonic sensor and then the whole measurement will stop until the ultrasonic sensors are free again.

This means always min. one of the ultrasonic sensors will be covered with something like big raindrops or snowflakes, leaves, dust etc. the wind measurement will stop until the sensors are uncovered again.

This is a general problem of ultrasonic wind sensors and not a special Lufft problem.**


Is there any merit to this?
 
Yep, that's exactly where I was going with this. A lot of Modbus equipment set register values to a special value if the value is "unreliable".

From the manual:
The measurement values are mapped to the 16bit registers using scaling factors (0 ... max. 65530 for unsigned values, -32762 ... 32762 for signed values). Values 65535 (0xffff) resp. 32767 are used for the indication of erroneous or not available measurement values. A more detailed specification of the error can be evaluated from the status registers.

Assuming the native measurement is in 0.1m/s units, 3276.7 m/s is 11796.12 km/h, which would explain exactly what you're seeing.

You need to ignore values outside of the valid range (0 - 65530 for unsigned, -32762 - 32762) in your acquisition software when doing averaging. Optionally, it might be a good idea to flag some type of error or alarm if the value exceeds these ranges.
 
Yep, that's exactly where I was going with this. A lot of Modbus equipment set register values to a special value if the value is "unreliable".

From the manual:
The measurement values are mapped to the 16bit registers using scaling factors (0 ... max. 65530 for unsigned values, -32762 ... 32762 for signed values). Values 65535 (0xffff) resp. 32767 are used for the indication of erroneous or not available measurement values. A more detailed specification of the error can be evaluated from the status registers.

Assuming the native measurement is in 0.1m/s units, 3276.7 m/s is 11796.12 km/h, which would explain exactly what you're seeing.

You need to ignore values outside of the valid range (0 - 65530 for unsigned, -32762 - 32762) in your acquisition software when doing averaging. Optionally, it might be a good idea to flag some type of error or alarm if the value exceeds these ranges.
Ok
I now have a good understanding of the issue and a path to a resolution, however it is frustrating that a device designed for extreme conditions (met sensor) employs technology that can be jammed up my the exact thing it's trying to measure...lol just saying..... anyway folks thanks for your help

Cheers!
 
While I can't speak to the validity of the vendor's claims regarding the ultrasonic wind sensing technology (I'm a Modbus guy, not a sensor guy), I do agree with you that it seems like an extreme reaction to a single sensor reading out of range (assuming there are multiple sensors employed to measure the wind speed).

I understand from a technical standpoint why the vendor may do this, but if they knew their device would have this limitation during the design phase, they could have designed in redundant sensor(s).
 
While I can't speak to the validity of the vendor's claims regarding the ultrasonic wind sensing technology (I'm a Modbus guy, not a sensor guy), I do agree with you that it seems like an extreme reaction to a single sensor reading out of range (assuming there are multiple sensors employed to measure the wind speed).

I understand from a technical standpoint why the vendor may do this, but if they knew their device would have this limitation during the design phase, they could have designed in redundant sensor(s).
So there are 4 sensors(fyi) but I had a thought, is there a readily available software solution that I could employ that I can use to capture their mapping and remap as well as impose logic to discard oob values ?

So I wouldn't need to enter into a whole new dev phase with our software team
 
I'm not sure about the availability of software that can perform mapping, remapping, and logic on Modbus registers, but my company does have a hardware solution that can perform this task. Our Mirius serial gateway supports Modbus RTU and can map, remap, and perform logic on register values. The Mirius is available here:
http://www.iccdesigns.com/protocol-gateways/66-mirius.html

That being said, I encourage you to discuss this with your software team to add the ability to detect special Modbus register values. As I said, many Modbus devices employ this approach to signal that a value is unreliable, so it would be a useful feature for you to have in your software for this and future projects.
 
Top