sigrok - User contributions [en]

Protocol decoder:Modbus

2023-10-10T09:05:11Z

BartW: Add Modbus to Protocol Decoder category

{{Infobox protocol decoder
| id = Modbus
| name = Modbus RTU
| description = Modbus RTU
| status = supported
| license = GPLv3+
| source_code_dir = modbus
| image = [[File:Pd modbus.png|250px]]
| input = uart
| output = Modbus
| probes = —
| optional_probes = —
| options = channel
}}

The '''modbus''' decoder supports the [https://en.wikipedia.org/wiki/Modbus Modbus] bus protocol. Right now it only supports Modbus RTU, but it could be extended to support Modbus ASCII.

== Protocol ==
Modbus RTU is a single client, multi-server protocol that is normally used over RS-485 for simple networks of devices. It can also be used over RS-232.

It can be used in several different setups, but normally it's used with the following settings:

;Baud rate:19200
;Parity: none or even
;Stopbits: 1 or 2

Modbus RTU is a client/server (or master/slave) protocol, where one device on the bus is a client, and the rest are servers. The client makes a request and (usually) a client responds; there is no other communication. Every server has an id between 1 and 247, these have to be set in advance.

Every message starts with the server ID (or 0 for broadcast messages), then the function code. It ends with a 2 byte CRC. Because both client→server and server→client messages have the same format, it can be impossible for a logic sniffer to determine which is which.

Modbus is an open protocol that is managed by the Modbus organization. The newest version of the specification at the time of writing is [http://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf v1.1b3]

== Decoding ==
The decoder always decodes the TX output from the UART decoder as client→server.

The ''channel'' setting determines which channel will be interpreted as server→client, RX or TX.

=== RS-485 ===
Most Modbus RTU happens over a RS-485 bus. The problem is that the decoder can't tell if a message is meant to be client→server or server→client. The solution Sigrok uses is to decode it as both, and let the user decide which of the two outputs it the correct one for that message.

So for RS-485 you usually have only one UART channel, and that should be set to TX. Server→client communication is on the TX channel, so set the option in the Modbus decoder to TX.

For the physical interface, the neatest thing to do is to use some kind of converter to convert the differential RS-485 bus to a signal line (relative to ground). In practice you can get away with other solutions.

Properly terminating the RS-485 bus can do a lot to improve signal quality.

=== RS-232 ===
In some applications the client will be connected though a RS-232/RS-485 converter. In these cases it's easier to probe the signal on the RS-232 side. So the TX line of the UART decoder should be set to the client's TX line.

In this case the server→client communication is on the RX line, so set the channel setting to RX.

You probably have to invert the signals, and you can do this with the UART decoder.

Some logic analyzers are not rated for the high voltages that RS-232 is allowed to reach. For their older models, Saleae recommended putting a 10 kΩ resistor in series with the probe.

[[Category:Protocol decoder]]

Protocol decoder:Mdio

2023-10-10T09:03:46Z

BartW: Removed image that I copied from Modbus

{{Infobox protocol decoder
| id = MDIO
| name = IEEE 802.3 MII Management Interface
| description = Two wire clocked bidirectional signal
| status = supported
| source_code_dir = mdio
| input = logic
| output = mdio
| probes = MDIO, MDC
| optional_probes = —
| options = show_debug_bits
}}

The '''mdio''' protocol decoder supports the [https://en.wikipedia.org/wiki/Management_Data_Input/Output Management Data Input and Output] protocol. This is a bidirection, single master protocol. It's also known SMI (Serial Management Interface), or as the MII Management layer.

The goal is to allow communication of settings and status between an Ethernet PHY and some device that needs Ethernet connectivity (the MAC).

It's defined in the IEE 802.3 standard. This standard is available for free from IEEE, but you do need to register to download it. It's defined (amongst other things) in chapter 22.

The protocol defines how to read and write registers. Registers 0-15 are defined by the standard, and 16-31 are left free for a specific PHY to have specific settings. These should be described in the PHY's datasheet.

== Protocol ==

The clock line (MDC) goes between 0 and the chip's logic level. The data from the MDIO signal is read on the clock rising edge. A high voltage is read as a 1, and a low voltage as a 0.

The MAC provides the clock signal. The clock should be a maximum of 2.5 MHz (although a lot of PHY's will accept faster clocks), but can be as slow as you want and doesn't need to be a stable frequency.

There should be a pullup on the MDIO signal. To start a message, the MAC takes over writing on the MDIO. If it's a read command, control of the MDIO is given to the PHY during the "turnaround".

The frame structure is defined in chapter 22.2.4.5 of the standard. A message is structured as follows:
;Preamble: there are first 32 high bits. Some PHY's allow this to be shorter under certain conditions, but this isn't supported by the logic analyzer.
;Start of frame: this is a 0,1 pattern
;Operation code: 1,0 for a "read" message, 1,0 for a "write".
;PHY address: 5 bits to select the PHY being addressed. Under certain contexts 0 is a broadcast address, check your PHY's datasheet.
;Register address: 5 bits to select the address. Usually all registers are in the PHY's datasheet, and 0-15 are also described in the standard in chapter 22.2.4.
;Turnaround: 1,0 signal to give the PHY the chance to take over the MDIO line (in the case of a read) and to make sure there are never 32 consecutive ones within a valid message
;Data: 16 data bits

== Logic analyzer requirements ==

According to the protocol the maximum clock speed is 2.5 MHz (400 ns per clock cycle), but some PHY's allow faster speeds.

According to the standard, the MDIO only needs to be stable for 10 ns around the rising clock. This means that although the clock signal is in theory only 2.5 MHz, you might need a much faster logic analyzer to actually read the signal. 100 MHz or more is recommended.

[[Category:Protocol decoder]]

Protocol decoder:Mdio

2023-10-10T09:02:30Z

BartW: Created page with "{{Infobox protocol decoder | id = MDIO | name = IEEE 802.3 MII Management Interface | description = Two wire clocked bidirectional signal | status = supported | source_code_dir = mdio | image = 250px | input = logic | output = mdio | probes = MDIO, MDC | optional_probes = — | options = show_debug_bits }} The '''mdio''' protocol decoder supports the [https://en..."

{{Infobox protocol decoder
| id = MDIO
| name = IEEE 802.3 MII Management Interface
| description = Two wire clocked bidirectional signal
| status = supported
| source_code_dir = mdio
| image = [[File:Pd modbus.png|250px]]
| input = logic
| output = mdio
| probes = MDIO, MDC
| optional_probes = —
| options = show_debug_bits
}}

The '''mdio''' protocol decoder supports the [https://en.wikipedia.org/wiki/Management_Data_Input/Output Management Data Input and Output] protocol. This is a bidirection, single master protocol. It's also known SMI (Serial Management Interface), or as the MII Management layer.

The goal is to allow communication of settings and status between an Ethernet PHY and some device that needs Ethernet connectivity (the MAC).

It's defined in the IEE 802.3 standard. This standard is available for free from IEEE, but you do need to register to download it. It's defined (amongst other things) in chapter 22.

The protocol defines how to read and write registers. Registers 0-15 are defined by the standard, and 16-31 are left free for a specific PHY to have specific settings. These should be described in the PHY's datasheet.

== Protocol ==

The clock line (MDC) goes between 0 and the chip's logic level. The data from the MDIO signal is read on the clock rising edge. A high voltage is read as a 1, and a low voltage as a 0.

The MAC provides the clock signal. The clock should be a maximum of 2.5 MHz (although a lot of PHY's will accept faster clocks), but can be as slow as you want and doesn't need to be a stable frequency.

There should be a pullup on the MDIO signal. To start a message, the MAC takes over writing on the MDIO. If it's a read command, control of the MDIO is given to the PHY during the "turnaround".

The frame structure is defined in chapter 22.2.4.5 of the standard. A message is structured as follows:
;Preamble: there are first 32 high bits. Some PHY's allow this to be shorter under certain conditions, but this isn't supported by the logic analyzer.
;Start of frame: this is a 0,1 pattern
;Operation code: 1,0 for a "read" message, 1,0 for a "write".
;PHY address: 5 bits to select the PHY being addressed. Under certain contexts 0 is a broadcast address, check your PHY's datasheet.
;Register address: 5 bits to select the address. Usually all registers are in the PHY's datasheet, and 0-15 are also described in the standard in chapter 22.2.4.
;Turnaround: 1,0 signal to give the PHY the chance to take over the MDIO line (in the case of a read) and to make sure there are never 32 consecutive ones within a valid message
;Data: 16 data bits

== Logic analyzer requirements ==

According to the protocol the maximum clock speed is 2.5 MHz (400 ns per clock cycle), but some PHY's allow faster speeds.

According to the standard, the MDIO only needs to be stable for 10 ns around the rising clock. This means that although the clock signal is in theory only 2.5 MHz, you might need a much faster logic analyzer to actually read the signal. 100 MHz or more is recommended.

[[Category:Protocol decoder]]

Developers

2015-09-15T22:13:21Z

BartW:

This page contains documentation and resources for aspiring sigrok developers.

== Source code browser ==

* [http://sigrok.org/gitweb/ gitweb]

== Tutorials and API descriptions ==

* [http://sigrok.org/api/libsigrok/unstable/index.html libsigrok API]
* [http://sigrok.org/api/libsigrokdecode/unstable/index.html libsigrokdecode API]
* [[Protocol decoder HOWTO]]
* [[Protocol decoder API]]
* [[Formats and structures]]
* [[Hardware driver API]]
* [[Portability]]

== Development guidelines ==

Please check the respective sub-project's HACKING file for coding guidelines and development tips.

* [http://sigrok.org/gitweb/?p=libsigrok.git;a=blob;f=HACKING;hb=HEAD libsigrok]
* [http://sigrok.org/gitweb/?p=libsigrokdecode.git;a=blob;f=HACKING;hb=HEAD libsigrokdecode]
* [http://sigrok.org/gitweb/?p=sigrok-cli.git;a=blob;f=HACKING;hb=HEAD sigrok-cli]

* [http://sigrok.org/gitweb/?p=pulseview.git;a=blob;f=HACKING;hb=HEAD PulseView]
* [http://sigrok.org/gitweb/?p=sigrok-firmware-fx2lafw.git;a=blob;f=HACKING;hb=HEAD sigrok-firmware-fx2lafw]

== Design pages ==

This is a list of pages we use while working through new features or designs. They are working documents, not official API or feature documentation.

* <s>[[New trigger specification]]</s>
* <s>[[High precision analog]]</s>
* <s>[[Probe Groups‎]]</s>
* [[Improved Configuration Enumeration]]
* <s>[[Input/output API revamp]]</s>
* [[File format:sigrok/v3]]
* [[Domain-specific measurements and analysis]]
* [[Feeding hardware-decoded packets into libsigrok]]
* [[Sending data sequences to devices]]

== Debugging ==

If you would like to see the output of the sr_dbg() or sr_err() functions you can use one of the following [[sigrok-cli]] options:


$ '''export SIGROK_DEBUG=1'''
or
$ '''sigrok-cli -l 5 ''<options>'' '''


The '''5''' above is the log level. The following levels are available:

* 0: no output at all
* 1: error messages
* 2: warnings (the default)
* 3: informational messages
* 4: debug
* 5: spew

== PulseView and GDB ==

[[PulseView]] can be a bit tricky to debug as running it in GDB can stall the entire X11 session when PulseView crashes. This can be worked around, however. One approach is running GDB with a script that automatically creates a backtrace and terminates GDB (and thus, PulseView):


$ '''gdb --command=auto_bt.gdb build/bin/pulseview'''


with auto_bt.gdb containing lines as these:


run -l 5
thread apply all bt
quit


Another approach is to run gdb in tmux. When X11 freezes you can switch to a different virtual console, reattach to tmux, and continue the debugging process from there. This approach also makes it easier to use breakpoints.

== Valgrind ==

The following instructions outline how you can use [http://valgrind.org/ valgrind] to help find memory-related bugs in the sigrok libraries and frontends.

'''Debug packages setup (optional):'''

In order to get more useful output from valgrind you can (optionally) install various '''-dbg''' packages (if your distro provides them).

Example for [[libsigrok]] / [[libsigrokdecode]] / [[sigrok-cli]] on Debian:


$ '''apt-get install libgcc1-dbg libpcre3-dbg libglib2.0-0-dbg libftdi1-dbg zlib1g-dbg libasound2-dbg python3-dbg valgrind-dbg'''



For Qt and/or Boost based frontends (e.g. [[PulseView]]) additional packages might be helpful in some cases:


$ '''apt-get install libboost1.50-dbg libqt4-dbg libstdc++6-4.7-dbg libaudiofile-dbg \'''
'''libsm6-dbg libice6-dbg libxt6-dbg libicu48-dbg libjpeg62-dbg'''


'''Building:'''

Here's a short overview of how to build the sigrok subprojects for use with valgrind. Basically everything should be built with '''-g O0''' (enable debug output, and disable compiler optimizations). In this example, everything is installed into a custom install directory ($HOME/sr) in order to have a clean and consistent environment.


$ '''cd libsigrok; CFLAGS="-g -O0" ./configure --prefix=$HOME/sr && make install'''
$ '''cd libsigrokdecode; CFLAGS="-g -O0" ./configure --prefix=$HOME/sr && make install'''
$ '''cd sigrok-cli; CFLAGS="-g -O0" PKG_CONFIG_PATH=$HOME/sr/lib/pkgconfig ./configure --prefix=$HOME/sr && make install'''

$ '''cd pulseview; CXXFLAGS="-g -O0" PKG_CONFIG_PATH=$HOME/sr/lib/pkgconfig cmake . -DCMAKE_INSTALL_PREFIX:string=$HOME/sr && make install'''


'''Usage:'''

You can now run valgrind with your preferred options against the tools/libs in $HOME/sr. Note that '''G_SLICE=always-malloc G_DEBUG=gc-friendly''' should be used to get valgrind-friendly glib behaviour.

Different command-line options, attached hardware and so on, will test different code paths in the libs/tools (e.g. [[sigrok-cli]]), of course.


$ '''LD_LIBRARY_PATH=$HOME/sr/lib G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full \'''
'''--num-callers=40 --track-origins=yes --leak-resolution=high --track-fds=yes --fullpath-after=. \'''
'''--read-var-info=yes ~/sr/bin/sigrok-cli --help'''


== Release process ==

See [[Developers/Release process|Release process]].

== Miscellaneous ==

* [[Current events]]
* [[Public relations]]
* [[News]] (obsoleted by [http://www.sigrok.org/blog the blog])
* [[sigrok-gtk]] (GTK+ based LA GUI, currently not actively maintained)
* [[sigrok-qt]] (Qt based LA GUI, currently not actively maintained)

[[Category:APIs]]

Protocol decoder:Modbus

2015-07-28T19:14:30Z

BartW: Looking back at the capture I was talking about, the trick I mentioned here didn't actually work, so I shouldn't mention it.

{{Infobox protocol decoder
| id = Modbus
| name = Modbus RTU
| description = Modbus RTU
| status = supported
| license = GPLv3+
| source_code_dir = modbus
| image = [[File:Pd modbus.png|250px]]
| input = uart
| output = Modbus
| probes = —
| optional_probes = —
| options = channel
}}

The '''modbus''' decoder supports the [https://en.wikipedia.org/wiki/Modbus Modbus] bus protocol. Right now it only supports Modbus RTU, but it could be extended to support Modbus Ascii.

== Protocol ==
Modbus RTU is a single client, multi-server protocol that is normally used over RS485 for simple networks of devices. It can also be used over RS232.

It can be used in several different setups, but normally it's used with the following settings:

;Baud rate:19200
;Parity: none or even
;Stopbits: 1 or 2

Modbus RTU is a Client/Server (or Master/slave) protocol, where one device on the bus is a client, and the rest are servers. The client makes a request and (usually) a client responds; there is no other communication. Every server has an id between 1 and 247, these have to be set in advance.

Every message starts with the server ID (or 0 for broadcast messages), then the function code. It ends with a 2 byte CRC. Because both client→server and server→client messages have the same format, it can be impossible for a logic sniffer to determine which is which.

Modbus is an open protocol that is managed by the modbus organization. The newest version of the specification at the time of writing is [http://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf V1.1b3]

== Decoding ==
The decoder always decodes the TX output from the UART decoder as client→server.

The ''channel'' setting determines which channel will be interpreted as server→client, RX or TX.
=== RS485 ===
Most Modbus RTU happens over a RS485 bus. The problem is that the decoder can't tell if a message is meant to be client→server or server→client. The solution Sigrok uses is to decode it as both, and let the user decide which of the two outputs it the correct one for that message.

So for RS485 you usually have only one UART channel, and that should be set to TX. Server→client communication is on the TX channel, so set the option in the modbus decoder to TX.

For the physical interface, the neatest thing to do is to use some kind of converter to convert the differential RS485 bus to a signal line (relative to ground). In practice you can get away with other solutions.

Properly terminating the RS485 bus can do a lot to improve signal quality.

=== RS232 ===
In some applications the client will be connected though a RS232/RS485 converter. In these cases it's easier to probe the signal on the RS232 side. So the TX line of the UART decoder should be set to the clients TX line.

In this case the server→client communication is on the RX line, so set the channel setting to RX.

You probably have to invert the signals, you can do this with the UART decoder.

Some logic analyzers are not rated for the high voltages that RS232 is allowed to reach. For their older models, Saleae recommended putting a 10kΩ resistor in series with the probe.

Protocol decoder:Modbus

2015-07-28T18:35:33Z

BartW: Added information on how to use the decoder

{{Infobox protocol decoder
| id = Modbus
| name = Modbus RTU
| description = Modbus RTU
| status = supported
| license = GPLv3+
| source_code_dir = modbus
| image = [[File:Pd modbus.png|250px]]
| input = uart
| output = Modbus
| probes = —
| optional_probes = —
| options = channel
}}

The '''modbus''' decoder supports the [https://en.wikipedia.org/wiki/Modbus Modbus] bus protocol. Right now it only supports Modbus RTU, but it could be extended to support Modbus Ascii.

== Protocol ==
Modbus RTU is a single client, multi-server protocol that is normally used over RS485 for simple networks of devices. It can also be used over RS232.

It can be used in several different setups, but normally it's used with the following settings:

;Baud rate:19200
;Parity: none or even
;Stopbits: 1 or 2

Modbus RTU is a Client/Server (or Master/slave) protocol, where one device on the bus is a client, and the rest are servers. The client makes a request and (usually) a client responds; there is no other communication. Every server has an id between 1 and 247, these have to be set in advance.

Every message starts with the server ID (or 0 for broadcast messages), then the function code. It ends with a 2 byte CRC. Because both client→server and server→client messages have the same format, it can be impossible for a logic sniffer to determine which is which.

Modbus is an open protocol that is managed by the modbus organization. The newest version of the specification at the time of writing is [http://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf V1.1b3]

== Decoding ==
The decoder always decodes the TX output from the UART decoder as client→server.

The ''channel'' setting determines which channel will be interpreted as server→client, RX or TX.
=== RS485 ===
Most Modbus RTU happens over a RS485 bus. The problem is that the decoder can't tell if a message is meant to be client→server or server→client. The solution Sigrok uses is to decode it as both, and let the user decide which of the two outputs it the correct one for that message.

So for RS485 you usually have only one UART channel, and that should be set to TX. Server→client communication is on the TX channel, so set the option in the modbus decoder to TX.

For the physical interface, the neatest thing to do is to use some kind of converter to convert the differential RS485 bus to a signal line (relative to ground). In practice you can get away with other solutions.

For the RS485 dump in the sigrok dumps library, the ground was left disconnected. Channel 0 was put on one of the lines, with a 10kΩ resistor in series to protect the logic analyzer (A Logic16 clone).

Properly terminating the RS485 bus can do a lot to improve signal quality.

=== RS232 ===
In some applications the client will be connected though a RS232/RS485 converter. In these cases it's easier to probe the signal on the RS232 side. So the TX line of the UART decoder should be set to the clients TX line.

In this case the server→client communication is on the RX line, so set the channel setting to RX.

You probably have to invert the signals, you can do this with the UART decoder.

Some logic analyzers are not rated for the high voltages that RS232 is allowed to reach. For their older models, Saleae recommended putting a 10kΩ resistor in series with the probe.

File:Pd modbus.png

2015-07-28T16:58:15Z

BartW: Modbus message being decoded in pulseview

== Summary ==
Modbus message being decoded in pulseview
== Licensing ==
{{PD}}

Protocol decoder:Modbus

2015-07-28T16:53:05Z

BartW: Created page with "{{Infobox protocol decoder | id = Modbus | name = Modbus RTU | description = Modbus RTU | status = supported | license = GPLv3+ |..."

User:BartW

2015-07-13T20:44:41Z

BartW: Created page with "== Decode the test file == An example Modbus RTU capture can be found in the sigrok-dumps repository under [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree;f=uart/modbus_r..."

== Decode the test file ==
An example Modbus RTU capture can be found in the sigrok-dumps repository under [http://sigrok.org/gitweb/?p=sigrok-dumps.git;a=tree;f=uart/modbus_rtu;h=1525f12f8cc7e06c9d2ffb5b9c4f505a216acdb4;hb=HEAD uart/modbus_rtu].

To decode this dump, you first need to add a uart decoder with the following settings:
;RX:0
;TX:1
;Baud rate:19200
;Invert RX: Yes
;Invert TX: Yes

To that add a Stack decoder: Modbus.