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!
Being a Canadian, as much as I hate Winter, it makes me appreciate Summer that much more. Plus it syncs up all the plants to turn vibrant green all at the same time.
It also gives you time to invent things, because its so dark and cold even math seems fun! Because its indoors!
I guess this is why Russia invents so many things.
I can see that we’ve in touch over the connectivity issues you’ve experienced in this community forum thread. Please keep us updated on your further tests with the latest Beta release there.
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!!
This is a duplicate post as it pertains to both this thread and the Legacy RTCM3 messages
Not sure the changes are working correctly. I tried to connect my M2 with my Trimble unit by taking out my Arduino 1008 injector. I could not get my monitor to go fixed with either all legacy output or MSM4 and message 1008.
I changed everything back to MSM4 and added my 1008 injector back in and still couldn’t get fixed. I have been racking my brain on it for almost three hours.
Tomorrow night, I will do a test with M2 version 2.24.2 and my 1008 injector and see if it goes fixed. If so, then there is definitely an issue with the BETA software.
There was one thing I did notice on SNIP that I do not recall seeing before this update. Once connected and parsed in the past it just said RTCM3. Tonight with the Beta software it made mention of UBlox F9P.
I know there are several sites that state “Do not mix new with legacy” perhaps there is a lot of truth to that.
I didn’t get a chance to mess with the talker changing from GN or GP. I wouldn’t think that has anything to do with it as that is NMEA not RTCM but who knows in a Beta. If nothing else, please keep the option of selecting what NMEA messages you want to output.
Connected to a hi target as rover, shows connected, and it even shows the coordinates of the base and the distance from the rover but rover just shows single solution
I reverted to 2.24.2 hooked everything up and now the system I had working is not. I did two things to double check my radio setup. First was having a receiving radio on my laptop connected to SNIP. It showed the correct data stream. When connected to my monitor, it still wouldn’t go fixed.
Then I used Lefebure NTRIP for windows. I connected one of my RFD radios to my laptop (COM30) and used OH CORS RTCM data stream out COM30 which connected to my 3DR on the Monitor. It went fixed immediately. This tells me it isn’t a radio connection problem.
Could there be any residuals from 26.1 on it still? If so, is there a “hard reset” that can be performed?
I know M2 base is talking to my monitor. In order to check this, I have my M2 setup a new base via 1 minute average with no corrections. Once it completes the average and the base is enabled, the Trimble monitor has a popup message appear “Base station has changed”. It just isn’t able to utilize the data for some reason.
This behavior is rather strange. We’d like to investigate why you’re facing the issues with Fix while using the legacy messages.
@vgo195, @joraybgo67, could you please share what messages you were sending from your Reach base? Would it be possible to send the base correction log recorded on the rovers in RTCM3 so that we could check it? Position logs and raw data logs will be of help for us, too.
@jp-drain-sol, could you also share the base correction log from your rover when Reach was on Beta version? Do I understand correctly that the revert back to your previous setup without the legacy messages from the Reach is not working properly?
After rereading the thread once again, I’ve got a couple of more questions.
@jp-drain-sol, could you please share the RTCM3 log when the base is on v2.24.2 as well?
Does the rover calculate the solution when your Reach base is on 26 beta 1 but with the injection of the 1008 message? This will help us to narrow down the issue with the messages as it’s hard to determine why it might happen for now.
I did some testing last evening before I read your replies.
First was on version 2.24.2, I did get it working using my Nano 1008 injector and the original base messages. Sorry I forget the numbers, I was using Arp at 1 Hz, GPS at 2Hz and GLONASS at 2Hz. I do not enable the others as my Trimble monitor doesn’t have their capability.
At first, I couldn’t get fix. I had it set as I had previously with ARP at 1 Hz and GPS/GLONASS at 5 Hz. It would go go fix but, not reliably, the correction age would clime then go Float/DGPS. I started testing different parameters to see what worked best. Eventually, I found the 1/2/2 Hz gave me the most stable fix. I should mention that my Trimble monitor (FMX) is GLONASS enabled but I realized last evening that in RTK, it isn’t utilizing the GLONASS corrections. It might need the legacy for GLO. I was only tracking 8-10 satellites and should have had 16-18 with GLONASS
After getting it to connect reliably, I again updated to 26.1 I first tested with the stable working conditions and it went fix, no problem. I then disabled all of the normal messages and tried enabling all of the legacy messages only. It dropped fix and did not go fixed for over 5 minutes. I should explain, the Nano injector will pass through all messages and only inject the 1008 if 1006 is present. I changed back to the working config and it went fixed in less than 45 seconds.
Separating logs on the FMX is kind of a pain. I will clear all logs and do more testing so I can get the data needed.
Another option would be to enable the 1007 message. I have attached a screenshot from SNIP. these are the messages that OH CORS put out on their RTCM3 stream. I know the only one you cannot enable in your DEV would be the 4094 as that is a Trimble Proprietary message.
By the way, I did notice that the M2 is transmitting something via the serial port even before the base has averaged and starts sending corrections. I know this as the lights on my RFD900 and Nano were blinking TX during startup of the M2.
As there’s a lot of information, let me separate the configurations that have been tested so that we can clearly see them. Please feel free to correct me if something is amiss.
The first test:
M2 on v2.24.2
enabled MSM4 messages
injected 1008 message
This gives you Fix on your rover.
The second test:
M2 on 26 Beta 1
enabled MSM4 messages
injected 1008 message
This gives you Fix on your rover.
The third test
M2 on 26 Beta 1
enabled legacy messages 1004, 1008, 1012
This doesn’t give you the Fix on the rover.
If I understood the previous configurations correctly, then it’ll be really helpful to check the following setups as well:
The first setup
M2 on 26 Beta 1
injected 1008 message
enabled 1004 and 1012 legacy messages
The second setup
M2 on 26 Beta 1
enabled 1008 message
enabled MSM4 messages
Would it be possible for you to check the two configurations above and share the results with us? They will help us to narrow down the issue so that we can see the possible reason for such behavior.
Though we should be in the 60-70’s F. next week!