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’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.
I will try it also on one of the receivers with the v2.16.2. These tests are performed under identical external conditions, the same smartphone (android), mobile wi-fi, the location of the receiver.
Maybe it would be worth comparing the settings. Can you share your ‘Simple report’ or compare with those ‘Full reports’ that I sent directly to EMLID? The details of the data stream can also be relevant here (RTCM messages from the correctionn provider).
It is worth finding the reason, because other users also report it. It can be outside of the receiver. This also can not be ruled out.
I have done several initialization tests in several places and I have full confirmation that the initialization for version 2.16.0 takes place in such locations about 30 seconds and never exceeded 40 seconds.
The test was on the ReachView 2.16.2 application, i.e. I made this upgrade from 2.16.0, which you mentioned. The tests were carried out only on the RTN4G_VRS_RTCM32 stream, but it is known that there is a Beidou limitation if GLONASS.
I moved with the receiver turned on, located on the trunk of the car. Before each measurement, I turned off the receiver ‘Reboot’ by default. This was to determine the initialization time, i.e. without the time to run the application. These 30 seconds (epochs) to fixed are exactly what’s in the U-blox cold start GNSS engine specification, for the M8N.
Thus, it completely confirms the technical assumptions of the receiver.
It is important, therefore, that this development version 2.17.3 retains these elements from 2.16.2, because for the same settings the receiver did not provide ‘fixed’ solutions at all. Have your tests been from RTCM3.2 or RTCM3.3 caster?
Did anything change with 2.17.3 that would impact the Ethernet over USB connection? After I upgraded, the device no longer shows up in my Device Manager on Windows. I managed to login over WiFi and ensured that rndis was set by running:
fw_setenv bootargs_ethconfig rndis
and rebooted, but that didn’t fix the problem.
Here is the output from modprobe -c | grep multi
root@ReachGCS:~# modprobe -c | grep multi
options g_multi removable=y stall=0 idVendor=0x8087 idProduct=0x0A9E iProduct=Edison iManufacturer=Intel
options g_multi ethernet_config=rndis
options systemd unit=multi-user.target
options g_multi iSerialNumber=1ad45deddee80ddcd11ccb6e4c587f38
options g_multi dev_addr=02:00:86:58:7f:38
and ifconfig usb0:
usb0 Link encap:Ethernet HWaddr 02:00:86:58:7f:38
inet addr:192.168.2.15 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Merrifield device shows up briefly in the device manager, but the RNDIS device never shows up under Network Adapters like it used to. I reinstalled the Intel Edison Ethernet over USB driver, but that didn’t affect the problem.
Couple off minor issues. Not sure its RS related only but thats where i found it. RS 2.17.3
-Base mode. Not possible to set a value below 1. E.g 0.123 (the dot or value disappears when setting antenna hight)
-Using www.rtk2go.com, it is not possible to resolve DNS and you are forced to use IP address. Reachview kind of hangs when you type the name, but with IP address it settles fast.
Not sure if its related to Reach or the rtk2go service