Yep, unfortunately the machine GNSS settings are what they are. They do run all constellations though. I can’t think of anything CAN-NET would be doing any differently than what you could do with the RS2 so it is totally on the machine side just like we experienced except ours was poor performance instead of not staying connected.
Can you get to a browser on the GX-55? You’ll have to back out of 3DMC. Hit fast.com and see what kind of speed it is getting at that spot. More importantly the ping.
@tatiana.andreeva So I did a bunch of trials today. I was using the RS2 on site, setup as base station through nTrip.
So far it does not seem to make much of a difference what the settings are on the RS2.
To recieve a fix, the only special thing required is message 1008
I have tried the settings you suggested, it made no difference.
Once a fix is aquired. I can use the dozer for 5-15 minutes, the accuracy is perfect, and there are no issues. But suddenly it just loses a fix and says “waiting for initilization”. It -will- reconnect after about 10-15 minutes, and the cycle repeats.
I feel like there is one setting that needs to be changed on the Topcon side, I just don’t know what it could be, or even if I can change it.
What happens if you shut down the system on the dozer and try to regain a fix? Does it also take the same amount of time as mentioned above?
Yes it takes the same time as if I reset the reciever.
It kind of sounds to me like there is a loss in the connection of the NTRIP and once it finally reauthenticates it takes the normal cycle time for the machine to initialize. There’s got to be a way to test the internet connection right when this happens.
See the weird thing is, if you go to the page where it shows the stats on the radio, it is 100%… Not sure what to say.
In my case, restarting the rover doesn’t help.
The incoming stream on the rover shows that is working but the rover doesn’t utilize the corrections. It is like the base is sending a dummy stream.
Just throwing things out there but have you tried legacy only messages? Also try GPS and GLONASS only.
I had an issue with porting in data from a RS2 to a Trimble Ag monitor (FMX) this week. It is an older model, when i changed from GPS/GLONASS/Gal/Deb to GPS/GLONAS only it worked.
Not having the same equipment as you makes it almost impossible for us or Emlid to truly troubleshoot your system. It may take some tinkering to get it to work. If you are, only change one thing at a time, establish a “workflow”. Once you find that “sweet spot” smile. It can burn some time. Took me over two hours on my unit. On the later models (FMX 3rd GEN and TMX) this wasn’t an issue is why it had me puzzled.
Hey there,
First of all, I want to outline that Reach receivers work with most of the 3rd-party equipment just fine. We’re open to lots of integration types and always ready to help to configure them. We specifically added the RTCM3 1008 message in the last update to let our users work with our bases and 3rd-party rovers.
However, as was already mentioned above, we’re limited in how we can help you when it comes to 3rd-party devices. Even if we can definitely help to troubleshoot the setup from our side, things become complicated once something started to go wrong from the side of 3rd-party equipment. The tests you’ve already conducted make me think that the root of the issue can lie on the rover’s side. That’s why I’d recommend reaching out to Topcon support as well so that they can check everything is fine with their configurations.
@tatiana.andreeva You are absolutely correct. Don’t get me wrong, everyone at Emlid has been fantastic about trying to help me out. I posted here mostly to see if there was anyone else who had a similar issue and was able to work around it.
Can I ask if there are any special settings to get a normal Topcon Rover working with nTrip (on the topcon side)? My biggest problem has been that I have gotten no response from Topcon at all. And there are very few settings, and almost no log files that I can look at on the topcon side.
Emlid’s support and the amount of information I have access to is FAR superior to anything I’ve seen from topcon.
I think that is standard practice isn’t it? : /
I don’t know anything about Machine Control, but want to look into it… but seems like the drone community, there must be a Machine Control community that could help?
See I’ve never used topcon before. I have lots of experience with Trimble, but I was also working at a giant engineering firm. So they responded really quickly, possibly for that reason.
Here, they keep saying “well we can’t let clients access that information, it’s proprietary and we don’t want operators changing something so it doesn’t work”…
Really disappointing.
yes of course. $$$$$$$$$$$$$$$$$
I can tell you from experience that neither Topcon or Trimble are going to waste much time helping you integrate 3rd Party hardware. You might get a 1st Tier support rep. Who’s your Komatsu dealer? As far as I know any Komatsu dealer is also a Topcon dealer.
Guaranteed
If purchased from me (a Trimble dealer) I help my customers. If on the phone, no fee. If I have to go to their location and help set it up, it is a service call.
If not purchased from me I am $120/hr for phone calls, with a minimum of 1 hour or in person including travel to and from.
I wonder if this post has anything to do with some of the third party receiver problems?
Dear timb1971
Thanking you very much for this reposting here. As I said I think that is an RTKLIB issue using the str2str tool for conversion of UBX data to specific RTCM data. I am reading now this specific manual: https://www.u-blox.com/en/docs/UBX-18010802
Page 19 says that:
"The desired RTCM messages must be selected and configured for the corresponding GNSS constellations received. The recommended list of RTCM output messages for a base operating in default GNSS configuration are:
•RTCM 1005 Stationary RTK reference station ARP
•RTCM 1074 GPS MSM4
•RTCM 1084 GLONASS MSM4
•RTCM 1094 Galileo MSM4
•RTCM 1124 BeiDou MSM4
•RTCM 1230 GLONASS code-phase biases
The RTCM3.3 correction stream must contain the GLONASS code-phase biases message
(type 1230) or the Receiver Antenna Description message (type 1033) otherwise the GLONASS
ambiguities can only be estimated as float, even in RTK fixed mode."
Reach RS2 and M2 are using the u-blox ZED-F9P GNSS module. I own this chip in standalone version (dev kit), so I will try to feed those RTCM messages directly from u-blox original firmware and not using RTKLIB in order to investigate if this procedure will work with third party receivers. If this process gonna work I will inform the Emlid about that in order to make the appropriate software updates to manage this issue through the u-blox original firmware and not through RTKLIB. Thanks.
Wonder if this new update fixed it?
I am just in the process of updating my base. The update is kind of vague for what has actually changed, but I will do some more testing.
