Remote Address Inversion Handled Differently on some remotes
grene78 opened this issue · 6 comments
I'm not sure if you want to handle this use case, but it might help someone else having issues using your code.
The remote I have inverts the remote address differently. Instead of a true inversion, it inverts the bit order
When I debug your code after the 32 bits have been read in on_data_bit() I have
packet.addr = 134 (1000 0110)
packet.addr_inv = 97 (0110 0001)
Since I only need to pay attention to this specific remote, I can easily hack it like this, and everything else works.
if (( packet.addr == 0x86) && (packet.addr_inv == 0x61) && ((packet.command + packet.command_inv) == 0xFF))
{
// new valid packet is received
on_new_packet_received();
}
Note: This only applied to the address bits on my remote, the command bits are truly inverted.
On second thought, perhaps I just have an extended NEC address and its a happy coincidence that the low byte is the reverse of the high byte.
Thank you Chris, for your comments.
It would be good to add support for the Extended NEC protocol, but for that I have to find such remote control to test and debug :)
I can send you one of these. I'm also running into a problem where the remote stops responding for a certain amount of time somewhat randomly (atmega328p @16mhz) but I have not had time to find the proper fix. It works fine for a while but then it gets hung up and won't respond for a few seconds (verified issue with nothing running but an empty main loop and your code, with this remote). I worked around the issue in my code by adding a global timeout for IR activity and resetting the receiver, but there is probably a better solution. I believe it has something to do with the repeat code logic. I can somewhat reliably reproduce the issue by covering the IR eye of the remote during a button press.
RE: "hung up" issue, good to know, I will try to reproduce the issue and find a solution.
Please test new version of the lib, and if it is fine, we close this issue.
Should work.