Checksum? #1
Comments
|
Hi! Honestly, I haven't even tried guessing how it's calculated or what it is. I've only had two remotes from A-OK and that is too less data to work with. It also relies on the fact if my interpretation of the tri-bit transmission is the same that the manufacturer is using (short HIGH = 0, long HIGH = 1). If you do make progress with this, I'd be very interested to know! |
|
I have some information to add! :) I have 10 remotes. 8 are single channel, 1 is 6 channel, and 1 is 16 channel. Here are pictures:
The multi channel remotes both have an "all call" mode, where the command is sent to all the channels. You select it by using the right or left buttons to go past the end of the channel numbers. On the 6 channel remote all 6 LEDs light up, and on the 16 channel remote it says "CC". Using a Sonoff RF Bridge with Tasmota and Portisch installed I captured every command from every remote and every channel: And here is a log of my parsed output from that file, using your description of the protocol: A few things of interest:
I'm going to keep working on this, but I thought I would share the data in case you want to try too :) Thanks, |
|
Forgot to add, here is how you interpret the B1 command in the raw log. |
|
Got it all figured out :) It's 64 bits of data, with a trailing 1 making it 65 bits transmitted. The packet format is: [Start][ID][Address][Command][Checksum][1]
Here is the log I sent previously, now decoded using this algorithm: |
|
Whoa, hats off to you, sir, that was fast! Just got back to my e-mail today and the solution was already there. :) I'll include the protocol description in the next commit, with compliments to you. Cheers! |
|
Thanks @akirjavainen, it was a very fun project! |
|
Sorry to reopen this, I am trying to use this information to craft my own B0 commands in Porstich firmware to control my blinds. @vonnieda How did you go from B1 output to the binary string representing the command? So far I was able to use Porstich advanced sniffing feature to repeat the same command from the remote, which works 50% of the times. Every sniff I get is different so I was hoping to do the reverse, craft my own remote with unique id, create each command using the information on this issue, and then convert that into a raw command for Porstich. |
For a long winded and unfinished explanation, see all the stuff below. I started typing up a full breakdown of how all this works, but I got tired and decided to just post the code instead :) Take a look at the attached code, and if there's anything that's not clear from the code or the explanation below let me know and I'll fill in the gaps. You can run the code at https://replit.com/@vonnieda/AzureRoundSystemintegrator#Main.java Here's the code: And here's the output: And here's the long winded explainer: See this: https://github.com/Portisch/RF-Bridge-EFM8BB1/wiki/0xB1 These commands are essentially a set of instructions sent to Portisch that tell it at a low level when to twiddle the radio output. Using that information, take this as an example:
AA: uart sync init The rest, starting with the The first and last bucket are synchronization related and aren't really used in data transfer. I think they are probably actually the same, but maybe Portisch didn't have the resolution to recognize it. Bucket 4 is called AGC or "automatic gain control" and is basically a way to wake up the receiver and let it know something is coming. This is sent at the beginning of the packet. Bucket 1 is sent at the end to signal the end of the packet. Buckets 2 and 3 are the ones we are most interested in. They are what is used to transmit the actual bits of data. So, to transmit a 1 bit the radio turns on for the number of microseconds in bucket 2 (610) and then low for the number of microseconds in bucket 3 (300). To transmit a 0 it's the opposite: high for 300 then low for 610. Something to keep in mind is that we're mixing two different systems here. There is the way Portisch represents radio data, which is this bucket and packet system, and the way the actual remotes look at the data, which is just periods of on and off on the radio - this is where OOK comes from - On Off Keying. So, finally we can decode the data from Portisch. Each byte represents one high/low pair and each nybble of each byte represents one of the two high/low bits. The highest bit of the nybble is the bit, and the bottom three bits are the bucket. So, starting with 38, which is in hex, we take bottom three bits of the first nybble 3, which are 011 on binary, or 3 in decimal. This is our bucket number - bucket 4 (or 3 if you are counting from 0). And the high bit of 3 is 0 so that's our value. So, the 3 in 38 means: Turn the radio off (0) for 5300uS (bucket 4) That's our first byte parsed, and the first bit sent. This is the AGC or wakeup. Next is 19: Next is 2A, let's look at it a different way: |
|
Thank you so much! I could not find anywhere documentation that explained what the buckets were supposed to be (maybe it's just part of encoding RF signals). The code is immensely helpful, I'll give it try. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @akirjavainen - do you have any ideas of what the checksum algorithm might be? I'm trying to figure it out because I would like to be able to generate new commands without having to record them from a remote. If you have any guesses it might help me figure it out. Thanks!
The text was updated successfully, but these errors were encountered: