GPS signal serial port

[Sinzar]

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()));
timer->start(1000);

AND

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


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

[Sinzar]

[aha_1980]

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

[VRonin]

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?

[Sinzar]

#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) :
    QMainWindow(parent),
    ui(new Ui::MainWindow),
    serial(new QSerialPort(this))
{
    ui->setupUi(this);
    timer = new QTimer(this);

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

    serial->setPortName("/dev/ttymxc0");//from the display device C/C++ manual
    serial->setBaudRate(QSerialPort::Baud115200);
    serial->setDataBits(QSerialPort::Data8);
    serial->setParity(QSerialPort::NoParity);
    serial->setStopBits(QSerialPort::OneStop);
    serial->setFlowControl(QSerialPort::NoFlowControl);
}

void MainWindow::serialReceived()
{
    QByteArray ba;

    ba = serial->readAll();//try 1
    ui->label_output->setText(ba);//try 1

    //qDebug() << ba;
    qDebug() << ba.toBase64();
}

[jsulm]

@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)?

[aha_1980]

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

[Sinzar]

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 terminal .

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

[aha_1980]

@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.

[SPlatten]

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.

[SGaist]

Hi,

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.

[Sinzar]

@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.

[aha_1980]

@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.

[Sinzar]

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.

[aha_1980]

@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.