@J.Hilk Thank You it did work. You saved me.

@donquixote said in Serial port data loss:

I used it because i thought maybe the problem is that new incoming data is interrupting the function before the previous one has not finished yet. The problem was still in there before that.

Slots are not interrupted. They are called one by one from the event loop in the background. Think of your slots are like a subroutine that is called from main if there is work to do.

process data and block serial signals at the time
QT'll continue to buffer data at the time

And I guess that will not work out. Even if it works on one platform, it may fail on another one.

OK, got your idea. That should be the problem since i don't wait for readyread signal in the loop, right?

Yeah, but don't wait for readyRead, leave the slot and give Qt the possibility to process the data. It will call your slot again once new data is ready.

Regards

I think a tracker has been raised from long time for the same https://bugreports.qt.io/browse/QTBUG-51751 and this is still in unresolved state.

@maxime.armand

Have you actually tried it? It does exactly what you demand in step 1.

And if you look in http://doc.qt.io/qt-5/qtserialport-creaderasync-main-cpp.html you will see that the serial port and the baud rate are given as command line parameters.

Just (cross-)compile the program for the Raspberry, and run it. It should work like your HypterTerminal test.

Thanks for your feedback.
I have identified that the problem is due to the EDBG chip (usb-serial bridge) which requires DTR signal to enable the serial port RXD and TXD pins.

Including the line of code "serial->setDataTerminalReady(true);" after opening the serial port, the serial port application is now working fine. I guess this is automatically carried out on hyper-terminal software and tera-term software.

Whether the communication uses the flow control or not,some of the hardware bridge requires the flow control signals to be set for the first time after power ON.

Never mind,

I had code in my the constructor of the to be threaded class, that caused the conflict...

connect(&modbusThread, &QThread::started, modbusDevice, &Modbus::setupClass);

fixed the issue.

The overlapped mode is the problem. If you only have a handle then ReadFile / WriteFile will fail if you don't include the overlapped structure in the call. It was opened with the OVERLAPPED flag so this parameter cannot be NULL.

What exactly are you trying to do? Maybe there is another way.

Hi and welcome to devnet,

You have several examples for the QtSerialPort module that should help you get started.

Hope it helps

@Wieland Well i found my problem, I chose the wrong baudrate. Now i have to adjust my code, but i think it will work sooner or later. Thanks again!

@Wieland, this float number is represent the speed Value of DC motor in RPM, may you mean I it should be in double type or something else!!.
in fact I don't know obviously whit's the type I should use this is the GUI I built
link text
you can see in Stack-overflow here:
link text
may you get what I need, I'am sory to be annoying but I spent alot of time in this problem :(

I am also trying to write a minimal qml app that uses the built in GPS to retrieve current position. I am not sure if I can use Qt positioning or if I should just parse the raw output of the GPS myself, like the OP did here, and extract the position manually. It seems very dirty to do it that way, I thought there would be a nice API in QML that I could use. Anyone can point to a simple example?

Then I'd recommend taking a look the example code and rewrite yours to match it.

@SGaist
Thank you very much my dear.
Your answer was a big help for me.

My problem was solved by set "setDataTerminalReady" function to false.
I did not have information about the signal DTR, by pointing you I read about that and find my problem.

@Dhinesh said:
HI and welcome
The signal readyRead (serialReceived) is sent when QSerialPort reads some data.
Try to not call serial->write("1",1); in your serialReceived
as it might make controller send more data and it might never get out of there.
(end less loop) as its called pretty fast.

Else they code seems fine.
Maybe say
QByteArray data.append( serial->readAll());
(and move QByteArray data to MainWindow.h)
and then when data.size() == 8 then
DOSTUFF
data.clear();

@Rondog @kuzulis I'm going to give the bytesWritten()signal a try, I will let you know how it worked out. I don't have a separate thread set up, but it's definitely worth the try! Big thanks for the reply's!

Hi and welcome to devnet,

Why the double conversion to stdString and c_str ? You can use something like toLatin1 if you want a QByteArray to write to your serial port.

Use QtSerialPort instead (branch qt4-dev): http://code.qt.io/cgit/qt/qtserialport.git/?h=qt4-dev
Wiki: https://wiki.qt.io/Qt_Serial_Port

PS: Also you can install QtSerialPort from the Fedora's repo

Thanks for your reply...
I agree that may be my code is not the best practice, as i learn Qt by myself only with doc and tutorials... but the program was working perfectly when i delivered it to the researchers... In fact, is working perfectly if i compile it on windows... few hour ago i borrowed a windows machine, installed qt, compiled the same project and worked just fine... So i doubt is really a code problem, because it should appear in both Windows and Linux, as the code is exactly the same...
I'm starting to think that is a linux driver problem, so i will try in another linux when i get the chance...
If someone has ubuntu 15.04 and is kind enough to reproduce this problem and tell me i would be very happy!
If anybody else reproduce this problem in other linux machine i will start a bug report

@kuzulis I used putty just to send data to my app. As you suggest, putty doesn´t detect parity errors.

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!

I used Qextserialport from git clone https://code.google.com/p/qextserialport/ and the problem is solved to a great extent.

With Qextserialport, around 4% of the bytes get dropped at 115200 baud. On decreasing the speed to 9600, data reception is much better. Only issue is that of the initial 160-190 bytes that are received, some bytes are missing. After the initial 190 bytes, there is no loss at all. Since the loss seems to be predictable, I plan to append some known value 200 times ahead of the actual data and send the whole sequence. The known value will be neglected at the receiver end in software.

You're welcome !

Since you have it working now, please update the thread title prepending [solved] so other forums users may know a solution has been found :)

Workaround: Start an application (QProcess) that pipes the serialport to a localhost socket.

@Jeroen3
Thank you for your sharing!

Hello, everyone. After some hours of debugging, I could finally find the problem. Long story short: apparently, the Linux driver for CP210x USB-TTL converter does not implement software flow control, but only hardware flow control. I've moved to the latter and it's working like a charm now. Thank you all for your help.

@SGaist
If i pass the object(QSerialPort) through the function to the dll, the test program stuck and there is no error written in the console.

If i create the object (QSerialPort) in the dll the following error is shown:
"QObject::start timer: Timers can only be used with threads started with QThread"