UART reading data issue

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

UART reading data issue

Post by garudaone » Sun Jul 24, 2022 5:15 am

Hi,
I use UART 1(GPS Uart) to communicate with RS485 Modbus. It works fine on REPL(Run the code line by line)

But in main.py, It cannot read data properly(some bytes are missing and some are corrupt except the first 2 bytes) even though I put sleep before reading or use while-loop. uart.any() returns 1. Buffer should not be an issue because the data to read is actually only 9 bytes. Try uasyncio also not help.

In my testing, if I use time.sleep or while loop after writing, the received data will have problem, that's why when I run write and then read in REPL, the received data is fine

I change the baudrate to 2400, the result is correct when the sensor value is less than 80%(humidity) but after that the data is corrupt again. I guess the transmission interval of the sensor change when the sensor value is high that's why it's corrupt again.

here's my init code:

Code: Select all

uart=UART(1,4800) uart.init(4800, bits=8, parity=None, stop=1)
uart.write(b'\x01\x03\x02')
time.sleep_ms(sleep)
while uart.any()==0:
 time.sleep_ms(10)
res=uart.read()
Thanks

p_j
Posts: 102
Joined: Mon Aug 23, 2021 1:08 pm
Location: Sydney

Re: UART reading data issue

Post by p_j » Mon Jul 25, 2022 9:46 am

Check your ground connection as this can sometimes cause issues.

Looking at your code, is it possible you are reading data from the buffer before the full 9 bytes are available?

Have you tried reading exactly 9 bytes with:

Code: Select all

res = uart.read(9)
or if the data from your sensor has a carriage return you can use uart.readline()

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: UART reading data issue

Post by garudaone » Mon Jul 25, 2022 11:59 am

p_j wrote:
Mon Jul 25, 2022 9:46 am
Check your ground connection as this can sometimes cause issues.

Looking at your code, is it possible you are reading data from the buffer before the full 9 bytes are available?

Have you tried reading exactly 9 bytes with:

Code: Select all

res = uart.read(9)
or if the data from your sensor has a carriage return you can use uart.readline()
Thanks for your suggestion. I try to read exact bytes(8 bytes) but no use.
Even though I put 2000ms sleep is useless.
The result I got is:
I always got the correct first 2 bytes. After those two, it missed a few other bytes but it's usable unless the value of sensors reach 80% then it become corrupt.

Code: Select all

The sample result: \x01\x04\x02\xaf\x03\x02(CRC bytes missing)
Expected result is: \x01\x03\x04\0x2\xaf\x03\x02(CRC bytes)
Explanation: First byte(x01) is address byte, second byte(x03) is function code, third byte(04) is the result length(4 bytes result).
So the result I got is: 1. missing the function code. and result is corrupt if the reading is high, 3-CRC is missing

p_j
Posts: 102
Joined: Mon Aug 23, 2021 1:08 pm
Location: Sydney

Re: UART reading data issue

Post by p_j » Mon Jul 25, 2022 12:43 pm

Are you sure you have the correct serial settings, baud rate, parity, stop bits etc...

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: UART reading data issue

Post by garudaone » Mon Jul 25, 2022 2:42 pm

p_j wrote:
Mon Jul 25, 2022 9:46 am
Check your ground connection as this can sometimes cause issues.

Looking at your code, is it possible you are reading data from the buffer before the full 9 bytes are available?

Have you tried reading exactly 9 bytes with:

Code: Select all

res = uart.read(9)
or if the data from your sensor has a carriage return you can use uart.readline()
Yes, I have tried reading exact 8 bytes, 9 bytes, 7 bytes.

Regarding ground connection, I also connect ground but same result. It's not the problem because I did received data but partially corrupted data.

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: UART reading data issue

Post by dhylands » Mon Jul 25, 2022 7:08 pm

It looks like there is one missing character: 0x03 which happens to correspond to Control-C (this may or may not be relevant).

Which board are you using?

Normally, I've only seen this issue when using the REPL as a UART. You might want to try disabling Control-C by calling

Code: Select all

  micropython.kbd_intr(-1)
Be aware though, that this will disable Control-C for interrupting your program, but it's probably a worthwhile test to see if that's affecting things somehow.

I know rshell needs to do this, but it's sending binary data streams over the same port used as the REPL.

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: UART reading data issue

Post by garudaone » Tue Jul 26, 2022 3:04 am

dhylands wrote:
Mon Jul 25, 2022 7:08 pm
It looks like there is one missing character: 0x03 which happens to correspond to Control-C (this may or may not be relevant).

Which board are you using?

Normally, I've only seen this issue when using the REPL as a UART. You might want to try disabling Control-C by calling

Code: Select all

  micropython.kbd_intr(-1)
Be aware though, that this will disable Control-C for interrupting your program, but it's probably a worthwhile test to see if that's affecting things somehow.

I know rshell needs to do this, but it's sending binary data streams over the same port used as the REPL.
I use A9 GPRS(AI Thinker). It has two UARTs. I don't use REPL UART. I am using second UART (for GPS) for this modbus communication. I use MAX485 chip for the conversion

Yes, when run the reading from REPL line by line, I received that 0x03 byte. i.e everything is ok when I run from REPL line by line.

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: UART reading data issue

Post by garudaone » Mon Aug 01, 2022 3:50 am

dhylands wrote:
Mon Jul 25, 2022 7:08 pm
It looks like there is one missing character: 0x03 which happens to correspond to Control-C (this may or may not be relevant).

Which board are you using?

Normally, I've only seen this issue when using the REPL as a UART. You might want to try disabling Control-C by calling

Code: Select all

  micropython.kbd_intr(-1)
Be aware though, that this will disable Control-C for interrupting your program, but it's probably a worthwhile test to see if that's affecting things somehow.

I know rshell needs to do this, but it's sending binary data streams over the same port used as the REPL.
After my further investigation, another byte is missing when the sensor value increase to 80%+(Humidity sensor). When I increase the baudrate, the number of missing bytes are more. However, I can't decrease it further as the sensor only minimum baudrate is 2400.

When I run code from REPL, I receive 9 bytes. anyhow, the missing one byte is ok. but if it missed two bytes. I can't figure out the real value of the sensor.

Here's the sample:
From REPL(The correct one, 9 bytes):
b'd\x03\x04\x02\xd9\x01/_:'
Normal one(8 bytes):
b'd\x04\x02\xd9\x012\x9f3'
When the humidity is above 80%(only 7 bytes):
b'd\x046\x013n\xfa'

garudaone
Posts: 23
Joined: Fri Jul 08, 2022 9:10 am

Re: UART reading data issue

Post by garudaone » Mon Aug 01, 2022 4:14 am

dhylands wrote:
Mon Jul 25, 2022 7:08 pm
It looks like there is one missing character: 0x03 which happens to correspond to Control-C (this may or may not be relevant).

Which board are you using?

Normally, I've only seen this issue when using the REPL as a UART. You might want to try disabling Control-C by calling

Code: Select all

  micropython.kbd_intr(-1)
Be aware though, that this will disable Control-C for interrupting your program, but it's probably a worthwhile test to see if that's affecting things somehow.

I know rshell needs to do this, but it's sending binary data streams over the same port used as the REPL.
@dhylands, you are right. all 0x03 bytes are missing from the data. Your suggestion to disable Ctrl+C works. Thanks;

When the humidity value is above 76%, it'll return 0x03(76.8%)

Post Reply