Qt World Summit: Submit your Presentation

GPS signal serial port

  • Greetings ~ The GPS receiver sends data continuously via serial connection, and can be visualized on the command line. When connected to my embedded linux device, it shows behavior that I cannot explain. The readAll() command reads all of the data, and prints it to the device screen as expected, but after what seems to be a random amount of time (sometimes 1 second, sometimes 5, or >30 seconds), only a single blank is printed to the screen indefinitely. I confirmed the serial port connection remains open. What else could be causing this problem? Please refer to example screenshot.

    I explored two strategies, but they both lead to the same output :

    connect(timer, SIGNAL(timeout()), this, SLOT(timeReceived()));


    connect(serial, &QSerialPort::readyRead, this, &MainWindow::serialReceived);

    ![0_1546503759314_debug output.jpg](Uploading 100%)

    Thanks in advance for any possible suggestions to get back on the right track.

  • 0_1546504857052_debug out.png

  • Lifetime Qt Champion

    @Sinzar Using readyRead() should always work. Can you break down to code to a minimal example and show us?

  • it might be that the data just happens to start with 0x00. instead of qDebug() << data; can you use qDebug() << data.toBase64(); and see if it prints more data?

  • #include "mainwindow.h"
    #include "ui_mainwindow.h"
    #include <QSerialPort>
    #include <QDebug>
    #include <QTime>
    #include <iostream>
    #include <QTimer>
    #include <QString>
    #include <QCoreApplication>
    QSerialPort *serial;
    MainWindow::MainWindow(QWidget *parent) :
        ui(new Ui::MainWindow),
        serial(new QSerialPort(this))
        timer = new QTimer(this);
        connect(serial, &QSerialPort::readyRead, this, &MainWindow::serialReceived);
        serial->setPortName("/dev/ttymxc0");//from the display device C/C++ manual
    void MainWindow::serialReceived()
        QByteArray ba;
        ba = serial->readAll();//try 1
        ui->label_output->setText(ba);//try 1
        //qDebug() << ba;
        qDebug() << ba.toBase64();

  • Lifetime Qt Champion

    @Sinzar said in GPS signal serial port:

    QSerialPort *serial;

    Is there a reason why serial is not a member of MainWindow?
    Also, what is the output now (that's actually what @VRonin asked for)?

  • Lifetime Qt Champion

    @Sinzar and to add to @jsulm: Can you show how the expected output should look like?

  • It turns out my previous post was misleading, because the output I displayed was using the timer version, not the readyRead version ~ I apologize for the oversight. The program runs a certain amount of time and then stops outputting data. I'm not sure if its freezing, or there is no data to be read from the serial port, or the port is closing for some reason. From other reading on the forums it appears likely I may need some buffer to handle the streaming characters appropriately, but that doesn't explain why the program just stops reading the characters. Attached are two screenshots, one of the toBase64 output as requested, and one as the expected output in a terminal0_1546586344638_Screenshot from 2019-01-03 23-09-00.png .

    0_1546586363552_Screenshot from 2019-01-03 23-16-19.png

    Thank you so much to everyone endeavoring to help. It will be paid forward.

  • Lifetime Qt Champion

    @Sinzar You said the GPS receiver is a serial device. Can you connect it to your computer and run the program on it?

    That would give some hint if it would work at all.

    On your embedded device, you should have a look at dmesg when the connection aborts.

  • A GPS typically sends data out when it is available, this is not a constant stream, so you must poll the GPS for data, by this I mean read it and wait for data to be arrive.

    When the data has arrived you can then process it and then return to the wait and read stage.

    I would suggest implementing a queue, with a thread that reads data continuously from the GPS in a loop and adds new received packets to a queue.

    Another thread then monitors the receive queue and processes it, removing data from the queue and keeping it from continually growing.

  • Lifetime Qt Champion


    One small thing you can do to determine whether you are still receiving data is to use a QTimer with a resonnable timeout that you'll reset each time you receive something. Connect it to a slot that will warn you that you haven't got something for a while.

  • @aha_1980 The GPS receiver was connected to the linux machine, and the program was ran on qt without issues - serial data was printed to the window as expected without stop.

    I will continue to pursue the suggestions offered on this page. Thanks you all once again.

  • Lifetime Qt Champion

    @SPlatten no, that would be over-engineered.

    The readyRead signal already provides everything: when new data is there, the slot is called.

    Only note that new data can mean 1 byte, 10 byte or 100 byte. you need to check that you only process the data if one chuck is complete. Usually thats a line, wherefore canReadLine() exists.

  • I have figured out a temporary solution by incorporating some advice from this thread, but i know it's not ideal. Even though the serial port never closes, readyRead() does not trigger after a certain amount of time. Using a timer, i quickly close and open the serial port. I am probably losing packets of data that i will test for tomorrow, and its not efficient, so this is not a permanent solution. In addition, I still can't explain why my device shows this behavior. However i am now receiving serial data "continuously".

    I will leave the thread open in hopes of a few more suggestions, then I will close it. Thanks to all again for your insight.

  • Lifetime Qt Champion

    @Sinzar are you sure the port does not close? have you checked receiving with an other program (e.g. minicom)?

    It might be as simple as an USB port with limited power that leads to such effects.

Log in to reply