Two-Device Radio Tests: Bind Both Peers and Their Firmware to One Result
A two-device radio result belongs to a specific pair, direction and pair of software configurations. Bind both participants before starting and invalidate that association when either side reconnects or changes firmware. A good response from a nearby third device must not complete the intended pair’s test.
This is an original paired-evidence procedure with one concrete API boundary from Zephyr v4.0.0 Bluetooth LE connection metadata. A small CPython 3.12.14 record-admission model was executed. No Bluetooth or Wi-Fi exchange, RF measurement, pairing operation or physical two-device campaign was performed.
Make both participants first-class test inputs
Give each participant a controlled unit identity, hardware revision, installed firmware identity and assigned role. Record the peer’s configuration with the same care as the nominal device under test. A reference peer running an unexpected release can change the result without any change to the other unit.
Create a pair identity and an attempt identity. Bind endpoint A and endpoint B, their current boot or connection generations, the test direction and relevant radio settings. Preserve the actual mapping when devices occupy interchangeable fixture positions.
A pair identifier is a record association, not proof of authenticity. Establish device identity through the product’s qualified mechanism. Do not treat a self-reported name, familiar advertising payload or matching service identifier as an authorization credential.
Keep addresses and product identity separate
The Zephyr v4.0.0 connection header distinguishes local and remote identity-address fields from addresses used during connection setup. Its LE destination identity field can still contain the remote resolvable private address before identity resolution.
Therefore, a raw address string should retain its address type, source and resolution context. Do not assume that every observed address is the permanent identity of a physical product. Conversely, a changed setup address does not by itself prove that a different unit connected.
The same header documents bt_conn_get_info() returning zero on success and a negative error on failure. A failed metadata query cannot supply a complete pair association. These API details are source-verified only; the article does not claim that the host fixture compiled or called Zephyr.
Require reciprocal application evidence
For a directional test from A to B, record the operation identifier at A and the corresponding accepted operation at B. Where the test requires an application acknowledgement, bind that acknowledgement to the same operation and current pair attempt.
A transport-level connection or radio acknowledgement may establish a narrower boundary than the application’s completed work. Define the required endpoint explicitly: received bytes, validated message, stored record or completed control action. Do not label all of them “delivery.”
When both directions matter, keep separate A-to-B and B-to-A results. A successful outbound path does not establish the reverse path or symmetric performance. Retain failed and missing operations rather than counting only the exchanges that produced complete logs.
Use a paired manifest
| Manifest field | Reason for retaining it |
|---|---|
| Pair and attempt IDs | Keep one campaign pairing separate from a later retry. |
| A and B physical identities and roles | Detect substituted units and accidental role reversal. |
| Both firmware/configuration identities | Make the interoperability result reproducible. |
| Both boot/connection generations | Reject evidence from a retired session on either side. |
| Direction, operation ID and expected endpoint | State which exchange and completion boundary were tested. |
| Radio/environment conditions | Bound the result to the actual setup rather than a universal range claim. |
The NASA verification handbook supports recording the test-article configuration, conditions and results. This two-endpoint manifest is an engineering adaptation, not a prescribed radio certification format.
Treat reconnect as a new association decision
When either endpoint disconnects, retire the affected session generation and stop admitting its late results. Preserve the incomplete attempt with its actual outcome. Do not attach a delayed success to a newly connected unit solely because the fixture slot or connection index was reused.
Re-establish the intended peer and both software configurations before starting another attempt. If the product deliberately resumes an application transaction, use its qualified resume contract and retain the transition; a new connection alone does not define whether replay is safe.
Record a peer firmware update as a configuration change even if the pair remains physically connected. Results before and after that change answer different compatibility questions.
Execute wrong-pair controls before trusting the campaign
The host model’s baseline record bound pair P1, attempt T1, units U1/U2, firmware F1/F2, two generation values and direction A_to_B. That exact record was accepted.
Six individual changes were rejected: substituting U3, using old B firmware, supplying stale A or B generation, reversing direction and using an old attempt. A reconnect control advanced B’s generation and the attempt identity; the old record was rejected and a freshly rebound record accepted.
These assertions check exact synthetic record association. They do not authenticate a unit, observe an on-air identity, validate a firmware attestation or establish that either endpoint actually transmitted. A real campaign needs those observation mechanisms separately.
Plan controlled physical substitution cases
On an authorized isolated bench, include an unintended third peer advertising a similar service, a reboot of only one endpoint, a firmware mismatch and a delayed application result from a retired attempt. Keep radio use within the product’s approved operating conditions.
Require each case to produce an explicit association failure or incomplete result without awarding the intended pair a pass. Preserve enough sanitized logs from both sides to establish which boundary rejected the event.
The deliverable is a pair-bound result set with reciprocal evidence, explicit directions and visible missing observations. It supports the stated interoperability experiment once executed. It does not establish RF compliance, universal peer compatibility or security merely because two identifiers matched.
