Making sense of IRrecDump ( IRremote Library)

Using Arduino Programming Questions
#1

This is the "Dump"

1FE40BF

Decoded NEC: 1FE40BF (32 bits)

Raw (68): 20072 9100 -4450 600 -500 650 -500 600 -550 600 -500 600 -550 600 -500 650 -500 600 -1650 600 -1650 650 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 650 -500 600 -550 600 -1650 600 -500 650 -500 600 -550 600 -500 600 -550 600 -500 650 -1600 650 -500 600 -1650 650 -1600 650 -1650 600 -1650 600 -1650 600 -1650 600

Here we have 7 "digit" hex why 7 ???? May be Zero is insignificant so 8 HEX Each is FOUR bits Leads to the mistry 32 !!!! One Up

32 bits !!!! does not relate to the number of timing elements.!!!!!! (We have 68)

68 timing elements !!! how do I convert that to Binary Then HEX.

The Eight HEX

0 0000 F 1111 E 1110 4 0100 0 0000 B 1011 F 1111

So, the timing is 68 elements, it is really should be 64 ( ON,OFF)@32

Where do I start matching Timing with Binary and HEX?????

It beats me.

All I want is to look at the timing; Convert it to Binary, then HEX to verify that the 3 properties are the same. Then use the Binary as RAW to transmit. send 32 bits

Add to the confusion... The inverting process, the not so precise timing data

#2

The typical IR remote sends some bytes of data. The program is measuring the timing for 68 units of time. During that time, some data came in. That data is shown in the last part of the output. Most of the time, nothing came in. That's why the last parts of the data repeat the same values.

The data that was received was compared to some known standards, and the type was determined to be NEC. So, you are told that. You are told how many bits there are in the received data.

You are correct that leading 0s are not printed.

I'm not really sure why you want to do anything with the data that you see printed. The key piece of information that you got was that the data does match a standard. The library includes methods to send and receive NEC data. Why do you not want to use those methods?

#3

What happens when I get Unknown protocol which happens so often, that I have decided to rely on RAW data. I am building "universal" remote and I have dozens of Remotes that carry no brand.

Are you saying it is impossible to decode the timing data to a binary one that matches the HEX given ??

#4

The leading 20072 is a bug in IRremote, which should be fixed in an upcoming release. So if you get 2 positive numbers at the start, ignore the first one.

FOR NEC IR protocol 9000 -4500 is the header mark /space a binary 1 one 560 -1690 a binary 0 is 560 -560 there are a few more consideration In the protocol. see http://www.sbprojects.com/knowledge/ir/nec.php

Note the recorded timings are always +/- 100-200 uSecs.

#5

Dear God, ( Nothing beats DIRECT communication)

That link you mentioned, made me more confused( I bet you ; it came straight from HELL). It states 4 bytes Two for address (send twice)and two for command (send twice). Where are they in this timing stream AND the HEX

#6

Sorry, that link provides a much better explanation than I could ;(

#7