ST1 Bluetooth HUD on Zebra TC53 — Admin Troubleshooting Guide¶

Audience	Administrator owning the full device-management stack (SOTI MobiControl, Ivanti Velocity, internal IT / device diagnostics).
Environment	Zebra TC53, Android 14 (managed) SOTI MobiControl (Android Enterprise / Device Owner) Ivanti Velocity TE (Android app + Velocity Console) Six15 ST1 Bluetooth HUD
Integration model	Intent Interface — Velocity broadcasts `com.six15.hudservice.ACTION_SEND_TEXT` to the Six15 ST1 service.
External escalation	`[escalate to Six15]` is the only handoff. Use the diagnostic packet in Section 8 when opening a Six15 case.
Version	1.0 (Admin Edition) — 2026-06-05

1. Scope¶

This guide is the technical companion to the operations-manager SOP for the ST1 Bluetooth HUD. It assumes platform familiarity with SOTI MobiControl, Ivanti Velocity (Console and Android app), and Android Enterprise on Zebra devices. Six15 is the only external escalation; everything else is in-house.

[escalate to Six15] markers throughout the guide flag the points where the symptom is most likely a HUD or Six15-service issue rather than a configuration issue, and a support ticket is the next step.

2. Architecture and Data Flow¶

Five components, two communication channels. The HUD only renders what the Six15 ST1 service sends to it; if the HUD output is wrong, the fault is in the chain feeding it.

Component	Identifier / role	Notes
Velocity TE app	`com.wavelink.velocity`	TE host client; runs Velocity scripts (JavaScript) on screen events.
Six15 ST1 service	`com.six15.st1_connect`	Holds Intent Interface and AIDL Interface; exposes IntentInterfaceActivity.
Intent Interface entry	`com.six15.intent_interface.IntentInterfaceActivity`	Target of Action.launch() from Velocity.
Primary broadcast action	`com.six15.hudservice.ACTION_SEND_TEXT`	Velocity → Six15 screen update.
Smart Velocity script	`six15_smart_velocity.js`	Default integration — generic, screen-agnostic.
ST1 HUD link	Bluetooth (post-pair); initial pair via NFC tap	Pair is also dropped when the HUD is placed in its charging dock.
Velocity project file	.wldep on /sdcard/Android/data/com.wavelink.velocity/files/	Deployed via Velocity Console export, distributed by SOTI.

End-to-end flow

Step	What Happens
NFC tap	TC53 to HUD — pairs the HUD; Bluetooth connection established. Pairing also drops automatically when the HUD is placed in its charging dock.
App start	Velocity launches the Six15 ST1 service via Action.launch({package, class}) on a session-scope script.
Screen transition	Velocity TE screen event fires WLEvent.on(“ScreenUpdated”); the linked script reads template values via ModernScreen.getTextById() and broadcasts ACTION_SEND_TEXT.
Render	Six15 ST1 service renders the extras (text0/text1/text2 …) into a compressed image (or set of drawing commands) and sends this information to the HUD over Bluetooth.
Draw	ST1 hardware decompresses the image, performs any drawing commands, and displays the image.

Two facts that constrain everything below:

Initial pairing requires NFC. Subsequent communication requires Bluetooth. Both must be permitted by the active device profile.

Inter-app communication is via standard Android intents. Anything that restricts intent broadcasting between com.wavelink.velocity and com.six15.st1_connect will break the integration.

3. First-Cut Triage¶

Use this to pick a starting point. The “Look first at” column tells you which console or tool to open. Multiple rows can apply during a complex incident — work them in parallel.

Observed symptom	Look first at	First action
HUD pairs but stays blank.	MobiControl: Permissions, FG service	Verify Bluetooth, `BLUETOOTH_CONNECT`, `BLUETOOTH_SCAN` runtime grants, battery optimization exemption, and that the Six15 ST1 foreground service is permitted to run.
HUD won’t pair (NFC tap does nothing).	MobiControl: AE restrictions	Verify NFC and Bluetooth are enabled in the AE profile; confirm no Bluetooth allowlist is blocking the ST1; verify pairing isn’t restricted by lockdown policy.
HUD connects, splash screen only.	Velocity Console: scripts/scopes	Confirm the active host profile is HUD-enabled and the Six15 integration script is linked to the correct scope. Run the Six15 built-in demo to isolate.
HUD updates pause when device is idle.	MobiControl: Power policy	Add com.six15.st1_connect to battery optimization exemption; verify App Standby Bucket is ACTIVE/WORKING_SET; verify `POST_NOTIFICATIONS` is granted (FGS requirement on Android 13+).
com.six15.st1_connect missing.	MobiControl: App Catalog	Confirm app catalog assignment to the device group; check policy push history; redeploy.
Single device affected.	MobiControl: Device inventory	Verify device shows Compliant; verify last sync time; compare effective permissions and policy version against a peer. Re-sync; factory-reset and re-enroll if symptoms persist.
Fleet-wide regression.	MobiControl: Change log	Pull policy/app/OS change log for the affected device group over the last 24-48h. The most recent change is the prime suspect; assess rollback feasibility for the group.

