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.
@jp-drain-sol, thanks for your tests!
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.
This gives you Fix on your rover.
This gives you Fix on your rover.
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:
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.
You got it right. Only 1 addition. On test 3 I also had 1034 or 1033 enabled. I forget which one is available in the legacy messages.
I think I tried your two suggestions but I can confirm this evening.
What do you mean by injected 1008 messages?
Prior to Dev version 26.1 the M2/RS2 could not transmit RTCM message 1008 which trimble components need to get a fix status. They can also go fixed with message 1007.
All the details are in this thread My M2 project, Trimble Base Station
To sum it up, I have an m2 putting out RTCM via serial at 57600, it is connected to an Arduino Nano that is programmed to add a blank message 1008 if there is none present but there is a message 1005/1006. It lets the rest of the RTCM messages pass through and adds the 1008 via serial port at 57600 which is connected to a RFD900+ radio which transmits to a 3DR radio that I have connected to my Trimble monitor for RTCM corrections.
Sorry, long day at work. I will not be able to test this evening. Perhaps tomorrow, if not it will be either Saturday or Sunday.
Very good addition, i changed the talker-id to GP GGA 10hz, VTG10hz and ZDA 1hz, as that is what my autosteer requires. RS2 communicates very good and stable with my autosteer device now, but RS2 isn’t able to get a fix, but may be i still have to change some settings.
Very hopefull that i will get in running on RTK! (using NTRIP)
DJ
You pass the RTCM or MSM stream output of the Emlid base through another device (like an Arduino) or through a capable NTRIP caster that adds an (artificial) 1008 RTCM message type.
This is done to enable certain legacy rover receivers (think Trimble or Topcon) that expect to see this message type (even if they effectively ignore the content of such) on the correction stream to establish an RTK fix.
I managed to get a fix now. Somehow i can only change talker Id in reachview2, reachview 3 doesn’t support this option, is that correct?
Hi,
I don’t know if something changed on the emlid caster but today everything was working fine with the hemisphere rover with the standard MSM4 messages of the M2. It fixed right away in 2 different sites.
I had enabled all the MSM4 messages plus 1006 and the rover did read the corrections immediately.
With the legacy messages I was not so lucky.
The legacy messages didn’t work with either rover (novatel or hemisphere). The hemisphere rover couldn’t read the corrections at all and stayed single and the novatel rover stayed float all the time.
As fas as the novatel rover is concerned I don’t need the legacy messages anymore because I don’t plan to use it as a rover (it would be nice though if it could work). I will use this receiver as base station in pair with the hemisphere receiver.
As far as the hemisphere rover in pair with emlid m2 this is something i want to use in my workflow because of the full gnss support. Fingers crossed I will check it some more times and will report back.
I attach two logs for you to check if everything is ok. One is the novatel base log and the other is the emlid m2 log. In both cases I was using the hemisphere rover successfully.
base_epoch.log (162.3 KB) base_M2.log (154.5 KB)
In the 1008 injector there are two messages to choose from;
// Blank RTCM3 type 1008 message for Trimble
const char packet1008[12] = { 0xd3,0x00,0x06,0x3f,0x00,0x00,0x00,0x00,0x00,0x99,0x25,0xca };
// ADVNULLANTENNA type 1008 message (station id =0)
// const char packet1008[26] = {0xd3,0x00,0x14,0x3f,0x00,0x00,0x0e,0x41,0x44,0x56,0x4e,0x55,0x4c,0x4c,0x41,0x4e,0x54,0x45,0x4e,0x4e,0x41,0x00,0x00,0x79,0x06,0x89};
// Swap // to change message and change packet size
Which did you end up using @jp-drain-sol ?
The top one. I will try the ADV perhaps today. I am also trying a message 1007 inject as well.
Just as a note, as I do each test, I will edit this post with the test results. Also, powering down both units between tests.
The unit would go fix (GPS only) but would not maintain it. Correction age would climb and it would drop to DGPS for about 10 seconds then go fixed again. About the longest it stayed fixed was 1 minute.
Test 2, message 1008/1074/1084 same Hz as above.
Unit stayed DGPS would not go fixed. Let it run for 5 minutes to hopefully log some helpful data on my rover
Hi @vgo195, @jp-drain-sol,
Just wanted to outline that the 1006 message should remain enabled no matter whether you use 1008 or not.
Please, check if this combination would work for you: 1006, 1008, 1074, 1084.
I will try that this evening.
Indeed 1006 is critical to RTK as it contains the base marker coordinates in ECEF format and antenna height.
Without that information it’s impossible to get a fix.
Hi @DirtyHarry,
We’ll make it not possible to disable 1006 message in the future so that it doesn’t affect someone’s workflow
Sorry, new to the whole selecting which RTCM message thing. I have used Trimble’s CMR the majority of the time and the RTCM used previously was from other brand bases and I didn’t have to do any modifications. They were all Ag products so, my guess is the manufacturer knew what messages where needed.
Good to know info on message 1006.
Thanks Tatiana. I can’t think of a scenario when you’d want to not have 1006 present on a correction output. Perhaps something for the next stable release.
Also how difficult would it be to have the ability to populate the actual antenna descriptor field in 1008? I’m presuming the current beta generates the message with a null field?
Note that I’m yet to inter-op. test the latest beta with other brands of rover using the classic messages, in this latest beta, so I may be jumping the gun so to speak.
