iPad not receiving GPS like it should

Rando

Explorer
Not that it would help in this situation, but another option to provide GPS to a Wifi only iPad is a Garmin InReach. If you pair the iPad with the inReach it will provide GPS just like the Dual or GLO units. If you already have an inReach, this is a free solution. I use it with a Wifi iPad Pro, and it all connects automatically and works seamlessly. It is annoying that there is no functionality (that I know of) to allow your iPad to use the GPS from your iPhone when they are tethered.
 

DaveInDenver

Expedition Leader
Not that it would help in this situation, but another option to provide GPS to a Wifi only iPad is a Garmin InReach. If you pair the iPad with the inReach it will provide GPS just like the Dual or GLO units. If you already have an inReach, this is a free solution. I use it with a Wifi iPad Pro, and it all connects automatically and works seamlessly. It is annoying that there is no functionality (that I know of) to allow your iPad to use the GPS from your iPhone when they are tethered.
GPS2IP may work: https://www.capsicumdreams.com/iphone/gps2ip/

It seems to work serving BLE positions to my MacBook for an APRS client (QTH.app) and the TCP server with QGIS. I don't have an iPad to test but I was able to use an app called "LE GPS Rec" to see the BLE from GPS2IP on another iPhone so seems like it's working.
 
Last edited:

Rando

Explorer
GPS2IP may work: https://www.capsicumdreams.com/iphone/gps2ip/

It seems to work serving BLE positions to my MacBook for an APRS client (QTH.app) and the TCP server with QGIS. I don't have an iPad to test but I was able to use an app called "LE GPS Rec" to see the BLE from GPS2IP on another iPhone so seems like it's working.
I actually bought and tried this app, and yes it works to provide the GPS position over TCP or UDP, but it will only provide a position solution to apps that can be configured to look for position via these ports - which seems to be limited to some rather obscure marine and APRS apps. I also remember it being kind of a bear to setup as you have to set up the devices in a peer-to-peer network, select IP addresses etc. It is not automatic or seamless.

The built in apps and most navigation apps (Gaia etc) expect position to be available from the native iOS location services framework. Somehow the inReach can inject its position into iOS such that it updates location services and is available to other apps. I am not sure why no one has been able to achieve this functionality between iPhone and iPad, maybe there is some security reason that it is not permitted.
 

DaveInDenver

Expedition Leader
I actually bought and tried this app, and yes it works to provide the GPS position over TCP or UDP, but it will only provide a position solution to apps that can be configured to look for position via these ports - which seems to be limited to some rather obscure marine and APRS apps. I also remember it being kind of a bear to setup as you have to set up the devices in a peer-to-peer network, select IP addresses etc. It is not automatic or seamless.

The built in apps and most navigation apps (Gaia etc) expect position to be available from the native iOS location services framework. Somehow the inReach can inject its position into iOS such that it updates location services and is available to other apps. I am not sure why no one has been able to achieve this functionality between iPhone and iPad, maybe there is some security reason that it is not permitted.
In the case of my macOS APRS client it's communicating via Bluetooth. The phone app GPS2IP has options to serve location via socket or push TCP or UDP still (gives option to use the phone's network assigned address or use it's own hotspot address) but the version I downloaded today (3/10/21, unsure of actual app version) has added Bluetooth sharing. It might be further along in its development?

I can sniff it using PacketLogger and it's definitely coming in via an ACL L2CAP receive from the phone using handle 0x0041, channel ID 0x0004 with either a 42- or 27-byte payload. Apple doesn't seem to document how PacketLogger works and I haven't dug in to understand the framing. Pretty sure it's a 4-byte header so that would leave either 23 or 38 byte of data.

Using Bluetility the phone shows it's offering a GATT service UUID 0x1819, which is Location and Navigation (org.bluetooth.service.location_and_navigation) with fields 0x2A6A, 0x2A67 and 0x2A68. In particular is field 0x2A67, which is defined as location and speed characteristic, where longitude and latitude reside, along with many other fields. BTW, this is using an iPhone 5s with iOS 12.4.9 so what's exposed could obviously be unique to my ancient device.

So I presume if the application is designed to use BLE location GPS2IP can present it now. I don't have anything to use to test BLE functionality on iOS other than that app (LE GPS Rec) I mentioned before, so it's mostly just information without much purpose.
 
Last edited:

Rando

Explorer
I tried this a couple of years ago and BLE was not an option at that point. I can update the app, try again and report back.

