A field tablet can show an external GNSS receiver as paired while the application still records the tablet's integrated location, a network location or no usable quality metadata. Connection is only one layer. The project must also select the receiver as the application's active position source, apply the intended coordinate handling and preserve the evidence needed to accept the result.
This guide is for GIS integrators, field-form teams and rugged-tablet buyers. It follows one documented Esri Field Maps example to show where the data path can break. It does not claim that an AIDC GO tablet supports a particular receiver, NMEA version, correction service or accuracy level.
Separate the link from the location source
Write the path as distinct states: the receiver has a position; the host discovers or pairs with it; a documented interface carries position messages; the field application selects that interface as its location provider; the application transforms and evaluates the position; the saved record retains the required location and quality fields.
A Bluetooth status screen can support the connection step, but it does not prove which provider the field application uses. A marker moving on a map can show that some location reaches the app, but it does not by itself identify the receiver, coordinate transformation, fix type or accuracy source.
Use Rugged Tablets to compare the host-device form factor and documented interfaces. Treat receiver compatibility, driver behaviour and application integration as exact-model and exact-version questions.
Follow one named Field Maps example
Esri's Field Maps high-accuracy data collection documentation says an external receiver must be connected and then selected as the location provider in Field Maps. Once selected, that provider is the source used until another is chosen. For non-Trimble or Spectra Precision receivers in the documented workflow, the user adds the provider, selects the receiver and records antenna height where relevant.
The same documentation states that Field Maps communicates with supported receivers through specified NMEA 0183 sentences and that not every receiver populates every metadata field. It also distinguishes the receiver's coordinate system from the map coordinate system and uses a location profile to define a horizontal datum transformation when needed.
This is a concrete Esri Field Maps workflow, not a universal Android setting. Another application may use the system location service, a vendor service, a serial or TCP stream, or its own SDK. The required steps and available metadata must come from that application and receiver documentation.
Check the active provider inside the application
In the editorial example, a survey team pairs an external receiver to an Android tablet. The receiver vendor's utility shows a corrected position, yet the test feature's metadata says the position source is the integrated provider. The team does not change acceptance limits or assume that Bluetooth is faulty. It first opens the field application's provider setting and confirms which source is active.
After selecting the external provider, the team records a new point in a controlled location. It saves receiver name, position source, fix type, fix time, horizontal accuracy, satellite count and coordinate-system fields where the configured feature layer and receiver provide them. It then checks that the intended location profile and transformation are named in the record.
This is an editorial test sequence based on documented Field Maps concepts, not a customer result. A missing field may mean the layer was not prepared, the receiver did not supply it, the connection route omitted it or the application version does not expose it. Silence is not enough to select one cause.
Use one evidence table across the path
| Layer | Evidence to capture | What that evidence does not prove alone |
|---|---|---|
| Receiver solution | Receiver status, fix type, correction state, time and antenna setup | It does not prove that the host or field app consumes this solution. |
| Host connection | Named receiver, transport and connected state | It does not prove that the app selected this receiver as its provider. |
| Application provider | Active provider name and application/version settings | It does not prove that the correct coordinate profile or output fields are configured. |
| Coordinate handling | Receiver CRS, map/layer CRS and named transformation | It does not prove that each saved feature met the project's accuracy rule. |
| Saved feature | Position source, fix type, time, accuracy and other required metadata | It does not prove that unsupported or empty fields were available upstream. |
The pass condition should join the rows: the named receiver produced the solution, the application selected it, the expected coordinate handling was applied and the saved feature retained the required evidence. A green icon in only one row is not an end-to-end result.
Understand direct and indirect Android routes
Esri's Survey123 FAQ distinguishes a direct external-receiver connection from an Android mock-location route. For supported direct connections, the application can obtain additional metadata such as accuracy and satellite information. With an indirect mock-location route, the app may receive a position without the same additional receiver metadata.
That distinction matters in procurement. Two routes may draw a point at a similar place while giving the application different evidence about source and quality. If the workflow requires fix type, correction age, satellite count or receiver identity, verify that the selected route and application version preserve those fields rather than assuming any delivered latitude/longitude is equivalent.
Android, iOS and Windows use different transport and permission paths. Esri's named receiver lists and tested-device notes are scoped to its products and versions; they are not a certification of every receiver, operating-system build or rugged tablet.
Test the switch and the failure boundary
Record a positive control with the external receiver selected and a negative control with the integrated provider intentionally selected. The saved position-source evidence should change in the expected way. If the application cannot expose a reliable provider identity, define another documented observation rather than labelling the route by assumption.
Then interrupt only one layer at a time. Disconnect the receiver while leaving the application open, remove the correction input while keeping the receiver connected, and select a different provider without changing the receiver. Observe whether the app stops collection, falls back to another source or continues with a changed status. Do not assume automatic fallback; record the exact application/version behaviour.
For the broader positioning acceptance target, use GNSS, DGNSS and RTK for Field Mapping. For unconfirmed field records and later synchronization, use Offline Barcode Capture and Unconfirmed Transactions only for the application-state principle, not as GNSS-specific evidence.
Bring the complete data-path packet to the purchase discussion
Provide the host model and OS build, field application and version, receiver model/firmware/region, transport, expected NMEA or SDK route, correction source, antenna arrangement, coordinate reference systems, transformation, required status fields and acceptance rule. Include a sample layer or form with the actual metadata fields and one bounded test location.
Ask the receiver and application suppliers to identify the supported connection route, active-provider selection, message or SDK version, available metadata, fallback behaviour and coordinate handling. Ask the hardware supplier to confirm the host interfaces and OS configuration for the exact deployment model.
Use Rugged Tablet Field Operations to connect the location path to the real field form, then use Integration & Support and contact AIDC GO with the complete configuration. The decision is not whether the receiver can pair. It is whether the intended position source reaches the named application with the quality and coordinate evidence the project must retain.