Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Additional info for generating data for IR/RF from LIRC DB etc. ... #57
Last week I received my RM2 Pro and did some reverse engineering on the data required for command 2.
Data for sending an IR/RF command (payload for the send command)
Each value is represented by one byte. If the length exceeds one byte
Example: The header for my Optoma projector is 8920 4450
So the data starts with
If you use LIRC as a template then you have just to continue with pre-data and then command, where you would use the "zero" pulse lengths for 0 and the "one" pulse lengths for 1
It seems that infrared commands need to be terminated always with
So far I was able to produce all IR commands for my devices as well as for all RF devices. I have quite a bunch of RF devices, like remote controllable sockets and switches and a projection screen. For most of them I was not able to learn the RF code with the RM2 PRo, but as I knew the timings already generating the codes works perfectly well.
If you have any questions or you need help let me know. I will publish soon the C code of my xpl gateway on GitHub, if someone is interested.
One more thing: If you don't want your device to connect back home to China or to talk to Amazon then you better block outgoing traffic for your device.
I was wondering if someone could help me translate a LIRC remote profile into a Broadlink command payload. I want to control my old Philips FA 330 Amplifier with my Broadlink RM3 Mini. I've been playing with the python-broadlink library for a while now and I know how to capture codes and replay them. I don't own the remote that belongs to the device.
I found this remote profile in LIRC's database. This is not the remote for my exact device, but I figured that it might work, since their functionality is quite similar. I am struggling to convert it to a usable format. Even though the above information is very helpful, I don't quite understand how to write down a command in pulse lengths. Thanks in advance for the help!
referenced this issue
Mar 1, 2017
Here's a Gist of a Python program that converts Pronto IR hex codes to LIRC and then to Broadlink commands according to this specification. I've successfully converted dozens of Pronto codes with it. I hope it saves somebody the trouble of recreating it!
One thing I think wasn't mentioned is that the command needs to be padded with zeros at the end so that after
Hi Dimitris, actually you are right, it is a 24bit, here are some hints how to read it: The first one: b2 RF 08 Repetitions 34 00 52 bytes follow (big endian) Afterwards there is a series of 24 0d and 0d 24 (0c and 23 are the same, there is some tolerance). Let's interpret long-short (24 0d) as 1 and short-long (0d 24) as 0. Then there is one sequence 0c 00 01 6f. This is the footer. 0c is short as always and 00 01 6f means 016f. It seens that the BL device is not smart enough to detect the footer as end, but as there are repetions it works anyway. So let's start to write down the pairs _after_ the footer and at the end switch over to the start. Then we have: 24 0d, 0c 24, 0c 24, 0c 24 ..... 0c 24, 0c 00 01 6f If we interpret the bits and write it in hex we get: 8074a4 If you do the same for the second one you get: 8074a8 In the 3rd and 4th one the BL device was not able to detect that it is a repetion. Therfore the repeat count is 0. We can pick any sequence between two footers and get 8074a2 or the 3rd and 8074a1 for the 4th. So it seems that the first 20bits are the device ID and then each bit 21..24 is representing one button. If you want more buttons I would try to increment the ID by one, so e.g. 8074b8, 8074b4, 8074b2, 8074b1 The sequence would be then: b2 RF 08 Repetitions 34 00 52 bytes follow (big endian) 24 pairs + 4 for the footer ## ## 24 0d for a 1, 0d 24 for a 0 0c 00 01 6f (Footer) Cheers, Tobias…
-----Ursprüngliche Nachricht----- Von: dimkaram <firstname.lastname@example.org> Gesendet: Don 16 März 2017 16:47 An: mjg59/python-broadlink <email@example.com> CC: Tobias Waldvogel <firstname.lastname@example.org>; Mention <email@example.com> Betreff: Re: [mjg59/python-broadlink] Additional info for generating data for IR/RF from LIRC DB etc. ... (#57) Hi All and thanks for the fantastic work that you have been doing here! First of all, apologies for the long post. Also, I don't have much experience on electronics or programming, but I am keen to try and learn. So, I am using this script as part of Home Assistant. Among other devices, I want to control this RF 3-gang light switch: http://www.ebay.co.uk/itm/182305423992?_trksid=p2057872.m2749.l2649 <http://www.ebay.co.uk/itm/182305423992?_trksid=p2057872.m2749.l2649> It has 3 buttons, and each one can be programmed to 3 commands: toggle, on and off, i.e. a total of 9 commands. However, the remote that comes with it only has 4 buttons, so I can only produce 4 codes. I am using these codes for toggling switch 1, toggling switch 2, toggling switch 3 and switching everything off. This is OK for normal use, however, for home automation purposes, I want to have different codes for explicitly switching each switch on and off. To make the long story short, I want to generate 6 additional RF commands for my Broadlink device, so that I can program each switch to turn on and off when these commands are transmitted. I found out that the remote has an ev1527 chip, where it also says 1410 (I suppose this is a pin). I have obtained the hex codes for the 4 buttons of my remote, and they are as follows: b2083400240d240d230d0c24240d0c250c25230d0c25240d0c250c24230d0c250c250c00016f240d0c240c240c250c240c250c250c250c2400000000 b21034000c250c240c24240d240d240d0c24230d0c240c24240d0c25230d0c25240d0c250c250c240c00016f230d0c240c250c250c250c2400000000 b200ca0004000185240c0c23230c0c230c240c23240b0c230d00016d240b0c230c240c230c230c230c230d230c23240b240c230c0c23240b0d230c23240b0c23240c0c230c230c23240c0c230c00016e230c0c230c230d230c230c230c230c240c23240b240b240c0c23240b0c240c23240b0c23240c0c230c230c23240c0c230c00016e240b0c230c240c230c230c230c240c230c23240b240b240c0c23240b0d220d23240b0c23240c0c230c230c24230c0c230c00016e240b0c230d230c230c230c230c240c230c23130005dc0000000000000000000000000000 b2006c000c000172240c0c240c240c230d230d230d230c240c24240c240c240c0c23250b0d230d23240c0c24240c0c240c240c230d23250b0d000172240c0c230d230c240c240c240c240c240c23250b250b250b0c24240c0c240c24240c0c24240c0c240c240c230c24240c0d0005dc000000000000000000000000 Clearly, they all start with b2 as expected. Second byte varies from 00 to 10 for different buttons. Third and fourth byte are indeed the length of the following data in little endian (the rest is filled with zeros). I have also found out that the ev1527 should be transmitting 24bit codes. However, the values that I can see don't make any sense to me (even their length is not always a multiple of 24bits!). Does anyone have any idea on how I can understand what these codes are and/or how I could possibly produce the 6 additional ones that I actually need? Many many thanks, Dimitris — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
referenced this issue
Apr 24, 2017
So, I've been struggling to understand the actual protocol, because there are many sources of remote control data, and I really wanted to understand what the format was actually doing.
The Pronto -> LIRC -> broadlink format shifter was cruicial to understanding it, and appden probably understands what was going on, but it took me a long time to finally understand what was happening.
This isn't really that useful for people to know, but I finally fully understand what the broadlink protocol is. tobias' description above isn't quite right. It might be appropriate for some IR protocols, but not for all of them. (tobias might know this already, but the description above didn't actually explain the protocol for me properly).
As I say; this is going too in depth, but I needed to understand it for myself so I thought I might describe it anyway.
So, in large part the protocol is as described above.
Now, if you read tobias' description above you might be confused. above he describes IR commands representing "0" and "1" using 2 seperate bytes. For some IR encoding schemes this is accurate. but read on for why.
Each of these duration values, represents the duration until the next "change" in IR brightness.
Some IR schemes represent 1's and 0's with a full up and then down pulse, and associated durations. (this is the scheme tobias described above) In this instance, you can describe the "1"s and "0"s using each of the distinct 2 byte pairs.
For different IR encoding schemes however (the one I unfortunately was investigating!) the 1's and 0's are encoded slightly differently. in the RC6 scheme, it is slightly condensed.
Specifically in RC6 it is the movement of "low" to "high" that represents a 1, and the movement from "high" to "low" that represents a 0. You might be thinking to yourself, so? that sounds the same! but it isn't. The data is condensed. It takes varying numbers of bytes to describe different values.
it is easiest to show the difference when you look at consecutive numbers.
(header of this table represents the "duration" of the time-slice)
Notice how the value of 00 and 11 are the same codes, and the values of 01 and 10 are also the same (and also only 3 bytes not 4 bytes long). This kind of encoding is more efficient, but the actual value being transmitted, relies on the previous state. So, 01 and 10 are the same, but their initial conditions were different. The initial condition was low or high, which changed what the subsequent value would be.
other than the 0d0f at the very end, and the first 4 bytes for the type-repeat and lengthofpacket bytes, every single byte (or 2 bytes when there is a leading zero) represents a duration. but does not explicitly represent a 1 or a 0, or even if it is a "high" pulse of a "low" pulse. It is a duration until you go "high" or go "low".
Just in case someone was wondering how this all worked! (it was doing my head in!)
RC6 description (the windows media center remote uses the RC6 protocol)
the Pronto->Lirc->broadlink was critical for my understanding of this. But I needed it in context of the RC6 protocol.
Importantly, not all IR protocols are the same. Some of them really are as simple as looking at 2 bytes at a time to get a 1 or 0, but the RC6 protocol requires that you know every byte that came before, before you can know if you are looking at a 1 or a 0.
I'm trying to do some RF reverse engineering with a roller shutter switch that I bought at aliexpress.
0xB2 0x3D 0x32 0x00 0x0F 0x0E 0x07 0x0A 0x07 0x0B 0x06 0x0A 0x0B 0x06 0x0A 0x07 0x0A 0x07 0x0B 0x07 0x0A 0x07 0x07 0x0B 0x0A 0x07 0x06 0x0B 0x06 0x0B 0x06 0x0B 0x06 0x0A 0x07 0x0A 0x07 0x0A 0x07 0x0A 0x0A 0x07 0x0A 0x07 0x07 0x0A 0x06 0x0B 0x07 0x0A 0x06 0x0B 0x0A 0x07 0x00 0x00 0x00 0x00 0x00 0x00
Thank you very much!
@marcoalexpinheiro Hi Marco,
so starts with 0xb2, so it is 433 mhz. (just states the frequency that the pulses are done at, has nothing to do with the "protocol")
0x3d = 61, this implies that it repeats the following sequence 61 times. I have zero experience with RF transmitters and don't know if this is a sane value. (IR this value is usually more like zero or 1 or sometimes 2).
0x32 0x00 = 50, indicates 50 bytes of "data" to follow. Unlike IR, RF data appears to be all "pulse information" which is to say, there is no pattern at the end of a transmission.
All of the remaining bytes represent durations spent either "high" or "low". Those durations should be roughly the same. The only exceptions to this are usually the "lead ins".
Your packet contains:
As per Tobias's post above, each value is multiples of ~32.84ms. so 32 * 6 = 192
let us assume that this is a simple encoding scheme (not like the RC6 IR protocol) and that each following two bytes represents either a 0 or a 1.
Using Tobias' example above, Long-Short can be 1, and Short-Long can be 0
So your data becomes:
0xB2 0x3D 0x32 0x00 0x0F 0x0F
So lead in with a pulse that goes high for 480ms, then low for 480ms
I don't know if these durations mean anything to you or the documentation for your transmitter, but hopefully the above helps.
(for what it is worth, using the above your code is: 0001 1111 0100 0000 0110 0001 => 1F4061, which appears to be a 24 bit number in a similar vein to the message Tobias was helping to decode above.)
I tried to use the frequency identifier 0xd7 to transmit on 315MHz, but it didn't work. So I decided to just brute force the id and listen to the radio on rtl-sdr. Found out that codes 0xaa to 0xac work for me. I have an RM pro without a number, really hard to identify these devices tbh.
Correction - codes 0xaa through 0xbd are picked up on frequencies from 314.729 to 324.228. There's 500kHz between adjacent codes. BUT the 315MHz signal from the RM pro is so weak I doubt it can be useful for any practical purposes. It's way weaker than a 315 remote control. I might be doing something wrong though, will update.