as far as I know Hemisphere P40 works with any message type RTCM3, RTCM3.2, MSM etc.
It is a 2020 board so I think it will work with every message type.
As far as GetBlue is concerned i think i have found an alternative solution that works. So you can ignore the GetBlue related question.
Thanks again for your help.
Have you tried to switch base and rover roles? I mean connect Hemisphere as a base to Emlid caster and receive corrections on Reach M2.
No I haven’t done this yet. It is in the to-do list.
Please keep me updated on the results.
I have some news. I managed to send the corrections of another base station to the emlid caster and the hemisphere p40 receiver worked right away. It fixed the solution in a few secs.
So to sum up:
- COORS base station (MSM3) —> Hemispere rover ----> WORKS
- Local base station (novatel oemv gps+glo legacy rtcm3 —> Emlid caster —> Hemisphere rover —> WORKS
- Emlid M2 base station (MSM4) —> Emlid caster —> Hemisphere rover —> DOESN’T WORK (rover reports single solution)
The last test I can do is to update the M2 with the latest dev firmware that supports legacy RTCM3 messages and test it again as base station.
Yes, I had an assumption that Hemisphere may require legacy RTCM3 messages like 1008 to operate. It would be very helpful if you could try the 26 Beta 1 that supports legacy RTCM3. However, please note that Beta versions are mostly used for testing purposes.
unfortunatelly I am experiencing the same behaviour with legacy RTCM3 messages.
I’ve read your post. That’s quite strange behavior. I was pretty sure it should resolve all issues. Have you enabled all legacy RTCM3 messages on the Reach?
Does your rover support logging incoming corrections in RTCM3 format? It will help us to check if the Reach sends all messages correctly.
Unfortunately my rover doesn’t support logging the incoming corrections so I can’t help you with that.
One thing I would like to mention is that I connected to some random MSM4 mountpoints from rtk2go.com and the rover responded with float solution which is normal because the base was hundredths of km away. With some other rtk2go MSM4 mountpoints the rover had the same behavior as the emlid m2 base and responded with single solution.
We’ve done some tests ourselves and have an assumption that 1008 + MSM4 messages should work. Please take a look at the screenshot below:
Have you tried such a selection of messages? If not, it would be very helpful if you could test it and share the results with us.
I think I did various combinations of the RTCM3 messages without success.
I will try to log the rtcm3 corrections of the emlid m2 via RTKGPS+ app.
I will do the same with the novatel base station and will send you the files to check.
Today something weird happened.
It was the 4th time in a row that I was working fine with emlid m2 base and hemisphere rover.
Suddenly in the middle of the job the rover would go single.
I did check the corrections tab of the rover and it seemed that it was receiving them.
I did also check the M2 (i was near) and there was nothing strange.
I had to connect to some other CORS in order to finish the job.
Maybe something changed in your caster?
Really it must be some bug in the caster. I can’t find other explanation.
The emlid base stopped working at about 8:10 - 8:15
Do you see anything strange between this timespan?
I attach the raw file of the day i had problem.
raw_202103020732_ubx.zip (6.5 MB)
I’ve checked the log but couldn’t find anything suspicious for now. As far as I understand, you’ve set the following settings on Reach M2 base:
1006, 1074, 1084, 1094, 1124 RTCM3 messages
1Hz update rate
Am I missing something?
Is there a chance you know what messages the CORS station sends and how often?
Yes you are correct, only the 1006 message was set at 0.1Hz (every 10 seconds)
The other CORS I use sends these messages:
Thanks! We’ll continue the investigation. I’ll get back to you once we have any results.
I just want to clarify one thing: haven’t you tested CORS stations transmitting MSM4 messages?
Just want to post an update there that we moved this conversation to private messages. The following investigation requires some sensitive info from @vgo195.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.