Test 2.22.1 shows that restrictions have been introduced for the NMEA data stream in ‘Output’ by BT. It seems that for each of the systems (GPS, GLONASS, Galileo) the output is performed only for a maximum of 4 satellites. In previous versions this restriction was not there. I explain this in an example:
The problem was detected for Reach RTK.
Is it possible to restore this possibility, which was in previous stable versions and is important for using processing with NTRIP?
Thanks for the report!
We’ll try to reproduce this issue and get back to you as soon as possible.
I’m afraid I couldn’t reproduce this issue.
May I ask you to record the NMEA position log on your device and share it with us?
I would like to point out that adding the ZDA NMEA message to Reach View v2.22 apps complicates its use.
These two attached files show the problem. By using the program NMEA GPS monitor for Windows. NMEA.EXE Ver3.73 February 2020 © 4river you could see the difference.
Log with ZDA (2020-02-08)
Without GNZDA, earlier versions of Reach View (2018-08-24)
I suggest alternative paths or like here.
The key difference is that
GPRMC (recommended minimum specific GPS/Transit data) is only sent after GPS has a location whereas
GPZDA is sent as soon as the time is received from a satellite. You will get time when the signal is too weak for fixed solutions, enough for float only.
This is what this example is for:
If you ignore the check-sum option:
It would be good to check whether the improvment by addition of ZDA NMEA affects other parts in the Reach View algorithm since version 2.2.2, especially in the case of an iterative procedure for obtaining established solutions. It should not affect, because these operations are from the u-blox binary raw data but initialization procedure in newer versions is more difficult. Maybe is it the case of lack of more precise time synchronization at start-up.
Gives probable mistakes in NMEA. „Check-Sum Error”.
solution_202002141159_NMEA.zip (639.3 KB)
Please also check if these values PDOP HDOP and VDOP are correct.
The „Check-Sum Error” probably causes that the external programme to picking given reads only 4 satellite from individual systems (4 - GPS, 4- GLONASS, 4- Galileo).
I ask to confirm that Emild analyses the problem NMEA „Check-Sum Error”
Sorry for the delayed response!
Thanks for pointing out this issue. We’re checking the output at the office and will get back to you with the news.
He thanks for the answer.
In the enclosure the additional data on the confirmation of the problem.
Reach View 2.23.1
solution_202002200819_NMEA.zip (730.6 KB)
ReachView v2.23.2 he still appears “Check-Sum Error” in the data NMEA
You have for me the solution of the problem?
My suggestion to you is to check the Reach View is not mistaken in one of its implemented components with zenith elevation (precisely: zenith distance, zenith angle) instead of the elevation mask.
‘Zenit elevation’ is equal to 90 degrees minus the "elevation mask ".
Hence, probably such a small number of satellites as visible.
I think that the Zenith elevation is not the cause. The data is taken only from the 2 of poems $ GPGSV. Satellites are sorted according to numbering and not the Zenith elevation.
Sorry it took so long to get back to you!
We can confirm there’s an issue with checksum in the latest ReachView. Shortly we’ll post more specific information on it and on the release of the fix for it.
Thanks for the answer. Can you write the exact deadline of the introduction of the correction?
The issue with the incorrect checksums was fixed in the v2.22.3 update. You can check other fixes in this community forum thread.
Thank you for fixing the problem. I checked. It is now correctly in our external application.
2.22.3 is Stable or Dev ?
I thank Polina for the solution of the problem. I confirm that ReachView v2.22.3 works correctly