Support RTK gps connection on Android

[geofrancis]

i would very much like this feature, it would reduce the ground station to a phone using remote RTCM

[dlwalter]

@DonLakeFlyer Is there any feasible path forward for this feature or is it an underlying hardware limitation? We would be very interested in supporting this however we can.

[DonLakeFlyer]

It's not a hardware limitation. It's a problem since QGC android serial port support is completely different than everything else. Hence it doesn't just come for free like most other cross platform stuff. So it's some special case work for android builds.

[DonLakeFlyer]

I tried some quick changes to make this work. With that I'm not sure if there is a hardware or android os limitation here. I can open the port for the RTK but I can't read from it. Could be some sort of driver problem which doesn't exist an android devices. Not sure.

[dlwalter]

Do you have a branch you started any work on?

[DonLakeFlyer]

No I tossed it. But it's pretty easy to get started. Look at LinkManager.cc and see where the rtk gps autoconnect is commented out with and ifdef mobile. Change that to an ifdef __ios___ and then keep pulling the string of compiler telling you things are missing. Basically RTK should only be out for ios buid. When you're all done you'll find that in GPSProvider which provides callbacks for serial port read/writes that for some reason although the ports opens you can't read anything from it.

[DonLakeFlyer]

Theoretically if you can get the serial port reading/writing it should just work.

[tilaktilak]

On that topic, I started to have a look at how to connect via Wifi to a base station. I think it's probably more practicable for a tablet, solve the serial issue and should represent a similar amount of work. What do you think ?

[DonLakeFlyer]

connect via Wifi to a base station.

Are you talking about NTRIP? That would be a great feature as well. Lots of folks have asked.

[tilaktilak]

I was thinking of opening a TCP or UDP socket that streams RTCM and as QSocket and QSerial are parent classes, use the same code to parse RTCM. That should be as complex as trying to fix serial on Android and be beneficial for all platforms :-)

[DonLakeFlyer]

Was is the thing that is going to stream RTCM? Do those exist?

[tilaktilak]

Any wifi base station should do that. But I just realized that pixhawk default setup is a Ublox in usb/serial unless you connect to some other piece of hardware that will read from serial and send through wifi.

[DonLakeFlyer]

But I just realized that pixhawk default setup is a Ublox in usb/serial unless you connect to some other piece of hardware that will read from serial and send through wifi.

Not sure how that matters. The reading/writing to RTK is abstracted through the GPSProvider.* callbacks which can be anything. Even though they are only serial now.

[DonLakeFlyer]

Any wifi base station should do that.

WiFi base station. You mean an RTK WiFi base station. Can you point me to such a thing? Apologize for what may seem basic questions. I know next to nothing about RTK.

[tilaktilak]

https://www.septentrio.com/en/products/gnss-receivers/rover-base-receivers/smart-antennas/altus-nr3 I think Trimble ones have wifi as well (like Trimble r8 ?). I think all the "GIS" oriented base station has at least an ethernet connection.

Anyway, I thought it was a common setup to connect to the base station through wifi/ethernet but it's not. So my idea is not relevant for this : http://www.proficnc.com/system-kits/77-gps-module.html

[dlwalter]

@DonLakeFlyer Do you think the issue is in the CDC ACM serial driver? I have no problem getting NMEA messages from an M8P over USB using the app "Serial USB Terminal."

I think I am close to where you left off - LinkManager opens the serial port but then the ubx driver can't get a connection so just keeps retrying at different baud rates.

[DonLakeFlyer]

Not really sure since I didn't get that far. But most likely in the java serial port stuff since the QGC stuff on the other side of that is mostly the same code for everything which works fine on other os.

[dlwalter]

Yeah, I’ll dig that way. I realized the CDC driver must be working though because I had no problem talking over an OTG cable to a Pixhawk here using that chipset

[dlwalter]

Also, interesting to note - it looks like RX might be working correctly - when the ubx driver is trying to configure the M8P at 9600 baud it detects an RTCM message getting received (I used u-center to configure the device to output RTCM only on USB at 9600). The driver still times out though.

