You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the contribution made in #5381, a new API was introduced in the PositionService interface, to retrieve information regarding the GNSS System Type used to get the position information.
Both PositionProviders (Serial and GPSD) retrieve this information, but in different ways.
1. Serial provider
The serial provider looks directly into the NMEA sentences: each of them represents a particular set of position information and is associated to a specific tag.
This tag is composed by two parts: the first one is the Talker ID, so the code that represent the GNSS System that supply that information, the second is the Sentence tag, representing what kind of information the sentence is proposing. For example, if a GPS System is supplying the Geographic position, latitude and longitude (and time), the sentence will have tag $GPGLL because the GPS Type is coded into the GP acronym, while the information is named GLL.
From the implementation POV, the Serial Position Provider implements the new API by extracting the System ID from each NMEA Sentence and building the Set of GNSSType that are providing the data (may be zero, one or more systems depending on how many different IDs are found in the NMEA sentences list). This Set is continously updated inside a time windows of 50 sentences: after that the Set is cleared and the accumulation of information is restarted to ensure having a GNSS Type information which is always updated (for example: if the device received one different TalkerID in 6 hours of GP data monitoring, we can say that the used System is GPS and not both of them just because I received one sentence 5 hour ago).
2. GPSD
The GNSS Type is extracted from the GPSD SKY sentence, which contains information about the portion of sky that the device can see. This sentence contains also the list of satellites the device can see: each satellite is wrapped in a Satellite Object containing (among the many information) some valuable fields like PRN, gnssid and used. The first one represent the GNSSType of the satellite, while the second one if the satellites is used or not to calculate the position. More info are available in the gpsd docs.
To parse the GPSD infos we use the GPSJD4Java library, that has a SKYObject wrapping the SKY sentence, which includes a SATObject containing the satellites information: from the link it can be noticed that the library is missing the gnssid information, but says that from the PRN is possible to retrieve the same information (but only for GPS, GLONASS and SBAS, other satellites will be represented by OTHER value).
PROBLEMS
Information inconsistency
There is not always consistency between the two data: indeed, from the GPSD provider we can get just a general information about the satellites in the sky which are visible and used, but nothing is known about the single position information. The Serial provider is not affected by this problem, as we can always extract the ID from the NMEA tag to retrieve the GNSS System used to get the punctual data.
For this reason, it could happen that the Serial provider information is different from the GPSD one, using the same device: indeed, while the GPSD may say that the GNSS Systems used are GPS and GLONASS (because the satellites are visible and used), the Serial provider will notify the usage of the GPS only, because the GLONASS satellites may be used for some reason, but at the end the specific information is coming from GPS only (NMEA Sentences whose tags are $GP+TAG).
GPSD lack of representation
Only 3 Systems are clearly represented by the GPSD4Java lib: GPS, GLONASS, SBAS. All other satellites will be represented by the GNSS Type OTHERvalue. This means for example that satellites different than those will be always referenced by the same value, with a lack of affidability.
GPSD4Java seems to be not mantained
The last commits of the repo are really old (couple of years ago) and it seems to be no more mantained. We open an issue in the repo to ask for information about the gnssid and the SATObject, but no one is replying.
CONCLUSION
We can say that currently the Serial Position Provider is the more reliable provider to retrieve infos about the GNSS System Type. We can also affirm that usually the GPS and GLONASS systems are the more used, so also the GPSD provider may be sufficient to get the information. It's up to the user choosing the provider that best fits its needs.
We could make a contribution to the GPSD4Java library, but again the SKY Sentence is representing information about the portion of visible SKY, so it could be not improve the single position data gnss type information.
Expected behavior
At least a consistent information about the GNSS Type among different providers.
Additional context
When this bug was firstly opened, the last release is Kura 5.5.0, but the contribution is done in 5.6.0 which will be the next release.
The text was updated successfully, but these errors were encountered:
After the contribution made in #5381, a new API was introduced in the PositionService interface, to retrieve information regarding the GNSS System Type used to get the position information.
Both
PositionProvider
s (Serial and GPSD) retrieve this information, but in different ways.1. Serial provider
The serial provider looks directly into the NMEA sentences: each of them represents a particular set of position information and is associated to a specific tag.
This tag is composed by two parts: the first one is the
Talker ID
, so the code that represent the GNSS System that supply that information, the second is the Sentence tag, representing what kind of information the sentence is proposing. For example, if a GPS System is supplying the Geographic position, latitude and longitude (and time), the sentence will have tag$GPGLL
because the GPS Type is coded into the GP acronym, while the information is named GLL.From the implementation POV, the Serial Position Provider implements the new API by extracting the System ID from each NMEA Sentence and building the Set of GNSSType that are providing the data (may be zero, one or more systems depending on how many different IDs are found in the NMEA sentences list). This Set is continously updated inside a time windows of 50 sentences: after that the Set is cleared and the accumulation of information is restarted to ensure having a GNSS Type information which is always updated (for example: if the device received one different TalkerID in 6 hours of GP data monitoring, we can say that the used System is GPS and not both of them just because I received one sentence 5 hour ago).
2. GPSD
The GNSS Type is extracted from the GPSD SKY sentence, which contains information about the portion of sky that the device can see. This sentence contains also the list of satellites the device can see: each satellite is wrapped in a
Satellite Object
containing (among the many information) some valuable fields likePRN
,gnssid
andused
. The first one represent the GNSSType of the satellite, while the second one if the satellites is used or not to calculate the position. More info are available in the gpsd docs.To parse the GPSD infos we use the GPSJD4Java library, that has a SKYObject wrapping the SKY sentence, which includes a SATObject containing the satellites information: from the link it can be noticed that the library is missing the gnssid information, but says that from the PRN is possible to retrieve the same information (but only for GPS, GLONASS and SBAS, other satellites will be represented by
OTHER
value).PROBLEMS
There is not always consistency between the two data: indeed, from the GPSD provider we can get just a general information about the satellites in the sky which are visible and used, but nothing is known about the single position information. The Serial provider is not affected by this problem, as we can always extract the ID from the NMEA tag to retrieve the GNSS System used to get the punctual data.
For this reason, it could happen that the Serial provider information is different from the GPSD one, using the same device: indeed, while the GPSD may say that the GNSS Systems used are GPS and GLONASS (because the satellites are visible and used), the Serial provider will notify the usage of the GPS only, because the GLONASS satellites may be used for some reason, but at the end the specific information is coming from GPS only (NMEA Sentences whose tags are $GP+TAG).
Only 3 Systems are clearly represented by the GPSD4Java lib: GPS, GLONASS, SBAS. All other satellites will be represented by the GNSS Type
OTHER
value. This means for example that satellites different than those will be always referenced by the same value, with a lack of affidability.The last commits of the repo are really old (couple of years ago) and it seems to be no more mantained. We open an issue in the repo to ask for information about the gnssid and the SATObject, but no one is replying.
CONCLUSION
We can say that currently the Serial Position Provider is the more reliable provider to retrieve infos about the GNSS System Type. We can also affirm that usually the GPS and GLONASS systems are the more used, so also the GPSD provider may be sufficient to get the information. It's up to the user choosing the provider that best fits its needs.
We could make a contribution to the GPSD4Java library, but again the SKY Sentence is representing information about the portion of visible SKY, so it could be not improve the single position data gnss type information.
Expected behavior
At least a consistent information about the GNSS Type among different providers.
Additional context
When this bug was firstly opened, the last release is Kura 5.5.0, but the contribution is done in 5.6.0 which will be the next release.
The text was updated successfully, but these errors were encountered: