CRC errors and no DEBUG with power meter and RTU example code

[brainstorm]

Hello, I'm new here, coming from #136 (comment) (see minimodbus code and output in unfoldable details there)...

I'm now struggling with some CRC errors and after reading through this forum I think I need to:

1. Adjust the bus biasing properly, following the great discussions... adapted to my MAX481 instead of the MAX485.
2. Enable -DLOG_LEVEL=LOG_LEVEL_VERBOSE in the platform.ini common build_flags to overcome the CRC errors I'm having:

[E] 1635| main.cpp             [  59] handleError: Error response: E2 - CRC check error
[E] 2636| main.cpp             [  59] handleError: Error response: E2 - CRC check error
[E] 3637| main.cpp             [  59] handleError: Error response: E2 - CRC check error
(...)

I can't seem to have an HexDump of the packets on the bus as shown in other discussions, what am I doing wrong? From what I'm reading in the library code, the error handler should have hexdump macros too...

Unfortunately I'm on holidays and don't have an oscilloscope/LA at reach to see what's going on electrically :-S Here's my relatively precarious setup with a couple of resistors, one of them biasing to GND with 220Ohm:

[Miq1]

Please try again with -DLOG_LEVEL=6 in the build_flags of platformio.ini. It may be that the #define LOG_LEVEL_VERBOSE 6 is not yet read at that point.
If the verbose log is successfully activated, you should see a "Raw buffer" line in it with the received bytes.

[brainstorm]

Thanks, progress, see commit brainstorm/esp-modbus-power-meter@c8a16b8! Now I see proper hexdumps :D

[E] 1636| main.cpp             [  59] handleError: Error response: E2 - CRC check error
[V] 2614| ModbusMessage.cpp    [ 529] checkData: Check data #3
[D] 2614| ModbusClientRTU.cpp  [ 126] addRequestM: request for 01/04
[D] 2615| ModbusClientRTU.cpp  [ 175] addToQueue: RC=01
[D] 2615| ModbusClientRTU.cpp  [ 137] addRequestM: RC=00
[D] 2616| ModbusClientRTU.cpp  [ 193] handleConnection: Pulled request from queue
[D] Sent packet: @3FF9F7A0/6:
  | 0000: 01 04 00 01 00 08                                 |......          |
[D] 2627| ModbusClientRTU.cpp  [ 198] handleConnection: Request sent.
[D] Raw buffer received: @3FFC348C/7:
  | 0000: 7F DF FD FF EF BF DE                              |......         |
[D] Received packet: @3FF9F7A0/1:
  | 0000: E2                                                |.               |
[D] 2633| ModbusClientRTU.cpp  [ 204] handleConnection: Error response (1 bytes) received.
[V] Data: @3FF9F7A0/1:
  | 0000: E2                                                |.               |
[D] 2636| ModbusClientRTU.cpp  [ 225] handleConnection: Response generated.
[V] Response packet: @3FF9F7A0/3:
  | 0000: 01 84 E2                                          |...             |

[brainstorm]

Makes sense, I'll revisit bus biasing and report back, thanks for the super quick feedback!... oh, just read your last (edited) sentence about inverting and reversing... I'll try also flipping the A/B bus leads then?

[brainstorm]

For the record, I physically disconnected the boards (ESP32S2 and RS485 transceiver) from the power meter and the same message keeps on going:

[E] 1505731| main.cpp             [  59] handleError: Error response: E2 - CRC check error
[V] 1506722| ModbusMessage.cpp    [ 529] checkData: Check data #3
[D] 1506722| ModbusClientRTU.cpp  [ 126] addRequestM: request for 01/04
[D] 1506723| ModbusClientRTU.cpp  [ 175] addToQueue: RC=01
[D] 1506723| ModbusClientRTU.cpp  [ 137] addRequestM: RC=00
[D] 1506724| ModbusClientRTU.cpp  [ 193] handleConnection: Pulled request from queue
[D] Sent packet: @3FF9F7A0/6:
  | 0000: 01 04 00 1D 00 08                                 |......          |
