ReachView v2.17.6 dev release

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:
    is_connected: true
    mac_address: fc:db:b3:95:7c:61
    ssid: UPCBAE5EB6
"Simple system report"
app version: 2.17.3-dev-r0
'wifi_status, interface: wlan0':
- wifi_mode: wpa_supplicant
- ip:
is_connected: true
mac_address: fc:db:b3:92:bd:f8
ssid: UPCBAE5EB6

You can send it to 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

Distance between rover/base is around 40 meters

And RTK setting on rover?

Hi @Bunog,

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.
RTN method.
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.

General rule:

If age of differential is increasing, then compensate by one of the following:

  1. increasing LoRa bitrate
  2. disabling RTCM3 message(s)
  3. slow down the rate of RTCM3 message(s)
1 Like

Hi @r.pazus,

I’ve tried to reproduce your issue without success.
My steps:

  • 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 :slightly_smiling_face:

1 Like

Hi Andrew!

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?


Because the world is now pictorial I present the problem graphically :smile:
RTCM 3.2 needs unlocking the fourth GNSS service on ‘RTK Settings’. ie. Beidou with GLONASS together.
A request to the EMLID team to test. :smiley:

Thank for all tests, detailed reports and pics :slightly_smiling_face:
I’ll look into it and provide my comments as soon as possible.

1 Like

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
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: Bcast: Mask:
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
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.

According to this article
I should see lines like:
[ 5.145231] g_multi gadget: g_multi ready
[ 6.337976] g_multi gadget: high-speed config # 1: Multifunction with RNDIS

Is it possible that RNDIS support wasn’t provided or is broken in this release?

Any news @andrew.yushkevich ?

have tests been conducted?

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, 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

1 Like

have tests been conducted?

1 Like