4. SOTI MobiControl Configuration Reference¶

Minimum policy surface for a working ST1 deployment on Android 14. Verify each item for the affected device group via the MobiControl console (Profile / Configurations and Application Catalog).

4.1 Connectivity policies¶

Policy area	Required setting	Notes
Bluetooth (AE restriction)	`DISALLOW_BLUETOOTH = false;` `DISALLOW_CONFIG_BLUETOOTH = false;`	Both must be false. The latter blocks new pairings even when Bluetooth itself is allowed.
NFC (AE restriction)	NFC radio not disabled by profile.	ST1 pairing uses NFC tap. If NFC is hard-disabled, pairing cannot occur.
Bluetooth allowlist	If allowlist mode is enabled, include the ST1 device class or MAC range.	Allowlists based on MAC alone may not match BLE service-based discovery; prefer device-name or class filters where supported.
Location (Android 12+)	`ACCESS_FINE_LOCATION` grant only required if the Six15 app declares the legacy BLE scan permission set.	If com.six15.st1_connect declares `BLUETOOTH_SCAN` with the `neverForLocation` flag, Location is not required.

4.2 Application Catalog¶

Package	Required state	Notes
com.six15.st1_connect	Required / Auto-install; version pinned to the validated build	Latest service app (SDK 5.0.2 family at time of writing). If pinned, ensure the pin is current; mismatches with older SDKs may not support all ACTION_SEND_TEXT extras.
com.wavelink.velocity	Required / Auto-install	Version must be compatible with the deployed .wldep schema and any custom scripts.

4.3 Runtime Permission policy¶

Apply a Runtime Permission policy (Android Enterprise) that grants — not just prompts — the following on com.six15.st1_connect:

android.permission.BLUETOOTH_CONNECT           → GRANT
android.permission.BLUETOOTH_SCAN              → GRANT
android.permission.POST_NOTIFICATIONS          → GRANT   (Android 13+ FGS requirement)
android.permission.ACCESS_FINE_LOCATION        → GRANT   (only if neverForLocation flag is NOT set on BLUETOOTH_SCAN)

Set policy default to GRANT for these specifically rather than relying on user prompt — staff cannot grant runtime permissions on a locked-down device, and ungranted permissions silently break Bluetooth operations on Android 12+.

4.4 Power and background-activity policies¶

Setting	Required value	Why
Battery optimization exemption	com.six15.st1_connect exempt	Without exemption, Doze mode and App Standby will throttle the Six15 service when the device is idle, causing screen updates to stall.
App Standby Bucket	ACTIVE or WORKING_SET	Restricted/Rare buckets aggressively defer background work; FREQUENT may also pause foreground service refresh on some Zebra firmwares.
Background restriction	Off for com.six15.st1_connect	User-visible “Restrict background activity” toggle has an MDM equivalent; must be off.
Foreground service allowance	Permitted for com.six15.st1_connect	Six15 service runs as a foreground service to maintain the Bluetooth link. Requires `POST_NOTIFICATIONS` on Android 13+.

4.5 Inter-app communication and lockdown¶

No intent-broadcast restriction blocking com.wavelink.velocity from sending to com.six15.st1_connect. If a managed configuration enumerates allowed targets for Velocity’s broadcasts, com.six15.st1_connect must be in that list.

Both packages must permit RECEIVE_BOOT_COMPLETED (or equivalent) so the chain is intact after a device reboot — relevant for swing-shift handoffs without manual app launch.

If kiosk / Lock Task Mode is in use: both com.six15.st1_connect and com.wavelink.velocity must be in the allowed package list, and Lock Task must permit foreground services. Single-app kiosk on Velocity alone will block the Six15 service.

4.6 OEMConfig / Zebra MX considerations¶

