Agreeing on Sensor Hub Timestamp Migration and BSP Acceptance

Thanks for joining the BSP acceptance call. Noah is here for Sensor Framework, Maya and Tomas represent Velora BSP, and Sujin owns System Quality coverage. We are reviewing drop V32 for the Meridian development board. The vendor proposes a new timestamp format for batched sensor events, but the integration branch still expects the old format. Yesterday's smoke run passed while an overnight suspend test showed events arriving out of order. Our decision today is whether V32 can enter the shared branch, what acceptance evidence is missing, and which interface behavior both sides can commit to before Monday's integration window.

I have the V32 release notes and the sensor hub interface document. The firmware now exports a sixty-four-bit tick counter instead of the old thirty-two-bit field. The motivation was to avoid frequent wrap handling in the host driver, not to change event ordering. Unfortunately, our release note called the update binary-compatible because the packet length stayed the same after reserved bytes were reused. That statement was too broad. The meaning of the payload changed, and the host cannot safely infer the format from length. We need an explicit version agreement rather than a note that asks integration to guess.

Framework is not opposed to the wider counter. My concern is the clock contract around it. The old driver converted hub ticks to the Android elapsed-time domain using an offset captured during initialization. After suspend, the hub keeps counting but the host may refresh that offset. If a batch spans the refresh, two events can receive inconsistent conversions. A wider counter alone does not solve that. I need the interface to say which clock domain an event belongs to, how tick frequency is established, and whether one conversion epoch covers the whole batch. Without those rules, a clean smoke run tells us very little.

The hub counter is continuous while the low-power island remains powered. It resets only when that island restarts, and V32 adds a reset-generation field. The frequency is fixed within a firmware session, though it differs between two board configurations. Our driver already reads the frequency during handshake, but it does not attach that information to each saved batch. I suspect the failing run combined samples collected before suspend with an offset measured after resume. I can provide the raw packet capture and hub reset log. We should first establish whether there was a reset, because that determines which conversion rule applies.

There was no hub reset in the captured failure. The sequence number increased continuously, and the generation field stayed at twelve. The user-visible symptom was a brief reverse movement in the orientation plot after a long idle interval; the application did not crash. I reproduced it on two boards with batching enabled, but not with direct event delivery. That narrows the path without clearing the rest of V32. Quality needs an acceptance matrix for batch duration, suspend boundaries, hub reset, and counter wrap. I also want the raw timestamps preserved, because converted application values can hide where ordering first changed.

Let us follow the failing batch rather than debate compatibility in the abstract. Tomas, identify the first sample, last sample, and offset update in one common timeline. Noah, explain exactly where the host applies the conversion. Sujin, distinguish a late delivery from a timestamp reversal; applications can tolerate batching delay while still requiring ordered event time. We also need to separate this correctness defect from the format migration. They may share code, but a fix for one should not be presented as proof that the other is safe. What evidence can resolve that distinction today?

The batch begins before suspend and ends shortly after resume. Its first eighty events were saved under the original offset, but the drain routine converts every event with the latest offset instead of the offset associated with collection. The latest value differs by six milliseconds. That difference is enough to place an early event after a newer event already delivered through the direct path. The packet sequence itself remains ordered. I can reproduce the conversion error on V31 as well by forcing the offset change, so the defect predates the sixty-four-bit format. V32 made it easier to observe because its batching limit is longer.

That explains the cross-path reversal, but I would not fix it by sorting events after conversion. Sorting can disguise a bad time base and alter ordering between different sensor streams. Nor should we clamp every timestamp to the last delivered value; that would turn several distinct samples into one instant. I propose preserving the collection epoch with each batch and converting with an immutable snapshot of its frequency and offset. If the hub resets during collection, the driver should split the batch at the generation boundary. The framework then receives explicit continuity information instead of fabricated monotonic values.

