Decoding the 433.92Mz LightwaveRF protocol

  • February 3, 2013 at 14:46 #4565
    Chris
    Keymaster

    Benjie Gillam (@benjie on twitter) has done some interesting work decoding the 433.92Mhz protocol used by LightwaveRF devices. This could lead to a number of home brew recipes for custom controllers and Wi-Fi link emulators based on Arduino and Raspberry Pi hardware amongst other things. Check out his blog post here:

    http://www.benjiegillam.com/2013/02/lightwaverf-rf-protocol/

    Chris Mills
    Founder and Editor - LightwaveRF Community
    http://cpmills.com/ https://staging.lightwaverfcommunity.org.uk

    February 4, 2013 at 15:44 #4599
    Benjie
    Participant

    Hello everyone 🙂

    I’ve both received and sent 433MHz LightwaveRF data now – and more reliably than my RFXCOM to boot!

    I plan to make a cheap generic 433MHz RF transceiver capable of talking to many different things, and do the decoding in software on the computer. There’s no reason that you can’t embed the LightwaveRF encoding/decoding on an embedded chip though if you prefer.

    If you want more details just let me know what parts you’d like me to expand upon – I’m planning on writing a post about building your own transceiver using an Arduino and 433MHz radio receiver/transmitter. The wiring is insanely simple.

    February 6, 2013 at 01:32 #4668
    brownjl
    Participant

    🙂 I wish you had published this just two weeks ago.. I’ve also decoded the protocol, but took a slightly different approach..

    I ignored high pulses and just looked at the timing of low’s. A short low is considered as a wire bit 1 and long as a wire bit 0. I see 72 bits per transmission with a single short bit (1) at the start and end of the packet for framing leaving 70 bits. I then found that there was 10 sets of 7 bits with each of these groups of 7 bits representing a nibble. So;

    Wire 7bits = 4 data bits

    0x7A:   0x00

    0x76:   0x01

    0x75:   0x02

    0x73:   0x03

    0x6E:   0x04

    0x6D:   0x05

    0x6B:   0x06

    0x5E:   0x07

    0x5D:   0x08

    0x5B:   0x09

    0x57:   0x0A

    0x3E:   0x0B

    0x3D:   0x0C

    0x3B:   0x0D

    0x37:   0x0E

    0x2F:   0x0F

     

    I believed they encode 7 bits to 4 so every nibble has exactly the same number of 0/1’s when transmitted so all packets regardless of content will take the same transmission time. I then found that the packet had the following framing:

     

    2 nibbles = 1 byte which I just called data!

    1 nibble = unit number

    1 nibble = cmd

    6 nibble = 3 byte id/address

     

    I found that there was 16 units –  with address F also being used as a broadcast too. I found the following commands;

     

    On    Unit:X CMD:0x01 DATA::0x00

    Off    Unit:X CMD:0x00 DATA::0x00

    Group oFFUnit:F CMD:00 DATA::0xC0

    MOOD1Unit:F CMD:0x2 DATA::0x82

    MOOD2Unit:F CMD:0x2 DATA::0x83

    MOOD3Unit:F CMD:0x2 DATA::0x84

    MOOD4Unit:F CMD:0x2 DATA::0x80

    MOOD5Unit:F CMD:0x2 DATA::0x81

    Lock Unit:XCMD:4 DATA::0x80

    UNLOCKUnit:XCMD:4 DATA::0x00

    All LockUNIT:x CMD:4 DATA::0x8F

    Close RelayUNIT:x CMD:7 DATA::0x00

    Open RelayUNIT:x CMD:4 DATA::0x1F

    Stop RelayUNIT:x CMD:4 DATA::0xC0

    Dim to Set LevelUNIT:XCMD:1 – LEVEL 1-31 = DATA::0x81-9F

     

    I found when an on is sent and the button is pressed the data value changes after a number of seconds of being pressed – I believe this is so the receiver can detect the long press and can start dimming until transmissions stop.

    I think this pretty much repeats everything you have done! Shame as I spent quite a few hours decoding this!

     

    James

     

    February 6, 2013 at 08:05 #4669
    Benjie
    Participant

    Great work, brownjl!

    I ignored high pulses and just looked at the timing of low’s. A short low is considered as a wire bit 1 and long as a wire bit 0. I see 72 bits per transmission with a single short bit (1) at the start and end of the packet for framing leaving 70 bits. I then found that there was 10 sets of 7 bits with each of these groups of 7 bits representing a nibble.

    I did something like this initially but felt that something was missing – the data didn’t look right to me. When I switched to encoding as “10” and “1” suddenly the data was a lot clearer – 10 groupings of 8 bits, each separated by a “1” bit with extra starting and terminating “1” bits – see the table toward the bottom of this post. It makes scanning the columns for changes much clearer. The 16 nibbles are just 16 of the 21 possible bytes which have exactly two “0”s in and the “0”s aren’t touching: https://gist.github.com/benjie/4698300 – I’m not sure why they picked the ones they did though.

    Our actual understanding of the commands comes out the same – which is great validation – and I’ll add your lock/close relay/open relay/stop relay commands to my list at some point, since I hadn’t got this far 🙂 (I don’t have any relays… yet.)

    What does the lock functionality even do? I’ve never had success with it.

You must be logged in to reply to this topic.