Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FYI: weird stop bit behavior #49

Closed
MoritzBiester opened this issue Nov 18, 2020 · 3 comments
Closed

FYI: weird stop bit behavior #49

MoritzBiester opened this issue Nov 18, 2020 · 3 comments

Comments

@MoritzBiester
Copy link

Hi there!

First off all. Thank you for publishing your code here.
I used it to read out my SDM630 Modbus V2 in combination with an influxDB.

I ran in some issues when using the following settings:
SDM630: 2400baud, no parity, 1 stopbit

As you can see in the following picture the last stopbit of the response is out of spec. (only sometimes).
link to the unknown ;)

Fixed it by using 2 stop bits.

Have a nice day
M.Biester

@reaper7
Copy link
Owner

reaper7 commented Nov 18, 2020

@MoritzBiester - 8N1 is a default settings for this lib and from the beginning I have been using such settings without any problem.

  1. you use hw or sw implementation?
  2. your oscillogram shows signals on A B pins (converter output) but what signals looks on converter input (on tx/rx uC pins)?
  3. oscillogram shows transmission from uC to SDM or from SDM to uC?

Basically this library does not affect the transmission, because it doesn't use its own implementations.
It uses builtin serial.write

@MoritzBiester
Copy link
Author

MoritzBiester commented Nov 18, 2020

  1. I was using Softwareserial 8N1(ESP and SDM630), changed it to 8N2(ESP & SDM630)
  2. The rx pin on the ESP8266 corresponds to the differential Signal on (A-B).
  3. Shows the Modbus lines(A, B) with the request(first 8 bytes) and the response(last 9 bytes and crippled stopbit)

The software is all working fine.
Its just some weirdness from the SDM630 releasing its dere pin to early or something.
Maybe they implemented a pourly designed auto direction control on their RS485 transceiver IC.

This was just for information purpose. So if someone else runs into this issue, they dont have to spend a whole day debugging in the cold dark basement.
(silly me had it installed before he tested it)

It all works with no errors since two days.(8N2 --> 36000 measurements).

@reaper7
Copy link
Owner

reaper7 commented Nov 19, 2020

Interesting information.
I will pin this thread to the problems section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants