lars/splat-indoor-navigation
1
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Research: MikroTik TG-BTS-IN beacon capabilities and configuration #4

New Issue
Closed
opened 2026-08-11 15:41:38 +00:00 by lars · 1 comment
lars commented 2026-08-11 15:41:38 +00:00
Owner
Copy Link
Copy Source

Question

We own 3x MikroTik TG-BTS-IN. What can they actually do, and how do we configure them for positioning?

Answer specifically:

  • Advertising formats supported (iBeacon, Eddystone, MikroTik's own TG format) and whether iBeacon can be emitted directly.
  • Minimum advertising interval — live positioning wants ~100ms; the usual default of 700-1000ms is far too slow.
  • TX power settings and their nominal ranges.
  • How configuration is done: does it require a RouterOS device / MikroTik app / cloud, or can it be set standalone? This determines whether the beacons are usable at all in a session.
  • Battery life at the fastest advertising interval — relevant to any later deployment story.
  • Whether 3 beacons are enough for 2D trilateration in a single room, or whether more are needed for a non-degenerate geometry.

Part of the wayfinder map #1.

## Question We own **3x MikroTik TG-BTS-IN**. What can they actually do, and how do we configure them for positioning? Answer specifically: - Advertising formats supported (iBeacon, Eddystone, MikroTik's own TG format) and whether iBeacon can be emitted directly. - **Minimum advertising interval** — live positioning wants ~100ms; the usual default of 700-1000ms is far too slow. - TX power settings and their nominal ranges. - How configuration is done: does it require a RouterOS device / MikroTik app / cloud, or can it be set standalone? This determines whether the beacons are usable at all in a session. - Battery life at the fastest advertising interval — relevant to any later deployment story. - Whether 3 beacons are enough for 2D trilateration in a single room, or whether more are needed for a non-degenerate geometry. --- Part of the wayfinder map #1.
lars added this to the Wayfinder: RN prototyping spec milestone 2026-08-11 15:41:38 +00:00
lars added the wayfinder:research label 2026-08-11 15:41:38 +00:00
lars added a new dependency 2026-08-11 15:42:12 +00:00
#9 Configure and verify the three TG-BT5-IN beacons
lars commented 2026-08-11 15:49:57 +00:00
Author
Owner
Copy Link
Copy Source

Answer

Product identity first: there is no MikroTik "TG-BTS-IN". The part number is TG-BT5-IN — "BT5" with a five, for Bluetooth 5. MikroTik ships exactly two Bluetooth tags: TG-BT5-IN (indoor) and TG-BT5-OUT (outdoor, adds NFC, a temperature sensor and data logging). Both are BLE 5.2 on a Silicon Labs BG22 SoC, $10 list. Everything below is TG-BT5-IN.

(Claims below were re-verified directly against the Android manual, the TG-BT5-IN manual and the product page on 2026-08-11.)

1. Advertising formats — iBeacon is emitted directly

Five selectable advertisement types. The Android manual lists them verbatim as "DeviceName, MikroTik, Eddystone-TLM, Eddystone-UID and iBeacon"; the product page says the tag broadcasts "iBeacon, Eddystone or MikroTik telemetry advertising packets".

Format Payload
MikroTik (factory default) proprietary 26-octet payload, company ID 4f09 — accel X/Y/Z, temperature, uptime, trigger flags, battery %
iBeacon full Apple layout: 16-byte proximity UUID + Major + Minor + TxPower byte. MikroTik's default UUID is b2b98de4-c81c-47c2-b14e-791b3e5587ec; Major/Minor freely settable 0–65535
Eddystone-UID 10-byte Namespace + 6-byte Instance, both settable
Eddystone-TLM battery voltage, temperature, adv count, uptime
DeviceName plain name broadcast; added in tag firmware 2.5.0

Yes — the tag emits standards-compliant iBeacon frames itself. No gateway, no translation layer. Each format has its own Enable advertising checkbox plus its own interval / TxPower / trigger block.

For our stack: set the tags to iBeacon. That is the one format react-native-beacons-manager handles natively on both platforms, and on iOS it is the only way to identify a tag at all (see §4 caveat).

2. MINIMUM ADVERTISING INTERVAL — 20 ms. This is not a blocker.

"Advertisement interval (20ms...24h or disable)" — Beacon Manager for Android manual, "Advertisment properties" table, doc rev. 2025-08-26

  • Factory default: 5.0 seconds (TG-BT5-IN manual, factory-settings table). That is worse than the 700–1000 ms the ticket feared — unusable as shipped.
  • Minimum settable: 20 ms — the BLE spec floor for non-connectable undirected advertising.
  • Our 100 ms target sits comfortably in range, 5x above the floor.
  • Firmware 2.2.0 added "support for non-standard advertising intervals"; 2.5.0 specifically "reduced watchdog-timer power draw for any beacon with interval < 7 s" — MikroTik deliberately optimised the fast-interval case.
  • Minor doc inconsistency: the iOS manual says 20ms...10s, the Android one 20ms...24h. Both agree on the 20 ms floor, so it does not affect us. Probably a stale iOS page predating fw 2.2.0.

Bottom line: the tags must be reconfigured off their 5 s default before they are useful, and they can be.

3. TX power and range

"The transmit power level in decibel-milliwatts. Can vary between -28dBm...6dBm." — Android manual

  • Default 0 dBm. Range -28 dBm … +6 dBm.
  • Antenna 1.5 dBi, 360° beamwidth (datasheet) → EIRP ceiling ≈ +7.5 dBm.
  • MikroTik publishes no range figure in metres. Anywhere. Not the product page, not the datasheet, not the manual — only "short distances" / "proximity-based". Any metre number you find online is reseller marketing, not primary. At +6 dBm expect a small room to be trivially covered; for a 4x5 m room we will likely want to reduce TX power so RSSI has usable dynamic range across the room instead of saturating.

4. Configuration — NO RouterOS DEVICE REQUIRED. Phone-only. But bring a magnet.

This was the ticket's kill-switch question, so plainly: we do not need a RouterOS device, a KNOT, or any MikroTik hardware whatsoever. Both halves of the workflow are ordinary-phone operations.

Two real gates — both physical, neither RouterOS:

  1. The tags are asleep out of the box. They ship in "Factory sleep mode" and broadcast nothing. To wake one: "put a magnet to the tag's edge (where the 'Magnetic switch' is) and hold it for 3-10 seconds until LED turns off." If nobody brings a magnet, the session is dead on arrival. This is the actual risk item, not RouterOS.
  2. Entering config mode also needs the magnet. From the app you press CONFIG, then "put a magnet over the reed-switch for 5-10 seconds". So reconfiguring is a deliberate, hands-on, per-tag operation — you cannot re-tune 3 tags from across the room mid-demo. A "Batch Configuration" flow exists but still requires magnet-touching each tag in turn.

Footgun — do not set a Write Protection password. The app can lock a tag's settings behind a 6-symbol password, and per the Android manual: "once the password is set, there is no way to remove password protection (you can only edit it)." A locked tag is read-only without the password. Tags do not ship locked. Leave it alone.

Firmware updates are also app-driven; files at https://download.mikrotik.com/firmware/bt-tag/latest — worth pulling ≥2.5.0 for the sub-7 s power optimisation before the session.

5. Battery — the real cost of 100 ms

  • Built-in, NON-REPLACEABLE LiMnO2 CR2032, 220 mAh (TG-BT5-IN manual / datasheet). The OUT model has 550 mAh. You cannot swap it; when it's flat the $10 tag is landfill.
  • MikroTik's only published figures: datasheet "Estimated battery life (MikroTik format, 1s/5s update interval): 2-6 years"; product page "if you set the interval to 1 second, the battery will typically last two years".
  • MikroTik publishes nothing for 100 ms or 20 ms.

[My estimate, not a MikroTik source] Scaling MikroTik's 1 s → 2 years figure by packet count (100 ms = 10x the rate) gives roughly 2–4 months at 100 ms, and weeks at 20 ms. Order of magnitude is the point: a 100 ms config converts a 6-year tag into a ~one-quarter consumable. The authoritative number is free and on-device — the Beacon Manager app has an "Estimated battery life" screen that "calculates how many packets are estimated to be broadcasted daily, for how long the tag will be active, and the estimate for the average daily power consumption" from your actual settings. Read it off the app in the session and record it; that closes this question properly.

Mitigations if we want to keep the tags alive: disable advertising channels 38/39 (fw 2.4.0, ~3x saving, costs scan reliability), drop TX power toward -28 dBm (which we want anyway per §3), disable the accelerometer entirely (fw 2.4.0). For a prototyping session this is all irrelevant — burn the battery. For any ship deployment story, 200–500 ms plus phone-side filtering is the sane operating point, not 100 ms.

6. Encryption / rotating IDs — will not break plain BLE scanning

Checked because it would have been a silent killer. It isn't one.

  • Encryption is opt-in, off by default, and MikroTik-format only. The setting reads "Encrypt (on/off) — note: only available for MikroTik format", AES-ECB over part of the payload with a random 2-byte salt per transmission. iBeacon and Eddystone modes have no encryption option at all — plaintext standards frames.
  • No rotating identifiers. No MAC randomisation option, no Eddystone-EID support, no rotating-key scheme documented anywhere in the settings tables. Identity is the static BLE MAC (which is what the tag's QR code encodes and what RouterOS filters on, e.g. print where address=DC:2C:6E:0F:C0:3D).
  • So from React Native: stable MAC + stable UUID/Major/Minor + RSSI. Nothing to decrypt, nothing that rotates. Just never tick the Encrypt box.
  • iOS caveat (platform, not MikroTik): iOS hides BLE MAC addresses from apps and gates iBeacon parsing behind CoreLocation. On iOS we must key off iBeacon UUID/Major/Minor, never MAC — another reason to run the tags in iBeacon mode. On Android, MAC is available but Location services must be ON or BLE scans silently return nothing.

7. Do 3 beacons suffice for a 4x5 m room?

[Standard BLE/RF geometry — my reasoning, not a MikroTik source.]

Three is the bare minimum for an unambiguous 2D fix, and minimum in the brittle sense: zero redundancy. With three ranges and three unknowns-minus-one you have no residual left over, so there is no way to detect — let alone reject — a single bad range. And RSSI ranges are routinely bad: 30–100% error per sample. Three circles will essentially never intersect at a point.

Geometry that kills you:

  • Collinear placement is the classic failure — three tags along one wall gives a mirror ambiguity about that line plus terrible conditioning along it. In a room you can sometimes resolve the mirror by clipping to the floor polygon, but the covariance stays awful. With only 3 tags, they must form a fat triangle spanning the room, not a line.
  • Clustered tags → tiny baseline, huge dilution of precision.
  • Thin//sliver triangles (three corners of one long wall) → high GDOP along one axis.
  • Mount all three at a consistent height ~2–2.5 m, above head height. A human body between tag and phone costs ~10–20 dB at 2.4 GHz, which RSSI ranging misreads as several metres. Keep them off metal and out of cabinets.

Realistic accuracy, so we set expectations before the bake-off:

  • Raw, uncalibrated, single-sample RSSI: 3–8 m error — larger than the room, i.e. meaningless.
  • With per-tag 1 m reference-RSSI calibration, a room-fitted path-loss exponent, 1–3 s temporal smoothing, and 4+ beacons: 1.5–3 m median with a long tail, worse near walls.
  • Best case in a small empty LOS-clean 4x5 m room: ~1–2 m. Sub-metre from RSSI is not achievable at any beacon count — multipath and body shadowing cap it. That is precisely why the industry moved to BLE 5.1 AoA/AoD (antenna arrays) and UWB (10–30 cm).
  • Honest framing for a 4x5 m room: RSSI trilateration gives you "which quadrant", not a smooth cursor. If the AR overlay needs a stable moving dot, RSSI will lose the bake-off to visual positioning on accuracy alone — and we should design the comparison to measure the right thing (zone-level latency and robustness, where BLE may genuinely win, vs. pose accuracy, where it will not).

Recommendation: 3 tags will produce a position, so the session is not blocked — but buy 3 more. At $10 each, going to 6 (four corners + two mid-wall) is the cheapest accuracy improvement available and is the difference between "a fix" and "a fix we can trust".

Verdict

The 3 beacons ARE usable for the bake-off as-is. No RouterOS device is needed — the ticket's kill-switch concern does not apply. Configuration is done entirely from an ordinary Android or iOS phone via the free MikroTik Beacon Manager app over BLE, RouterOS cannot configure tags at all, and reading advertisements needs nothing but our own React Native BLE scanner. No cloud, no license, no gateway.

Three things must happen or the session stalls:

  1. Bring a magnet. Non-negotiable. The tags ship asleep and broadcast nothing until a magnet is held to the reed switch for 3–10 s, and entering config mode needs another 5–10 s magnet hold per tag. This, not RouterOS, is the actual single point of failure. Any fridge magnet should do; bring two.
  2. Install MikroTik Beacon Manager before the session (iOS / Android links above) and re-flash to firmware ≥2.5.0 while you have connectivity.
  3. Reconfigure all 3 tags off their factory default of 5.0 s to 100 ms (floor is 20 ms, so there is headroom), switch format from MikroTik to iBeacon with distinct Major/Minor per tag, and reduce TX power below the 0 dBm default so RSSI isn't saturated across a 4x5 m room. Do not set a Write Protection password — it is irreversible.

Must buy/borrow — nothing mandatory, two things strongly advised:

  • A magnet (£0, but the session fails without it).
  • 3 more TG-BT5-IN, ~$10 each. 3 tags is the degenerate minimum with zero redundancy; 6 is the cheapest real accuracy gain we can buy. Not a blocker for the session, a blocker for trusting the numbers.

Set expectations now: RSSI trilateration in a 4x5 m room realistically delivers ~1.5–3 m, best case 1–2 m, i.e. quadrant-level rather than a smooth AR-anchor pose. Against camera-based visual positioning that is a loss on pose accuracy. Frame the bake-off around where BLE can actually win — cold-start time, robustness in the dark, no-camera-permission operation, zone-level presence — rather than positional accuracy, or the comparison is decided before we start.

One deployment caveat worth flagging early: the battery is non-replaceable, and 100 ms burns a 6-year tag in an estimated 2–4 months. Fine for a prototype, fatal for a cruise-ship rollout. Any real deployment story needs 200–500 ms plus client-side filtering, or different hardware.

Open / unresolved

  • Battery life at 100 ms is my extrapolation, not a MikroTik figure. MikroTik publishes only 1 s → 2 y and 5 s → 6 y. Action: read the app's on-device "Estimated battery life" screen at 100 ms during the session and post the real number here. Cheapest possible resolution.
  • No range-in-metres figure exists from MikroTik for any TX power. Must be measured empirically — do an RSSI-vs-distance calibration sweep in the session; we need it for the path-loss model anyway.
  • Can multiple advertisement formats broadcast simultaneously? Per-format Enable advertising checkboxes imply yes, but no MikroTik doc states it, nor what the combined air-time behaviour is. Matters if we ever want MikroTik-format telemetry and iBeacon at once. Test on the bench.
  • Interval upper bound contradicts between MikroTik's own pages — iOS manual 20ms...10s vs Android 20ms...24h. Irrelevant to us (we live at the floor), unresolved nonetheless.
  • Does the interval snap to the BLE 0.625 ms grid, or is it arbitrary? fw 2.2.0's "non-standard advertising intervals" hints at sub-spec values; step size is undocumented. Verify the tag actually delivers ~10 packets/s at the "100 ms" setting rather than something quantised — measure observed packet rate, don't trust the label.
  • Is the BLE MAC guaranteed static/public? Strongly implied (QR code encodes it, RouterOS filters on it, no randomisation setting exists) but never stated as a guarantee. Low risk; we key off iBeacon UUID/Major/Minor anyway for iOS reasons.
  • fw 2.4.0's changelog entry "optional password protection removal" is ambiguous — it may contradict the manual's "no way to remove password protection". Untested, and we intend never to set a password.
  • Which firmware first shipped iBeacon/Eddystone is unknown — the published changelog only reaches back to 1.4.0 and both formats already exist there. Treat as always-present.
  • The forums yielded nothing. The single TG-BT5-IN thread (forum.mikrotik.com/t/.../169799, Sep–Oct 2023) is about KNOT coverage in a warehouse; no MikroTik-staff statement on fast-interval operation, real-world battery drain at high rates, or positioning use exists that I could find. Nobody appears to be publicly using these tags for live positioning — we are off the beaten path, so budget bench time.
## Answer **Product identity first: there is no MikroTik "TG-BTS-IN".** The part number is **TG-BT5-IN** — "BT5" with a *five*, for Bluetooth 5. MikroTik ships exactly two Bluetooth tags: `TG-BT5-IN` (indoor) and `TG-BT5-OUT` (outdoor, adds NFC, a temperature sensor and data logging). Both are BLE 5.2 on a Silicon Labs BG22 SoC, $10 list. Everything below is TG-BT5-IN. - Product page: https://mikrotik.com/product/tg_bt5_in - User manual: https://help.mikrotik.com/docs/spaces/UM/pages/58720307/TG-BT5-IN (doc rev. **2024-10-22**) - Datasheet PDF: https://cdn.mikrotik.com/web-assets/product_files/TG-BT5-INTG-BT5-OUT_220249.pdf - Beacon Manager (Android) manual — the settings reference: https://help.mikrotik.com/docs/spaces/UM/pages/105742455/MikroTik+Beacon+Manager+for+Android+devices (doc rev. **2025-08-26**) - Beacon Manager (iOS) manual: https://help.mikrotik.com/docs/spaces/UM/pages/105742508/MikroTik+Beacon+Manager+for+iOS+devices (doc rev. **2024-10-21**) - Advertisement format reference: https://help.mikrotik.com/docs/spaces/UM/pages/105742533/MikroTik+Tag+advertisement+formats - Tag firmware changelog: https://help.mikrotik.com/docs/spaces/UM/pages/215351328/MikroTik+Bluetooth+TG-BT5-XX+tag+changelog *(Claims below were re-verified directly against the Android manual, the TG-BT5-IN manual and the product page on **2026-08-11**.)* --- ### 1. Advertising formats — iBeacon is emitted directly Five selectable advertisement types. The Android manual lists them verbatim as "**DeviceName, MikroTik, Eddystone-TLM, Eddystone-UID and iBeacon**"; the product page says the tag broadcasts "**iBeacon, Eddystone or MikroTik telemetry advertising packets**". | Format | Payload | |---|---| | **MikroTik** (factory default) | proprietary 26-octet payload, company ID `4f09` — accel X/Y/Z, temperature, uptime, trigger flags, battery % | | **iBeacon** | full Apple layout: 16-byte proximity UUID + Major + Minor + TxPower byte. MikroTik's default UUID is `b2b98de4-c81c-47c2-b14e-791b3e5587ec`; Major/Minor freely settable 0–65535 | | **Eddystone-UID** | 10-byte Namespace + 6-byte Instance, both settable | | **Eddystone-TLM** | battery voltage, temperature, adv count, uptime | | **DeviceName** | plain name broadcast; added in tag firmware **2.5.0** | **Yes — the tag emits standards-compliant iBeacon frames itself.** No gateway, no translation layer. Each format has its own `Enable advertising` checkbox plus its own interval / TxPower / trigger block. For our stack: set the tags to **iBeacon**. That is the one format `react-native-beacons-manager` handles natively on both platforms, and on iOS it is the *only* way to identify a tag at all (see §4 caveat). ### 2. MINIMUM ADVERTISING INTERVAL — 20 ms. This is not a blocker. > **"Advertisement interval (20ms...24h or disable)"** — Beacon Manager for Android manual, "Advertisment properties" table, doc rev. 2025-08-26 - **Factory default: 5.0 seconds** (TG-BT5-IN manual, factory-settings table). That is *worse* than the 700–1000 ms the ticket feared — unusable as shipped. - **Minimum settable: 20 ms** — the BLE spec floor for non-connectable undirected advertising. - **Our 100 ms target sits comfortably in range**, 5x above the floor. - Firmware **2.2.0** added "support for non-standard advertising intervals"; **2.5.0** specifically "reduced watchdog-timer power draw for any beacon with interval < 7 s" — MikroTik deliberately optimised the fast-interval case. - Minor doc inconsistency: the **iOS** manual says `20ms...10s`, the Android one `20ms...24h`. Both agree on the 20 ms floor, so it does not affect us. Probably a stale iOS page predating fw 2.2.0. **Bottom line: the tags must be reconfigured off their 5 s default before they are useful, and they can be.** ### 3. TX power and range > "The transmit power level in decibel-milliwatts. **Can vary between -28dBm...6dBm.**" — Android manual - Default **0 dBm**. Range **-28 dBm … +6 dBm**. - Antenna **1.5 dBi, 360° beamwidth** (datasheet) → EIRP ceiling ≈ **+7.5 dBm**. - **MikroTik publishes no range figure in metres. Anywhere.** Not the product page, not the datasheet, not the manual — only "short distances" / "proximity-based". Any metre number you find online is reseller marketing, not primary. At +6 dBm expect a small room to be trivially covered; for a 4x5 m room we will likely want to *reduce* TX power so RSSI has usable dynamic range across the room instead of saturating. ### 4. Configuration — **NO RouterOS DEVICE REQUIRED.** Phone-only. But bring a magnet. This was the ticket's kill-switch question, so plainly: **we do not need a RouterOS device, a KNOT, or any MikroTik hardware whatsoever.** Both halves of the workflow are ordinary-phone operations. - **Writing config:** the **MikroTik Beacon Manager** app, over plain BLE GATT from any Android or iOS phone. The TG-BT5-IN manual's setup procedure is literally "Install the 'MikroTik Beacon Manager' application and run the app". RouterOS is never mentioned as a configuration path — because it isn't one. - iOS: https://apps.apple.com/us/app/mikrotik-beacon-manager/id1561796698 - Android: https://play.google.com/store/apps/details?id=com.mikrotik.android.bt5 - **Reading advertisements:** any BLE scanner. RouterOS's own tag-tracking doc describes the KNOT as a *passive* scanner that "supports any BLE tag that sends advertisement data, including iBeacon, Eddystone, or any other format" (https://help.mikrotik.com/docs/spaces/ROS/pages/176914435/Bluetooth+tag-tracking+using+MQTT+and+ThingsBoard, rev. 2025-03-06). RouterOS **cannot configure tags at all** — that is exclusively the app's job. There is nothing privileged about a MikroTik gateway; our React Native app reads these tags with zero MikroTik infrastructure, no pairing, no cloud account, no license. **Two real gates — both physical, neither RouterOS:** 1. **The tags are asleep out of the box.** They ship in "Factory sleep mode" and broadcast *nothing*. To wake one: "put a magnet to the tag's edge (where the 'Magnetic switch' is) and hold it for **3-10 seconds** until LED turns off." **If nobody brings a magnet, the session is dead on arrival.** This is the actual risk item, not RouterOS. 2. **Entering config mode also needs the magnet.** From the app you press CONFIG, then "put a magnet over the reed-switch for **5-10 seconds**". So reconfiguring is a deliberate, hands-on, per-tag operation — you cannot re-tune 3 tags from across the room mid-demo. A "Batch Configuration" flow exists but still requires magnet-touching each tag in turn. **Footgun — do not set a Write Protection password.** The app can lock a tag's settings behind a 6-symbol password, and per the Android manual: "**once the password is set, there is no way to remove password protection (you can only edit it)**." A locked tag is read-only without the password. Tags do *not* ship locked. Leave it alone. Firmware updates are also app-driven; files at https://download.mikrotik.com/firmware/bt-tag/latest — worth pulling ≥2.5.0 for the sub-7 s power optimisation before the session. ### 5. Battery — the real cost of 100 ms - **Built-in, NON-REPLACEABLE LiMnO2 CR2032, 220 mAh** (TG-BT5-IN manual / datasheet). The OUT model has 550 mAh. You cannot swap it; when it's flat the $10 tag is landfill. - MikroTik's only published figures: datasheet "Estimated battery life (MikroTik format, 1s/5s update interval): **2-6 years**"; product page "if you set the interval to **1 second**, the battery will typically last **two years**". - **MikroTik publishes nothing for 100 ms or 20 ms.** **[My estimate, not a MikroTik source]** Scaling MikroTik's 1 s → 2 years figure by packet count (100 ms = 10x the rate) gives roughly **2–4 months at 100 ms**, and weeks at 20 ms. Order of magnitude is the point: **a 100 ms config converts a 6-year tag into a ~one-quarter consumable.** The authoritative number is free and on-device — the Beacon Manager app has an **"Estimated battery life"** screen that "calculates how many packets are estimated to be broadcasted daily, for how long the tag will be active, and the estimate for the average daily power consumption" from your actual settings. **Read it off the app in the session and record it; that closes this question properly.** Mitigations if we want to keep the tags alive: disable advertising channels 38/39 (fw 2.4.0, ~3x saving, costs scan reliability), drop TX power toward -28 dBm (which we want anyway per §3), disable the accelerometer entirely (fw 2.4.0). For a prototyping session this is all irrelevant — burn the battery. For any ship deployment story, **200–500 ms plus phone-side filtering is the sane operating point, not 100 ms.** ### 6. Encryption / rotating IDs — will not break plain BLE scanning Checked because it would have been a silent killer. It isn't one. - **Encryption is opt-in, off by default, and MikroTik-format only.** The setting reads "Encrypt (on/off) — note: only available for MikroTik format", AES-ECB over part of the payload with a random 2-byte salt per transmission. **iBeacon and Eddystone modes have no encryption option at all** — plaintext standards frames. - **No rotating identifiers.** No MAC randomisation option, no Eddystone-EID support, no rotating-key scheme documented anywhere in the settings tables. Identity is the static BLE MAC (which is what the tag's QR code encodes and what RouterOS filters on, e.g. `print where address=DC:2C:6E:0F:C0:3D`). - So from React Native: stable MAC + stable UUID/Major/Minor + RSSI. Nothing to decrypt, nothing that rotates. Just never tick the Encrypt box. - **iOS caveat (platform, not MikroTik):** iOS hides BLE MAC addresses from apps and gates iBeacon parsing behind CoreLocation. On iOS we must key off iBeacon UUID/Major/Minor, never MAC — another reason to run the tags in iBeacon mode. On Android, MAC is available but **Location services must be ON** or BLE scans silently return nothing. ### 7. Do 3 beacons suffice for a 4x5 m room? **[Standard BLE/RF geometry — my reasoning, not a MikroTik source.]** **Three is the bare minimum for an unambiguous 2D fix, and minimum in the brittle sense: zero redundancy.** With three ranges and three unknowns-minus-one you have no residual left over, so there is no way to detect — let alone reject — a single bad range. And RSSI ranges *are* routinely bad: 30–100% error per sample. Three circles will essentially never intersect at a point. **Geometry that kills you:** - **Collinear placement** is the classic failure — three tags along one wall gives a mirror ambiguity about that line plus terrible conditioning along it. In a room you can sometimes resolve the mirror by clipping to the floor polygon, but the covariance stays awful. **With only 3 tags, they must form a fat triangle spanning the room, not a line.** - Clustered tags → tiny baseline, huge dilution of precision. - Thin//sliver triangles (three corners of one long wall) → high GDOP along one axis. - Mount all three at a consistent height ~2–2.5 m, above head height. A human body between tag and phone costs ~10–20 dB at 2.4 GHz, which RSSI ranging misreads as several metres. Keep them off metal and out of cabinets. **Realistic accuracy, so we set expectations before the bake-off:** - Raw, uncalibrated, single-sample RSSI: **3–8 m error** — larger than the room, i.e. meaningless. - With per-tag 1 m reference-RSSI calibration, a room-fitted path-loss exponent, 1–3 s temporal smoothing, and 4+ beacons: **1.5–3 m median with a long tail**, worse near walls. - Best case in a small empty LOS-clean 4x5 m room: **~1–2 m.** Sub-metre from RSSI is not achievable at any beacon count — multipath and body shadowing cap it. That is precisely why the industry moved to BLE 5.1 AoA/AoD (antenna arrays) and UWB (10–30 cm). - **Honest framing for a 4x5 m room: RSSI trilateration gives you "which quadrant", not a smooth cursor.** If the AR overlay needs a stable moving dot, RSSI will lose the bake-off to visual positioning on accuracy alone — and we should design the comparison to measure the right thing (zone-level latency and robustness, where BLE may genuinely win, vs. pose accuracy, where it will not). **Recommendation: 3 tags will produce a position, so the session is not blocked — but buy 3 more.** At $10 each, going to 6 (four corners + two mid-wall) is the cheapest accuracy improvement available and is the difference between "a fix" and "a fix we can trust". --- ### Verdict **The 3 beacons ARE usable for the bake-off as-is. No RouterOS device is needed — the ticket's kill-switch concern does not apply.** Configuration is done entirely from an ordinary Android or iOS phone via the free MikroTik Beacon Manager app over BLE, RouterOS *cannot* configure tags at all, and reading advertisements needs nothing but our own React Native BLE scanner. No cloud, no license, no gateway. Three things must happen or the session stalls: 1. **Bring a magnet.** Non-negotiable. The tags ship asleep and broadcast nothing until a magnet is held to the reed switch for 3–10 s, and entering config mode needs another 5–10 s magnet hold per tag. **This, not RouterOS, is the actual single point of failure.** Any fridge magnet should do; bring two. 2. **Install MikroTik Beacon Manager before the session** (iOS / Android links above) and re-flash to firmware ≥2.5.0 while you have connectivity. 3. **Reconfigure all 3 tags off their factory default of 5.0 s** to **100 ms** (floor is 20 ms, so there is headroom), switch format from MikroTik to **iBeacon** with distinct Major/Minor per tag, and reduce TX power below the 0 dBm default so RSSI isn't saturated across a 4x5 m room. Do **not** set a Write Protection password — it is irreversible. **Must buy/borrow — nothing mandatory, two things strongly advised:** - **A magnet** (£0, but the session fails without it). - **3 more TG-BT5-IN, ~$10 each.** 3 tags is the degenerate minimum with zero redundancy; 6 is the cheapest real accuracy gain we can buy. Not a blocker for the session, a blocker for trusting the numbers. **Set expectations now:** RSSI trilateration in a 4x5 m room realistically delivers ~1.5–3 m, best case 1–2 m, i.e. quadrant-level rather than a smooth AR-anchor pose. Against camera-based visual positioning that is a loss on pose accuracy. Frame the bake-off around where BLE can actually win — cold-start time, robustness in the dark, no-camera-permission operation, zone-level presence — rather than positional accuracy, or the comparison is decided before we start. **One deployment caveat worth flagging early:** the battery is **non-replaceable**, and 100 ms burns a 6-year tag in an estimated **2–4 months**. Fine for a prototype, fatal for a cruise-ship rollout. Any real deployment story needs 200–500 ms plus client-side filtering, or different hardware. ### Open / unresolved - **Battery life at 100 ms is my extrapolation, not a MikroTik figure.** MikroTik publishes only 1 s → 2 y and 5 s → 6 y. **Action: read the app's on-device "Estimated battery life" screen at 100 ms during the session and post the real number here.** Cheapest possible resolution. - **No range-in-metres figure exists from MikroTik** for any TX power. Must be measured empirically — do an RSSI-vs-distance calibration sweep in the session; we need it for the path-loss model anyway. - **Can multiple advertisement formats broadcast simultaneously?** Per-format `Enable advertising` checkboxes imply yes, but no MikroTik doc states it, nor what the combined air-time behaviour is. Matters if we ever want MikroTik-format telemetry *and* iBeacon at once. Test on the bench. - **Interval upper bound contradicts between MikroTik's own pages** — iOS manual `20ms...10s` vs Android `20ms...24h`. Irrelevant to us (we live at the floor), unresolved nonetheless. - **Does the interval snap to the BLE 0.625 ms grid, or is it arbitrary?** fw 2.2.0's "non-standard advertising intervals" hints at sub-spec values; step size is undocumented. Verify the tag actually delivers ~10 packets/s at the "100 ms" setting rather than something quantised — measure observed packet rate, don't trust the label. - **Is the BLE MAC guaranteed static/public?** Strongly implied (QR code encodes it, RouterOS filters on it, no randomisation setting exists) but never stated as a guarantee. Low risk; we key off iBeacon UUID/Major/Minor anyway for iOS reasons. - **fw 2.4.0's changelog entry "optional password protection removal" is ambiguous** — it may contradict the manual's "no way to remove password protection". Untested, and we intend never to set a password. - **Which firmware first shipped iBeacon/Eddystone is unknown** — the published changelog only reaches back to 1.4.0 and both formats already exist there. Treat as always-present. - **The forums yielded nothing.** The single TG-BT5-IN thread (forum.mikrotik.com/t/.../169799, Sep–Oct 2023) is about KNOT coverage in a warehouse; no MikroTik-staff statement on fast-interval operation, real-world battery drain at high rates, or positioning use exists that I could find. **Nobody appears to be publicly using these tags for live positioning** — we are off the beaten path, so budget bench time.
lars closed this issue 2026-08-11 15:49:57 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
wayfinder:grilling
HITL ticket: conversation to reach a decision
 wayfinder:map
The wayfinder map — index of the effort
 wayfinder:prototype
HITL ticket: make something cheap to react to
 wayfinder:research
AFK ticket: find a fact a decision waits on
 wayfinder:task
Manual work that unblocks a decision
No labels wayfinder:research
Milestone
No items
No Milestone Wayfinder: RN prototyping spec
Projects
Clear projects
No projects
Assignees
Clear assignees
Dennis lars
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Blocks
#10 Decide: bake-off design — comparands, ground truth, decision rule
lars/splat-indoor-navigation
#9 Configure and verify the three TG-BT5-IN beacons
lars/splat-indoor-navigation
Reference: lars/splat-indoor-navigation#4