Conversation
A learning session is arm, poll, wait, re-arm, one code at a time, with a device that leaves learning mode without saying so and a send that ends the session. capture() and capture_rf() own that loop and hand back clean signals, so a consumer subscribes and reads instead of reimplementing the dance (as the remote platform, the receiver PR and others each did). - capture(window, stop_after_first, poll_interval, rearm_interval): async generator yielding CapturedSignal. Re-arms on a timer (default 15 s, under the 25-40 s the device was measured to hold a session) and after any send_data (a send ends the session; both from the bench). One window per device; a second raises CaptureInProgressError. - capture_rf(window, frequency, ...) on the Pro classes: takes the carrier directly, or sweeps for it when not given. The sweep is unreliable on some firmware, so the known-frequency path is primary. - CapturedSignal: device packet, pulses at the corrected tick, kind, repeat, and the RF carrier the packet does not itself record. - pulses_to_data gains kind and repeat; parse_packet is the inverse; SignalKind names the bands. A returned RF packet does not always carry the canonical type byte (an RM4 Pro sends 0xB1 for 433 MHz), so kind is read by band and a capture is tagged from what it armed, never dropped on the byte. - One shared front-end lock and a transmit generation counter already live on the device; capture reads the counter so a concurrent send re-arms the window. Tests drive the loops against a scripted device that models the bench findings; the transport oracle fixtures are unchanged.
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.
A learning session on these remotes is arm, poll, wait, re-arm, one code at a time, on a device that leaves learning mode without saying so and whose own transmissions end the session. capture() and capture_rf() own that loop and hand back clean signals, so a consumer subscribes and reads instead of reimplementing the dance the remote platform and the receiver PR each did separately.
capture(window, stop_after_first, poll_interval, rearm_interval) is an async generator yielding CapturedSignal. It re-arms on a timer (15 s, under the 25 to 40 s the device was measured to hold a session) and after any send_data, since a send ends the session. One window per device. capture_rf(window, frequency, ...) on the Pro models takes the carrier directly, or sweeps for it when not given; the sweep is unreliable on some firmware, so the known-frequency path is primary. CapturedSignal carries the device packet, the pulses at the corrected tick, the kind, the repeat count, and for RF the carrier the packet does not itself record.
Packet helpers: pulses_to_data gains kind and repeat, parse_packet is the inverse, SignalKind names the bands. A returned RF packet does not always use the canonical type byte (an RM4 Pro answers a 433 MHz capture with 0xB1, not 0xB2), so the kind is read by band and a capture is tagged from what it armed rather than the byte.
Benched live on an RM4 Pro: IR single and multi-capture confirmed, the 25 to 40 s session limit and the send-ends-session behaviour measured, the 0xB1 RF byte and the flaky sweep observed. 242 tests on 3.13 and 3.14; the transport oracle fixtures are unchanged.