rkl099/Appinventor-SerialOTG

Mistakes while using read New line

romain974 opened this issue · 8 comments

Hi,
My Arduino is sending messages with a baudrate >100000 (3d lidar scanner). In appinventor, using serialOTG read Line fonction inside a timer, it got several "mistakes": sometimes lines are 'skipped' , sometimes 2 lines are merged, ...
IS it due to baudrate or internal buffet size or ?
I don't understand why those mistakes appears.

Fyi: it works perfectly with Android app : Serial USB Terminal.

There are 3 buffers involved:
in the USB-serial converter, 64b or more depending on type.
Driver library 1024b circular buffer
In extension 256b to collect characters up to EOL character.

Are you using ascii characters to transfer data?
Are you using any type of handshake?
Are you sending a continuous stream of bytes?

To send blocks of 1024b binary data should be ok.

On arduino, Inside a for loop, i read value from 3 sensors and use: Serial.Print(value1);Serial.Print(value...); Serial.PrintLn("|")
=> so each line should be: val1;val2;val3| (ex: 1000;2000;3000| ) (max lenght for sensor values are 9999)

On appInventor: when a button is clicked, activate a timer (interval=1ms): read lines and save each line to file

And about a few seconds, errors start to appear (somes row are skipped and some end lines are not recognised)

Any delay between lines?
It seems to be (max) 16 char for each line. At 115kbaud: 11k char/sek, 700 line/sek.
Can you test just to receive lines and check if its ok, without saving to a file?

Same thing without writing to file (just writing result to appinventor label)

If you have no delay between messages, it's about 1.4-1.5 ms/mess. That's fast compared to the 1ms timer, but not impossible.
I need to see your AI code to help you.

my aia file is here if you want to check: https://easyupload.io/n3apbp (valide for 30 days)

Some comments after a first look
The extension has never been tested with baudrate >115200. It seems to work with your serial-usb adapter on the aurdino, but a message will be only 0.7-0.75 mS if you don't have a delay between messages. That is to fast with a 1mS timer and you will get an "overflow" in one of the buffers involved. You can try to get the messages in a loop for each 1mS tick from the timer, until you get an empty string (no complete messages received). This will allow you to receive more than 1 message for each 1 mS.

You can also try to pack more than one reading with 3 values in each message, maybe 4 or 5 times 3 values.