Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

serialnmea plugin help



  • I'm trying to use the serialnmea plugin in order to obtain position data. At the moment I'm developing on macOS using 5.14.2. I can see the NMEA stream by pointing a terminal client to the device node below. But when I attempt to use serialnmea I get Failed to open cu.usbserial-1420. I copied the existing serialnmea code into a new plugin directory so I could get more debugging output from the plugin and it appears that I'm getting error 2 from QSerialPort->open. But I don't know where to go from there. Nothing else has the device open, and when I close my QML app, miniterm successfully reads the data without issue.

    Here's the code I'm using:

    locationDisplay {
      positionSource: PositionSource {
        id: positionSource
        name: "serialnmea"
        PluginParameter { name: "serialnmea.serial_port"; value: "/dev/cu.usbserial-1420" }
        preferredPositioningMethods: PositionSource.SatellitePositioningMethods
        updateInterval: 1000
        active: true
    
        onPositionChanged: {
          ...
        }
      }
    }
    

    The console shows:

    QObject::connect(QSerialPort, Unknown): invalid nullptr parameter
    serialnmea: Failed to open /dev/cu.usbserial-1420
    serialnmea: Failed to open /dev/cu.usbserial-1420
    

    We've also tried under Windows using com ports (value: "COM4", for example) and we get the same invalid nullptr error, followed by one or more serialnmea: Failed to open errors.

    Any help would be much appreciated.



  • @Pablo-J-Rogina Thanks! I found the bug: QTBUG-82819. Using the patch in that issue against 5.14.2 fixed the serialnmea plugin, at least in early testing. I don't know what the Qt protocols are for fixing bugs in previous versions, but it seems like the patch for that issue should have been applied to 5.14 and a new release made (or applied when there is a new point release of 5.14).



  • Sorry to reply to my own post, but I've realized that on macOS, the serialnmea.serial_port parameter doesn't need the /dev/ portion. So the Failed to open error makes sense since there is no /dev/dev/cu.usbserial-1420 device node.

    However, I'm still getting the QObject::connect(QSerialPort, Unknown): invalid nullptr parameter error when I set the port to simply "cu.usbserial-1420".

    Also: the device I happen to be using (Garmin 76Cx, connected via serial, then serial-USB dongle) is vendor 0x67b, so it is part of the supportedDevices list, which means that I don't even have to specify a port at all. I still get invalid nullptr parameter, however, when I don't specify the port.


  • Lifetime Qt Champion

    Hi and welcome to devnet,

    One thing you should do is enumerate the serial ports of your computer with QSerialPortInfo::availableaPortsto see which one matches your device.



  • @SGaist Thanks! I'm not sure how to do that in QML, but I have copied the serialnmea code into my own version of the plugin and added logging lines to the NmeaSource::NmeaSource() function where it loops through QSerialPortInfo (lines 148-153 of qgeopositioninfosourcefactory_serialnmea.cpp). When I do that I get logging lines like this:

    myserialnmea: vendor identifier 67b, port name cu.usbserial-1420
    myserialnmea: found a supported device, cu.usbserial-1420
    

    However, no matter what I do (specifying that serial port, or leaving the plugin to load it on it's own (since it's supported)), I always get something similar to this (the order of the "Failed to open" message and "invalid nullptr parameter" varies, probably due to threading):

    QObject::connect(QSerialPort, Unknown): invalid nullptr parameter
    serialnmea: Failed to open cu.usbserial-1420
    

    When I set QT_FATAL_WARNINGS=1 and use my plugin source code so I can determine the line number of the crash, it appears to be crashing on this line (equivalent to line 68 of qgeopositioninfosourcefactory_serialnmea.cpp):

    QSerialPort *port = new QSerialPort(portName);
    

    But I don't know how to diagnose this any further. In cases where I'm not specifying portName using a QML parameter, the plugin is determining the port name itself via QSerialPortInfo, so I'd think there could be no issue with the naming. It seems like it should "just work," but it's not and I am out of ideas on how to fix it. I haven't tried other versions of Qt beyond 5.14.2, and I can't use 5.15 because the ESRI SDK doesn't support it yet.


  • Lifetime Qt Champion

    Is that plugin code available somewhere ?



  • @SGaist Which? You mean the code I modified? I can share it if that's what you mean, but it's essentially identical to serialnmea except I renamed it and added a bunch of qWarning() statements so I could trace the progress of the plugin. I'm having the same trouble with the Qt-supplied serialnmea; mine just attempts to explain what's going on. But if you think it'd help identify where serialnmea is failing, I'm happy to dump it somewhere you can access.



  • @SGaist The serialnmea code is in $QT_HOME/$QT_VERSION/Src/qtlocation/src/plugins/position/serialnmea. It looks to be different between 5.14.2 and 5.12.9. In 5.14.2 it's subclassing QGeoPositionInfoSourceFactoryV2 instead of
    QGeoPositionInfoSourceFactory, which means it can take parameters. The older version uses environment variables (or searching for a supported device using QSerialPortInfo).



  • An update: I built my app using 5.12.9 and the serialnmea plugin works as advertised with the same code and hardware GPS I was using before. Unfortunately, this version of the plugin doesn't allow for parameters because it doesn't subclass QGeoPositionInfoSourceFactoryV2, which was introduced in 5.14.

    To me, this seems like a regression between 5.12.9 and 5.14.2 since the same code works with 5.12.9 and doesn't with 5.14.2. Is there a place to report regressions like this? Can someone help me figure out how to get the 5.14.2 version to work so I can dynamically change the serial port being used (rather than require users pass it in at startup via environment variable or depend on the auto-detection of supported devices)?



  • @cswingle said in serialnmea plugin help:

    Is there a place to report regressions like this?

    I'd say Qt Bug Tracker
    Please provide any meaningful information (and even data sets if applicable) so the issue is easy and quickly reproducible.



  • @Pablo-J-Rogina Thanks! I found the bug: QTBUG-82819. Using the patch in that issue against 5.14.2 fixed the serialnmea plugin, at least in early testing. I don't know what the Qt protocols are for fixing bugs in previous versions, but it seems like the patch for that issue should have been applied to 5.14 and a new release made (or applied when there is a new point release of 5.14).



  • @cswingle said in serialnmea plugin help:

    but it seems like the patch for that issue should have been applied to 5.14 and a new release made

    Well, it looks like the patch is applied to 5.15.0, from the bug details:

    Fix Version/s: 5.15.0 Beta2, 5.15

    which at some point makes sense with the ongoing policy regarding patches and open-source versions, LTS and commercial offering

    We are making this change to encourage open-source users to quickly adopt new versions

    BTW, would you consider using Qt 5.15.0 as it's the latest (as of today) LTS release?



  • @Pablo-J-Rogina I would use 5.15 if I could, but I'm also using the ESRI ArcGIS Runtime SDK for Qt (100.8) in the project, and they don't yet support 5.15. Version 100.9 will, but it's not out yet. For now, I'll patch and build the serialnmea plugin for 5.14.2.


Log in to reply