The Radio That Remembered:
Bluetooth Signal Attenuation
as a Location Witness

This engagement arose from a criminal investigation referred to Mjolnir Security by outside legal counsel acting for a defendant in a property crime case. Among the items disclosed was a forensic image of an aftermarket car radio's internal flash storage. The prosecution's digital forensics team had noted the existence of Bluetooth pairing logs but had not analysed them beyond confirming the defendant's phone was paired. Our instruction was to examine everything those logs actually contained. What we found was a 47-minute RSSI timeline that placed the defendant's phone within 2–4 metres of the vehicle on two separate occasions — with an 18-minute absence window that aligned precisely with the alleged offence.

Background: The Scene

The prosecution's theory was straightforward: the defendant had been present at the location of a commercial burglary at a specific time window on a Tuesday evening in November. The defendant's position was equally straightforward: they were elsewhere, had no connection to the location, and the only evidence placing them nearby was a single witness statement that the defence characterised as unreliable.

The defendant owned a vehicle — a mid-2010s European saloon — fitted with an aftermarket detachable DIN-format head unit. Detachable radios of this generation are a security feature: the face panel removes, rendering the unit inoperable. Many owners leave the panel clipped to a visor or in a centre console rather than carrying it. This unit had been left in the vehicle. The vehicle was impounded as part of the investigation.

The Head Unit: What We Were Working With

Hardware and Firmware

The unit was an aftermarket double-DIN head unit from a major tier-1 automotive electronics manufacturer, running an embedded Linux variant on an ARM-based SoC. It featured integrated AM/FM/DAB tuners, a touchscreen interface, Android Auto and Apple CarPlay connectivity, internal storage for media, and — critically — a Bluetooth 4.2 transceiver used for hands-free calling, audio streaming, and device pairing.

The internal flash storage (eMMC, 8 GB) contained the operating system partition, a user data partition (FAT32), and several write-once log partitions that the firmware used for diagnostics and regulatory compliance. It was in these log partitions — not the user data partition — that the Bluetooth session records resided.

Why Detachable Radios Log More Than You Expect

The design constraint that makes detachable-panel head units forensically interesting is their power management architecture. Unlike a permanently installed radio that can draw standby current indefinitely, detachable-panel units are engineered to maintain a minimal-power listen state even when the panel is detached. The Bluetooth subsystem maintains a continuous low-power scan cycle whenever the vehicle's accessory circuit provides standby current — which it does whenever the vehicle is parked with the ignition off but not battery-disconnected.

Log Format and Structure

The Bluetooth log files were stored in the diagnostics partition as rotated binary log files: bt_session_YYYYMMDD_HHMMSS.log. Each file represented one operational session (ignition-on to ignition-off) plus standby-mode scan records accumulated between sessions.

The RSSI Poll records (Type 0x04) are the forensically valuable records. For every paired device within detection range, the Bluetooth controller generates an RSSI measurement every 5 seconds during an active connection and every 30 seconds during passive standby scanning.

The Physics: From Signal Strength to Distance

How RSSI Encodes Distance

Radio signal strength decreases as distance increases. For Bluetooth operating in the 2.4 GHz ISM band, the fundamental relationship is the inverse-square law: doubling the distance between transmitter and receiver reduces the received power by approximately 6 dB. In practice, Bluetooth path loss is modelled using the log-distance path loss formula:

RSSI(d) = RSSI(d0) − 10 × n × log10(d / d0)

Where:
  RSSI(d)    = received signal strength at distance d (dBm)
  RSSI(d0)  = reference RSSI at reference distance d0 (typically 1m)
  n          = path loss exponent (2.0 free space; 2.5–4.0 obstructed)
  d          = distance to estimate (metres)

Solved for distance:
  d = d0 × 10((RSSI(d0) − RSSI(d)) / (10 × n))

Calibration values used in this case:
  d0 = 1m:  RSSI(d0) = −59 dBm  (manufacturer-measured)
  n = 2.7  (outdoor, partial obstruction — vehicle body metal)

Calibration and Error Budgeting

Raw RSSI-to-distance conversion is not a precision technique. In a controlled laboratory environment, RSSI-based ranging is accurate to approximately ±1–2 metres at short range (under 5 metres), degrading to ±5–10 metres beyond 20 metres. In this case, three factors significantly improved accuracy:

