I have encountered a critical issue with the Rolling Code Encoder. When emulating/sending a signal, the Flipper UI correctly displays an incrementing counter (e.g., Cnt: 100 -> Cnt: 101 -> Cnt: 102). However, the actual RF signal transmitted does not change. It remains a static replay of the original captured signal.
I verified this by using a second Flipper with read Raw
Expected Behavior:
The Encoder should re-calculate the encrypted payload (Hex Data) for every transmission based on the new counter value displayed in the UI.
Actual Behavior:
The Encoder updates the UI label but transmits the original, cached buffer (Static Replay) without re-encrypting the payload for the new counter.
Technical Suspicion:
It seems like the encoder->update() function or the payload generation logic is not being triggered or is failing to overwrite the transmission buffer. The logic seems to be desynchronized: The UI updates logically, but the RF worker sends the static data buffer from the file/capture.
I have encountered a critical issue with the Rolling Code Encoder. When emulating/sending a signal, the Flipper UI correctly displays an incrementing counter (e.g., Cnt: 100 -> Cnt: 101 -> Cnt: 102). However, the actual RF signal transmitted does not change. It remains a static replay of the original captured signal.
I verified this by using a second Flipper with read Raw
Expected Behavior:
The Encoder should re-calculate the encrypted payload (Hex Data) for every transmission based on the new counter value displayed in the UI.
Actual Behavior:
The Encoder updates the UI label but transmits the original, cached buffer (Static Replay) without re-encrypting the payload for the new counter.
Technical Suspicion:
It seems like the encoder->update() function or the payload generation logic is not being triggered or is failing to overwrite the transmission buffer. The logic seems to be desynchronized: The UI updates logically, but the RF worker sends the static data buffer from the file/capture.