To some degree this is academic as I have an inReach, but it has just bugged me that this is not a default option when a Wifi iPad is tethered to an iPhone.
 

rnArmy

Adventurer
Yeah... that's what I was thinking DaveInDenver.

No, change that - I have no idea what you guys are talking about - too technical for me. Glad there are smart folks out there!

And of course, my phone is an android, so probably not much communicating going on between my phone and iPad.

I'm just happy the Garmin GLO2 got my iPad up-and-running the GAIA program for my next adventure.
 

Rando

Explorer
In the case of my macOS APRS client it's communicating via Bluetooth. The phone app GPS2IP has options to serve location via socket or push TCP or UDP still (gives option to use the phone's network assigned address or use it's own hotspot address) but the version I downloaded today (3/10/21, unsure of actual app version) has added Bluetooth sharing. It might be further along in its development?

I can sniff it using PacketLogger and it's definitely coming in via an ACL L2CAP receive from the phone using handle 0x0041, channel ID 0x0004 with either a 42- or 27-byte payload. Apple doesn't seem to document how PacketLogger works and I haven't dug in to understand the framing. Pretty sure it's a 4-byte header so that would leave either 23 or 38 byte of data.

Using Bluetility the phone shows it's offering a GATT service UUID 0x1819, which is Location and Navigation (org.bluetooth.service.location_and_navigation) with fields 0x2A6A, 0x2A67 and 0x2A68. In particular is field 0x2A67, which is defined as location and speed characteristic, where longitude and latitude reside, along with many other fields. BTW, this is using an iPhone 5s with iOS 12.4.9 so what's exposed could obviously be unique to my ancient device.

So I presume if the application is designed to use BLE location GPS2IP can present it now. I don't have anything to use to test BLE functionality on iOS other than that app (LE GPS Rec) I mentioned before, so it's mostly just information without much purpose.
For giggles I gave this a go between my iPhone with the latest version of GPS2IP and Wifi iPad running Gaia - and no dice. It does not appear to provide GPS positions to location services on the iPad, therefor Gaia cannot use it. It appears that others have asked Gaia to add a GPS via IP/UDP feature, but I imagine it is a very low priority for Gaia as it is a clunky solution at best.
 

DaveInDenver

Expedition Leader
For giggles I gave this a go between my iPhone with the latest version of GPS2IP and Wifi iPad running Gaia - and no dice. It does not appear to provide GPS positions to location services on the iPad, therefor Gaia cannot use it. It appears that others have asked Gaia to add a GPS via IP/UDP feature, but I imagine it is a very low priority for Gaia as it is a clunky solution at best.
This does appear to be a non-standard (or perhaps really a way that's non-Apple blessed) approach, so it's completely dependent on the app. In this little test between GPS2IP and LE GPS Rec I have running neither requires Location Service to be enabled (nor the cell modem or WiFi for that matter), just Bluetooth has to be on on both devices.

In the case of LE GPS Rec it doesn't seem to even look at anything *other* than the BLE source and I think this is just because it's intention is to demonstate a Github project called "LE GPS" (which is no longer in the App Store it appears, just the receiver is and that's probably just happenstance) that can be included by a developer to do precisely what you want, stream GPS data. It appears to be a Bluetooth 4.0 LE/Xcode 8.0 project so not sure if it's even still active. The most recent commit was 2019 (a license change) and the last functional commit was 2017.

http://www.xdappfactory.com/wp/?page_id=181

The other iOS apps I have (COTREX, CalTopo, maps.me, aprs.fi) all look at Location Services and I see no way around them using the internal source (e.g. built-in GPS) on my iPhone, so I have zero doubt in your assessment w.r.t. the Apple ecosystem. Not having a WiFi-only iPad I don't have any experience in how they talk to the source. I'm left thinking the GPS2IP app or the phone itself must provide a vendor or device IDs that Apple and the BT SIG approve before allowing communication and spoofing one would open a real can of trouble from Apple/Dual/Garmin.

I have an even more ancient Android device that is the APRS client in my truck that I'll mess with. My memory is that Georg @ APRSdroid is relatively unconcerned with doing things the correct Google way so it might look at generic BLE sources fine. I've got the old Backcountry Navigator and Oruxmaps on that phone, too. But all of this is, as you say, academic since most devices and apps do things the approved way and for an Apple developer (therefore users) that's really the only option.
 
Last edited:
Top