• Known reference point — the vehicle's GPS position was recorded in the navigation log at multiple timestamps, giving a precise anchor point for all distance estimates
• Multiple readings per interval — the 30-second RSSI poll cycle provided multiple measurements per minute, allowing rolling averages and outlier identification
• Temporal RSSI gradient — analysing the rate of change of RSSI over time determined direction of movement and velocity. A steadily decreasing RSSI indicates approach; increasing indicates departure

The Python Implementation

import numpy as np
from scipy.signal import savgol_filter

# Calibration parameters (manufacturer documentation + field verification)
RSSI_REF    = -59.0   # dBm at 1 metre reference distance
PATH_LOSS_N = 2.7     # outdoor/partial obstruction (vehicle environment)
D_REF       = 1.0     # reference distance in metres

def rssi_to_distance(rssi: float) -> float:
    """Convert a single RSSI reading to distance estimate."""
    return D_REF * (10 ** ((RSSI_REF - rssi) / (10 * PATH_LOSS_N)))

def process_rssi_series(timestamps: list, rssi_values: list) -> dict:
    """Process a time series of RSSI readings."""
    rssi_arr = np.array(rssi_values, dtype=float)

    # Smooth with Savitzky-Golay filter to reduce measurement noise
    rssi_smooth = savgol_filter(rssi_arr, window_length=5, polyorder=2)

    # Convert to distances
    distances = [rssi_to_distance(r) for r in rssi_smooth]

    # Compute RSSI gradient (rate of change, dBm/second)
    dt = np.diff([t.timestamp() for t in timestamps])
    drssi = np.diff(rssi_smooth)
    gradient = drssi / dt   # positive = moving away, negative = approaching

    return {
        'timestamps': timestamps,
        'rssi_raw': rssi_values,
        'rssi_smooth': rssi_smooth.tolist(),
        'distances_m': distances,
        'gradient_dbm_per_s': gradient.tolist(),
    }

The RSSI Timeline: Reading the Approach

Phase 1 — First Approach and Brief Presence

Phase 2 — The 18-Minute Absence

Phase 3 — Second Return and Departure

Interactive Signal Reconstruction

The visualization below reconstructs the full RSSI timeline, spatial movement paths, and phase analysis from the Bluetooth log data. The left panel plots signal strength over time with the 18-minute absence window highlighted in red. The right panel shows the spatial reconstruction with GPS-anchored distance rings and approach/departure paths.

Analysis: What the Numbers Mean

The Three-Phase Movement Pattern

Phase 1 First approach and brief presence (20:47–20:55). The device approached from the south access road at a steady walking pace of ~1.3 m/s. It reached within 2–4 metres of the vehicle (peak RSSI −54 dBm, closest-approach estimate 2.5 m ± 0.8 m) and spent approximately 90 seconds in the immediate vehicle vicinity. It then departed via the eastern pedestrian exit. Total time: ~8 minutes.

Phase 2 18-minute absence (20:55–21:14). No Bluetooth signal for exactly 18 minutes 18 seconds. The device was 100+ metres away. This window overlaps with the prosecution's alleged offence window at the adjacent commercial premises, 85 metres north-northeast of the vehicle.

Phase 3 Second return and departure (21:14–21:23). The device returned from the eastern direction, reached within 1.5–3 metres (peak RSSI −53 dBm), spent ~3 minutes in the vehicle vicinity, and departed northward via a different exit at a brisk pace (~1.8–2.2 m/s).

The GPS Position Intersection

Using the closest-approach RSSI values from both phases and the vehicle's GPS position as anchor, we drew two near-annuli around the vehicle. Their intersection — constrained to navigable surfaces (pavement, not inside buildings) — produced a highly bounded location estimate.

The Absence Window — Corroborating the Timeline

The prosecution's stated window (21:14–21:38) was based on CCTV timestamps which were subsequently found to have an 18-minute clock drift. Correcting the CCTV timestamps brought the CCTV-evidenced window into alignment with the RSSI-evidenced absence window, converging two independent datasets on the same 18-minute period.

What the Phone Didn't Know It Was Recording

The defendant's phone was not doing anything active during this period. It was in a pocket or bag, screen likely off, broadcasting Bluetooth advertising packets at the standard interval — approximately once per second. The phone had no way of knowing it was being logged. No application was running. The user took no action.

The radio — sitting in a dark, parked car with the panel removed — was passively recording every advertising packet it heard from every paired device in range, with a timestamp and RSSI value, as part of its normal standby diagnostic operation.

