Native Mobile Test Application for Bluetooth Beacon Signal Analysis

Objective

Scheidt & Bachmann is seeking an external mobile engineering partner to build a native iOS and Android test application for BLE beacon signal analysis.

POC Goal:

Within the Venture Client framework, deliver a test application that:

• Detects and registers a number of BLE beacons per session (up to 20-40) via their broadcast advertisements, which does not require a persistent Bluetooth connection to each beacon, either through manual ID entry (MAC address on Android, UUID/Major/Minor on iOS) or by scanning nearby devices and selecting them from a list
• Allows beacons to be grouped by physical installation zone and evaluates/visualizes RSSI as a vector/pattern per group, not just as an absolute distance estimate
• Supports a configurable sampling/scan rate, and empirically measures and documents, under defined test conditions (full expected beacon count in range, realistic ambient Bluetooth interference), the shortest reliable reading interval achievable in the foreground, as well as the longest interval the platform still enforces once the app is backgrounded
• Shows a live, per-beacon and per-group RSSI graph over time (dBm vs. time), with smoothing/aggregation (e.g. moving average, Kalman filter or exponential moving average) to reduce multipath and body-shadowing noise, and visually highlights the currently strongest beacon group
• Records full sessions (RSSI values, timestamps, beacon/group IDs, plus device motion sensor data such as accelerometer, gyroscope, compass and step count) in both foreground and background operation, supports a free-text marker/flagging function to tag key moments (e.g. the exact moment of passing a gate), and exports the recorded data (e.g. CSV/JSON) for offline analysis

The PoC is expected to prove that the platform's true technical BLE scanning limits, in both foreground and background operation, can be identified, measured and clearly documented, together with a usable live visualization and reliable data logging. Building the final passenger-facing production application is explicitly out of scope for this first phase.

Success Criteria

Final, binding success criteria for the PoC will be defined jointly with the selected provider in the Kick-Off Workshop. The following gives an early, directional sense of what a successful first phase looks like:

What success looks like:

• In a live field test, the application's real-time visualization clearly and reliably shows how the RSSI signal pattern shifts as a person moves, allowing Scheidt & Bachmann's team to investigate and adapt the setup at the fare gate.
• The platform's true maximum (foreground) and minimum (background) achievable sampling rates are identified, measured and clearly documented, rather than assumed or estimated.
• The application remains usable and its visualization stays legible in a realistic environment with many other Bluetooth devices present nearby.

What would be a No-Go:

• The application does not enable this kind of hands-on beacon-placement experimentation at all.
• Sampling rate, usability or visualization clarity are inadequate for the team to draw conclusions from a test session.
• Performance (sampling rate or responsiveness) degrades unacceptably in a realistic, Bluetooth-crowded environment.

Separate from these directional success criteria: Scheidt & Bachmann considers a background sampling rate below one second (at least 1 Hz) an important threshold for the underlying concept to be viable at all.

Long-Term Goal:

If the test application confirms technical feasibility, Scheidt & Bachmann intends to continue with the same partner into a co-development phase that encapsulates the validated logic into native iOS/Android Software Development Kits for integration into Scheidt & Bachmann's own passenger-facing application, moving toward a production-ready solution.

Solution Requirements

Functional

• Native iOS (Swift) and Android (Kotlin) applications, with no cross-platform abstraction layer, to preserve maximum access to system-level Bluetooth APIs and scan performance
• Beacon detection and registration, based on BLE advertisement scanning rather than a persistent Bluetooth connection to each beacon, via manual input (MAC address on Android; UUID/Major/Minor on iOS) and via scan-and-select from nearby BLE devices
• Logical grouping of beacons by physical installation zone, with RSSI evaluated and visualized as a vector/pattern per group
• Configurable BLE sampling/scan rate via a slider or input field, supporting at least a 1 Hz (1000 ms) baseline and the shortest reliable reading interval empirically determined for the given device/OS (neither Apple nor Google publish an exact figure for this; it must be measured, not assumed)
• Live dashboard showing raw RSSI (dBm) per beacon and per group, plus rolling average and peak RSSI over a defined time window
• Real-time line chart of RSSI vs. time, with distinct colors per beacon/group, to visualize the cross-over point as a person moves between beacon zones
• Start/stop session recording of all scanned RSSI values with timestamps, beacon/group IDs, plus synchronized motion sensor data (accelerometer/gyroscope, compass, step count)
• Free-text marker/flagging function to tag specific moments during a recording session (e.g. the moment of passing a gate)
• Secure local storage of recorded sessions, with export/share in a standard format (e.g. CSV or JSON) via email, AirDrop or messenger apps

Technical & Security

• Explicit measurement, testing and documentation of BLE scanning behavior and limitations in background operation (screen off / app minimized) on both iOS and Android, including an automatic flag in the recording marking foreground/background transitions
• A software interface (API-style toggle) to programmatically start/stop RSSI scanning and tracking, so other app modules can trigger scanning on demand rather than scanning continuously
• Documented battery consumption impact of continuous, high-frequency BLE scanning, particularly in background operation
• Proper handling of required permissions (Bluetooth, motion/activity recognition, and location, which is required for BLE scanning under Android as well as for GPS-based station detection)

Operational readiness

• Deliverable as a working, demonstrable test application within a reasonable timeframe, so Scheidt & Bachmann's team can begin field experimentation with beacon placement and shielding

Nice-to-haves

• Simultaneous availability on both iOS and Android from the start (a single-platform first version is acceptable if it accelerates delivery)
• Platform-specific optimizations beyond the baseline sampling rate, where the operating system allows it

Not in Scope

• The final passenger-facing production application and its ticket-validation logic
• Continuous background operation as a shipped product feature (only its technical limits need to be measured and documented in this phase)
• The broader business rationale and application context behind this evaluation (shared only after signing an NDA)