Hello, I’m using Saleae analyser with Epever MPPT controller. The controller communicates using Modbus on RS-485.
By ESP32 and library ModbusMaster I every second read 3 values from the controller (solar voltage, solar current, battery voltage). The connection I have like here (using RS-485 converter): Cheap MPPT Controller Live Stats on Mobile - Hackster.io
The function for reading data from the controller I’m using is:
void AddressRegistry_3100() {
result = node.readInputRegisters(0x3100, 6);
if (result == node.ku8MBSuccess) {
pvvoltage = node.getResponseBuffer(0x00) / 100.0f;
pvcurrent = node.getResponseBuffer(0x01) / 100.0f;
bvoltage = node.getResponseBuffer(0x04) / 100.0f;
}
}
The communication with ESP32 goes properly so I recorded the complete sequence by the analyser.
I have RS-485 channel A and B connected to the Saleae analyzer, all converter wires and serial line pins (RX /TX).
I write data to the serial port as follows:
00:14:45.545 → - - - - - - - -
00:14:45.545 → PV Voltage:
00:14:45.545 → 2.95
00:14:45.545 → PV Current:
00:14:45.545 → 0.00
00:14:45.545 → Battery Voltage:
00:14:45.545 → 12.17
I tried to set up some analyzers in Saleae Logic, but I don’t really understand it. Could you please advise me how to properly decode the intercepted modbus communication? (Get some valuable information from the capture)
I am attaching the recorded sequence file (3 measurement cycles).
Thank you
Session3.sal (13.2 KB)
@iotdeveloper It looks like the Modbus analyzer is out of sync with your data (you can notice this by the decoding continuing even after the data transaction has ended). Either the Modbus analyzer settings are not correct, or your data is formatted in such a way that our Modbus analyzer is not able to properly decode it.
Perhaps, as a starting point, we can try helping to properly decode your data via our Async Serial Analyzer. There is quite a lot of data to parse through in your capture file.
To help us debug this with you, can you:
- Provide a trimmed down capture file (in .sal file format) that contains only the transaction(s) you’d like us to debug?
- Can you also only show the channel containing the data you’d like us to take a look at? Preferrably, please only include 1 channel, so we know which one to debug.
- Please remove all protocol analyzers as well, except for 1 configured protocol analyzer (for example, 1 Async Serial analyzer) to help us focus on which transaction and analyzer to debug.
This will help narrow down our debugging efforts.
So, since the RS-485 bus works with two wires (A+ and B-), I left 2 channels (A and B) in the capture. The capture is trimmed to one reading from MPPT controller. I would like to take a look at RS-485 (Modbus respecivelly) captured communication and try to decoe it.
I left there only one analyzer (Async Serial analyzer on channel A) with default settings.
Here is maybe useful sheet - Modbus register Address list of the user MPPT controller: Tracer-RS485-Modbus-Blynk-V2/doc/1733_modbus_protocol.pdf at master · tekk/Tracer-RS485-Modbus-Blynk-V2 · GitHub
And here I’m attaching the file:
mppt_epever_trim.sal (6.2 KB)
Thank you
@iotdeveloper Thanks! We haven’t had a chance to take a closer look at the new files you sent, but I’ll keep you updated once we get a chance to do so.
Well, thank you, I very much appreciate the findings from the captures provided.
@iotdeveloper The pulse recorded at the beginning of channel 0 looks invalid, can you confirm if that is correct? If so, we may want to work with the inverted data on channel 1 to avoid any decoding issues.
Configuring the Async Serial Analyzer on channel 1 (and perhaps the Modbus analyzer) looks like it may produce cleaner results given that the initial 0.1ms pulse is not present at the beginning of the transaction.
I set signal inversion to “Inverted.”
On channel 1, you will notice a false 0xFF reading at the end however. I’ve zoomed into it below to show the culprit (a 1.75 us positive pulse), which our Async Serial analyzer is incorrectly recognizing as a start bit.
As such, you may want to configure a glitch filter value of around 2 us to filter out these pulses for future captures.
