Tracker - bluetooth GPS being used?

[danbecker]

We're using the Tracker Mobile app with various bluetooth GPS receivers (BadElf Surveyor and EOS Arrow-100) both of which have a horizontal accuracy around 1m, the Arrow-100 commonly gets below 0.5m. Collector is correctly reporting the GPS accuracy, yet the field team is saying that Tracker reports 15+ ft accuracy.

Questions:

1) Does tracker (iOS) use the connected bluetooth GPS receiver to position points?

2) The location_tracking hosted feature service records "Horizontal Accuracy" in the attribute table, along with other GNSS metadata, but what is the h. accuracy unit? Meters, feet, ect...?

3) Why is some of the GNSS metadata missing, i.e. <Null> in the feature service? I know that Collector erases GNSS metadata when a feature is manually placed, what causes this behavior in Tracker?

[Anonymous User]

Hi Dan,

1) Does tracker (iOS) use the connected bluetooth GPS receiver to position points?

Yes, it will automatically use the high accuracy data that is fed into the location manager.

2) The location_tracking hosted feature service records "Horizontal Accuracy" in the attribute table, along with other GNSS metadata, but what is the h. accuracy unit? Meters, feet, ect...?

Meters. We are working on documenting the location tracking schema.

3) Why is some of the GNSS metadata missing, i.e. <Null> in the feature service? I know that Collector erases GNSS metadata when a feature is manually placed, what causes this behavior in Tracker?

Can you expand on this? Do you mean why Tracker doesn't record the GNSS metadata?

So Tracker will use the high accuracy receivers location but it does not read or use the additional metadata provided by the receiver (like Collector does). On iOS the location manager reports a minimum of 5m accuracy regardless of whether the external receiver actually has a higher accuracy. So the data is accurate but the "horizontal_accuracy" that is recorded is capped to 5m when in reality it could be 1m. We'd have to do significant work to support capturing high accuracy metadata.

[danbecker]

Thanks Aaron. I figured that since Tracker is in it's infancy the recorded "horizontal_accuracy" attribute is not correct (just like in the early days of Collector). For our workflow, this is an issue.

We're required to report the accuracy of our tracklog lines because the protocol survey's we're performing require the field staff to walk transects that are 15 ft apart (we generated a set of fishnet lines to use as a guide). If the accuracy is capped at 5m (by the iOS LM) and that's what we report, then we may not have surveyed according to the protocol, as adjacent tracklog lines could potentially be 5m (~15 ft) +/- of where the line geometry is placed thereby creating 30 ft "gaps" in violation of the protocol. Tracker needs to report the accuracy of the GPS stream it's utilizing. We'll have to tell our client "even though the line feature states an average accuracy of 5 meters, it's likely much more accurate but we're not sure".

By GNSS metadata, I was just referring to "location_source", "session_id", "signal_strength", ect... Not necessarily GNSS metadata, but regardless, these values aren't being regularly populated.

Don't get me wrong, Tracker has been working great, it was 3 instructions in an email to the field staff to roll it out, very simple, which is awesome. We spun up a dedicated Linux VM for the spatiotemporal datastore, holy smokes does that take a lot of memory! These are shortcomings of the new tracking functionality for our org: GNSS accuracy reporting, no GUI tools to delete data from the hosted feature layer and requirement for Geoanalytics Server License to do almost anything with the track points.

The ArcGIS API for Python will easily handle the deleting and point-to-line conversion though.

[Anonymous User]

Thanks for explaining your workflow. I've added your information to our "high-accuracy" issue that's in the backlog. Right now it's not a high priority item but that may change once the product gets going.

The "location_source" field is only populated by the Android app and it always reports "fused" meaning it's using GPS+WiFi+BT and other sensor to derive the location. Similarly CoreLocation on iOS uses multiple sensors but doesn't have a value "source" that is returned. 

The "session_id" field is something that we don't plan to write to at least for now. The idea is it's a string field that would allow someone to "classify" their tracks say for different projects.

The "signal_strength" field we are also not populating at this time but may in the future.

I'm glad you've had a good experience so far. Yeah both the Spatiotemporal datastore and GeoAnalytics Server need a lot of RAM. We are actually working a Tracker module for the ArcGIS API for Python and it should be available in one of their next releases. It will make it easier to configure Track Views and access the location tracking views and layers for doing analysis and querying/deleting.

[BernardRomey]

I have an Android related question.  I am using Survey123 with a Bluetooth GPS receiver and it works fine.  When I try to use Tracker at the same time, no bueno.  The only way I can get Tracker to work with a Bluetooth GPS is with an app called Bluetooth GPS to handle the mock GPS on Android.  When I do this, Survey 123 stops working because now the Bluethooth GPS app is handling the connection to the Bluetooth GPS receiver and it conflicts with Survey123.  Why does Tracker not have the capacity to handle Bluetooth GPS receivers like Survey123, and why does it not work at the same time as Survey123?

[CraigGillgrass]

Hello Bernard,

Can you expand a little on what you mean by Tracker doesn't with with a Bluetooth GPS receiver?  Is there a problem in the mobile app?  Are locations and tracks not uploaded to the tracking service?  Are you expecting it to capture the GNSS metadata and it isn't?

thanks,

[Anonymous User]

Tracker does not support directly connecting a 3rd party receiver. For many receivers, on iOS locations are fed directly into the location manager and shared across apps. For Android, you will need to set the mocked location app to be the GPS manufacturers app. This should allow locations be shared across multiple apps. What type of receiver are you using? If Bad Elf, you can read about it here.