Hey y’all! Hope everyone’s doing well.
First of all, I’m using a Reach RS unit with the ReachView app version 2.5.3 for this particular application.
Have the Reach RS base unit receive NTRIP corrections via bluetooth from a cellular phone, which is running the Lefebure NTRIP Client application, without the base unit having to be connected to an internet-accessible network.
Lefebure NTRIP Client app connects to the Reach unit, then the caster, but immediately drops the connection. This connecting then dropping connection happens continuously as the NTRIP Client app tries to connect.
Previously, we’ve had success with having the Reach unit connect to a WiFi network that has internet, and set the Corrections Input in the ReachView app to NTRIP and entered the caster info there. This works great, but what about when we’re somewhere that doesn’t have internet access?
Below are screenshots showing the ReachView app’s Correction Input settings, the NTRIP app’s settings, and the NTRIP app’s logging as it attempts to connect to the caster.
Is the setup we’re using not quite right for the output we’re expecting? Is it possible to get input corrections via bluetooth from a cellular phone without being connected to an internet-accessible network?
Any suggestions, advice, or if any additional information is required to help troubleshoot, just let me know.
Good idea, I’ll update the ReachView version to the latest.
The NTRIP corrections are coming from a paid service, there’s a tower not too far from us.
I guess we’ll see what happens after you update, but I’ll fire a couple of shots in the dark:
Do you have position output turned on? If so, what settings are used there? If Bluetooth, turn it off. Check the base mode tab and turn that off as well.
I wonder if there is some issue with getting the GGA messages backwards over Bluetooth, through Lefebure, and then out the cell data link out to the caster. I suppose this would only matter if you were getting a VRS.
Thanks for the reply.
I’ve updated the unit to the lastest ReachView version: 2.11.0, but still getting the same outcome.
Below is a screenshot of the Corrections Input:
Next, a screenshot of the Position Output:
I’ve got the Base Mode set to off:
And for the full value, here’s the Status tab:
My phone is paired with the Reach RS unit (red-rover), and the Corrections Input seems to indicate it’s connected, although I’m not sure if “Connected to localhost” is the expected message, as I expected it to say it’s connected to the cell phone’s name.
For the NTRIP Client app, I’m getting the same output as the screenshot in the original post. In the phone app’s log, you can see that it connects to the Reach unit, connects to caster and subsequent satellites, but then the connection drops and reconnects.
I’m starting to wonder if it’s an issue with the phone app side of things, but I’m not totally sure. We get NTRIP corrections if we directly set the Reach unit to receive NTRIP for it’s Corrections Input, for what it’s worth, but when we setup the above configuration with the phone and BT, we get the above issues.
Tried now with reachview 2.10.3 and it works just fine.
Gonna try 2.11.0 version now.
Still working. Connected to base zillion miles away.
Would try any of those ntrip found in the www.rtk2go.com list. No VRS i think. Just to see if it makes any difference.
Thanks for testing. I’ll try an NTRIP from the list and report back. It’ll most likely be tomorrow morning when I’m able to give it a shot.
Should the Position Output of the GPS unit be set to Bluetooth as well?
And the “Send NMEA GGA messages to the corrections provider (required for VRS)” setting in Correction Input, should that be unchecked (it’s currently checked)?
Also, I set the GPS unit and phone app settings to match the ones from the post you referenced above, but at the moment I’m still getting the caster-connected-then-dropped problem. I’ll double check the settings along with testing an NTRIP from the site and let ya know how it goes.
No. Have other input or output features turned off that you dont use, i might cause a conflict if multiple streams are enabled.
Have it checked when using VRS service.
One thing i dont do, is use my phone to connect to Reachs bluetooth (from the bluetooth menu on the phone). I just have bluetooth enabled on my phone and Reach and then have Lefebure connect.
Digging around bluetooth to provoke a hickup i noticed this.
1.If using VRS and having GGA return message sent, i noticed lefebure keep jumping randomly from fix type is now GPS, to fix type is now unknown and then back again. I noticed this when i turned Lefebure sound on. I had it turned off. It still shows position when used with e.g Mobile topographer but position is out for a millisecond or two.
2.If enabling output solution bluetooth with NMEA at the same time having GGA to VRS active, Lefebure stops this known/unknown hickup thing.
So to correct/recap what i said earlier.
-If you need bluetooth messages back to your phone for applications like mobile topographer etc, turn on bluetooth output solution.
-If you only need correction messages from a ntrip service sent from your phone over blutooth to your Reach and dont use VRS, It works with bluetooth active on correction input and the rest deactivated.
-And if using VRS, you may now try having output solution active with bluetooth and GGA to VRS enabled for now.
But there seems to be a hickup when using VRS and only having GGA return messages sent, at least if you look at the lefebure app. Not sure if is related to Lefebure or Reach NMEA messages.
Also there is a bug in the Input correction menu. When you have enabled VRS message and hit apply, if you then need to turn it off, i would need to refresh the screen to get the apply button again. Reachview 2.11.0
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.