[D] 1506735| ModbusClientRTU.cpp  [ 198] handleConnection: Request sent.
[D] Raw buffer received: @3FFC3690/7:
  | 0000: 7F DF C5 FF EF 3D 6B                              |....=k         |
[D] Received packet: @3FF9F7A0/1:
  | 0000: E2                                                |.               |
[D] 1506741| ModbusClientRTU.cpp  [ 204] handleConnection: Error response (1 bytes) received.
[V] Data: @3FF9F7A0/1:
  | 0000: E2                                                |.               |
[D] 1506744| ModbusClientRTU.cpp  [ 225] handleConnection: Response generated.
[V] Response packet: @3FF9F7A0/3:
  | 0000: 01 84 E2                                          |...             |

[Miq1]

There's definitely noise on your lines. Did you remove the two white patch cables I saw on the picture? These very well may act as antenna!

[brainstorm]

I just removed those two white cables you mentioned and the situation improved, when disconnecting it from the device, it goes E0 - Timeout and when connecting E2 - CRC Error, which makes much more sense than before :)

Perhaps I should just invert and reverse the bits in code now as you hinted? Let's not forget that this device is a dead-brand chinese 60eur thing after all, so I'm not super confident about its adherence to ModBus proper ;)

[Miq1]

The bits do not match exactly, so I rather would look after the signal quality first. Another thing could be parity etc. - do you know and match the settings of the meter? 8E1 is the commonest, but may be the meter is different?
On the other hand there seems to be at least a reaction (if the data was not completely fake signals), so the meter then must +ave received something understandable.

[Miq1]

There is a very similar device that has a manual available that includes Communications and Modbus register specs.

[Miq1]

Then the signal path again should be your primary target. There is a RS485 GND connector mentioned in the manual. did you try to connect that to earth potential or even the ESP's GND?
Second, again consider to at least put in a 120 Ohms termination resistor between A and B on the shield's side.
BTW, what voltage is the shield running - 3V3 or 5V?
Last, do you have a scope or a logic analyzer? That may reveal what really is going on on the bus.

[brainstorm]

Puzzling side effect... if I set BAUDRATE to 115200 (instead of 9600), the RGB LED on the Saola-1 board turns green :-!

I can't explain it by the schematic: https://dl.espressif.com/dl/schematics/ESP32-S2-SAOLA-1_V1.1_schematics.pdf

So I guess it's some kind of register-setting artifact? I'll double check whether I'm using the "wrong" pins that clash somehow with the pin MUX of the Espressif IC.

[brainstorm]

Then the signal path again should be your primary target. There is a RS485 GND connector mentioned in the manual. did you try to connect that to earth potential or even the ESP's GND?

Indeed I did not connect Device GND to Saola's GND, I will focus on that next. It's a bit challenging because there's no GND exposed outside. I'll open up the box and measure the "COM 21" bit (which does not have leads outside):

[Miq1]

No, stop that. if there is no official earth connector, it would be a shot into the dark. Strictly speaking RS485 does not need a GND to work, it is advisable (if possible) to earth the device.
Again, at what voltage are you driving the shield?

[brainstorm]

Gotcha. The shield is being driven at 3.3V but can be driven up to 5.25V MAX according to MAX481's datasheet.

[brainstorm]

There's a 78L05 LDO GND, powering a RS485 transceiver, so I could use that for the ESP32S2 board's GND (and perhaps as 5V supply substituting it by a beefier LDO that can do more than 100mA to power up the ESP):

[Miq1]

I did warn you...

You might try to put a 4.7k pullup resistor between A and 5V, another as pulldown between B and GND, and an 120 Ohms between A and B. Even if these are not the ideal values they will pull the bus to a stable state.

If the signal is okay and still you are getting these 7-byte messages, please collect a couple and post them here. May be we can make out a pattern.

7 bytes is odd, an error response had 5 (server id, function code, error code and two bytes CRC). A one register response on a read request may fit, but then it would have to be identical for at least the initial three bytes.

[brainstorm]

Thanks! Added the resistors as advised:

