Surveillance Hound roadmap¶

The roadmap follows hands-on exploration of an external browser emulator. Its interactions are references for original Hound implementations; no third-party sprites, text or implementation are incorporated. All characters remain dogs. Landscape remains the default, with the existing rotation lock and portrait support.

Selected for this iteration¶

The implementation uses 64 saved ignore slots and six wardrobe choices (classic plus five accessories). Snooze is global and temporary; ignores target a device/category. All three features have separate RAM-only demo state. See the hound care and wardrobe guide for controls and unlock requirements.

Planned additions¶

Follow Scent tag ringing — potential addition¶

Research only; not selected for implementation and not available in installed firmware. This would be an explicit, user-triggered active Bluetooth operation alongside default passive scanning. Detection alone would never ring a tag.

For a future implementation, bind one bounded attempt to the selected fresh identity, show connecting/request-sent/unavailable/timeout states, support cancellation, disconnect promptly and restore scanning. Distinguish an accepted request from proof of an audible beep. Test scan coexistence, heap, SD logging and UI responsiveness; revisit the current passive-only API checks and connection-buffer budget explicitly. Demo controls must not contact real tags.

Evidence: AirGuard's sound implementation demonstrates AirTag/Find My Bluetooth sound requests. Apple's guidance describes availability limits. AirGuard's feature matrix lists no Samsung sound support. Published SmartTag protocol research, §3.4 describes server-assisted authentication for non-owner ringing on the studied firmware; this does not establish compatibility with every current SmartTag model.

Camera doorbells and home cameras — planned¶

Extend the existing Ring and camera-vendor coverage (including Wyze) to investigate Google/Nest doorbells and additional home-camera families. There are currently no dedicated Nest doorbell rules; this roadmap item adds no detection rules or firmware behavior.

• Research vendor-address prefixes, setup-network names and advertised BLE services using primary documentation and controlled captures. Start with labels such as “Google/Nest device nearby” when only manufacturer evidence is available; a Google/Nest match may be another kind of device.
• Investigate passive sampling of transmitter addresses from ordinary 2.4 GHz Wi-Fi data-frame headers. The current receiver/parser handles management frames only, which limits observation of cameras already connected to a router. Keep radio callbacks bounded, deduplicate/rate-limit observations, discard payloads, and measure queue loss, heap, storage load and UI responsiveness before enabling broader capture.
• Confirm whether useful BLE advertisements exist during normal operation as well as setup. A product's Bluetooth capability alone does not establish a persistent or identifying broadcast. Google's camera and doorbell specifications provide radio capabilities, not detection signatures.
• Preserve per-category alert controls, confidence filtering and Ignore/Snooze. Keep vendor-only clues tentative; reserve product-specific labels for corroborated signatures tested against both known doorbells and other devices from the same vendor. Retain source provenance and clear evidence in the Scent Book/log.
• Validate multiple models and operating states, including idle, live view, motion activity, setup/reconnection, and 2.4 versus 5 GHz connections. Include non-camera Google/Nest devices as negative controls. Test on the Hosyond before claiming reliable coverage.

The current board cannot receive 5/6 GHz Wi-Fi; firmware changes cannot remove that hardware limit. A separate BLE broadcast may still supply a clue if present. Detection indicates radio presence and does not establish recording, ownership or viewing direction. The feature remains passive, with no network association or camera-feed access.

Detection expansion — easiest to hardest¶

Items below are based on the detection feedback reviewed on 2026-09-22. Items 1–2 are implemented; unchecked items remain planned. They do not add to the currently enabled 67 rules across 19 categories. The order estimates engineering effort once usable evidence is available, not detection value or a delivery date. Obtaining real devices and positive/negative captures may make a simple-looking rule take longer than a documented protocol decoder. Each numbered item must also meet the shared acceptance criteria below.

1–8: Small changes to help, inference and existing rule types¶

Research handoff (2026-09-23): Evidence, candidate matchers and coding plan for items 1–8. Items 1–2 and the beacon/probe-response SSID guard are implemented. Coverage is reachable from every Scent Book page. Local/group transmitter addresses cannot supply manufacturer evidence, and a phone searching for a remembered network cannot match its SSID product rule. All 15 host suites and the ESP32 release build pass; host tests use address, undefined-behavior and leak checks; installed on the Hosyond on 2026-09-24 with verified saved-data preservation and a successful boot/radio smoke check. Physical UI/SD checks and controlled RF validation remain pending. New name/vendor rules retain explicit source, category and RF-validation gates.

