search

danielweidman / pixmob-ir-reverse-engineering

Hacking the PixMob infrared (and now also RF!) protocol to enable control of PixMob wristbands at home.
MIT License
593 stars 42 forks source link

Contribution to pixmob-ir-reverse-engineering /rf #43

Open MajedAbouhatab opened 8 months ago

MajedAbouhatab commented 8 months ago

https://www.hackster.io/abouhatab/reusing-pixmob-waveband-without-flipper-zero-040f3a#comments

danielweidman commented 8 months ago

Wow, this is excellent! Your guide looks great. I had wondered if it would be possible to use one of those LoRa boards--glad to see it is! I bet you get super long range with that.

I don't have that specific board, but I might get one to try your method out.

MajedAbouhatab commented 8 months ago

Thank you so much for your kind words and starting this project. Wonder no more. I trusted your code and as soon I sent the signal expected PIXMOB to blink. I made few observations to enhance the modified signal and help out anyone else. If we know how signal is constructed, we will not need to modify raw captures. The board I have happened to have a LoRa module on it, but radiolib library should work on many sub-Ghz modules such as RFM69 and CC1101. LoRa modules are more expensive than ordinary sub-Ghz modules. As for the long range, it is a LoRa modulation feature, not the module. Haven't tested the range, but I'm sure it will not be comparable to LoRa since we are using OOK modulation (maybe closer to ASK).

sueppchen commented 5 months ago

at first: great work - thank you all. I got some pixmob wavebands from cleaning up a concert hall and could reuse them with the RF codes here. got it running with an arduino and an cc1101 transmitter( see https://github.com/sueppchen/PixMob_waveband). so I connected the logic-analyzer and tried to flip some bits - the result was no light and the receiver entered sleep-state. ok... some kind of checksum or CRC so maybe someone else has an idea: transmition is 0xaa, 0xaa, logic 0, logic 1, 9 bytes payload

the 9 bytes are: unknown(frc), zero (maybe mode), green, red, blue, rise, fall, zero(maybe group), unknown (maybe crc)

all the bytes are ,,encrypted" 0b10000100 0.0% = 0x00 0b00110010 6.9% = 0x11
0b10010001 28.7% = 0x49 0b10110001 43.0% = 0x6E 0b10110101 45.5% = 0x74

byte 5 and byte 6 are the timing-bytes: maybe devided into 4 nibbles: rise, random, hold, fall 0b10001001 + 0b10001001 = 440ms rise, 516ms hold, 440ms fall,
0b10001001 + 0b10101001 = 440ms rise, 118ms hold, 440ms fall, 0b10001100 + 0b01000101 = 440ms rise, 215ms hold, 85ms fall, 0b01001001 + 0b01000101 = 80ms rise, 215ms hold, 85ms fall, 0b00101001 + 0b01100101 = 80ms rise, 113ms hold, 85ms fall, 0b10110110 + 0b01001101 = 16ms rise, 48ms hold, 85ms fall, 0b01100100 + 0b01101010 = 0ms rise, 32ms hold, 16ms fall,

so... has anybody an idea how to decode everything and... how the checksum is calculated? if we solve that we can send what we want to the object ;-)

btw: at powerup the mcu reads 6 bytes from eeprom: address 0x00 : 0x0D address 0x03 : 0x02 (some 0xff, some 0x01) address 0x02 : 0x00 address 0x01 : 0x03 (some 0x00) address 0x0B : 0x04 (some 0x09) - some of them read address instead 0x08 : 0xff or 0x01) address 0x04 : 0x00 (some0xff or 0x00)

MajedAbouhatab commented 4 weeks ago

@sueppchen you are a freaking genius, and I hope that translates well in every language you speak. I had to do a lot of the work you did in order to understand what you did. I spend days trying to figure out CRC only to realize that you already did. Here is a project I built with your new library; I would be honored if you include it in your examples. https://www.hackster.io/abouhatab/controlling-pixmob-waveband-with-wemos-d1-mini-and-cc1101-404c89