Machines under acoustic test usually publish their own operating data — temperatures, motor load, fan speed, status bits — on an internal RS485 bus speaking Modbus RTU, or on a network port speaking Modbus TCP. Deepsona can read that data with a plain USB-RS485 adapter (or the PC network port) and store it alongside the acoustic and vibration channels, in the same file, on the same time axis.
| Screen | What it is for |
|---|---|
| Tools › Modbus Bus Monitor | A survey tool. It does not feed the acquisition chain. Use it on site to discover the port settings, the slave addresses and which registers are alive, and to record a CSV of raw samples. Nothing you do here ends up in the measurement file. |
| Channel Setup › RS485 / Modbus source | The production entry. Points configured here become channels: they show in the channel table and Online Monitor, and are written into the recorded file. |
The usual order is survey first, configure second: find the settings with the Bus Monitor, then enter them once in the source dialog.
Wire the adapter A to A and B to B — unlike RS232 the lines are not crossed. Connect the grounds as well; on a short bench cable it often works without, but an unconnected ground produces occasional corrupted frames that are easily mistaken for a software problem. Termination resistors are not needed for short runs at ordinary baud rates.
FTDI chips ship with a default latency timer of 16 ms — the maximum time the chip waits to accumulate bytes before passing them to the host. Deepsona detects this for you: once a serial source is configured, the Modbus area of Channel Setup shows a notice with a button that sets it to 1 ms. Pressing it asks for administrator confirmation once (the value lives in the system registry and cannot be written otherwise), then re-enumerates the adapter automatically — no unplugging, no Device Manager, no command line.
The button does nothing while a recording is running, because re-enumerating the adapter briefly drops the serial connection. Stop the recording first.
This choice is the one that most often decides whether you see any data at all.
| Mode | Use when | Consequence |
|---|---|---|
| Passive listening | The machine already has its own controller polling the bus. | Deepsona never transmits. It simply overhears the traffic. Completely safe on a live bus. |
| Active polling (we are the master) |
The device is a pure slave — nothing else is asking it for data. | Deepsona sends read requests itself. Only read function codes are ever used; the device is never written to. |
Modbus RTU allows one master per bus. Do not enable active polling while the machine's own controller is polling — two masters on one bus collide. If you connect passively and see nothing at all, that is the symptom of a slave-only device: switch to active polling.
Baud rate and character format must match the device. If you do not know them, press Auto Scan: it listens on each common baud rate and reports which one carries valid Modbus frames. If nothing matches at 8N1 it also tries the other character formats.
The character format matters more than it looks. The Modbus RTU specification actually calls for 8E1 (even parity), while 8N1 is the most common setting in practice. Listening to an 8E1 bus as 8N1 produces a large number of framing errors and almost no valid frames — which looks exactly like “this device does not speak standard Modbus”. If the status line reports framing errors, change the format before concluding anything about the device.
This is the one thing Deepsona cannot work out for you. Register addresses, scaling and data types are defined by the equipment manufacturer and follow no standard. Ask the vendor for the register map — their firmware engineers always have one.
The table is a CSV file, one row per point:
slave,address,name,type,scale,offset,unit[,function][,min,max] 1,0x0010,Hotend temperature,u16,0.1,0,degC,4,0,300 1,0x0100,Total runtime,u32,1,0,s,3 1,0x0000,Fan running,bit,1,0,,1 1,0x0040,Fault flag,bit3,1,0,,3
| Column | Meaning |
|---|---|
slave | Slave address, 1–247. |
address | Register or bit address, decimal or 0x hex.
Check whether the vendor's document uses the “40001-based” offset convention —
copying those numbers directly shifts every address. |
name | Point name. Must be unique. Recorded values are grouped by name, so two rows with the same name are silently merged into one channel. |
type | u16 s16 u32 s32 f32.
For 32-bit values append the byte order when it is not big-endian: _cdab (word
swap), _badc (bytes swapped inside each word), _dcba (fully reversed).bit = a coil or discrete input; the address is a bit address.bit0…bit15 = one bit inside a register (a status word); the
address is a register address and bit0 is the least significant bit. |
scale offset | Engineering value = raw × scale + offset. A register holding 2105 for 210.5 °C needs scale 0.1. |
unit | Engineering unit. May be empty for dimensionless values. |
function | Optional. 1 = coil, 2 = discrete input, 3 = holding register, 4 = input register. |
min max | Optional plausible range, in engineering units. See below. |
When a table is loaded, Deepsona checks it and reports problems that would otherwise corrupt data silently — duplicate names, a 32-bit point overlapping its neighbour, a scale of zero.
On a busy bus it is possible, though rare, for two adjacent frames to combine into a byte sequence whose checksum happens to pass. Choosing the wrong byte order produces values that are wrong by orders of magnitude. Either way the result is a single implausible value that becomes a visible step in the recorded curve, and afterwards it is very hard to tell whether that step was real.
Filling in min and max discards such samples: the curve holds its previous value instead. Discarded samples are counted and shown in the status line, so a range accidentally set too narrow does not silently produce an empty channel.
Leave the range empty for any value that legitimately goes out of range when the machine faults — for example a sensor that reports 32767 when it breaks. The guard cannot tell a fault reading from a corrupted frame, and would hide the fault.
The status line under the source button, and the acquisition log, name the reason. The three causes point in completely different directions:
| What the status says | What it means |
|---|---|
| Timeouts only, no replies at all | Nothing is answering. Check the slave address, the baud rate and character format, and the A/B wiring — swapped A and B is the classic case. |
| Modbus exceptions only | The device is talking, but rejects the addresses. The point table does not match this device. The message names the offending point and the exception code. |
| Samples discarded by range limits | Values are arriving and decoding fine, but fall outside the min/max in the point table. |
| Framing errors climbing | The character format is wrong — try 8E1. |
Values carry a PC timestamp and are expanded to the acoustic sample rate by holding the last valid value, so each point becomes an ordinary channel in the measurement file that can be dragged into Data Viewer and overlaid on acoustic curves.
The time resolution of these channels equals the bus refresh rate — typically below 1 Hz for temperatures and around 10 Hz for load values. They are suitable as an operating- condition axis for order analysis and for correlating trends with noise. They are not signals: they cannot be used for torsional vibration, order tracking or anything else that needs bandwidth.
A frequent request is to read motor torque. Whether that is possible depends entirely on the drive:
A true torque figure in N·m otherwise requires a torque transducer.
If the measurement must be hardware-synchronised rather than PC-timestamped, the bus data can be
brought in through the frontend CAN port using an RS485→CAN gateway. The Bus Monitor's
Export DBC… button turns a point table into a .dbc database plus a gateway
mapping sheet, so the gateway can be configured to put each register at a known CAN identifier and
byte offset. See also RPM, CAN / DBC & GPS Channels.
Standard Modbus RTU and Modbus TCP, read side: function codes 0x01 (coils), 0x02 (discrete inputs), 0x03 (holding registers) and 0x04 (input registers). Passive listening additionally decodes write frames (0x06 / 0x10) that it overhears.
Proprietary serial protocols are outside the supported scope. If Auto Scan reports traffic but no valid Modbus frames at any setting, the device is not speaking standard Modbus; ask the manufacturer to expose a standard Modbus interface, or convert the protocol externally.