USB serial port reads only one line of ASCII data

[BranislavHatala]

only one line of data is read per opening of port when USB COM is used.
This can be seen in text view where only one line is added when port is opened.
Closing and reopening port adds another line.

[hyOzd]

Can you provide more information?

Which version of serialplot are you using? Which OS?

Can you capture a few lines of your data with a text terminal software and put here?

[BranislavHatala]

Serial plot: 0.12.0
platform: Windows 10 home 21H2
Data structure as logged via TeraTerm and copied from notepad++:
1 968
1 920
1 1108
1 1070
1 1136
1 1106
1 971
1 1120
device sends string that follows "%d %d\r\n" where first number is number of samples measured between USB frames sending.
Second is value from ADC.

[hyOzd]

What does your data format settings look like? Can you share a screenshot?

Your data seems okay. But can you also check with a terminal software that can display hex data? Sometimes there can be other binary data that confuses serialplot. I just want to make sure we are on the same page before I try to reproduce this.

[BranislavHatala]

and text view after clicking open few times:

Log:

[hyOzd]

@BranislavHatala I'm sorry but I cannot reproduce the issue on my linux based system with the data you provided. This could be a windows specific issue which means it will take a while before I can debug it.

Maybe you can try to use another data format?

Actually if you switch to 'simple binary format' you should be able to see some data even though it would be junk. If you observe the same behavior this would mean that this is most likely a serialport reading issue (not a parser issue).

[BranislavHatala]

It seems so. In binary it does read the data continuously.
It seems as if the culprit may be line endings, or is separator required after last column in a line?

[hyOzd]

It seems so. In binary it does read the data continuously.

Hmm this means there is an issue with the parsing.

It seems as if the culprit may be line endings,

It might be the line endings. Can you try linux style line endings (just \n)?

or is separator required after last column in a line?

No, separator isn't required after the last column.

[BranislavHatala]

I tried changing firmware of source device to use the linux style line ending.
Behavior is same, problem prevails.

[ldoktor]

Hello folks, I'm using Fedora 36, serialPlot from AppImage and I am hitting the same issue. I tried sending \n \n\r \r\n \r, the \r shows nothing, the rest works similarly bad. Every open results in reading 1-6 lines and then it gave ups.

The other side is micro:bit's serial console redirected to usb, I tried simple binary format as well as ASCII using space separated values (7 values).

[ldoktor]

Interesting, I tried running it with strace and suddenly it started working and now it works even when running without strace.

[hyOzd]

This is strange. I am not familiar with strace. Not sure what it changed. I would try restarting my pc to see if issue comes back. In that case I would suspect the libraries included in the appimage. Maybe you can build serialplot yourself and see if you see the same issue?

[ldoktor]

Still no luck reproducing, I'll let you know if that reoccurs.

[franzflasch]

I am facing the exact same issue in Debian 12. I am using a pl2303 usb to serial adapter. I also have another usb to serial adapter (blackmagic debug probe) that works just fine. The pl2303 works fine with minicom so I must assume that there is an issue in serialplot.

starting it with strace did not solve the issue in my case

[franzflasch]

Seems that there is an issue with canReadLine() in Qt. It seems for some devices this does not work correctly.

If someone is interested I solved it like this:

diff --git a/src/asciireader.cpp b/src/asciireader.cpp
index 75cf929..73f6b05 100644
--- a/src/asciireader.cpp
+++ b/src/asciireader.cpp
@@ -90,10 +90,18 @@ void AsciiReader::enable(bool enabled)
 unsigned AsciiReader::readData()
 {
     unsigned numBytesRead = 0;
+    int endIndex = 0;
 
-    while(_device->canReadLine())
+    readBuffer.append(_device->readAll());
+
+    if (readBuffer.indexOf('\n')  == -1)
+        return 0;
+
+    while((endIndex = readBuffer.indexOf('\n')) != -1)
     {
-        QByteArray bytes = _device->readLine();
+        QByteArray bytes = readBuffer.left(endIndex).replace('\0', "");
+        readBuffer.remove(0, endIndex + 1);
+
         QString line = QString(bytes);
         numBytesRead += bytes.size();
 
diff --git a/src/asciireader.h b/src/asciireader.h
index 4aa41e8..ff61bfb 100644
--- a/src/asciireader.h
+++ b/src/asciireader.h
@@ -52,6 +52,7 @@ private:
     QString filterPrefix; ///< selected ASCII mode filter prefix
 
     bool firstReadAfterEnable = false;
+    QByteArray readBuffer;
 
     unsigned readData() override;

I am not very familiar with Qt so probably not a good solution but it works for me.

[hyOzd]

@franzflasch Thanks for debugging the issue and even providing a workaround. Since this seems like a bug with the Qt library (probably related to hw differences as you mentioned), maybe a newer version of Qt have already fixed it? Can you tell me which version of Qt you are using?

[hyOzd]

There is this note in canReadLine documentation:

Note that unbuffered devices, which have no way of determining what can be read, always return false.

If I remember correctly, QSerialPort always have a buffer, so canReadLine should have worked. But maybe it doesn't use buffer in some cases. Need to investigate. And probably I should implement buffering in the Serialplot code (as you did) instead of relying on QSerialPort::canReadLine.

[franzflasch]

I am happy to test your solution with my setup if you want.