-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RF bridge doesn't accept every 16th-32th B0 string #11
Comments
this 16-16 rule applies on using the same command. whenever you change the command within the 16 requests (e.g. from DOWN to UP), this 'doom count' seems to be reset. Here's some output from running
|
I know the problem, that sometimes the RF bridge does not send the command but starts beeping and stops working. It happens randomly and I could not find a pattern like you describe. It usually works by sending the exact same command again after rebooting the bridge. Do you have any suggestions, what could be wrong with the |
@sehaas - it is indeed a problem with the length of the string - What i did for now is a workaround, which checks whether the length of the generated encrypted payload is an odd number - if it is, it doesn't transmit it, but increments the rolling code counter and tries again until it gets an even payload length (tl;dr it discards the invalid b0 strings). EDIT:
|
I was trying to nail down the issue, where after several commands, the RF bridge stopped transmitting the messages and just beeped.
So i focused on
yfmos
as it might compose the messages wrong.and what i found out is, whenever I start clean - and transmit exactly 16 messages, the 17th-32th messages don't work. Funny enough, after trying to transmit 16 another messages where none of them came through, it started to work for another 16 messages again.
Isn't there a bug in the way you compose the message (
strLen
maybe)?The text was updated successfully, but these errors were encountered: