Emlid

Community Forum

Getting started, multiple problems


(Chiz) #1

I am trying to get my new EMLID REACH+ units to work and am having problems. I have tried the helpdesk, but it’s not really helping.

I’m in UK. Trying to use the units to survey, using a pole mounted Rover. I want to get as accurate a survey as possible, with minimum post-processing. I have set up RTK as per the instructions as I was told this would be accurate if I left the Base up for at least an hour before initial survey.

I am struggling to get FIX, despite BASE unit being set up all day in an open field with no obstructions. FIX occasionally comes on, but then goes quickly. Rover is maybe 150m from base. Maximum.

The survey points I took when it was in Fix say they are accurate to about 20-40mm (great!) but when exported they are clearly in error -baselines are not straight, buildings are not square. The sides of surveyed trenches overlap.

Also, the Base unit just turns itself off. Still has charge, not touched it. Just turns off.

Doesn’t help that I can’t use internet on my phone to look up answers when I am conected to the Reach units.

I want to export into QGIS, where I believe I need to be working in WGS84 CRS.

Any help would be very much appreciated


(Chiz) #2

when I export the dxf into QGIS it pops up the wrong position relative to the mapping, although project and shapefile and mapping CRS are all set to WGS84


(Michael Lambert) #3

Would you be willing to share the data?


(Chiz) #4

yep, ta


(Chiz) #6

‘No matter which method you use relative position of the rover will always be cm-precise, the actual accuracy will be set by the accuracy of the base position.’

Doesn’t seem to be the case. Square structures are coming out rhomboid


(Jurijs Ješkins) #7

In WGS84 it is true for all square structures, since it is not a cartesian CRS. You should convert your coordinates to UTM, for example, or any other orthogonal CRS.


(Chiz) #8

thanks. Have converted to OSGB1936, survey points still all over the place. In roughly the correct location, but not correct relative to each other.


(Andrew Yushkevich) #11

Can I ask you to share your base+rover raw logs, please?


(Chiz) #13

sorry, been on easter holiday, back in office Monday, will sort then. Thanks


(Chiz) #14

PM sent, thanks


(Chiz) #15

Hi, did either of you get a chance to look into this? cheers


(Andrew Yushkevich) #17

@chiz, I looked into files you sent and it’s a bit hard to make a conclusion as there’re a lot of different logs. Can you share only one raw UBX base log and one raw UBX rover log?
In our docs, you can find instruction on how to download raw logs from the device.

Here’s your raw_201904021946_UBX log.
raw_201904021946.zip (4.9 MB)

If I understand right, it’s a rover. This log has a lot of cycle slips and really poor signal quality. I assume that it’s the main reason for not getting a fix solution.

Please, share 2 raw UBX logs (base/rover), 2 full system reports and hardware setup photo of the rover.
In that case, it’ll be much easier to help you with troubleshooting.

Thanks.


(Chiz) #19

thanks, what is a cycle slip? By signal quality do you mean the Lora or the satellite signals to the base? The base was in the middle of a field c150m from the Rover.
I’m on an away job without the units but will get them to you asap
thanks


(Christian Grüner) #21

Simplified, to have a good “lock” on the signal from a particular satellite, you need to have a continuously excellent signal to gain centimeter accuracy. A cycle slip is an interruption of this lock/stream.

By signal quality, @andrew.yushkevich means SNR or Signal-To-Noise Ratio, which is what you see in the Status tab in Reachview (all the vertical bars). For the fix to be trusted it should be 40 or more, though 35 will work.

The plots from RTKplot indicates really poor signal strength to a degree that I have not seen in an RS+ unit (unless covered, like inside).
Do you have a picture of your setup and environment you can share with us ?


(Chiz) #22

Thank you, the base was in the middle of a field, no photos sadly, there was nothing above unit level on 75% of circumference, some trees c 100m away on 25% of circumference. Only sky above!


(Christian Grüner) #23

But the file that is problematic seems to be the rover rs+?
I don’t have access to your base log.
Both need excellent receiver-conditions to be centimeter precise.


(Chiz) #24

the rover was also outside, c150m from Base. Theer were some trees in between, but no buildings (but that shouldn’t matter anyway if it is on Lora?). I’ll try and get the logs when I am with the units


(Chiz) #25

It would occasionally get Fix, but only for very short periods (less than a minute). The Base was up all day


(Christian Grüner) #26

Correct, lora doesn’t matter when doing postprocessing.

Given the SNR of your rover, the fixes you have seen are very likely false fixes.


(Chiz) #27

thanks, what is a ‘false fix’?

If the Base unit is set up with excellent sky, and is up all day, why the bad signal?