Repository navigation
Advertise faults, survive garbled messages and stale connections - #22
Merged
Merged
Conversation
The pod told the phone the transfer failed, then exited, relying on run.sh to restart it. With nothing to restart it in the Simulator, a relaunched Loop that sent a message the pod read garbled lost its pod. The phone sends it again.
A paired pod's 2nd service UUID is C001 normally, C005 while an alert fires and C00A on a fault, and its manufacturer data carries a status word with the fault code and alert slots, as captured from real pods in OmnipodKit. The simulator advertised neither, so Loop's connectionless fault detection (a background scan for C00A, which wakes the app) never saw a simulated fault. Faults and alerts set from the control panel or by commands now show in the advertisement. paypal/gatt advertises no manufacturer data, so over Bluetooth only the UUID changes.
Connected() stopped the message loop, but a loop blocked inside a message only checked for that between messages. When the phone went away mid-message (an app suspended in the background), the old loop stayed blocked in ReadData and took the first packet of the next connection's next message. The new loop read the rest out of step, failed its checksum and told the phone FAIL, and every session after that failed the same way. Each connection now gets its own input channels, and the loop's reads end when it is stopped.
OmnipodKit quiets its C00A fault scan once it detects a fault and only lifts that when alerts clear or it pairs a new pod. A fault cleared from the control panel leaves the scan off, so a second fault test needs a relaunched Loop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
run.shto restart it. Nothing restarts it in the Simulator. The phone now just sends the message again.C00Aon a fault (C005for a firing alert), and the manufacturer data carries the fault code and alert slots, as real pods do. Loop's background scan forC00Anow sees a simulated fault and wakes the app.pkg/bluetooth/bluetooth_test.gocovers it, and fails on the old code.The first two commits were pushed to #21 after it had been merged, so they never reached
main.go test -race ./...passes, and it builds forGOARCH=arm. Tested against Loop in the Simulator through ImpossiBLE: a fault woke the suspended app, and sessions and status reads work after Loop is suspended mid-message.