Hi Michael,
I’ll need more info about the point collection to see what can be wrong. How did you collect the points? Were they stored in the same ReachView 3 project?
Hi Michael,
I’ll need more info about the point collection to see what can be wrong. How did you collect the points? Were they stored in the same ReachView 3 project?
The points were RTK from the network with a 30 second collection using Reachview 3.28 beta 3. Here’s the full system report.
Rover2-RS2_ReachRS2_20211203_SystemReport.zip (2.2 MB)
This should have been the last project I shot.
Hi Michael,
Do I get it right that you collected points for different walls in the same project, and now this project contains only points for walls 2-5? Also, please tell me if you work with an Android or iOS device.
Correct. I am using a Pixel 5 with Android 12. Points 100-175 were wall 1 and they just disappeared at some point between finishing wall 5 and doing the export. Walls 2-5 show all of their points.
I think the UBX-looging need to be more explicit yet after the recent change:
Hi Michael,
Thanks, got it! I’ve reached out to you in PM, as I need some sensitive info for further troubleshooting. Let’s continue our discussion there.
Hi Christian,
Logging settings don’t change after a reboot, so there’s no need to worry about it
Otherwise, sounds pretty fair to me. We’ll think about it!
I would say one has to always check. Software is not perfect, neither is human memory.
Assumption is the root of evil here.
Assume, It makes an A** of u and me. LOL
There seems to be a bug that RTCM log are not saved, and maybe even existing RTCM log being deleted, when the device is out of memory, when unit set to rolling logs?
Hi Christian,
If the rolling logs option is enabled and Reach is out of memory, it should overwrite old logs with the new ones. If it works another way, please describe what happens in more detail or share a screencast. Also, please send a Full System report from your unit to support@emlid.com. We’ll find out what’s going wrong.
A quick question about this again:
I checked the final 28.1 version and the green LED stayed as in the beta versions.
Is this the way it will be going forward? Or is this maybe still subject to change?
I would have to educate some clients/Users that the green LED does not show GNSS/Timesync availability anymore. (But will probably stay on the version before as long as possible for this).
Hi @goamberg,
We’ve decided to keep the indication as it was in the Beta. Now, the green LED becomes solid once the unit can be accessed in the app.
Sorry to bring this up again, but it messes really with the workflow for me and my clients about when the system is “somewhat” ready
Would it be maybe possible to do some in between like with the Wifi settings?
rapid flash green is setting up
normal flash is ready for download
solid green is when download is ready and timesync is done via satellite or internet
would already be a big help
goam
Hi Goam,
We really want this indication to be straightforward for you and your clients. So, here’s our solution. The green LED will blink until time sync is passed. Still, you will be able to connect to Reach in ReachView 3 even if the LED blinks.
I can’t share any exact dates for this update, but I don’t feel it will take too long. I’ll let you know once it’s out
Hi Goam,
Just released the 28.2 firmware with the updated indication Would be great to know how it works for you!
hi
Took some time, because we were in the field.
I updated directly to 28.3 and LED is what it used to be again. Thank you!
I was already scared about retraining our clients about this.
What I dont look forward to now, is to update all the receivers… and there are many
Hi @goamberg,
Glad to receive good news! Hope it won’t take too long to update everything
A post was split to a new topic: Can’t connect to the receivers
A post was split to a new topic: Need to change the frequency after each reboot