I agree with Christian on this. Dev versions are designed to deliver the new features faster. This means that they are not tested long enough to guarantee it will work flawlessly. So it’s better to avoid using them for crucial surveying work.
These changes will be merged into one of the next stable versions after more thorough tests. The stable version will be fine to use for any kind of job.
We ended up on the dev route as it fixed some features for us at the time. I updated today to try and solve the Wi-Fi issue which appears to have worked, it connects to either the phone hotspot or office router every time now. But… where’s the logging option gone in RV3? I had to use RV2 to access the logging screen which is a pain as the approximate locations of the GCPs are imported into RV3.
Thanks for your feedback. We’re quite excited, too. And we hope that this feature will be useful.
“The output rate for NMEA must be lower than the output rate for RTK”
Is this same as or lower? 5hz rtk for 5hz or 1hz NMEA?
Or is it 10Hz RTK, for 5Hz NMEA?
Our interface shouldn’t let you misconfigure the device and will give you a warning in case something’s up. It looks like you stumbled upon one.
So The rule of thumb here is that the rate at which the NMEA is getting our of the device should be equal to or lower than the rate set in the RTK Settings. So 10HZ RTK and 5Hz NMEA should work just fine.
I agree with the “wish winter would leave” part!!! As a former Michigander that moved to Texas about 17yrs ago to escape winter, you can have this winter stuff!! I blame it on the Canadians, I think they left their refrigerator door open!! :smile Though we should be in the 60-70’s F. next week!
Today I was in the field and did my first test with legacy RTCM3 messages.
The result was not good for me.
Besides emlid M2 I have two other gnss receivers, one legacy novatel oemv gps+glo and one new hemisphere gps+glo+gal+bei.
Neither of the two receivers were able to fix with RTCM3 messages. In fact both receiver stayed single or autonomous. I had the same problem with the stable firmware and msm4 messages with hemisphere receiver.
The workflow is to set the emlid M2 base to send the corrections to the emlid caster and the rover(s) connect to the caster.
A second test in another site was almost successful.
In this test I was using the emlid as base station and the novatel also as base station. Both base stations was sending the corrections to the emlid caster. Then i used the hemisphere as rover and was switching between bases to check the behaviour of the rover. The rover worked as it should with novatel base but not with the emlid base. With the emlid base the rover was reporting single solution. Then i was messing with the legacy messages of the emlid and at some point it managed to fix only with msm4 messages but never with legacy rtcm3.
Then rebooted the emlid in order to do the workflow from scratch and the rover didn’t work this time even with msm4. It stayed single.
So I think that there is some stupid bug on the data emlid sends that doesn’t allow 3rd party rover(s) to receive the corrections properly. With the stable firmware I had also a couple of successful connections between emlid base and 3rd party rover but most of the time it was unsuccessful.
I’ll wait other users to report their experience and i hope to solve the mystery!!