How to make a hardware setup for monitoring BER of modbus

Click For Summary

Discussion Overview

The discussion revolves around creating a hardware setup to monitor the Bit Error Rate (BER) of a Modbus communication system, specifically between a PC (master) and a compressor (slave) using the Modbus RTU protocol over an RS485 line. Participants explore methods to quantify communication errors and propose various approaches to achieve this monitoring.

Discussion Character

  • Technical explanation
  • Experimental/applied
  • Debate/contested

Main Points Raised

  • One participant describes the need to measure BER in a Modbus communication setup and mentions coupling white noise and burst signals to the line.
  • Another participant suggests that if the transmitted and received data are known, a bit-by-bit comparison can be made to determine errors, assuming no error correction is in place.
  • There is a question about whether the Modbus RTU protocol includes a checksum or CRC, and the length of that checksum or CRC.
  • A participant confirms that the Modbus signal includes a CRC and inquires about the number of bits in the CRC.
  • Another participant proposes that if each packet has a CRC check, the packet error rate can be calculated and multiplied by the average packet length to estimate BER.
  • It is suggested that the testing should involve sending numbered packets to identify any packet loss that does not result in a CRC error being logged.

Areas of Agreement / Disagreement

Participants express various methods for measuring BER, but there is no consensus on the best approach or the specifics of implementation. Some participants agree on the importance of knowing the transmitted and received data, while others raise questions about the CRC and its implications for error measurement.

Contextual Notes

There are unresolved questions regarding the specifics of the CRC implementation and how it affects the measurement of BER. Additionally, the discussion includes assumptions about the absence of error correction and the need for precise definitions of packet structure.

Who May Find This Useful

Individuals interested in Modbus communication, error measurement in digital communication systems, and those working on hardware setups for monitoring communication performance may find this discussion relevant.

Nikhil N
Messages
80
Reaction score
2
I have to devices in communication with modbus protocol. Master is PC and slave is compressor(100ft line,RS485 standard, modbus RTU protocol). I have to build a setup which will show how much the error in communication. I am coupling some white noise to the line and some burst signals too. I could see error has happened in communication from communication log file which is getting from the Omnimbt software that I am using in master. But instead of this I need to get the BER(bit error rate) and show persons who will be monitoring the performance of modbus communication. Can anybody suggest some possible ways for doing this?
 
Engineering news on Phys.org
If you know exactly what was transmitted and what was received, and if there was no error-correction, you can compare transmitted/received bit by bit.
 
Nikhil N said:
modbus RTU protocol
Jeeze, this is turning into a long project! :smile:

Does the RTU protocol include a checksum or CRC with each packet transmitted? How long of a checksum or CRC?
 
anorlunda said:
If you know exactly what was transmitted and what was received, and if there was no error-correction, you can compare transmitted/received bit by bit.
My doubt is how to determine the error, whether by comparing the signal with noise and without noise coupled as we can see in the noise analyzer(ref:figure below) or by determine in bit level comparison(BER)?
31174-3893607.jpg
 
berkeman said:
Jeeze, this is turning into a long project! :smile:

Does the RTU protocol include a checksum or CRC with each packet transmitted? How long of a checksum or CRC?
It has CRC with modbus signal
 
Nikhil N said:
It has CRC with modbus signal
How many bit CRC? If each packet has the CRC checked, look at the packet error rate and multiply by the number of bits in the average packet length.

Your test should also send numbered packets, so that any loss of a packet without a CRC error logged is seen also.
 

Similar threads

  • · Replies 8 ·
Replies
8
Views
4K
Replies
11
Views
3K
  • · Replies 14 ·
Replies
14
Views
2K
  • · Replies 16 ·
Replies
16
Views
7K
  • · Replies 23 ·
Replies
23
Views
37K