• 1. Explain coverage in the UI. Scent Book → Coverage has five pages covering identifiable 2.4 GHz Wi-Fi/BLE broadcasts, silent receivers, unsupported radios and clue limits. Empty Log uses “No matching signals observed” with directions to Coverage. Help preserves the book page and does not change discoveries, scanning or idle policy.
• 2. Tighten manufacturer inference for local addresses. Wi-Fi transmitter-MAC manufacturer matching rejects locally administered and group addresses, with regression tests for all U/L + I/G combinations. Matching against protocol identifiers inside vendor payloads is preserved. Local administration does not necessarily mean randomization, and BLE address types need their own handling. See the IEEE address guidelines.
• 3. Expand camera-vendor clues. Research Dahua, Lorex, Reolink, Uniview, Hanwha/Wisenet, Arlo, Eufy, Blink and Google/Nest mappings. Validate assigned prefixes and OEM overlap before enabling rules. Manufacturer-only matches remain weak clues and may identify non-camera products. Coordinate with the camera-doorbell work.
• 4. Add verified dashcam names. Collect setup/normal-operation SSIDs for Viofo, BlackVue, 70mai, Garmin, Nextbase and Thinkware. Use bounded, model-specific patterns with non-dashcam controls; names are editable and may disappear when the hotspot is off. Do not infer that recording is active.
• 5. Expand O.MG / Hak5 default-name coverage. Verify candidate O.MG and Key Croc defaults, plus other Hak5 Wi-Fi gear beyond current Pineapple coverage. Record model, firmware and operating mode; do not assume all products advertise an AP. Default names are changeable/spoofable clues, not proof of an attack.
• 6. Add fleet and retail infrastructure clues. Research Cradlepoint IBR900/IBR1700, Sierra Wireless AirLink, Getac and Panasonic Toughbook names/prefixes. Treat them as general fleet/computing equipment, with no police attribution. Consider a separate informational label for analytics-capable Meraki/Aruba infrastructure; recognizing the vendor does not reveal whether customer tracking is enabled.
• 7. Research low-cost camera setup networks. Candidate names: HDWiFiCam, V380, Yoosee, LookCam, IPC-, HIPC, A9, SmartLife-, Tuya and ESP_; candidate module vendors: Espressif, Beken and Realtek. Verify each against captures before shipping. Broad IoT names/prefixes alone must not produce a camera alert or a claim that a rental-property sweep is complete.
• 8. Expand generic module clues cautiously. Investigate HC-08, HM-10, JDY-xx, AT-09, MLT-BT05, ESP_xxxxxx and ESP8266 as possible leads for skimmer investigations. They also occur in ordinary electronics. Keep standalone matches informational/weak and quiet by default; being near an ATM or pump is not proof, and Hound currently has no location input.

9–11: Small, structured matchers and overlapping protocols¶

• 9. Recognize Tesla vehicle advertisements. Add a bounded exact-format matcher for S + 16 hexadecimal characters + C, supported by Tesla's BLE implementation. Validate real advertisements and near-miss names. Label vehicle-radio presence only; this does not establish Sentry mode, camera use or recording.
• 10. Expand informational retail/venue beacons. Parse Eddystone 0xFEAA UID/URL/TLM frames, then research Estimote and Kontakt.io signatures. Validate frame type and length rather than UUID alone; prevent overlap with existing Google Find Hub rules using the same UUID. Keep beacon discovery informational and quiet by default, with no automatic URL opening. Follow the Eddystone specification; advertising a beacon does not establish that it is collecting phone data.
• 11. Expand inexpensive tracker coverage and deduplication. Research iTAG with service 0xFFE0, Chipolo, Pebblebee and Eufy SmartTrack. The generic service/name pair needs corroboration. Prefer existing Find My/Find Hub family matches when applicable and merge simultaneous rule hits for one supported identity, preventing duplicate alerts, counts, meals and XP. Test multiple tags together; do not merge unrelated tags by brand.

12–18: Capture research, protocol decoders and broader Wi-Fi reception¶

