Thank you for the idea. Yes, writing a wrapper class around the serial port worked like a charm. I implemented it a bit differently, a message handler manages the message building and sending it off to the serial port but the concept is the same. The only thing I found different from your example is that the timer isn't destroyed when it runs out. Instead of creating a new one every time, I created one as part of the class and use it over and over again. Thank you very much for the insight!!

This might be the culprit: while (serial->waitForReadyRead(200)) This will put your thread to sleep until data has arrived or 200 ms has elapsed. QSerialPort seems to rely on the message loop to handle data so this might interfere with it (?). There is no guarantee that you will have 512 bytes of data back at once either. There is a signal (QSerialPort::readyRead() ) you can use when received data arrives. Connect this to a suitable slot and buffer what has arrived each time the signal is fired (I assume you will not get all the data at once). Do this until you have 512 bytes then process it. Keep the event loop active if you have some other 'heavy' function somewhere (QApplication::processEvents() ).

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!

@SGaist Thank you very much for your tips! I probably should give up on the serial thread. It is beyond my ability to play with that problem.

Hi @pthinks, I highly recommend you proofread your post. It contains false advertising (you are not the top 2nd contributor in the forum) It contains outdated information (qt-project.org is now offline) It's full of formatting errors ("list listItem")

@syndrome QSerialPort serial; ... // some stuff for initialisation and more char xon ( 17 ); char xoff ( 19 ); serial.writeData ( &xon, 1 ); // will send XON serial.writeData ( &xoff, 1 ); // will send XOFF Check out writeData . Do you know how send the rest?

@JohnYork said: based on my experience, I think some warning comments should be added into Qt's API documents, to avoid the unecessaried mistakes on Qt newbies, just like me. Do you think so? It is tempting to want to place the blame on your framework or compiler however in my experience 99.9999% of the time it is the design or the programmer that is causing the issue. For the most part the code was exactly what you programmed it to do. What makes things harder now days is you really don't know how long an object lives when it is created in some strange place. Most objects in the framework have a parent pointer and when the parent dies or if you don't use parent (in some cases) and the object dies because of scope then all bets are off if you have pointers to that object. In the "old" days we pretty much managed everything ourselves. You created something, you had to get rid of it. Even with the newer ways of managing items I still find that at times knowing exactly when an object is valid and when it is not is invaluable. Therefore somethings need to be singletons that you create and leave around until you decide you are done with them. Anyway I doubt there is any comment that could be added to docs to help out with these concepts. The Qt docs document the use of the framework, not how to manage objects and object scope. Since those principles apply to ALL C++ objects a standard C++ tutorial, book or online course will give you what you need. This forum with the great people here can help to fill in the gaps on Qt related stuff. You'll find the people here amazingly knowledgeable and talented.

@joaopagotto http://www.simcore.com.br/downloads/QtForum/53877/ this link is not available

#2 is wasteful way indeed! but in low baud rates it will help, but in this case I don't think this is a low baud rate. EDIT : I said for example 1ms, you really don't need it this fast, it depends on the frequency of getting bytes, for example for 20Hz you will have 20bytes every second which means you need a timer with at least 50ms refresh time and of course you read from serial port in asynchronous way then you can't 100% trust this way to read byte by byte, So as @JKSH said you better don't use this way if you don't have a specific reason.

Resurrecting this ancient thread with a concrete solution in case it helps someone: I just ran into this as well; libudev debug messages were cluttering the Application Output. It turns out you don't even have to query serial ports -- the messages are emitted just by virtue of including the serialport module. Like the OP, turned out that I too had turned on some logging to debug a different problem ages ago. After some hunting, I discovered that this logging had been enabled by adding the line udev_log="debug" in /etc/udev/udev.conf. After I commented out that line and rebooted, the libudev messages are gone!

I added a delay function before reading the serial port, console->SenDelay(70); QByteArray data = serial->readAll(); now everything is working.

Hi, Thanks for your reply. The problem was the code in snippit I pasted was executed in the Main/UI-Thread, which seems to receive new bytes asynchronously. So my infinite loop was not allowing the Main-Thread to execute the receive-handler and therefore bytesAvailable() always returned 0. I now call processEvents() within the loop, and things seem to work as expected :) Thanks & br, Clemens

I looked at the Qt source for the serial port, and it's relatively simple, so it was pretty clear the issue wasn't there. I did more digging and found that the reset signal is inverted on the device I'm using (maybe it normally is - I'm not sure). In any case, me setting the DTR line true was causing the reset. I had tried setting it false as well, but it's possible I did that without having the "restoreOnClose" setting cleared. Regardless, thank you for pointing me in the right direction.

AFAIK, there's no detection going on, you have to tell the terminal at which speed it should communicate with your device

@kuzulis I wanted to see what happened that triggered the "improvement" :) Thanks for the pointer

@SGaist I think if I store available ports string in a combo box will do this for me. right?