Averaged position count update frequency?

[bettellam]

I am using a U-Blox ZED-F9P GNSS receiver, connected Bluetooth, set to 1HZ. Enable medium placement requirement (on) Minimum number of positions collected (30)

In theory, if I set 30 as minimum number of positions collected, I would have to wait 30 seconds. This does not happen! Everything is completed in less than 5 seconds!

I performed a similar operation with smartphone's internal GNSS receiver. Actually time spent collecting the positions was much longer, it is approaching 30 seconds, but I don't know the data collection clock of receiver!

I think it is more correct, to use the time elapsed since the start [Add Point], as a reference for the calculation of the average position value!

Am I wrong, or do I have to use another method? Thank you

[nirvn]

@bettellam , we process an average of 1 position every 0.5ms. By that rate, you'd need 60 positions to get to 30 sec. By the looks of what I'm reading, it does sound like your GNSS's updated position rate is higher. An easy solution is just to tweak that number up :)

BTW, you can always do averaged position by long-pressing the (+) add vertex button (whether the minimum collection count is activated or not). That offers a manual way to collect for an arbitrary nb of seconds.

[bettellam]

Thanks @nirvn , happy to hear from you! I am pleased to read the excellent processing performance of QField (5ms). I'll take your advice with a long press of (+) to add a vertex.

However I would like to clarify that the NMEA sentence, which distinguishes each detected position, is characterized by a Time-Clock. If no check is made on this Time-Clock, you risk processing the same point many times in the average of the positions!

This is confirmed by the "jerky" of the bar that indicates the number of points measured. I am attaching 2 screen recorders Thank you (standard) https://user-images.githubusercontent.com/23143342/191448611-c0dfc876-31be-46fa-bf76-ac1174b92311.mp4

(longpress) https://user-images.githubusercontent.com/23143342/191448879-0b37a421-0e86-4e91-a703-4caaec2458e0.mp4

[nirvn]

@bettellam , good to know, and thanks for the screencasts, always heartening to see people's usage in action :)

Can we close this issue?

[bettellam]

OK @nirvn , I hope for a future improvement!

[nirvn]

@bettellam , the improvement / enhancement you're looking for here is having an averaged positioning duration that's based on time, not nb of collected positions?

[bettellam]

@nirvn That's right, generally the GNSS survey software collect the positions, at least, with: 1) time spent on station point (feature Point / Vertex Point); 2) distance from the previous surveyed point (polyline and polygon features) also in combination with the previous one.

Then there are many other operations concerning the theme: Topographic survey (but it's another job !!!)

[bettellam]

This could be a good upgrade!

[bettellam]

@bettellam , we process an average of 1 position every 0.5ms. By that rate, you'd need 60 positions to get to 30 sec. By the looks of what I'm reading, it does sound like your GNSS's updated position rate is higher. An easy solution is just to tweak that number up :)

BTW, you can always do averaged position by long-pressing the (+) add vertex button (whether the minimum collection count is activated or not). That offers a manual way to collect for an arbitrary nb of seconds.

Hi @nirvn , I have to go back to content of your answer, because I am not convinced of the NMEA position counting method (Minimum number of positions collected). I use a U-Blox ZED F9P GNSS receiver connected in Bluetooth set with a frequency of 1Hz. With these settings the receiver sends a sequence of NMEA messages at a rate of 1 second (1 new position every 1 second).

In these days I have thought and thought about it, I have done other tests and I need some clarifications in order to dispel my doubts about it. Let me be clear, I don't want to question QField's computing speed, but I would like to know what is the event that indicates to QField that it has received a new position.

For QGis (I refer to the master version) the attribute is used by 'QgsGpsInformation Class Reference': satInfoComplete it is only used to update the graphs of the GPS Tools Widget: satellite signals and satellites in view (not active) \src\core\gps\qgsnmeaconnection.cpp 360 // for determining when to graph sat info 361 mLastGPSInformation.satInfoComplete = (result.pack_index == result.pack_count);

ATTENTION: satInfoComplete will be True / False according to the following scheme (last column):

For QField this solution is not usable !!!!

Can you tell me what is the event with which the GNSS position is updated in QField? Sorry if I'm unclear and if there are spelling mistakes, my English is Google's :-) Thank you Ciao