• 12. Expand body-camera and trigger coverage. Investigate Motorola Solutions/WatchGuard, Getac and Reveal vendor clues, and Axon Signal BLE trigger advertisements beyond current Axon rules. Prefix-only clues stay weak. Product/trigger labels require documented payload structure and positive/negative captures; receiving a trigger does not prove a particular camera recorded anything.
• 13. Research AI recording wearables. Collect advertisements for Plaud NotePin, Limitless Pendant, Bee and Omi/Friend across pairing, idle and recording states. Verify advertised names/services and versions before making rules; a service discoverable only after connecting is outside passive detection. Presence does not establish recording.
• 14. Research other smart glasses. Investigate Snap Spectacles, Brilliant Labs Frame, Even Realities, Amazon Echo Frames and Solos. Distinguish model capabilities, including audio/display-only products, rather than assigning every pair a camera label. Validate normal-operation broadcasts and avoid claiming that recording is active.
• 15. Add Wi-Fi beacon Remote ID. Extend the current BLE-only Remote ID coverage with structured ASTM F3411/OpenDroneID beacon parsing: vendor identifier FA:0B:BC, type 0x0D, valid message-pack framing and lengths. First improve bounded IE extraction: the current parser retains only the first vendor IE and may miss a later Remote ID IE. Review the 128-byte vendor buffer and 512-byte raw-frame limit without blindly increasing radio-queue memory. Cross-check against the OpenDroneID Wi-Fi implementation and actual captures. A valid message supports protocol presence, not authenticated aircraft identity.
• 16. Add French drone identification. Reuse the bounded beacon infrastructure from item 15, then validate CID 6A:5C:35, version and TLV structure against the published French technical format. Record supported channels/bandwidths; the format includes variants that must not be assumed receivable on this board. Keep regional coverage explicit.
• 17. Investigate DJI legacy Wi-Fi DroneID. Validate the proposed vendor identifier 26:37:12 and complete message structure against known captures and an existing DJI IE decoder. Establish a model/firmware compatibility table for older Wi-Fi-linked aircraft. Treat Spark/Mini support as a research lead, not coverage for every Mini. This task does not add OcuSync decoding or imply that every DJI aircraft emits legacy Wi-Fi DroneID.
• 18. Observe already-connected Wi-Fi devices through headers. Implement the bounded data-frame-header investigation described in the camera-doorbell section. Correctly distinguish transmitter, receiver and AP addresses; avoid assigning an AP's vendor to its clients. Discard payloads and validate channel scheduling, queue loss, UI responsiveness and heap with SD logging enabled. This may expose more camera/retail equipment clues, but cannot reveal analytics or recording status.

19–22: Stateful behavior detection and new frame support¶

• 19. Detect possible beacon flooding. Track bounded SSID/BSSID churn, timing and per-channel reception over windows rather than counting one burst. Test dense legitimate venues, multi-BSSID APs, channel hopping and simulated Marauder/mdk4-style floods using offline fixtures. Use a qualified anomaly label; rate alone is not strong evidence of an attack. Deduplicate incidents and limit logs, alerts and game rewards.
• 20. Detect possible BLE pairing spam. Investigate Apple Continuity proximity-pairing bursts with changing models/addresses, Samsung, Microsoft Swift Pair and Google Fast Pair patterns, including Flipper/ESP32 “Sour Apple” behavior. Combine valid payload structure, repetition, diversity and timing in bounded windows. Include busy-venue and normal-pairing negative controls; random MACs or high rate alone must not become a strong attack verdict. Validate packet loss and scanning duty-cycle effects.
• 21. Detect possible Karma/MANA-style responses passively. Correlate observed probe requests/responses where one BSSID answers for many unrelated SSIDs, with bounded history and legitimate multi-SSID/AP negative controls. The current parser can see probe frames, but this requires new correlation logic. Do not transmit probes, join networks or provoke a response; results remain tentative when channel hopping misses the exchange.
• 22. Add Wi-Fi NAN Remote ID reception. Investigate passive Public Action frame reception and NAN service-descriptor/message-pack decoding, separately from the beacon path in item 15. The existing Wi-Fi parser does not handle these action frames. Validate supported channels and real hardware reception against the OpenDroneID NAN parser; do not assume a NAN network connection or active discovery is necessary or acceptable.

23–24: Research with identity, location or hardware dependencies¶