On Zebra devices managed via SOTI, Zebra MX profiles delivered through OEMConfig can override Android Enterprise settings depending on policy ordering. Two specific conflicts to watch for:

A Zebra MX Bluetooth manager profile disabling pairing UI even though AE policy permits Bluetooth.

A Zebra MX power manager profile forcing aggressive sleep behavior despite AE-level battery exemption.

Confirm Zebra MX and AE policies are not contradicting each other. Resolve in favor of the AE policy unless a Zebra-specific requirement supersedes it.

5. Ivanti Velocity Configuration Reference¶

Velocity-side configuration required for HUD output, plus the most common diagnostic checks in Velocity Console.

5.1 Required project artifacts¶

A HUD-enabled Velocity project must contain, at minimum:

A session-scope launcher invoking Action.launch() against com.six15.st1_connect / com.six15.intent_interface.IntentInterfaceActivity.

Either the Six15-provided six15_smart_velocity.js script linked to the session scope (Smart Velocity model), or per-template scripts linked to @TemplateName scopes (Custom Velocity model).

If using the Custom model: matching Component IDs on each template, populated as script parameters.

Reference: minimal launcher (session scope)
  Action.launch({
    package: "com.six15.st1_connect",
    class:   "com.six15.intent_interface.IntentInterfaceActivity"

});

Reference: minimal screen broadcast (template scope)

function sendTextToHud(event) {
    var body = ModernScreen.getTextById(body_text_id);
    if (body == null){
        return;
    } else {
        body = body.trim();
    }
    Action.sendBroadcast({
        action: "com.six15.hudservice.ACTION_SEND_TEXT",
        flags: ["ReceiverForeground"],
        extras: [
            { name: "text0", value: "Scan Location", type: "string" },
            { name: "text1", value: body, type: "string" }
        ]
    });
}
sendTextToHud();
WLEvent.on("ScreenUpdated", sendTextToHud);

5.2 Diagnostic checks in Velocity Console¶

Open the deployed Velocity project. Verify the script(s) exist on the Tasks list and that their text matches the controlled version.

On the Tasks tab, confirm each HUD script’s Linked Scope. Smart Velocity expects session (no @ prefix). Custom scripts expect @<TemplateName> — verify by switching to Screens, selecting a sample screen of that template, and reading the Scripts panel.

For Custom scripts, validate every Component ID parameter resolves on the linked template. Stale IDs after a TE screen redesign are a frequent cause of “splash-only” symptoms even when the script runs.

Velocity halts ALL scripts on a single JavaScript syntax/runtime error. If one script has been edited recently and the HUD has been silent across all templates, suspect a syntax error before suspecting SOTI. These error messages can be seen in the device’s logcat output.

5.3 Multi-profile pitfall¶

If the Velocity app on the device presents multiple host profiles at startup, users can select a profile without the HUD integration. Mitigations, in order of preference:

Deploy only the HUD-enabled profile to the affected device group.

If multiple profiles are operationally required, replicate the all the Six15 related scripts (including the initial session script) and re-link them to their corresponding template.

This is easiest to do by duplicating the HUD profile, and re-applying any differences.

If duplicating can’t be done, the other profiles likely won’t include screen and template data for HUD enabled screens. You’ll have to import a WLTSC screen recording containing those screens, re-create matching templates, re-create ModernScreen ID’s, and finally re-link.

If a non-HUD profile must coexist, document it explicitly and train accordingly — this is the single most common cause of “the HUD doesn’t work for that one worker.”

5.4 .wldep deployment via SOTI¶

Target path on the device: /sdcard/Android/data/com.wavelink.velocity/files/.

Velocity may need to be restarted on the device to enumerate a newly delivered .wldep. SOTI file-deployment policies should sequence the file copy before any “open Velocity” action.

Verify the deployed file is the intended version — older .wldep files in the same folder are not auto-cleaned, and Velocity will list any valid file as an available profile.

It is recommended to use the same file name so the file always gets replaced and is the most recent.

6. Device-Level Diagnostics¶

Checks for the device itself, used to confirm state before pinning a cause on SOTI policy or a Velocity script. ADB commands are listed for environments where a debug profile permits USB debugging on the affected device; otherwise use the MobiControl console equivalents.

6.1 Inventory and compliance¶

MobiControl: device shows Compliant; Last Seen within expected sync window; assigned to the correct device group.

Effective policy version on the device matches the latest pushed policy version. A device in “Pending” or “Out of Compliance” state has likely missed a recent change.

Android build number and Zebra BSP version match the validated baseline for this deployment.