However, I've observed a bad side effect of this arrangement: on the one hand, if I keep all three resistors as advised: 4K7 ohm A+ pullup, 4K7 ohm B- pulldown, 100Ohm termination (didn't have 120ohm handy), the ESP gets stuck in CRC error, even when the ESP is disconnected altogether from the power meter.

On the other hand, If I leave the 100Ohm termination and the 4k7 ohm B- pulldown connected and disconnect the A+ pullup, I'm getting: E0 - Timeout when disconnected from the meter and E2 - CRC error when connected to the meter (this latter setup yielding a more logical behavior?).

Perhaps the internal power meter GND is indeed required to stabilize this setup after all? It's definitely challenging to not be able to see the waveforms :/

[Miq1]

Rats. This obviously did not help at all. RS485 normally is independent of any GND potential, but just works with the voltage differences between A and B. Provided your shield is working okay the regular 120 Ohms termination should be sufficient and most probably you will find another termination resistor of the same value inside the meter. Only one end of the bus is supposed to be biased against some Vcc and GND potential to maintain a certain voltage difference between A and B.

Too bad you have no scope available - otherwise you could directly look at the A/B voltage difference to see what is happening on the bus.

If the data you are receiving is always 7 bytes, that would speak against electrical bus issues, but hint to some protocol problem. Would you mind collecting a bunch of the received responses and post those here, as I suggested?

[brainstorm]

It works now (valid ModBus responses)!!!

After examining the RS485 circuit from the power meter side, I noticed 10k ohm on the A/B bus and this electronics post was the eye opener I needed to place a 100ohm resistor on the other side, close to the device connector... until reading that post I assumed that there was an internal terminator resistor, but it turned out that 10k is placed there for other reasons (read the linked post for details).

So, lesson learned: even if the bus cables are barely 5cm long, resistors on each end are crucial to match the conductor's impedance and avoid reflections that confuse the transceivers :)

[V] 122980| ModbusMessage.cpp    [ 529] checkData: Check data #3
[D] 122980| ModbusClientRTU.cpp  [ 126] addRequestM: request for 01/03
[D] 122981| ModbusClientRTU.cpp  [ 175] addToQueue: RC=01
[D] 122981| ModbusClientRTU.cpp  [ 137] addRequestM: RC=00
[D] 122981| ModbusClientRTU.cpp  [ 193] handleConnection: Pulled request from queue
[D] Sent packet: @3FF9F7A0/6:
  | 0000: 01 03 00 1D 00 04                                 |......          |
[D] 122992| ModbusClientRTU.cpp  [ 198] handleConnection: Request sent.
[D] Raw buffer received: @3FFC3918/13:
  | 0000: 01 03 08 00 00 00 00 00  00 00 00 95 D7           |.............   |
[D] Received packet: @3FF9F2BC/11:
  | 0000: 01 03 08 00 00 00 00 00  00 00 00                 |...........     |
[D] 123018| ModbusClientRTU.cpp  [ 204] handleConnection: Data response (11 bytes) received.
[V] Data: @3FF9F2BC/11:
  | 0000: 01 03 08 00 00 00 00 00  00 00 00                 |...........     |
[D] 123020| ModbusClientRTU.cpp  [ 225] handleConnection: Response generated.
[V] Response packet: @3FF9F2BC/11:
  | 0000: 01 03 08 00 00 00 00 00  00 00 00                 |...........     |
[V] got float: @3FFC0E88/4:
  | 0000: 00 00 00 00                                       |....            |
[V] got float swapped: @3FFC0E88/4:
  | 0000: 00 00 00 00                                       |....            |
[V] got float: @3FFC0E8C/4:
  | 0000: 00 00 00 00                                       |....            |
[V] got float swapped: @3FFC0E8C/4:
  | 0000: 00 00 00 00                                       |....            |
Requested at  122.980s:
   001D:    0.000
   001F:    0.000

So next step would be enumerating the registers and mapping the values from the display correctly, case closed, thanks a ton for your help @Miq1 :)

[Miq1]

You are welcome 😉

Glad to read that you got it running. Come back to ask whenever you like.