Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. GPS signal serial port
Forum Updated to NodeBB v4.3 + New Features

GPS signal serial port

Scheduled Pinned Locked Moved Unsolved Mobile and Embedded
15 Posts 6 Posters 3.8k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S Offline
    S Offline
    Sinzar
    wrote on last edited by VRonin
    #5
    #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();
    }
    
    jsulmJ aha_1980A 2 Replies Last reply
    0
    • S 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();
      }
      
      jsulmJ Offline
      jsulmJ Offline
      jsulm
      Lifetime Qt Champion
      wrote on last edited by
      #6

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

      https://forum.qt.io/topic/113070/qt-code-of-conduct

      1 Reply Last reply
      2
      • S 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();
        }
        
        aha_1980A Offline
        aha_1980A Offline
        aha_1980
        Lifetime Qt Champion
        wrote on last edited by
        #7

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

        Qt has to stay free or it will die.

        1 Reply Last reply
        1
        • S Offline
          S Offline
          Sinzar
          wrote on last edited by
          #8

          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.

          aha_1980A 1 Reply Last reply
          0
          • S 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 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.

            aha_1980A Offline
            aha_1980A Offline
            aha_1980
            Lifetime Qt Champion
            wrote on last edited by
            #9

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

            Qt has to stay free or it will die.

            S 1 Reply Last reply
            3
            • SPlattenS Offline
              SPlattenS Offline
              SPlatten
              wrote on last edited by SPlatten
              #10

              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.

              Kind Regards,
              Sy

              aha_1980A 1 Reply Last reply
              1
              • SGaistS Offline
                SGaistS Offline
                SGaist
                Lifetime Qt Champion
                wrote on last edited by
                #11

                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.

                Interested in AI ? www.idiap.ch
                Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                1 Reply Last reply
                3
                • aha_1980A 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.

                  S Offline
                  S Offline
                  Sinzar
                  wrote on last edited by
                  #12

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

                  1 Reply Last reply
                  1
                  • SPlattenS 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.

                    aha_1980A Offline
                    aha_1980A Offline
                    aha_1980
                    Lifetime Qt Champion
                    wrote on last edited by
                    #13

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

                    Qt has to stay free or it will die.

                    1 Reply Last reply
                    1
                    • S Offline
                      S Offline
                      Sinzar
                      wrote on last edited by
                      #14

                      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_1980A 1 Reply Last reply
                      0
                      • S 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_1980A Offline
                        aha_1980A Offline
                        aha_1980
                        Lifetime Qt Champion
                        wrote on last edited by
                        #15

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

                        Qt has to stay free or it will die.

                        1 Reply Last reply
                        1

                        • Login

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups
                        • Search
                        • Get Qt Extensions
                        • Unsolved