Step 1: Why?
So why normalize and compress signals.
Well to be honest I am not sure if this is a must or if it is another way to make this better. But I come across an issue that lead me to search for this solution. The problem is that I was experimenting with this kind of transceiver nRF24L01 (a device with the capability to send and receive information throughout radio waves ) and find out that it has a limitation on the amount of information to send each time (32 byte payload). Even thought this exchange of information it is done very fast, the more information you send, more possibilities of crashes during the exchange. So I knew then I had to shorten some how the signal, in order to make the less exchanges possible.
I would like to make clear what I mean by normalize and compress. May be not everyone is aware of that. As you might know, this kind of signals are basically made by a big array of numbers (456, 912...) that represent information. But what they are expressing is not specific numbers, what they really represents is states (500,1000...). Or lets say true and false. Once you are capable of extract the meaning of that number, you'll find out that you can handle that information in another way. So you will be normalizing the information, no more number, they are states. By doing that you are not only normalizing, you are also compressing the signal because you can transform what once was an integer into a char. And that is very important because char need half of bytes to be stored!!!!
Take a look at this page:
An once you see a normalized signal you will find out that the numbers are very repetitive. Same number is repeated many times, and that is waste of precious space!!!. And working with Arduino you will find soon that your memory is very limited, mostly if you want to put code for doing several things, like for example receiving signals of any kind and forwarding those to another Arduino devices or decompressing and emitting that signal to the final device (television), among other things.
Now let me show you the final result of this:
860, 820, 860, 816, 1720, 820, 860, 820, 860, 820, 860, 820, 860, 816, 860, 820, 864, 1640, 856, 820, 1716, 824, 860, 19844, 836, 820, 860, 820, 1716, 824, 860, 816, 864, 816, 860, 820, 860, 820, 860, 820, 860, 1660, 840, 820, 1716, 824, 860,0
839, 839, 839, 839, 1684, 839, 839, 839, 839, 839, 839, 839, 839, 839, 839, 839, 839, 1684, 839, 839, 1684, 839, 839, 19844, 839, 839, 839, 839, 1684, 839, 839, 839, 839, 839, 839, 839, 839, 839, 839, 839, 839, 1684, 839, 839, 1684, 839, 839, 0
To char: (converted to states and characters) T=treu, F=false, H=high, z=zero.
As you can see, we are reducing the payload by far!!!
Another thing to bare in mind in why to do this, is that it will be so much easier to handle the strings. Believe me when you are testing and you have to copy and paste, you do not want big strings seriously... lol.
Also for the sake of nicer code you will prefer shorter strings and of course, event dough you wont worry about space in your computer, is better to store less always. And finally, if you final purpose is to centralize your domestics in one computer, you do not need large signals moving all round your house.
So let me show you how I did it.
Step 2: Normalization
If you take a look at the original signal, you will see that the number are kind of similar. They are grouped in ranges, for example (860, 820, 860, 816), represent the same state. Am not an expert on the field but I guess this is because when you are capturing the signal the receptor wont be accurate in the moment of detecting the blinking of the ir led or the time of the blinking. But it would be very precise in a certain range. So quickly we can figure out that we have number in the range of 800, 1700 and 2000. That would be our states. Let say TRUE, FALSE, HIGH. Or T,F,H.
You can replace this by hand, but it would be some kind of barring...lol. Did it once, to see if it works. But then decided to generate a SCRIPT. So I wouldn't worry any more. So the only hard coded parameter that we will have. would be the range in which we will be looking and grouping our numbers. This number will depend I guess with the kind of device you are dealing with and the sensibility of your IR receptor. In my case I could normalize and compress the signals for my tv, air conditioning and ceiling fan. So would say is pretty accurate.
I did the code in java since am a Java programmer. But the logic behind is pretty simple and I think is not hard to read. It has three basic important methods: normalize, compress and inflate. The last method is just to check if all the process went well and the original signal is intact. By simply reverting the process.
Here you have the code
Running the code
The output of the program will give you this information:
Number of states:3
839 1684 19844
normalized length: 48
Compressed string: 4FT12FT2FT2FH4FT12FT2FT2FS
Compressed length: 26
Inflated length: 48
As you cans see is pretty clear, gives you the information of what is happening in those 3 basic steps.
Step 3: Compression
Now you will see that the compression part is pretty simple. It goes through all the signal if the state is repeated, counts the repetitions and add the count first and the the state.
Step 4: Reverting the Process
I did this just to check if the process will be successfully reverted and if signals would work without problems once they where inflated. I called it inflate since is basically an compressing process. Bare in mind that i try to do it as simple as possible so I can us it later as a model to implement the code in The arduino board.