Why my rover die alone
Maybe it wanted to be promiscuous instead of marry?
Yesterday I did two simultaneous tests with EMLID v2.17 and Promark 3. In EMLID I had only 3 green bars and a very high PDOP in the fieldgenius 10 trial version and in the Promark 3 I had PDOP less than 2 While in the moment that the PDOP indication in fieldgenius worked it started in 3.1 until it reached 13 and the Promark 3 only indicated 1.8 of PDOP with only GPS constellation. In the application of my IPhone 7 the indications are fixed but only three bars of satellites in green, the PDOP indication could be included to the next versions. I do not know what will be happening with EMLID and fieldgenius with these PDOP variations high or does it indicate zero?
What’s fixed in ReachView v2.17.2? updated or not?
v2.17.2 has been pushed, fixing the correction input issue!
v2.17.3 has been pushed, fixing an issue with dropdown bars getting stuck on mobile devices.
Versions 2.17.2 and 2.173 are not stable. The iterative process of convergence (initialization) has been completely downgraded - it lasts for a dozen or so minutes while in version 2.16.0 it is two or three minutes. I am talking about using NTRIP casters for RTK, i.e. Reach as ‘rover’ only.
Is it possible to return to the initialization module such as in version 2.16.0 or 2.16.2, possibly entering the stable version 2.17.4?
Is it really like here?:
“… the dev updates will not revert.ReachView version back to stable. You will be prompted to update to the next stable version as soon as it is released.”
RTK engine was not affected by this update. Would be great if you could share solution logs recorded on v2.17.3 and v2.16.2 showing the behavior you described.
I do not know what happened. ‘Simple system report’ is too simple. And a few days ago they were complete. I can send full reports but not through this thread (too sensitive)…
"Simple system report"
app version: 2.16.0-r0
‘wifi_status, interface: wlan0’:
- wifi_mode: wpa_supplicant
- ip: 192.168.0.185
"Simple system report"
app version: 2.17.3-dev-r0 'wifi_status, interface: wlan0': - wifi_mode: wpa_supplicant - ip: 192.168.0.94 is_connected: true mac_address: fc:db:b3:92:bd:f8 ssid: UPCBAE5EB6 None```
You can send it to email@example.com or via PM here.
upgraded to v2.17.3 from 2.17.2. Age of differential keeps increasing when using Lora. Age of differential time does not update properly.
Full reports have been sent.
Hi, are you sure this is related to the update?
Could you describe setting used on Lora (base setting and Hz) and distance between rover/base used?
Base Settings: Frequency 868.0 Mhz; Output Power 20dbm
GPS 1 Hz
ARP Station Coordinates 0.1 Hz
GLONASS 1 Hz
Distance between rover/base is around 40 meters
And RTK setting on rover?
I’ve made a test and can’t confirm this issue.
I can assume that you might have the wrong settings or bad environmental conditions.
Can you share your raw logs and full system report, please?
I have completed dozens of tests of receiver initialization with versions 2.17.3 and 2.16.0.
All of 2.16.0 were OK. Initialization to ‘fix’ lasted from 1 to 2 minutes.
Only a few with version 2.17.3 had such results.
This version is not stable. The bug is probably in the beginning. Version 2.16.0 always starts initialization with GPS + GLONASS and version 2.17.3 does not include GLONASS at the beginning, although it is ON.
This is clearly visible in the logs.
v2_16_0_solution_201903151639_ENU.pdf (266.5 KB)
v2_17_3_solution_201903151731_ENU.pdf (428.3 KB)
I already downgraded to v2.16.0. Will do test today if the problem persist. Maybe my lora is broken.
If age of differential is increasing, then compensate by one of the following:
- increasing LoRa bitrate
- disabling RTCM3 message(s)
- slow down the rate of RTCM3 message(s)
I’ve tried to reproduce your issue without success.
- reflash 1st unit with 2.17.3
- reflash 2nd unit with 2.16.2
- turn them on and don’t change any default settings
- fill in NTRIP info, hit apply
- wait for a fix, compare time and solution logs
I got fix status in around 2 min on both devices with not the best possible NTRIP caster and satellite view.
In the solution file during some test I can see the same behavior but with 2.16.2.
As we didn’t change anything in RTK engine, I can assume that it’s mostly connected with NTRIP caster and not ReachView version. However, I’ll look into it.
Thanks for your tests and time