Reach Firmware 26 Beta 2 is out for all devices

Ok equal to or lower, makes sense thats how I thought it would work.

Just the wording as is seems ambiguous.

Very excited by this change! Just wish winter would leave so can get back out in the fields.

2 Likes

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 :slight_smile: Though we should be in the 60-70’s F. next week!

3 Likes

2.24.2 is terrible connecting to wifi and pairing bluetooth with Reach 3 version 5.4

Going to try updating to 2.25.1 and ReachView 3 version 5.5 finger cross

2 Likes

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.

5 Likes

Hi @aholsteinson,

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.

1 Like

A post was merged into an existing topic: RS2 can’t be seen in RV3

Visit Santo Domingo is Alway Summer. JAJAJAAJAJ.GOOD BLESS YOU

3 Likes

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!!

1 Like

Bench tested today and it appears to work according to SNIP. Tomorrow I will field test with my Trimble FMX as the rover.

2 Likes

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.

1 Like

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

2 Likes

My hemisphere rover has exactly the same behaviour.

1 Like

Well now I am not sure what is up.

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.

1 Like

Hi everyone,

Thanks for the reports!

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?

1 Like

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.

1 Like

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.SNIP messages

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.

1 Like

@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.

  1. The first test:
  • M2 on v2.24.2
  • enabled MSM4 messages
  • injected 1008 message

This gives you Fix on your rover.

  1. The second test:
  • M2 on 26 Beta 1
  • enabled MSM4 messages
  • injected 1008 message

This gives you Fix on your rover.

  1. 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:

  1. The first setup
  • M2 on 26 Beta 1
  • injected 1008 message
  • enabled 1004 and 1012 legacy messages
  1. 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.

1 Like

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.

1 Like

What do you mean by injected 1008 messages?

1 Like

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