I have a Trimble BD970 base, its big security feature is adding a few extra bits, an arbitrary station number in an addition on a message. It messes up the parsing side unless its ready for it.
Topcon may employ a similar strategy to preserve rtk as a service.
Can you tell me what bits, and what message? Are we talking rtcm messages?
Can we keep this thread back on the topic of getting Emlid working with Topcon and GPS control?
Hi guys,
I’m not ready to provide the final solution but have some comments.
Based on the research we have done so far, Reach firmware doesn’t have any bugs. But 3rd-party receivers have some specific requirements for corrections coming. Now, we’re checking if it’s possible to support these requirements from our side. However, I’d recommend you reach out to your rovers manufacturer’s support to check it with them just because it may be easier to fix from their side.
Hi Svetlana, glad to hear you are getting some idea of what is going on.
I doubt that Topcon or Trimble would be willing to create an update for their rovers, especially the older models.
Can you tell me what their rovers are looking for that the RS2 is not broadcasting?
Here’s a blog where it looks like someone has worked on this challenge. It’s for a small microcontroller that interfaces with several different GPS chips (including the F9P - which is what’s in the RS2 so thats great news in general). Seems like there are several users on the AGOPENGPS forum and there are several users you could reach out to listed at the bottom who might be willing to lend a hand.
They list several different RTCM messages that they inject so that might make a difference since a few are different than what the RS2 uses. But since in your experience it fixes for about 10min it might be something different. They also list adjusting the RTCM stream so that the observables are on the second instead of fractional second (TADJ=1). I know that has caused compatibility issues for some in post processing with RS2 log files and adjusting in RTKlib has fixed it. They also set the F9P to use MSM7 (the RS2 sets it to MSM4). Something is mentioned about locking the L2 band and it’s not clear what they mean. It may be that they are stripping the L2 band (maybe to remove the L2P vs L2C incompatibility) and running RTK on L1 only. Not clear if that’s what’s meant. If this is the case MSM7 would help because it includes Doppler measurements. Anyways, In the end, I think it gives hints about the problem, but isn’t 100% explanatory on how they solved every problem.
Hope it’s helpful to maybe link you to some folks who’re trying to work out the same thing as you.
Hi there,
I, indeed, can’t go into details. But in a few words, Reach broadcasts everything that is needed. However, it adjusts the data from time to time to make it relevant, which is the right thing to do but causes these compatibility issues.
Still, we’re looking into what we can do to help you with this. And if we come to any conclusion, I’ll post it here.
Svetlana, I’m working on what I think is a similar compatibility problem. If you want to share findings/ideas feel free to get in touch directly.
I have an F9 operating as a basestation (not in RS2), and a Topcon B210 as rover.
Hi @dan.fox,
Thank you for being so willing to help! Currently, we seem to manage it on our own. But thank you once again!
I just wanted to keep this thread alive before it gets locked after 3 months.
But if there is any update, I would appreciate it!
Hi Grant,
I remember about this thread and keep my eye on it. Don’t worry! Even if it’s closed, I’ll open it in case of any news.
I understand that smooth workflow with 3rd-party receivers is essential for you. But this fix still doesn’t look like the easiest one for us. So, I’ll keep you updated.
Same problem with Geomax Zenith series as rover (tried Zenith 35 and 40). They simply stay in float, and never fix.
Hi Christian,
I’m not sure that it’s the same issue. In the cases I saw previously, rovers could get a Fix, but solution becomes Signle after 15-40 minutes.
If it never gets Fix, maybe some data is missed. For example, 3rd-party receives often require L2P observables. Do you know Geomax requirements?
Yep, from the tests I made with a Hemisphere Vega 28 as base, the second GPS L2P was enabled (with just GPS L1CA otherwise enabled) , it would fix.
So, it seems we can hardly do anything to make this integration possible. We’ve already discussed somewhere on this forum that it’s a hardware limitation. If I recall correctly, you participated in this discussion too, but I repeat it just in case 
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
Hi guys,
Big great news is here 
The new 30 Beta 1 brings improved support for third-party receivers when Reach receiver is set up as a base.
More details are here: Reach Firmware 30 Beta 3 is out. We would love to hear your feedback in that thread!
