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+.
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
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
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.
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.
I have the same problem. One of my logs doesn’t have UBX file only Rinex. I have firmware 31.8 The only difference between situations of using Reach 2 + is that it recordet UBX file when I connected to it by android app. The UBX file was not saved when I only powered on Reach RS2+ and it was working for 1 hour and I did not connect anything to it just turn it off after hour.
Do you mean the UBX file is not being recorded when you use the auto-recording feature? On the other hand, if you manually start the recording, the UBX file is saved?
Did Inertial Labs say anything about why there was a processing error when you were using the RINEX files from Reach? Did they figure out what’s causing the issue?
Also, does it only happen when you provide the RINEX files from Reach, or does the issue persist even with the converted UBX to RINEX?
This does not happen on short observations. But on longer observations (ie 3-4 hours) it occurs every single time
If you decimate the RINEX file to reduce the quantity of the data, do you still have the same error? One theory is that the software couldn’t handle large amount of data so it crashes.
I have my unit set to Autorecord Data. I also have it set to record both UBX and Rinex. But when I do longer observations ( 2-6 hours) there is NO UBX file. Never. If I do a short 15 minute observation there will be both ubx and rinex. I use an iphone but that should have no bearing. I am running the latest stable software what ever that is.
Sorry, I misunderstood your previous reply. I’m going to test it and try to reproduce the issue with the missing UBX when it’s recording for more than 3 hours. I’ll keep you posted!
Was this option enabled in Flow? I checked, and if you enable the “Backup source data for RINEX” option, this option will still be enabled even after restart.
I’m going to test too if autostart log recording without connection to Emlid flow results in missing UBX files even if the option to record UBX is enabled.