• 23. Improve Travel Watch under address rotation; defer movement confirmation. Extend the existing time-window watch with controlled rotation/multiple-tag tests and clearer continuity/uncertainty reporting. Payload structure identifies a family, not necessarily one physical tag; RSSI and rotation timing alone are insufficient to join identities safely. Rotation cadence varies by product, firmware and state, so do not hard-code a universal 15-minute interval. Cross-location following detection depends on a future location/motion design; the phone GPS companion remains deferred. Until then, keep warnings about repeated nearby presence and do not promise confirmed following. Also address the reported long-run Ignore limit: a Samsung alert returned after hours despite two known nearby tags. Clarify the current-identity scope in the Ignore UI and provide an explicit category-quiet shortcut with its Travel Watch effect disclosed; investigate owned-tag enrollment only if reliable identity evidence is available. Keep this open despite the separate queued-card fix and short successful retest.
• Implemented the bounded Samsung portion: supported FD5A broadcast-ID continuity, explicit connected-state alert filtering, legacy Ignore compatibility and an evidence/identity detail page. See Samsung handling. Tests cover same-ID MAC changes and several independent tags; physical privacy-ID rotation and long-run suppression remain open. No heuristic identity merging, permanent ownership enrollment or phone location work is claimed.
• 24. Investigate detection of active BLE scanners. Determine whether separate capture support or additional hardware can observe third-party scan requests. The current NimBLE advertisement-discovery callback does not expose those packets. Even a captured scan request indicates scanning, not retail tracking intent. Start with a feasibility experiment and measured coexistence costs; keep silent passive PAX counters outside claimed coverage.

Shared acceptance criteria for every expansion¶

• Evidence and confidence: Record a source, revision/date, exact field match, models/firmware, operating state and both positive and negative captures for each enabled rule. Candidate names in this roadmap are not a verified signature database. Strong protocol evidence describes the received format; unauthenticated radio traffic can be spoofed and does not prove ownership, recording, malicious intent or surveillance.
• Persistence and RSSI: Use repeated sightings, freshness and RSSI trends to manage noisy alerts and describe continuity. Do not automatically turn repeated weak manufacturer/name matches into Strong confidence; the current engine deliberately does not raise confidence merely for repetition. Avoid distance/direction claims and validate fading, channel changes and missed packets.
• Identity and counting: Separate rule-hit deduplication from speculative correlation across rotating identities. Keep identity state bounded and keyed, avoid long-lived raw identifiers, and test several same-brand devices together. Preserve correct alert, log, lifetime-count, feeding and XP behavior during floods and category overlap.
• Capture/parser resources: Test truncated/malformed/multiple IEs, length boundaries and relevant BLE address/advertisement types. Parse the appropriate vendor IE rather than assuming it is first. Bound buffers, work per callback, observation queues and time-window tables; measure heap, capture drops and SD backlog on the Hosyond with real scanning.
• Controls and presentation: Preserve per-category alert toggles, Monitor/alert behavior, Ignore, Snooze and Travel Watch semantics. Explain the actual evidence in the log and Scent Book, keep weak/informational additions quiet by default, and retain visible dog animations and controls in both orientations. Define fitting dog reactions without rewarding observation floods.
• Category/schema changes: Decide whether each addition extends an existing category or needs a new one. Review enum/bitmask capacity, generated assets, settings, Scent Book, logs/exports and saved-state migrations before expanding beyond the current 19 categories. Keep demo observations, progress and settings isolated from real state.
• Privacy and field validation: Preserve passive operation and discard unnecessary payloads. Do not automatically open beacon URLs or add persistent/exported drone serials or coordinates as a side effect of recognizing a protocol. Add host fixtures and simulator cases, then controlled positive/negative RF tests and a hardware soak before calling coverage validated.

Hardware limits to explain in help¶

The current board cannot infer the presence of a receiver just because it is listening. Passive PAX counters therefore have no guaranteed detectable Wi-Fi/BLE signature; an optional, independently identifiable broadcast may reveal only a clue. See the PAX counter project. An active BLE scanner is a separate feasibility task above, not an existing capability.

Do not claim coverage for cellular-only GPS trackers, IMSI catchers/Stingrays, cellular-only ALPR links, silent acoustic/ShotSpotter sensors, optical/IR/radar/RFID people counters, LoRa uplinks, 5/6 GHz Wi-Fi or proprietary OcuSync links with these radios. Some products may also emit an identifiable 2.4 GHz Wi-Fi/BLE signal; that auxiliary signal is the only potential clue within scope. No matches must never be presented as proof that no tracking or recording equipment is nearby.