6.2 App state verification (ADB)¶

# App installed and version
adb shell pm list packages -f | grep six15
adb shell dumpsys package com.six15.st1_connect | grep versionName

# Effective runtime permissions
adb shell dumpsys package com.six15.st1_connect | grep -E "permission|granted="

# Battery optimization state
adb shell dumpsys deviceidle whitelist | grep six15

# App Standby bucket
adb shell am get-standby-bucket com.six15.st1_connect

# Foreground service status
adb shell dumpsys activity services com.six15.st1_connect

Without ADB, the equivalent reports in the MobiControl console: app inventory, effective permissions, and policy-applied report for the device.

6.3 Log collection¶

If logs can be obtained (debug profile, bug-report capture, or vendor remote-support tool), filter logcat by these tags / packages when bundling a case for Six15:

Source	Filter	Looking for
Six15 service	`logcat \| grep -i six15`	Service lifecycle, Bluetooth state, intent reception.
Velocity	`logcat \| grep -i -E 'wavelink\|velocity'`	Script errors, scope transitions, broadcast send attempts.
Bluetooth subsystem	`logcat -b system \| grep -i bluetooth`	Pairing/bond state, GATT errors, ACL disconnects.
Power / Doze	`logcat \| grep -i -E 'deviceidle\|powermanagerservice'`	App Standby transitions, FGS terminations.

6.4 Network¶

Velocity TE host reachable from the device subnet; DNS resolves; TLS chain valid (if HTTPS to the TE host).

If a corporate VPN/MDM tunnel is in scope, confirm it is up and not stripping outbound intent or broadcast payloads (rare, but seen in tightly-managed environments).

7. Failure Mode Reference¶

Each failure mode below lists the most likely technical root causes and the consolidated diagnostic procedure. Section references point into the configuration sections above. Numbering aligns with Section 5 of the manager-edition SOP for cross-referencing during joint calls.

7.1 HUD blank after pairing¶

Likely causes: Bluetooth disabled at the policy layer; BLUETOOTH_CONNECT or BLUETOOTH_SCAN not granted; Six15 service unable to start its foreground service (typically POST_NOTIFICATIONS missing on Android 13+); kiosk policy blocking the Six15 launcher.

Procedure:

Verify items 4.1, 4.3, and 4.4 in MobiControl. Re-push the runtime permission policy and confirm grant state from the console.

Confirm com.six15.st1_connect is RUNNING with an active foreground service (6.2 dumpsys, or MobiControl app inventory).

[escalate to Six15] If permissions and policies are correct and the service is running but the HUD remains blank, open a Six15 case with the diagnostic packet in Section 8.

7.2 Pair fails on NFC tap¶

Likely causes: NFC radio disabled; Bluetooth pairing config disabled (DISALLOW_CONFIG_BLUETOOTH = true); Bluetooth allowlist excludes the ST1; HUD currently paired to another handheld AND not yet docked or re-tapped (re-tap or docking forces re-pair).

Procedure:

Verify item 4.1 in full.
Place the ST1 in its charging dock for ~10 seconds, remove, and re-tap. This clears any prior pairing definitively.
Swap-test: ST1 on a known-good TC53, and a known-good ST1 on the affected TC53. Outcome localizes the fault to handheld vs. HUD.
[escalate to Six15] If the same ST1 fails on multiple known-good handhelds, the HUD hardware is suspect — open a Six15 case.

7.3 HUD connects but only the splash screen renders¶

Likely causes (ordered by frequency in this deployment): non-HUD Velocity profile selected; Six15 script not linked to the expected scope; Component ID drift on a template after a TE screen change; script syntax error halting all Velocity scripts.

Procedure:

On the device, launch com.six15.st1_connect and run the built-in demo. If the demo renders, the HUD, Bluetooth, and Six15 service are all working — the issue is upstream in Velocity. If it does not render, treat as 7.1.
In Velocity Console, verify items 5.2 and 5.3. Cross-check linked scopes and recent script edits.
[escalate to Six15] Only after Velocity is verified clean and the symptom persists — typically a corner case in the Intent Interface itself.

7.4 Updates stop advancing during idle periods¶

Likely causes: Doze / App Standby restricting the Six15 foreground service; battery optimization not exempting com.six15.st1_connect; POST_NOTIFICATIONS not granted (foreground service cannot show its persistent notification, OS terminates it).

Procedure:

Verify item 4.4 in full in MobiControl. Add battery optimization exemption if missing. Confirm POST_NOTIFICATIONS is granted (4.3).
Measure: capture how long the device sits idle before symptoms appear (1, 2, 5, 10 min). Buckets above ~5 min point toward App Standby; sub-1 min points toward an explicit force-stop policy.
If a Zebra MX OEMConfig power profile is in use, verify 4.6 — Zebra-level power policy can override AE.

7.5 com.six15.st1_connect missing on a device¶

Procedure:

Confirm the app is on the assigned catalog for this device group; check the app-deployment history for this specific device; redeploy. Do not sideload — the device will fall out of compliance.

7.6 Single device affected¶

Procedure:

Run a peer comparison: same device model, same group, same firmware. Compare effective permissions, App Standby bucket, FGS state, and policy version against a working peer.
Re-sync the affected device. If symptoms persist post-sync, factory-reset and re-enroll.
[escalate to Six15] If a clean re-enroll still fails to restore the HUD on that specific device while peers work, hardware fault is likely — open a Six15 case.

7.7 Fleet-wide regression¶

Stop per-device troubleshooting. The cause is almost always a recent policy push, app deployment, or OS update applied to the device group. Workflow continuity: operations can continue on the TC53 alone — the HUD is an accessory to the Velocity workflow, not part of it.

Procedure:

Pull the change log for the affected device group across the last 24-48 hours. The most recent change is the prime suspect.
If a .wldep redeployment is in the recent change list, diff it against the previous version in Velocity Console.
If an OS / BSP update is in the recent change list, verify the new build is on the validated baseline.
Assess rollback feasibility for the affected device group while root cause is being identified.

8. Diagnostic Packet for Six15 Support¶

When opening a Six15 case, bundle the following. Items in italics are nice-to-have but materially accelerate resolution.

Symptom statement: what was expected, what was observed, when it started, scope (single device / device group / fleet).

Affected device serials, ST1 HUD serials, and Velocity host profile name(s).

Versions: Android build, Zebra BSP, com.six15.st1_connect, com.wavelink.velocity, deployed .wldep filename + Console export timestamp.

Effective runtime permissions for com.six15.st1_connect (granted vs. denied for each in 4.3).

Result of the Six15 built-in demo on an affected device (worked / did not).

Result of swap testing (HUD-swap and handheld-swap outcomes).

Recent SOTI change log for the device group (last 7 days).

Logcat capture filtered to the tags in 6.3, covering 5 minutes before and after symptom onset.

Velocity Console export (.wlproj or backing zip) of the deployed project.

Output of dumpsys package, dumpsys deviceidle whitelist, and am get-standby-bucket for com.six15.st1_connect.

9. Reference¶

9.1 Identifiers¶

Item	Value
Six15 service package	`com.six15.st1_connect`
Six15 Intent Interface activity	`com.six15.intent_interface.IntentInterfaceActivity`
Six15 primary broadcast action	`com.six15.hudservice.ACTION_SEND_TEXT`
Velocity package	`com.wavelink.velocity`
Velocity files directory (on device)	`/sdcard/Android/data/com.wavelink.velocity/files/`
Smart Velocity script filename	`six15_smart_velocity.js`
Velocity event for screen refresh	`WLEvent.on("ScreenUpdated", ...)`
Velocity API: read template text	`ModernScreen.getTextById(componentId)`

9.2 Critical permissions (com.six15.st1_connect)¶

android.permission.BLUETOOTH_CONNECT	Connect to the paired ST1; required for all BT communication on Android 12+.
android.permission.BLUETOOTH_SCAN	Discover the ST1 if not already bonded. Should be declared with `neverForLocation` where possible.
android.permission.POST_NOTIFICATIONS	Display the foreground service notification (Android 13+ requirement); without it the service is stopped by the OS.
android.permission.ACCESS_FINE_LOCATION	Required only on legacy permission setups (Android <12 or BT scan without `neverForLocation`).

9.3 Six15 documentation pointers¶

ST1 SDK overview, provided apps, and device compatibility — https://six15.engineering/st1_sdk_overview/

Intent Interface API definition (ACTION_SEND_TEXT and related extras) — https://six15.engineering/intent_interface/

Velocity integration guide (Smart Velocity script, scope linking, screen templates) — https://six15.engineering/velocity/

Smart Velocity script source — https://raw.githubusercontent.com/Six15-Technologies/Velocity-TE-Example/master/smart_integration/src/six15_smart_velocity.js

Known issues and SDK changelog — https://six15.engineering/reference/