Reach Firmware 26 Beta 2 is out for all devices

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.

1 Like

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.

1 Like

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)


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?

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.

  1. The first setup as you stated above, Dev 26.1 in order to inject 1008 I had to enable message 1006 for the Nano to inject 1008. I only had 1006/1004/1012 enabled at .5/2/2 Hz respectively

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

1 Like

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.

1 Like

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.

1 Like

DirtyHarry, I don’t know what I don’t know when it comes to RTCM. I am good with a lot of things but this is all pretty new to me. I am a tinkerer and willing and able to learn.

Yesterday, while doing my testing I tried changing my 1008 injector to ADVNULLANTENNA and it worked either way so, I don’t think that was the issue.

I am not sure about the other user but adding the 1006 message to the legacy messages might correct the problem I had. I will verify this evening.


No worries. It’s all a learning curve. My comment about keeping 1006 under the hood wasn’t really directed at your good self, but more in general. As there’s really no need to have the check box to enable/disable as its prerequisite - its a distraction in other words.

Good luck with your testing. What sort of baselines lengths are you checking?

1 Like

I forgot, I had to take my vehicle into the repair shop last evening so I didn’t get a chance to test the legacy messages with the 1006

Baselines have been “bench testing” only, no more than 50 feet. Once all the bugs are out and the weather gets fit, I will be doing some distance tests. I am certain my radio combination with the antennas I am using should easily cover the area I need. We place the base station in the field we are working in. Normally the longest distance is maybe 3000 feet and we are in flat country USA. Only time I have had troubles receiving corrections previously was when there was about a 5 acre woods in the middle of the field.

In my test setup, I am averaging fix for 1 minute for the base using the OH CORS network. When I actually use it on a job, there will be a 5 minute average. I played with averaging times with my M2/RS2 combination and a known surveyed point and found somewhere between 4 and 5 minutes got it extremely close.


Hi @DirtyHarry,

Yes, you’re right. We’re transferring the information about the null antenna.

The thing is that the base receiver broadcasts not the position of the point where the base is placed but rather the antenna phase center. In this case, we don’t need to transmit info on the antenna name since we calculate rover’s coordinates in regard to base’s antenna position.

Finally got a chance to test it again. I started with 1006/1008/1004/1012 and could not get a fixed status. I changed to 1006/1008/1074/1084 and it went fixed so your ADVNULLANTENNA is working but your legacy messages are not. Missing the 1006 previously was my issue.

When I had the 1006/1008/1004/1012 messages enabled I tried about every combination of Hz speeds for all the messages going from 1 Hz through 5 Hz with individual and all it just wouldn’t go fixed.

One strange thing I noticed this evening when I had the 1006/1008/1074/1084 config and got fix status the number of satellites on the Trimble monitor was jumping anywhere from 6 to 11 rather sporadically. I have never noticed that big of a jump previously. I can understand maybe one or two but 5? I am not sure if it is something to do with the MSM4 messages or not.

I have duty this weekend so I will not be doing much testing but if there is something else you would like me to try let me know and I will see when I can squeeze it in.