[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:133 - "baudrate set to 38400"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:765 - "timed out, returning"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:198 - "trying old protocol"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:133 - "baudrate set to 57600"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:765 - "timed out, returning"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:198 - "trying old protocol"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:133 - "baudrate set to 9600"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:908 - "got RTCM message with length 12"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:765 - "timed out, returning"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:198 - "trying old protocol"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:133 - "baudrate set to 115200"
[E] at /Users/dlw/Workspace/qgroundcontrol/src/GPS/Drivers/src/ubx.cpp:765 - "timed out, returning"

[dlwalter]

@bkueng @thomasgubler I saw your names on the QGC ubx driver. I've forced QGC to use the FTDI adapter as a U-Blox GPS for debugging and hooked up a logic analyzer and connected using an Samsung Galaxy S2. In addition I forced the baud rate to 9600 so I can read it consistently and QGC doesn't try different baud rates.

When it attempts to contact the U-Blox M8P I'm seeing the following messages repeat about 30 times -

B5 62 06 8A 4F 00
B5 62 06 00 28 00

I see the two U-Blox SYNC bytes at the front (0xB5, 0x62) and I'm guessing these are the attempts at the v27 and then the older protocol. The problem with the logic analyzer is I don't see a response from the M8P on the RX line. (No 0xB5 or 0x62 anywhere in the data - just NMEA sentences)

https://i.imgur.com/0BwcnuC.png (top row is TX to the M8P and bottom is RX from the M8P)

When I scoped a U-center desktop connection I would see the M8P respond with a sequence starting with 0xB5, 0x62 when it connected to the GPS.

https://i.imgur.com/1KplKDW.png (I've highlighted the return sequence from the M8P)

Is the UBX_MSG_CFG_VALSET incorrect when getting sent from an Android? Should something look different?

EDIT: So what we're seeing on android is just the 6 byte header being sent with no payload. Due to an issue with waitForBytesWritten the ubx driver thinks the serial writes aren't happening even though they were.

[dlwalter]

The following image is the TX/RX scope of macOS successfully connecting to the M8P (around 7 seconds it hits the correct baud/protocol).

macOS Successful RTK handshake with M8P

The next image is android attempting and failing to handshake with an M8P (same timescale)

Android unsuccessful RTK handshake with M8P

It looks like the attempts from the android are happening way too fast - the desktop attempts are about 4/second while android does 30 attempts in 1 second.

[dlwalter]

Another follow up - I'm finding that the serial write messages on android are getting cut short for some reason. I've fixed the baud rate to 9600 and forced it to use the older protocol (not v27). First is my macOS desktop handshaking with the M8P correctly. Top trace is TX to the M8P and bottom is RX.

macOS successfully connecting at 9600 baud

Next I have the same build deployed to android. The configuration sentence is too short and instead of ~250ms between attempts it is only 30ms.

Android unsuccessfully connecting at 9600 baud

My guess is how the write command is getting passed from GPS provider to the serial port driver.

On the bright side, android seems to be receiving and parsing the RX messages from the M8P correctly. Something is borked on writing the commands.

[dlwalter]

Another note on that android plot - the 6 bytes represent the 2 SYNC bytes, the 2 byte MSG ID, and the 2 byte payload length - 0x28 = 40 bytes. The payload of 40 bytes should be sent immediately after (ubx.cpp line 1827). Maybe the payload isn't getting passed to GPSDriverUBX::sendMessage correctly.

[bkueng]

I suspect a problem with QSerialPort, and would try to directly open and write to the UART device.

[dlwalter]

Thanks @bkueng I'm digging into QSerialPort and how it interfaces with the lower level serial drivers (qtandroidserialport and the hoho usbserial drivers).

I'm just wondering why every other serial interface is fine? The CDC ACM driver works fine talking to an autopilot and the FTDI driver is fine talking to a SiK Radio.

Here is a WIP PR with the basic RTK functionality (attempts to connect on android but fails) -

https://github.com/mavlink/qgroundcontrol/pull/8210

[dlwalter]

Tracing down the issue I see _serial->waitForBytesWritten(-1) is a culprit. I've noticed that the write implementation in SerialLink is different and doesn't use this function - which is why android doesn't have any issues talking to the other types of devices over serial.

EDIT: I cleaned up a few comments I had that were incorrect guessing.

[NTDary]

How do I use the GPS-RTK feature on Android?

[dlwalter]

Currently you don't. The branch linked above has some changes that has a "kind-of" working instance of RTK on android - but you won't be able to use a radio with it.

[NTDary]

Currently you don't. The branch linked above has some changes that has a "kind-of" working instance of RTK on android - but you won't be able to use a radio with it.

So,Is there any way for me to use RTK on Android?

[dlwalter]

Not yet - but possibly in the near future. Feel free to check out https://github.com/mavlink/qgroundcontrol/pull/8210

[WaldoPepper]

There are several very nice Android apps (e.g. "RTKGPS+" or "Mapit GIS - NTRIP Client") that can handle a range of external GPS receivers, e.g. of the u-blox kind. These apps can cast RTCM messages as a NTRIP or TCP server to a loopback port, where it could easily be read by QGroundcontrol. Would keep the hassle of dealing with the USB GPS out of QGroundcontrol on Android. In addition the apps allow to configure the GPS receiver in a tremendous range....

[WaldoPepper]

...there is a nice overview here: https://mapitgis.com/mapit-ntrip-client-app-manual/

[wattsinnovations]

There are several very nice Android apps (e.g. "RTKGPS+" or "Mapit GIS - NTRIP Client") that can handle a range of external GPS receivers, e.g. of the u-blox kind. These apps can cast RTCM messages as a NTRIP or TCP server to a loopback port, where it could easily be read by QGroundcontrol. Would keep the hassle of dealing with the USB GPS out of QGroundcontrol on Android. In addition the apps allow to configure the GPS receiver in a tremendous range....

Thanks for the tip. Have you had any luck getting the Here+ to work with the RTKGPS+ app? If so do you recall the settings you used?

[DonLakeFlyer]

These apps can cast RTCM messages as a NTRIP or TCP server to a loopback port, where it could easily be read by QGroundcontrol.

But QGC doesn't currently support NTRIP either. I was going to do some RTK ui stuff soon, let me take a look at that as well.

[wattsinnovations]

That would be excellent thanks a bunch