Chain of Custody and Technical Validation

Technical Reference: Factors Affecting RSSI Accuracy

Why Connection Events Are the Anchor

Connection event records (Type 0x02) have a special property: they record the exact moment the Bluetooth link was established at a known geometry. The RSSI value at connection represents signal strength at the precise moment of the handshake — a definitive data point that anchors the entire RSSI series. In this case, the two connection events (20:50:52 and 21:16:53) served as high-confidence anchor points at ~3–5 metres.

For Investigators: Adding Car Radios to Your Collection List

Which Devices Log RSSI Data

• Aftermarket double-DIN units with Android/embedded Linux firmware (2015–present) — high probability of diagnostic RSSI logging. Manufacturer service portals typically have firmware documentation
• OEM navigation systems from premium European marques — most log Bluetooth connection events with RSSI. Some log standby scan RSSI. Requires manufacturer-specific forensic tooling
• OEM infotainment from Japanese and Korean marques — variable. Some retain only connection/disconnection without RSSI. Others have full RSSI logs in proprietary formats
• Basic OEM single-DIN radios — typically log only pairing and connection events, not RSSI polls. Useful for confirming connection but not distance estimation
• Android Auto / Apple CarPlay head units — primary logs in car unit; phone-side logs (iOS paired device history, Android Bluetooth HCI log) may complement car-side data

Collection Methodology

1. Photograph in situ — document the head unit in the vehicle before removal, including panel state, damage, and vehicle VIN plate
2. Check for standby power — if battery intact, the unit may still be logging. Connect write-blocker before removing power if possible
3. Remove the head unit — standard DIN extraction tools. Document all connectors
4. Identify storage media — most have eMMC soldered to main board. Some have removable SD. eMMC extraction requires chip-off or JTAG if USB service port unavailable
5. Acquire forensic image — if USB service port available, use dd via write-blocker. Otherwise, chip-off eMMC extraction
6. Locate diagnostics partition — look for small (1–32 MB) partition with bt_*.log, bluetooth_*.log, hci_*.log, or diag_*.log
7. Parse log format — if undocumented, binary analysis: look for 6-byte BD_ADDR fields, 4-byte timestamps, 1-byte signed RSSI values (−100 to 0)
8. Correlate against GPS log — navigation NMEA track logs in a separate partition provide the spatial anchor for all distance calculations

Takeaways

For Digital Forensic Examiners

• Car head units are crime scene witnesses — they operate in standby mode, log silently, and retain data in write-protected partitions. They belong on every vehicle seizure checklist
• RSSI is distance — with calibration, smoothing, and a GPS anchor, Bluetooth RSSI data can constrain location to within a few metres
• The absence window is often the finding — in this case, the 18-minute gap was more evidentially significant than the moments of signal presence
• Connection events anchor distance estimates — RSSI at Bluetooth connection establishment is a high-confidence data point. Build your model around these

For Privacy Researchers and Security Engineers

• Your phone broadcasts its presence constantly — with Bluetooth enabled, advertising packets are sent every 20 ms to 1.28 seconds. Every Bluetooth receiver in range is logging them
• Disabling Bluetooth is the only mitigation — MAC randomisation prevents identification by unknown scanners but does not help against pre-existing paired devices whose pairing used the real MAC address
• Pairing records persist — removing a device from your phone's paired list removes it from the phone, but the car radio's pairing record in a write-protected diagnostics partition may persist independently. The radio will continue logging RSSI data for your phone's advertisements

References

1. Bluetooth SIG Core Specification 5.3 — Section 4.4 (Advertising), Section 7.5 (RSSI), Section 9 (Power Control). Publicly available at bluetooth.com.
2. Friis, H.T. (1946) — ‘A Note on a Simple Transmission Formula.’ Proceedings of the IRE. Free-space path loss reference.
3. Rappaport, T.S. (2001) — Wireless Communications: Principles and Practice. Chapter 3. Log-distance path loss model reference.
4. Savitzky, A. & Golay, M.J.E. (1964) — ‘Smoothing and Differentiation of Data by Simplified Least Squares Procedures.’ Analytical Chemistry.
5. NIST SP 800-101 Rev 1 — Guidelines on Mobile Device Forensics. Chain of custody methodology for vehicle-mounted devices.
6. Python scientific stack — numpy, scipy (savgol_filter), pyserial (live Bluetooth HCI capture), pyshark (PCAP analysis).