[m-kuhn]

QField uses the same NMEA parser as QGIS does, here's where it connects to updates:

https://github.com/opengisch/QField/blob/fd728fa/src/core/positioning/bluetoothreceiver.cpp#L37

and here's where they are handled

https://github.com/opengisch/QField/blob/fd728fa/src/core/positioning/bluetoothreceiver.cpp#L115-L128

[bettellam]

Hi @m-kuhn , a pleasure to hear from you, thanks for the valuable information!

What I allow myself to specify is:

• in NMEA string the element that distinguishes a position sequence is DATATIME UTC of position; Example: $GPGGA, 172814.0,3723.46587704, N, 12202.26957864, W, 2,6,1.2,18.893, M, -25.669, M, 2.0 0031 * 4F
• is GNSS receiver that sets the rate at which the position values ​​are updated in NMEA string log Can I have a sampling rate set at 1Hz, 5Hz, 10Hz, 20Hz, etc. depending on type of survey I have to perform or if I am in a static position or in a dynamic position.

Another aspect to specify concerns the completion of the NMEA sequence reading: 'QgsGpsInformation Class Reference' is updated in subsequent phases, there is no flag indicating: "I have read everything there is to read in the NMEA sequence for this DATATIME UTC of position"! But for our purposes, averaging the positions, when we read the NMEA $GxGGA message, we have the data we need (we will miss the number of satellites used, and the number of satellites in view).

Returning to the code https://github.com/opengisch/QField/blob/fd728fa/src/core/positioning/bluetoothreceiver.cpp#L115-L128

I would replace: info.latitude with info.utcDateTime it is a purely formal change because it is unlikely that the latitude will remain the same in two successive NMEA sequences !!!

115 if (mLastGnssPositionValid && std::isnan(info.utcDateTime))

120 mLastGnssPositionValid = !std::isnan(info.utcDateTime);

I would make a change in https://github.com/opengisch/QField/blob/fd728fa/src/core/positioning/positioning.cpp#L145-L176 void Positioning :: lastGnssPositionInformationChanged (const GnssPositionInformation & lastGnssPositionInformation)

I would only compare utcDateTime and not the whole class: 147 if (mPositionInformation.utcDateTime == lastGnssPositionInformation.utcDateTime)

perhaps this is the reason for the high number of positions/second and it also explains why the counting of the positions used proceeds 'in jerks'!

PS I have not checked but perhaps similar evaluations can also be made when using the internal GNSS receiver.

Thank you Ciao!

[m-kuhn]

Thanks for these thoughts and ideas. In qfield we don't know which statement triggered a status update, so we cannot filter $GxGGA.

We could however treat a changed timestamp as "last information package complete", accepting that we slightly lag behind. I think that's close to what you suggest?

N.b. the internal receiver works differently and is not affected by this.

[bettellam]

Ciao @m-kuhn I made the latest changes in QGis to qgsnmeaconnection.cpp and parse.c. They will be available in QField when you are aligned with QGis 3.28. Basically for $GPGGA there are not many differences, these are changes that affect the count of satellites in use and satellites in view. The update of the status took place in the reading of GPGSV (with the QGis 3.26 only GPS) now with QGis 3.28 it will read all the constellations (GPS, GALILEO, BEIDOU, GLONASS, QZSS), it must be remedied otherwise the average becomes wrong !!

If mPositionInformation.utcDateTime is available, I am convinced that everything works out with this simple change.

[m-kuhn]

I opened a pull request for you to test in #3488 , the update to 3.28.0 is inbound in https://github.com/opengisch/QField/pull/3489