Normalize and Compress IR Signals.

by RakaAmburo in Circuits > Arduino

1646 Views, 20 Favorites, 0 Comments

Normalize and Compress IR Signals.

20170708_165804.jpg
Raka's House

Chapter 5:

Hello again with this new chapter of Domotics. We are going to be discussing why and how to normalize and compress IR signals. Please check our previous chapters to understand what is all about.

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Why?

20170722_154602.jpg

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 leads 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 found out that it has a limitation on the amount of information to send each time (32-byte payload). Even though this exchange of information is done very fast, the more information you send, the more possibility of crashes during the exchange. So I knew then I had to shorten, somehow, the signal, in order to make the less exchanges possible.

I would like to make clear what I mean by normalize and compress. Maybe not everyone is aware of that. As you might know, this kind of signal is 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 represent is states (500,1000...). Or let's say true and false. Once you are capable of extracting 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 numbers, 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 the bytes to be stored!!!!

Take a look at this page:

Datatype Practices

Once you see a normalized signal you will find out that the numbers are very repetitive. The same number is repeated many times, and that is a 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 other 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:

Signal:

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

Normalized:

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.

FFFFTFFFFFFFFFFFFTFFTFFHFFFFTFFFFFFFFFFFFTFFTFFZ

Compressed:

4FT12FT2FT2FH4FT12FT2FT2FZ

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, even dough you won't worry about space in your computer, is better to store less always. And finally, if your final purpose is to centralize your domestics in one computer, you do not need large signals moving all around your house.

So let me show you how I did it.

Normalization

normal.png

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 in the field but I guess this is because when you are capturing the signal the receptor won't 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 numbers in the range of 800, 1700, and 2000. That would be our state. Let's 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 anymore. 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 on 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 processes went well and if the original signal is intact. By simply reverting the process.

You can download the code at the end of this section!

Running the code

javac Compression.java

java Compression

The output of the program will give you this information:

Original signal

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

Number of states:3

839 1684 19844

normalized: FFFFTFFFFFFFFFFFFTFFTFFHFFFFTFFFFFFFFFFFFTFFTFFS

normalized length: 48

Compressed string: 4FT12FT2FT2FH4FT12FT2FT2FS

Compressed length: 26

Inflated: 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,

Inflated length: 48

As you can see is pretty clear, and gives you the information about what is happening in those 3 basic steps.

Downloads

Compression

compress1.png

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 then the state.

Reverting the Process

inflate.png

I did this just to check if the process will be successfully reverted and if signals would work without problems once they were inflated. I called it to inflate since is basically a compressing process. Bear in mind that I try to do it as simply as possible so I can use it later as a model to implement the code in The Arduino board.