I agree about preserving evidence, but the framework still needs a policy for samples whose epoch is unavailable. Our stress tool can trigger a hub restart while the host queue contains a partial packet. If the driver discards that packet, we lose samples. If it converts with the new epoch, we may deliver a plausible but wrong time. Quality cannot judge correctness until the contract chooses a behavior. My preference is to discard only the incomplete packet, emit a discontinuity record, and resume with the new generation. We should measure the lost sample count, not hide it behind a generic recovery success.

That policy is feasible, although it means the release note must describe a discontinuity rather than promise uninterrupted delivery through every reset. We can guarantee complete packets within one generation, preserve their collection epoch, and report a bounded loss when a reset interrupts a packet. I will ask the firmware team to include a sample-count field in the recovery record. There is also a format question: V31 does not provide that field. The host must choose behavior from negotiated capabilities, not assume all firmware has the new record because the product name matches. That is the compatibility boundary I want documented.

Our original schedule assumed that V32 would replace V31 on every development board next Monday. Supporting both formats extends firmware testing, and the team is also preparing the next power-management drop. I would prefer a coordinated cutover: update the driver and firmware together, then stop accepting V31 on the integration branch. A capability fallback sounds flexible, but it may leave us maintaining two paths indefinitely. Can the program define a short transition period and a clear removal date? Otherwise the supposedly temporary decoder becomes part of the long-term support burden without anyone approving that cost.

A coordinated cutover works for boards we can update immediately, but twelve remote lab units cannot receive the firmware package until their maintenance slot next week. Rejecting V31 would remove those units from integration coverage at exactly the wrong time. I propose a two-week transition with explicit format negotiation during handshake. The default must remain the legacy decoder until both sides confirm the new capability. We can remove the legacy path on October twenty-ninth after the inventory proves every active unit has moved. That is a bounded compatibility plan, not a promise to support arbitrary firmware forever.

I can implement negotiation without maintaining two firmware branches. V32 will advertise the new counter capability but send the old packet layout until the host explicitly selects version two. The host selection is acknowledged before any sensor stream starts. If that acknowledgment is absent or malformed, the driver must fail initialization rather than guess. This keeps packet format stable for a session. We also need to prevent switching formats while a batch is queued; the only valid switch point is before stream activation or after a full hub restart. I will document that state transition so both implementations enforce it.

That avoids one class of ambiguity, but I want negative tests, not just a successful handshake. We should test a missing acknowledgment, an unsupported version, a frequency value of zero, and a generation change while the first batch is draining. The driver must reject invalid metadata without delivering invented timestamps. For the legacy path, we need an accelerated wrap test that starts the counter near its maximum; waiting for a natural wrap would consume too much lab time. The test report must distinguish intentional discontinuity after reset from an ordering violation within a continuous generation.

We can accept the two-week transition if it has an owner and a removal gate. Noah will own the host compatibility path, and Maya will own the remote-unit upgrade inventory. October twenty-ninth is the planned removal date, conditional on all active units completing the update and the legacy wrap evidence being archived. If one unit remains blocked, we will decide whether to exclude it from the shared branch rather than silently extend the decoder. Monday's V32 acceptance will require negotiation and epoch handling; the wider counter alone is not sufficient. Does that give each team a concrete commitment it can deliver?

Yes. I will deliver the host prototype by tomorrow, October sixteenth, at noon Seoul time. It will store an epoch snapshot per batch, split batches at generation changes, and expose counters for discarded partial packets. I will keep timestamp conversion separate from packet decoding so we can test both formats against the same clock rules. The prototype will not sort or clamp timestamps to make failures disappear. I will attach unit tests using a synthetic offset shift, an accelerated legacy wrap, and a reset boundary. The review will show the expected output sequence for each case.

Velora will provide a V32 candidate with negotiated format selection by tomorrow at ten in the morning. The package will include the capability document, firmware identifier, counter frequency for both board configurations, and recovery-record definition. Tomas will verify that the selected layout remains fixed until restart. I will send the remote lab inventory by three today, including the maintenance slot for each of the twelve units. If an upgrade date cannot be confirmed, that unit will be marked unresolved rather than counted as complete. We will review the inventory again before the October twenty-ninth removal decision.