Items 1–2 are implemented. Next consider the documented 3 confidence audit, verified defaults from 4–5 and structured matchers 9–10. Item 15 is a useful next protocol project once its capture and memory prerequisites are met. These future priorities do not change installed firmware or the existing hardware-test schedule.

Tag Watch¶

Implemented a manual Travel Watch for repeated AirTag/Find My, Samsung, Tile and Google tag presence: ten minutes, eight distinct minute bins, gaps no longer than two minutes. The compact possible-following warning slowly flashes the background red; steady red, acknowledgement, Ignore, Snooze and Stop remain available. A simulator time-jump preview exercises the same threshold. Per-tag status shows observation time, qualifying minutes and last-seen age, with reset counters and alert-filter hints. The table is bounded and volatile, with keyed identifiers and no new persisted record. This does not establish movement, ownership or intent; address rotation and table capacity can cause missed warnings. The user confirmed the alert trigger and red flashing on the Hosyond board, with the dog and controls visible. Controlled RF validation and broader physical acceptance remain pending.

Existing deferred work and release gates¶

• Phone GPS/companion work remains deferred at the user's request.
• Initial Hosyond display bring-up and short no-card heap measurements are complete. Remaining acceptance work includes formal display/touch checks, NVS/SD power interruption, sound, battery/current draw, minimum heap, controlled capture loss, cold boots and the long soak. The user has confirmed a 581-record SD export, safe eject, same-card reinsertion/remount and resumed logging. Private NVS readback confirmed retained settings/outfit/ignores and newly saved progress. Independent exported-file verification is deferred until a card reader is available. See status, hardware and test plan.
• Controlled positive/negative device captures, field confidence review, remote CI, license review and signed release acceptance remain separate gates.
• A simulator result does not establish RF accuracy, durable NVS writes or physical display performance.

Idle display and bouncing hound — implemented 2026-09-23¶

• Dim after 2 idle minutes, selected dog/outfit bouncing diagonally on black after 5, display/backlight off after 15. Independent settings: Never, 1, 2, 5, 10, 15, 30 or 60 minutes since user interaction (following warnings and protected screens hold the display awake). The most advanced due stage wins.
• Settings → Display → Display options → Screen saver / Timeouts, with instant preview. All six dogs and outfits, portrait/landscape, no fixed header/counters. Reduced animation relocates the dog every 15 seconds.
• Travel Watch always suppresses display-off while armed, including during snooze or paused sniffing. Dim/saver remain available. Ordinary alerts get a bounded five-second wake at most every thirty seconds, without restarting the idle timer or the bouncing path; active following warnings remain visible. Ignored, snoozed and owner-connected Samsung detections do not wake it.
• First waking touch/BOOT only wakes; radio reception, SD logging and pet/watch timers continue. Calibration, self-test and in-progress export/eject remain awake.
• Versioned appearance migration preserves existing appearance/progress/ignores and supplies default timeouts. No additional frame buffer; The first idle-display build added 32 bytes of UI state; the bounded-alert adjustment adds one 8-byte wake deadline.
• Verify dim/off/first-touch wake, alert wake and Travel Watch override on the Hosyond after safe eject and installation; confirm saved dog/outfit/timeouts and SD progress after reboot.

Ignore capacity, SD backup and dark-scene visibility¶

• Increase Ignore from 16 to 64 compact entries, migrate existing saved identities/outfits/scents, show used/free capacity and page occupied entries.
• Keep internal storage authoritative; automatically back up changed lists to two authenticated SD generations, including deletions. Show backup status and manual retry. Missing/ejected/read-only cards do not disable internal ignores; demo never writes an ignore backup.
• Add an explicit, reviewed on-device SD restore workflow. The current format has a validated recovery reader, but normal boot never imports an older card over current internal state. Original board key is required; factory-reset/new-board portability is not supported.
• Give dog silhouettes a subtle light rim on dark themes and the saver, preserving breed colors and original Daylight appearance.

These changes are software-verified and installed on the Hosyond board after safe eject; physical migration/backup/contrast acceptance checks remain pending. Increasing capacity does not establish continuity across rotating AirTag or Samsung identifiers.