QSerialPort Buffer Problems
-
I usually use the cheap USB-Serial adapters. They are no-name and I have a small pile of them now. The ones I have purchased for a premium gave me the most problems (Belkin in particular). The odds are low it is an adapter problem but easily checked if you can replace what you are using with something else.
You have three ports open? That means you have three pointers or scope/global serial port instances. Make sure that you are not accidentally using the one for your data in some other part of the program. Example, if 'port3' is your data port you might have some other part of the program reading data from 'port3' instead of the intended 'port1' or 'port2' (therefore a small part of the data is lost each time it reads from the wrong port).
The default read buffer size is unlimited for QSerialPort. The device or low level buffer is probably at least 4k. This shouldn't be an issue unless you start to have issues after 4k of data has been received.
The working to non-working samples show roughly the same amount of data between the '*' characters. The time to render the graph doesn't appear to be slowing it down (I would expect larger blocks of read data if it was).
I have not opened three ports simultaneously. I don't know if this is part of the problem. That would be new ground for me.
You don't have to get out the soldering iron (lol). If you have an old serial cable cut it, strip the wires for tx, rx, and ground connecting them half hazzardly together. To monitor you only need the tx line from the data source and the ground wire. You should be certain the input data is correct as the problem occurs (or you are 'chasing a wild goose').
-
What does this return?:
http://doc.qt.io/qt-5/qserialport.html#error-propOr connect the signal http://doc.qt.io/qt-5/qserialport.html#error-1
-
The error-methode returns always "0", in both cases.
So I comanded three other different USB-Serial converters. I hope that I will see a difference. Somtimes my windows is also crashing. With this driver is anything wrong I think. I currently use this one: link
For the three connections I created three different QSerialPort-Objects, and manage them all separate. But I have the problem also, when I use only one Serialconnection.
The only time, that I read the Port ist in the "serialRecieved" Slot who is connected to the "readyRead".
Hmm.. now I have an idea:
I have also in the serialRecieved, all the parsing algorithms in there. And if it is a big package it can take mabye longer. What happens, when the slot ("serialRecieved") is not jet finisched, and a new signal from "readyRead" is coming. Does he start again, or does he wait, until the oldone is done? Mabye I have conflicts there. -
The qt architecture is Asynchronous, but it secretly isn't.
The main returns a.exec(), and that is where you're event loop is handled, and where your application sleeps when there is nothing interesting happening. The actual serial port implementation might not be in your thread though.
It is impossible to have yourserialRecieved()run twice without you implementing threading.The adapter linked most likely works on a Prolific USB-UART, those never worked reliably for me.
I'd recommend you either get Silabs or FTDI converter chips. Such as FTDI Chipi-X.Meanwhile, HHD has a "free" serial port monitor. That might help determine the location of the problem.
-
Hello again! So I learnt something more about QT :)... I tried the new converters:
With this one from Exsys my Problem is still there but a lot better. As I saw it has also a FTDI chip in there.
This one from Moxa workt also better and with the Maxxtro, the driver does not work properly on my computer. I saw that FTDI Chipi-X is also very cheap. I will try this one too next monday.So thank you for your help until now, Jeroen3 and Rondog! It was helpful! Hope that I will find the solution soon...
-
Most likelly, a problem is in your code. QSerialPort doesn't lose data, especially on lowest 9600 baud (as I can see from your video).
UPD: Maybe you do wrong QByteArray <-> QString conversion.
-
Qt cannot keep up if you want to plot full speed 9600 baud to a multiline QTextEdit.
Neither can C# or VC++. There is severe lag in Windows' GUI implementation somewhere.QSerialPort does lose data if the above is occurring and the buffer is not unlimited.
-
QSerialPort does lose data if the above is occurring and the buffer is not unlimited.
No. This may happens only in case when event-loop is freezes (depends on wrong application design and by others reasons, e.g. QTBUG-34946). In this case QSerialPort does not read data which collected in FIFO of driver timely, and the FIFO can be overflowed.
Common recommendations:
- for Qt < 5.5 it is enough to move QSerialPort to the separate thread, to exclude an event-loop freezing (strongly recommended with a high streaming).
- for Qt >= 5.5 this do not need to do (but, also can be moved to the separate thread too).
-
Actually I use the baudrate 115200 and I have around 50 strings like above in a second. Now after recieving the data, I put it firstly in the database, then I plot them with qcustomplot. I used QT 5.4. Now I updated to 5.5 and the problem is still there. I saw, that when I start the program, all seems to work. But after a while the errors become more and more. Also when I drag and drop the mainwindow, there is always coming an error. I will try to make a thead for this. This make sens to me.
-
It means what are you doing something wrong. Somewhere you something blocks Qt event-loop.
Also when I drag and drop the mainwindow, there is always coming an error.
This should not be in Qt 5.5, check your code again and again.
PS: We here do not play in telepathists and predictors. If you want to get help, you should provide the minimal and simple example which reproduces an issue. E.g. try it with the com0com driver at first..
-
Replace the SerialPort with a TCPSocket. They both use QIOdevice api.
Then you can determine if the problem exists in the qt buffering, your display class ,or the hardware.
Here is an example to tunnel COM to TCP for windows https://github.com/Jeroen6/MultiTerminal/tree/master/driver.You can easily spy on a TCP localhost socket with wireshark.
-
I am sorry about my last post. I made a stupid error. I updatet to QT5.5, but I haven't reconfigurated the project, so I was still using QT5.4.
Now I tried also the Chipi-X10 USB-RS converters. I have to say, they work a lot better. I have now for all three ports, this converter. With the others, a lot of times I had to unplug and replug the connectors to get dem work. So there is something strange. The Chipi worked really good until now, thank you jeroen3, this will save a lot of time.
After building the programm with QT5.5, the programm also work a lot better. I saw that the qcustemplot keeps plotting while I drag and drop the window. I have sometimes errors but now only sporadic. For example when I resize the window very fast, I can provoke it. But in general the errorrate is about one or two percent, and with that I can live.PS: We here do not play in telepathists and predictors. If you want to get help, you should provide the minimal and simple example....
My problem was, that with the minimal simple example all seems to working. This communication problem I had only, wenn all the data was coming and when I was plotting someting in the same time. And I checked my code a lot of times. The problem is, my knowhow about QT and generell about programming with PCs is not very big. So I think there is something I do not know. So when I check my code a hundet times more, I will not find an error.
I made also an easy experiment to isolate the error:
My I slowed up the replot, so that I plot only every tenth time, but ten points at the same time. Like this I can see, that this error, comes only when the window is plotting. The error comes more, the more points he has to plot on the screen. So if I make fullscreen, and I set up the scale so that I have the maximum of points in the axis, the error comes every time again.
So QT has an influence to this problem. I think there is an overflow in some buffer, beause the program is to slow to read it or that he overwrites any part for some other reasons. But anyway.. For me I will pay attention now to not overcharge my comuter :)
Thank you for all help!