Error :CSV text cannot be parsed as a row , when receiving serial port data ( ext SerialOTG)

I have connected two devices using the NRF24L01 modules and the last one sends data to an APP via serial port using the SerialOTG extension. Frequently the indicated error appears and I don't understand why. I am sending a string of data with the following format:
sprintf(buffer,"%s,%d,%c\n",bufferTime,statenum,Base); bufferTime string , statenum int , Base char.
If I see it in the Arduino Serial Monitor it looks perfect, without errors or strange texts.

Captura de pantalla

However, from time to time this error appears in the app.

I sow you the reading sequence, previously the port has been started and opened , I do not see problems in the connection.
The driver that indicates that are using the phone:
com.physicaloid_ai.lib.usb.driver.uart.UartCdcAcm and the micro board needs the CH343SER driver to connect to the PC.(This is completely unknown to me, but could it be the origin of this error?)

I would appreciate any ideas, thanks in advance.

What do you get on the ReadLn? Remove all the blocks and leave only one label with the ReadLn to see what you get.

I did the test and put it in the title of the screen.
It is seen in the photo of the error above.
It has the form (23.45 10 A) that corresponds to the three data that I send.

I have managed to reduce the number of times the error appears, changing in the communication part the times of the access loops to the availability of radio data (arduino program). I have also seen that a message appears on the Arduino monitor that says: Prefix string too short, this appears very occasionally, one out of twenty that the Csv text error appears...... in the app. I had not seen this until today but surely it was already before.
I do not know if with this we can think of any other conclusion.

I have tried, as you requested, to represent the data received directly in a text box, as you will see I have modified your program to see the data received. No anomaly can be seen on the text screen. But I have tried to put the data in a file and here I do see anomalous things, for which I have no explanation. Clearly when I try again to make a list of this data the error appears again.
I am attaching the data reading block and the generated file.



datos[1].txt (265 KB)

It seems that it is a problem in the speed of data capture, we do not know what your device code is like, what is the interval of the clock and sending code?

You can filter the delivery, that is, before sending the data from the device to the app, check the delivery data, that is, if the data does not contain two commas (---, ---,---), that don't send it.

You can also do the opposite, that is, if the app receives data without two commas, it does not perform the "list from csv record".

The 'Prefix string too short' error could be a problem with some library that you are using, which does not have time to create a temporary file with a long name.

1 Like

component_event

Is it possible that you are trying to save to a file before the previous save attempt completed?

Otherwise, why would AI2 include an event like this?

You may need an interim storage destination like a list or text variable to hold text waiting to be saved to the file between file save completion events.

1 Like

I have been investigating the type of data that is actually sent and I have detected that it was sending null data through the serial port, they were not visible on the serial monitor screen but they did damage to the app. I have filtered the data so that it does not send if it is null data and the result is correct. The error no longer appears. The data update speed is high now I am testing if I can improve it, but it is working correctly at 300 msg.

ABG I think your reasoning is correct, it would be better to save over a variable and create a file once the data is collected, I'll keep that in mind. Thank you

Thank you very much for your interest in the problem, greetings to all.

1 Like

To better understand the problem, it sent up to ten null codes after the data. It had chosen a character array of a larger size, in case it was necessary. For this reason, it always sent about ten extra null data that remained stored in the buffer of the serial port input. With the ReadLn instruction it is only read until a "\n" is detected, with which the null data remained in the buffer, until the buffer was full and then the problems began.
I think this is what was happening.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.