New to Electronics, having trouble understanding Infrared.

[Memory Leak]

Hey everyone, first time poster here 

I am currently in the midst of a 1st year Electrical Engineering assignment. It is a team assignment and the goal is to develop a small scale autonomous car. One of its main functions is the ability to detect the speed zone it is in and change it's speed accordingly.

Here is an exert of how the speed limit is broadcast:

"The speed limit signs will transmit this speed using pulsed Infra-red, on a carrier frequency of 38kHz using on-off keying (the binary state of 0 means no signal, while 1 means maximum carrier amplitude – see Figure .The speed value will be transmitted at 1kbps, in a format shown in Figure 7. The signal is repeated, with 8ms of off-air time and 8ms on-air time. This 8ms of on-air times consists of an 8-bit code, with the first five bits being a pre-amble, 10100, and the final three bits containing the speed encoded in binary (plus one, so that 000 = 1cm/s and 111 = 8cm/s)."

Figure 7:

 

Figure 8:




So what have I done so far?
Not much

I am using an Arduino Uno and so far I have bought an IR Receiver and checked that it is working using this Test..

On top of that I have read through this article and have successfully run this example using my TV remote.

I have also played around with a few IR Libraries which print a hexadecimal value for the buttons I press on the remote.


What I am having trouble with is how to interpret the output of the Ir Receiver. It looks a bit like binary but outputs of running the above Example are really confusing me.

If anyone could explain how to interpret the output or link me to a quality resource I could read to further my understanding I would really appreciate it. I am quite lost at the moment.

I posted this on a different Electronics forum, but I am yet to get a response, so any and all help is greatly appreciated.

[Alex Eisenhut]

Maybe if you told us *what* is confusing you?

[Memory Leak]

Maybe if you told us *what* is confusing you?

I am having trouble understanding how to read and interpret the data from the IR Receiver using an Arduino. I am getting confused about the "On/Off" part, it feels like binary but clearly it is not. Sorry if this is vague, I am quite lost at the moment.

[Alex Eisenhut]

Oh, I think I see what you mean. You think a "1" should be a line, just like 0 is a line?

[ConKbot]

The receiver should be putting out binary, it has a TTL output.  It will  be putting out a demodulated signal. The transmit driver will put out a 38 KHz square wave to indicate a binary 1, and nothing to indicate a binary 0 (OOK, digital version of AM, as mentioned) The reciever looks for the modulated carrier, and will output your binary 1's and 0's.  With the receiver you've chosen, the 38 KHz carrier will be removed, and the whole modulation scheme is invisible to you. 

[Memory Leak]

Oh, I think I see what you mean. You think a "1" should be a line, just like 0 is a line?

Yeah, in a way. I was reading about IR remote signals here: https://learn.adafruit.com/ir-sensor/ir-remote-signals

I have been trying to figure out how this relates to my problem or if it relates at all. I have a feeling I am being really confusing here, I have even confused myself.

Slightly off-topic:
Would you know anyway of replicating the situation above (8ms on 8ms off)? I think reading the raw data captured from that might help me understand what is going on and what they want.

Thanks in advanced

[Memory Leak]

The receiver should be putting out binary, it has a TTL output.  It will  be putting out a demodulated signal. The transmit driver will put out a 38 KHz square wave to indicate a binary 1, and nothing to indicate a binary 0 (OOK, digital version of AM, as mentioned) The reciever looks for the modulated carrier, and will output your binary 1's and 0's.  With the receiver you've chosen, the 38 KHz carrier will be removed, and the whole modulation scheme is invisible to you.

Thanks I think I understand what you mean but what determines how many 'bits' are sent, does it send a constant 1 every 'x' seconds while an infrared LED is on and a constant 0 when there is no infrared. Sorry for my ignorance.

[Alex Eisenhut]

You are experiencing a philosophical quandary. 1 and 0 are concepts, true or false, yes or no, absent or present.

They can be represented many ways, depending on other practical realities. In your case, someone has decided that pulsing a LED at 38KHz is the way to go.

What determines what and how many bits is usually called a "protocol". Some protocols become so ubiquitous that no one thinks that much about it anymore.

One way to send bits is called a serial protocol. You just toss bits out one by one. Which bit is sent out first, how many bits are sent a time, what decides the start and finish of the message, how to make sure there are no errors are all part of a protocol.

I think an episode of Secret Life of Machines is in order.

[Memory Leak]

Thanks for the reply

I think I understand the concept behind the 1s and 0s now. However I am confused about the protocol would the protocol for the example I posted be something like:

Send a series of pulses every 8 milliseconds for 8 milliseconds. Each millisecond it pulses or doesn't pulse(I'll call this an 'event'). The first 5 are used to identify what is being sent and then the last 3 pulses determine the data (In this case the speed). So it will send the 8 events every 8 milliseconds.

Am I interpreting this correctly?

PS the video was awesome, just finished watching it! I know what I will be binge watching tomorrow

[Cherry]

Thanks a lot!

[KeepItSimpleStupid]

You can kinda look at it as someone typing s# every 8 mS although that 8 mS could actually be variable.  It doesn;t matter.  What matters is, your frequency and the transmitted frequency is agreed upon, unless the doppler effect is going on.  Frequency changes with speed. 

I'd assume that it doesn't. 

Serial protocols like RS232 has a start bit and one or 2 stop bits.  You could consider a portion of the 8 mS space a stop bit.

The existance of the 8 mS space is your cue to start looking for the rising edge,  So, look at the value at the center of the fist pulse at the right frequency until you find a space.

The space clears the word.  This rising edge starts starts the clock a 1/2 but time later (center of the pulse), so do an add 1 and shift left or add 0 and shift based on what the carrier is doing.  You then have your word,

You reject anything that does not have the preamble present.  The long space tells you to stop.

8 mS does not have to set in stone, but it does have to much greater than a space time.

You may be able to employ edge triggers as well.

[McBryce]

Hi Memory Leak,
         just to add to the confusion. TTL IR sensors are usually normally high outputs, ie: the signal will be inverted. I haven't checked the ZD1952 Datasheet, but it's highly likely. So in reality, what you should be seeing on the ZD1952 ouput pin would look something like the diagram below. As far as interpreting this on a microcontroller is concerned, the simplest way would be to connect the output of the ZD to a pin with an interrupt (when pin goes low) which starts a simple routine to sample the pin once per ms 8 times and then re-initialises the interrupt.
As the poster above said, you should reject any data if the pre-amble wasn't correctly detected in the first 5 bits.

McBryce.

[macboy]

It just so happens that logic-level UART signals are also inverted (like the output of IR receivers).
And your protocol, with 1 ms bit times, is exactly like a UART at 1000 bps (1.0 kbaud)

If you set up the Arduino to receive serial data at 1.0 kbaud, you should receive one valid data byte every 16 ms. Note that the first bit of the preamble (10100) will be considered by the UART to be the start bit and will not be given to you as part of the data. So your data byte will consist of the next four bits of the preamble (0100) followed by the three bit speed data, followed by a zero, since that part of the signal is always 'off'. So for each byte received, you should validate that the first four bits are in fact 0100 and the last bit is 0, then extract the 3 bit speed data.

Since the speed data is sent constantly (every 16 ms), you can do some error checking by looking for the same value two or three times in a row before considering it to be new "valid" data. Checking for three successive bytes will introduce an extra 32 ms of delay, but that might be acceptable compared to the negative consequence of mis-interpreting an errored byte.