tsop348 infrared receiver

Question

• Burst length should be 10 cycles/burst or longer. After each burst which is between 10 cycles and 70 cycles a gap time of at least 14 cycles is necessary

whereas I see only 7 in the 600us bursts of their time diagram enter image description here

And what is the "carrier frequency" (30kHz)? I think infrared light frequency is measured in terahertz? Are those 7 pulses in the 600us bursts in the diagram are periods when LED emits light with gaps imbetween? How actually I supposed to communicate over the carrier frequency?

Why do they tell that 30 pulses, f = 30 kHz, T = 10 ms in the following Figure 1

enter image description here

My computation is that if every pulse takes 1/30k sec then 30 pulses take T = 1 ms. Furthermore, I see on this diagram that reception terminates (V_O goes high) even though transmitter is still bubbling. Can it predict the future?

update Also, the upper part of the second diagram (Figure 1) says that 10 led pulses is optimal for reception but bottom clarifies that receiver recognizes the burst that is between 7 and 15 LED pulses. That is, it is guaraneteed to receive bursts only when they are 15 LED pulses or longer. How can I use the optimal 10-pulse bursts then?

JIm Dearden · Answer 1 · 2013-09-14T13:03:48.753

2

The BURST cycle

Is there to help the receiver acknowledge there is a signal and synchronize to it so the data is properly framed. In other words give it enough time to set itself up properly. There could be other IR senders with different carriers so it needs to be able to discriminate. Hence the specification to ensure the detector works correctly and doesn't respond to a false signal.

I think you missed a very important part of the drawing - the two vertical ticks on the X axis - this means a BREAK in the time line. enter image description here

The diagram was focused on the important part - the data and gives representative timings rather than the full signal which would have made the diagram very wide and less clear.

Carrier frequency

The LED is being switched ON and OFF with a carrier frequency (usually in the 10's of kHz - in your case 30 kHz)

The data stream - the bits that carry the information - modulate these 'carrier' pulses of infra red by switching them ON and OFF at a much lower frequency.

The emission frequency of the LED has nothing to do with it EXCEPT it is chosen to be infra-red to try and avoid interference in the sensor with other light sources.

edited Sep 14 '13 at 13:03

answered Sep 14 '13 at 12:53

JIm Dearden

18,926
30
40

This is something. The unnoticed breaks indeed can break synchronization between upper and bottom time axis. But, I do not see how they can add up the 30 30-kHz periods into 10 ms and how do you really transfer the data over the carrier? If I must always send series of 101010101 followed by gaps (I suppose the gaps are series of zeroes, eg. 000000000) then how do place my data into them? Btw, is 101010101000000000101010101000000000101010101000000000, that I must transmit, seen as 111111111000000000111111111000000000111111111000000000 at the receiver output? – Val Sep 14 '13 at 15:14
@Val Basically the chip strips out the carrier and outputs an inverted 'data' signal - i.e. it goes LOW when it receives a burst of carrier IR. The stream of burst signals are identical pulses - 1 'bit' = ON 30kHZ - OFF 30kHz, with equal mark space ratio & timing.**The processor following the receiver measures the pulse width** and can ignore these as it waits for the longer delay before the *actual data* frame starts. These devices are intended to be used with 'standard' protocols such as RC5 but if you are designing your own system you don't have to follow any particular standard timing. – JIm Dearden Sep 14 '13 at 18:25
I just experiance the problem with sending a single bit. I do not see how can you send the start bit and other data if all you can send is a sequence of bursts (01) interleaved with gaps (00). Where can I plug my data? – Val Sep 14 '13 at 19:00
@Val - this is becoming a different question but basically you need to think in terms of a frame of pulses. BURST - LONG DELAY (DATA SYNC) - START-DATA-END. The burst consists of identical short pulses - these can be detected on the output of the chip by some form of microcontroller. Ignore BURST and wait for LONG (HIGH) DELAY. The next falling edge is the start of the DATA. You need to encode this in a particular way eg. a fixed period pulse length with 0 = 25% width and 1 = 75% width. By applying an appropriate test - "what is the value at 50% of the pulse?" you can decode your data bit. – JIm Dearden Sep 15 '13 at 13:48

Wouter van Ooijen · Accepted Answer · 2013-09-15T06:57:38.530

whereas I see only 7 in the 600us bursts of their time diagram

That diagram is not to be taken literally: the burst are draw as 7 pulses, but 600 us of 30 a kHz signal is 18 pulses. The intent of the diagram is to specify the minimum pause length.

And what is the "carrier frequency" (30kHz)?

The frequency at which you must blink the IR LED

Are those 7 pulses in the 600us bursts in the diagram are periods when LED emits light with gaps in between?

yes

How actually I supposed to communicate over the carrier frequency?

by varying the length of the burst and/or the length of the pauses between the bursts

Why do they tell that 30 clocks at 30 kHz = 10 ms?

they don't, but I have no clue what they are trying to say.

reception terminates (V_O goes high) even though transmitter is still bubbling.

The top and bottom parts of the figure have individual time axises, hence you can't draw a vertical time line (actually you can, but it has no meaning)

the upper part of the second diagram (Figure 1) says that 10 led pulses is optimal

No, they say that >=10 pulses is recommended.

The explanation at the lower part is even more cryptical, I think it says that (for the test signal as specified in the upper part) the output will turn active (=low) at between 7 to 15 pulses after the start, and its length will be between burst length minus 5 and burst length plus six pulses.

Note that in general you can not use the common UART-like encoding with these IR receivers. They are optimized for encodings that have 'enough' pauses. Examples are Machester (used in the RC5 protocol) or pause-duration encoding (NEC protocol).

enter image description here