We have a similar problem with no fix with NTRIP even after an hour. Today we used GLONASS AR, so we’ll try that off next time to see if it work, but I’m uploading the raw log and simple in case there is anything else that could be improved in our settings since we have rarely been able to get a fix solution. Any additional suggestions would be greatly appreciated.
Simple system report
app version: 2.11.0-r0
'wifi_status, interface: wlan0':
- Client state
- IP address: 192.168.1.119
mac address: 90:b6:86:00:0c:c7
base mode:<a class="attachment" href="/uploads/default/original/2X/0/013840961e59b259c466df64a50de1e1a93f69de.zip">raw_201806251712_UBX.zip</a> (4.2 MB)
send position to base: single
air rate: '18.23'
output power: '20'
elevation mask angle: '15'
glonass ar mode: 'on'
gps ar mode: fix-and-hold
max horizontal acceleration: '1'
max vertical acceleration: '1'
positioning mode: kinematic
snr mask: '30'
update rate: '1'
Could you attach a raw log please?
raw_201806251712_UBX.zip (4.2 MB)
Here it is - this is from the field, the system report I generated was once we were back in the office.
As I can see from your raw log, there is a poor satellite visibility in the area where you’ve tested. In what type of environment did you test your Reach? Did you use Reach or Reach RS? What is the distance to the reference station you are using?
The area is very open without tree cover or buildings within a couple kilometers distance. These data were collected with Reach RS. The distance to the reference station is 9.602 km.
Have you already tried surveying with Glonass AR mode off? If yes, how was the result?
Please make sure there are no sources of interference around the receiver.
You can also try the latest ReachView v2.13.0 dev version, it allows to use GLONASS AR with non-Reach bases, such as NTRIP casters.
raw_201807051741_UBX.zip (777.5 KB)
Here is our log with Glonass AR off. The solution remained “float”. We will try the v2.13.0 dev version and see if that provides a fix solution.
Hello. Do you have another hardware? Like satlab, leica, topcon?
We have and they get fix at once where the emlid doesnt.
Guess the lack of L2-band is the explanation.
This log is better than the previous one. Could you also please share base station log so we can see what’s happening during post-processing?
Also, let us know about your tests with v2.13.0.
base_201807051741_RTCM3.zip (200.5 KB)
Here is the base correction file. We were using the same NTRIP correction from 9.6km away. We will be going out tomorrow again and will test out v. 2.13 and upload the logs.
Thanks for sharing the log, will look into it.
Please let me know about your tests with the latest dev update.
base_201807111404_RTCM3.zip (953.9 KB)
raw_201807111404_UBX.zip (4.5 MB)
It did much better with version 2.13 - for the first time we were able to get a fix solution which held for nearly the entire survey!
I’ve post-processed your logs and the solution is getting better.
However, according to the rover raw log, there was a poor satellite visibility again. I’ve attached the screenshot from RTKLIB, so, as you can see, the log contains a lot of cycle slips which’s not good.
Could you share the photo of your Reach RS setup in the field? Do you use survey pole?
Thank you - our pole is 1.67m tall. I’ve sent a photo via PM.
Did you have time to do more tests?
I hear would cost too much for Emlid to create a unit utilizing more than just L1… but just out of curiosity…what is the main cost restrictive factor to do so? Don’t mean to go off the topic here, but just curios is all the main thing simply that holds this back. Is there some sort of fee or something involved to use anything more than L1 on the satellites? Or technology-wise cost restrictive?
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.