Yoctopuce serial interfaces can do much more then standard USB to serial adapters. One of their features which is not well known is their ability to record a communication, including the time interval between messages. To help you take the most out of it, we have just improved the user interface of these devices.
The devices that benefit from these improvements are:
- The Yocto-RS232, that you use for the most common RS232 standard
- The Yocto-Serial, which can work with 3V or 5V levels
- The Yocto-RS485, and its follower, the Yocto-RS485-V2
- The Yocto-SPI, for SPI communication with a separate clock line
- The Yocto-I2C, for I2C and SMBus communication
On all these devices, you can simple update the firmware using VirtualHub software to benefit from the new functions, even if your purchase has been made years ago.
The communication analysis user interface
Here is what the new user interface looks like:
The new serail communication user interface
The new user interface widget will let you explore message exchanges more easily. As soon as the window opens, the last 4KB of messages found in the device memory are displayed. As long as messages are exchanged, they will be appended to the list. By typing a keyword next to the magnifier icon, you can restrict the display to messages including the selected keyword. If needed, you can temporarily pause the display update using button pause. The user interface can handle hundredths of messages. After a few thousands, the Web browser is likely to start slowing down, but you can always use the clear button to empty the display history and the device memory.
Each message is prepended by a timestamp, relative to the first message, and by the direction of the transmission - send or receive. To make it easier to read, one of the direction is highlighted as well. The message timestamps are recorded directly by the device, at the exact time when the message is detected. They are therefore quite precise, with a resolution of a millisecond.
Regardless of the selected protocol type, you can switch the display between ASCII and hex mode using the button view hex / view ASCII. Be aware however that when the capture is made using a text-based protocol (Line-based ASCII protocol, STX/ETX-based ASCII protocol or generic ASCII stream), all non-textual control codes will be automatically filtered and will therefore not appear, even in hex mode. So use a binary mode protocol if you need to check the control codes (see the section Message identification below).
If you need to study or to compare a communication involving many messages, use the button export to open the whole set of messages in a larger window:
HTML export of a communication trace
The exported view includes simultaneously hex codes, with 16 bytes per line, and the corresponding ASCII characters, formatted as text lines to facilitate reading. This view can be saved into a stand-alone HTML file if needed, using the Save button, to be reopened later using any Web browser.
When you develop support for a communication protocol using a Yoctopuce interface device, the communication user interface will be very helpful to let you check that everything went well. Indeed, as the device records in its internal memory the messages sent as well as the messages received, you can simply open this interface after running your software to verify how your software was handling the communication.
Even better, if you configure your software to talk to the Yoctopuce serial interface via the VirtualHub software, using function RegisterHub("127.0.0.1", ...), you can even monitor the communication between your software and the instrument in real time, as VirtualHub makes it possible for two software to access the same serial interface simultaneously.
Eventually, you can also use this user interface to analyze a communication protocol handled by a non-Yoctopuce serial interface, using the Snooping feature. We will discuss this in more details below.
Splitting a serial data stream into messages is very important to properly read and understand a communication. For this purpose, Yoctopuce serial interfaces have an option to choose among a few protocols the one that can best recognize the beginning and the end of messages. This makes it possible to assign a timestamp to each message in real time.
The simplest way to identify messages is to rely on the direction of the communication: obviously, when the communication direction changes, the previous message ends and a new message starts. This is the method used by protocols Generic Byte stream and Generic ASCII stream. It works quite wll for many common scenarios where a strict alternance of request/response is used.
In order to handle cases where every message is not followed by a response, or cases where the two sides may send messages simultaneously, a message delimiter controlled by the emitter itself is required.
For textual messages, the most common message delimiter is the end of line (CR and/or LF codes). You can choose the Line-based ASCII protocol if you want to use that solution. We have also recently added the ability to use text messages framed by STX and ETX codes, as used by some sensors. If you want to use that option, select STX/ETX-based ASCII protocol, and messages will only include characters sent between the STX and the ETX codes.
For binary messages, recognizing messages from the data stream may require a deeper knowledge of the underlying protocol. But as Yoctopuce serial interfaces can analyze messages in real time, they can leverage the measure of the time interval between byte frames, which often works quite well as a message delimiter. For some protocols such as MODBUS, the time interval between frames is even part of the specification. For this reason, when dealing with an unknown protocol, it is generally a good starting pointto select a Frame-based binary protocol with a frame interval of 3ms or 5ms for instance.
Snooping: analysing a serial communication from the outside
When working on the development of a communication protocol, it is often useful to study the message exchanges produced by the reference tools provided by the instrument manufacturer. Depending on the type of serial bus, it requires more or less efforts.
With RS485, snooping is trivial as the standard allows to add multiple interfaces in parallel on a RS485 bus. So by connecting an extra Yocto-RS485-V2 on the RS485 bus, you will easily get the trace of all messages sent on the bus. You will simply need to find out the proper bit rate and parity, and possibly switch D+ and D- if needed. However as both parties communicate using the same data lines, the snooping device will not be able to tell which party sent which message.
With RS232, snooping could be more complex, but we have created a RS232-Snooping-Adapter which can be inserted between two DB9 connectors to connect a Yocto-RS232 in parallel to the lines. Once configured in Snooping mode, the Yocto-RS232 will be able to show you the detail of messages sent in both directions, including the message direction.
On a TTL/CMOS 3V or 5V serial line, the same solution can be used as well, even if we don't mention it often. You can simply connect your Yocto-Serial in the same way as done in the RS232-Snooping-Adapter: connect one of the communication line to the RD input of the Yocto-Serial, and the other line to the CTS input (not on the TD line, as this is an output and should therefore stay disconnected in Snooping mode):
Connecting a Yocto-Serial for Snooping
For SPI, we have just added the snooping capability toe the Yocto-SPI. As the electric level changer of the device is fully bidirectional, once configured in Snooping mode you can simply connect the Yocto-SPI in parallel with all lines of the SPI bus, and the device will monitor all of them without interfering wirth the communication. Both SDI and SDO data lines are captured simultaneously, and then displayed separately. If the SPI bus includes a SS line, it is important to connect it as well for snooping, as this line helps a lot to synchronize the start of byte transfers. Without the SS line, a bit shift may easily happen when snooping data, in particular with SPI mode 0 and 2, which would then make the decoding of messages a very tedious task.
Eventually, for I2C, we do not yet have a Snooping function. But who knows, that might come as well one day if you happen to need it and to let us know about it...