No UBX file generated | Can't process Lidar data with RS2 Base

I have 3 problems and not sure if there is any correlation. I am running the latest stable firmware. I have noticed that my RS2+ is not saving the UBX file like it should. It should be saving both Rinex and UBX but it is not (only the Rinex files).

Also, I can not process my lidar data using the RS2+ Rinex file. Inertial Labs is trying to determine the problem in the RS2 file. Has anyone else had similar issues?

Lastly, today when I setup on the site control point, the surveyor provided the coordinates they got from OPUS. My RS2+ was getting RTK from the MS Trimble network. When I was on the control point, it showed me 7’ off of the point. I called the surveyor to make sure that no errors had been made in the coordinates. He assured me the provided coordinates were good. I then went and occupied the BASE 2 control point with my RS2+ Rover. When I staked that point using both MS Trimble RTK, and the Emlid Caster RTK, both were nearly identical and I was within 1/10th of a foot.

So at the end of the day when I went back to retrieve my Base, I did a stake out again and this time the RS2+ Base where it should be.

All of these make me think something is wrong with my RS2+.

1 Like

Is it required to specify the UBX file as the primary in order for Rinex to be secondary? Based on what you see, it should save the Rinex + UBX but it is NOT. It does not save the UBX file on either my Base or Rover

These are my settings

I reflashed both units and to 31.8 (same as previous) and they are both now saving the UBX files where they were not before.

Also, the BlueTooth (beta) connectivity is now showing up which is a very nice feature!!

So I am going to say that something went wrong in the last FW update. I’m sure others have experienced some issues as well.

I will fly a lidar mission today and see if that fixed my RS2 log problems for processing the Lidar data.

3 Likes

Last post. Re-flashing both units fixed all problems. There were obviously some errors that were caused in the last FW upgrade. Not sure of anything else it could have been. Case closed :grinning:

2 Likes

Hi @MDS,

Looks like you’ve solved the logging issue yourself. Thanks for the update! I’ll report the logging issue to the developers as well.

Regarding the processing of the LIDAR data with RINEX file from Reach, what error message did you get from their software? Could you please also send us the files so I can investigate? You can email them to support@emlid.com. Thank you very much!

Lastly, today when I setup on the site control point, the surveyor provided the coordinates they got from OPUS. My RS2+ was getting RTK from the MS Trimble network. When I was on the control point, it showed me 7’ off of the point.

The observed difference of 7 feet is significant. Even with rapid static, such a low accuracy is not expected. What datum Trimble broadcast its correction? And what CRS did you use to set up your receiver? Further, what CRS the control point imported in Emlid Flow was based on? In OPUS, you can have coordinates in UTM and State Plane.

Ruth,
Inertial Labs is looking into it. I let them know that reflashing the FW fixed the problem. So not sure if they will continue to investigate.

I was setup on Mississippi West US-SF (what I use 99% of the time). It was 7 feet at the beginning but when I returned to the Base that evening to tear down and leave the site, it was very close. Hopefully moving forward all will be good.


Here is the base file that would not allow processing the Lidar data

Thanks for the sharing the file! The RINEX looks okay except for the cycle slips 15-degrees below the horizon, which is understandable.

Also, I can not process my lidar data using the RS2+ Rinex file. Inertial Labs is trying to determine the problem in the RS2 file. Has anyone else had similar issues?

One of the common reason for this is that the observation time of the base does not cover the entire duration of the LIDAR flight. If you could extract the observation time from the LIDAR data, and check it against the time from the RS2 RINEX file, that would be a good start.

If the data needs to be salvaged, I suggest downloading the RINEX file from NGS that covers the entire duration of the flight. In this way, we can also check if the issue is indeed with the RINEX file from Reach RS2 or not.

It was 7 feet at the beginning but when I returned to the Base that evening to tear down and leave the site, it was very close. Hopefully moving forward all will be good.

That is strange indeed. If you encounter the issue again in the future, please reach out to us and we’ll investigate it further.

2 Likes