Serial port sensor's data frame delimiter

[nirvn]

Description

This PR implements this enhancement request (#56275) by adding a new data frame delimiter functionality to the serial port sensor:

In case multiple data frames are found in the last chunk of data pushed by the serial port, this implementation will only return all data frames. Users can then use an expression to further split the returned sensor last data value into individual frames (e.g. string_to_array).

@jtornero , this enhancement was something I needed on my end too, and had some free time. So here it is :)

[nirvn]

@jtornero , I've also made the serial port name combobox editable. It allows for entering that are either not currently available on the system, or that aren't registered by the system but accessible (e.g. on linux, virtual serial port such as socat). Helps testing things.

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 0995197)

[nirvn]

@nyalldawson , review addressed, thanks.

[jtornero]

@jtornero , I've also made the serial port name combobox editable. It allows for entering that are either not currently available on the system, or that aren't registered by the system but accessible (e.g. on linux, virtual serial port such as socat). Helps testing things.

Hello @nirvn

I haven't been able of testing it under Linux yet (I am not able of compiling your source, looks like compilation proccess somehow different ) but I managed to run the compiled windows artifact and it works perfectly.

It's been a fantastic idea enabling the virtual ports by editing the combobox, not only for testing but sometimes we have to do weird things on board, so that's a very nice feature to have also.

Thank you very much for your support and work. I'll close the issue now.

Jorge

[qgis-bot]

@nirvn
This pull request has been tagged as requiring documentation.

A documentation ticket will be opened at https://github.com/qgis/QGIS-Documentation when this PR is merged.

Please update the description (not the comments) with helpful description and screenshot to help the work from documentors.
Also, any commit having [needs-doc] or [Needs Documentation] in will see its message pushed to the issue, so please be as verbose as you can.

Thank you!

[nirvn]

@jtornero , glad to hear it works for you -- out of curiosity, if you don't mind sharing, what use(s) are you making of the sensor stuff in your project(s)?

[jtornero]

@jtornero , glad to hear it works for you -- out of curiosity, if you don't mind sharing, what use(s) are you making of the sensor stuff in your project(s)?

@nirvn

Of course, no problem sharing!!

The sensor stuff has opened two big gates for me. First is making possible to collect information from all the "sensors" we could have on board a research vessel: Not only GPS, which some times don't come through serial ports or TCP streams but it has a big potential with:

• Echosounders
• Ship attitude information (roll, heave, pitch...)
• Meteorological information
• AIS targets
• Fishing gear info (trawl opening, otter door distance...)
• Other custom sensors like CUFES (Continuous Underway Fish Egg Sampler) flowmeter

And also now AFAIK you are not able of handle some non-standard GPS sentences. For instance, is is potentially useful for parsing GPS custom sentences like Seatex SeaPath GPS, which are propietary sentences starting with $INGGA for instance so QGIS GPS parsing implementation is not able to cope with it (I made a dive into QGIS source but I realized there is not much what I could do, despite I hope I have time in the future to look it deeper)

Another advantage: We have a custom application for recording key positions on fisheries surveys (haul starts, tow starts, tows end...). Using QGIS' sensors for integrating not only GPS but time and depth data from the vessel's echosounder and having all the display provided by QGIS is so cool and makes very easy to create such applications, providing it is matter only of creating forms and its logic (data parsing, connections, display, layer managemente is already implemented by QGIS). Here is an prototype of a QGIS-based application I'm testing, in this case for recording plankton net maneouvers:

But the second one and maybe right now the most interesting for me is the possibility of using the signals provided by the Qgs[whatever]Sensor for triggering data collection. As an example, we are designing a sort of Raspberry PI Pico/Arduino based anglemeter. This device has several buttons, each of them are able to transmit a certain data frame to the computer. As the data frame is read, in this case, by a QgsSerialPortSensor, it parses it and triggers a particular action, in this case each action opens a different data form depending on the type of object we have detected. You can see it as if you were able more or less able of having a remote control or event driven data adquisition for QGIS.

Cheers

Jorge