Quality will begin the matrix tomorrow afternoon after both identifiers are frozen. We will cover two board configurations, both packet formats, batching on and off, and suspend intervals of one, ten, and thirty minutes. Each continuous-generation run requires zero timestamp reversals and a maximum conversion error of two milliseconds against the reference clock. Reset runs may lose one incomplete packet, but they must report the loss and resume within five hundred milliseconds. I will also compare orientation output against the direct-delivery baseline. Passing low-level timestamps should not excuse a visible motion discontinuity that our reference device does not show.

I will provide an external pulse reference and a capture script that records raw ticks, generation, epoch identifier, and converted time together. The pulse is sampled by the hub and timestamped by the host test instrument, giving us a common event without assuming that their clocks are already aligned. We will measure reference uncertainty before using the two-millisecond gate. If uncertainty exceeds half a millisecond, that run is inconclusive rather than failed or passed. I will also add a diagnostic control to inject a reset between packet fragments, so the partial-packet policy can be verified deterministically.

I will reserve Monday's integration slot but make acceptance conditional on the matrix, not on package arrival. We will first merge the epoch correction into an isolated validation branch, then pair it with negotiated V32 on the shared branch only after approval. This lets us compare V31 and V32 without bundling every change into one result. The release record will list packet format, firmware identifier, host commit, and board configuration. A result missing any of those fields cannot support acceptance. I will notify the dependent motion team today that Monday is a target with explicit gates, not an unconditional delivery promise.

The acceptance review is Monday, October nineteenth, at nine thirty in the morning Seoul time, before the integration slot at eleven. Sujin will post preliminary results on Friday evening and final evidence by nine Monday. We will choose among accepting the negotiated drop, accepting only the epoch correction, or holding both for unresolved correctness failures. There is no requirement to choose the most feature-rich option. The decision should follow the evidence and preserve a usable integration branch. I will keep a separate October twenty-ninth checkpoint for legacy-path removal, with the remote-unit inventory as its primary input.

One clarification on the framework API: applications will continue receiving timestamps in the existing elapsed-time domain. The new counter is an internal transport detail, not a new public time unit. We will not expose raw hub ticks to applications or ask them to repair ordering. The discontinuity record will be consumed by the driver and quality instrumentation, while normal sensor delivery resumes with the new epoch. I will document that distinction in the host change. It prevents an internal protocol migration from becoming an accidental application compatibility change, and it keeps the test expectations aligned with the user-facing contract.

For Monday, I will show the raw event sequence beside the converted sequence and the reference pulse. Reviewers should be able to locate the suspend boundary, offset refresh, and reset without reading a long narrative. I will include the worst passing conversion error and every inconclusive run, not just an average. If the thirty-minute batch fails while short batches pass, we will not narrow the acceptance claim quietly; we will propose a documented batching limit and ask the motion team whether it still meets their requirement. Any limit must be visible in the release note and enforced by the driver.

I accept the negotiated transition and the evidence schedule. I will correct the compatibility wording in the V32 notes today, before the candidate package is distributed. The note will say that packet length is unchanged but payload interpretation requires version selection, and that collection epochs are part of the host contract. I will also identify the firmware owner responsible for future capability additions. No reserved field will be repurposed without a versioned definition and a host review. That should make the next drop easier to integrate instead of leaving the same ambiguity for another team to discover.

I have the packet and clock actions. Before tomorrow's handoff I will replay the captured failure through both decoders and attach the expected sequence, including the six-millisecond offset change. That replay should show the epoch correction repairing the old behavior independently of the wider counter. I will then run the negotiation failure cases with Noah so our error handling agrees. If either side interprets an unsupported version differently, we will resolve it in the interface document before Quality starts the matrix. I will send the capture tools this afternoon, so Sujin can verify the reference setup while the candidate is being built.