IR receiver and MTIM

[PW_CTL]

Hi All,

I´m trying to build a NEC IR receiver with a RS08KA4. Now, I´m trying to detect the low pulse of the IR, and then read periodically the IR signal to decode it, but I´m having some synchronism problems, ant it seems a "fragile" algorithm.

I´ve read in this forum that some people uses the MTIM and interrupts, but this uC do not allow interrupts.

Could you recommend me any way to decode IR signals?

Best regards.

[ThaManJD]

I havn't looked at the app note. No doubt it's got the answers there.

I'm not sure what you mean by:                "but this uC do not allow interrupts."

TheRS08KA4 has MTIM,  ic/oc timer channel and other interrupts. 

I think most likely you mean that there is no dedicated single classic interrupt pin. You could use one of the pwm/timer channel inputs to capture your edges. This would use either TPMCH0 or TPMCH1 pins.

I take it the pulses are coming from some powered, 40khz filtered 5V TTL 3 pin thing or equivalent circuit?

If the direction the App Note takes is not what you were after, you can use the pwm/timer. They way you use it depends on how your IR protocol works and what way reading the edges or interval durations works better for you.

You can use one input capture interrupt to pick up pulse edges(high or low) and use another timer to check when the pulses happen or to make sure they happen at the times you're expecting them to.

You can use an input capture interrupt by itself to measure time differences between pulses.

JD

[PW_CTL]

Thanks for your answer.

I´m using codewarrior and processor expert to configure the main functions of the RS08KA4, and I cannot enable any kind of interrupt, there is no any event generated by this module.

I know the NEC protocol, but my problem is that I cannot set exactly the period between pulses, so after 20 or 30 pulses the acumulated delay causes an error on reading the bits. I need any way to set an accuracy period, so I could read bit by bit and decode the NEC command and address.

[bigmac]

Hello,

For the 'RS08 devices, the various "interrupt" sources are are available only as a means of wakeup from Wait or Stop mode.  During normal operation you will need to poll the flag associated with the MTIM module.

Your approach to the decoding process will need to take into account that the incoming IR data will be subject to a timing error tolerance for each carrier burst, and the gaps between the bursts, and there will also be a tolerance for the MCU bus frequency.  Therefore, the timing must be periodically re-synchronised so as to avoid error accumulation.

I assume that you are not attempting to detect the carrier signal, but are using a suitable IR module that already provides carrier detection and filtering?

Depending on the duration of the timing intervals to be detected, the use of C coding (and PE) may not produce tight enough code, and assembly coding may be required in the time critical areas.

It would be helpful if you would post the details of the NEC IR code.

Regards,

Mac

[ThaManJD]

============

bigmac said:

----------------------------------------------------------------------------------------------------------------------------------------------------------

For the 'RS08 devices, the various "interrupt" sources are are available only as a means of wakeup from Wait or Stop mode.  During normal operation you will need to poll the flag associated with the MTIM module.

------------------------------------------------------------------------------------------------------------------------------------------------------------

============

as penance for not realising about the interrupts, i've now ordered a couple to experiment with.

JD

[PW_CTL]

Hello again,

I am trying to use the input capture of the TPM module, but I found one little problem.

I can only assign only a few pins to be captured by this module, and I´ve launched a try run of some prototypes a few days ago, using PTB7 to read the IR signal, wich cannot be used directly by the TPM module.

I think an alternative way is to continuily check the IR pin and manually detect the falling edges. The speed of the uC is much higher than the speed of the IR signal, so the error is minimal (the code of the uC is simple). This way, we can use the TPM module.

What do you think about that? Do you think there is a best way?

Thanks and best regards.

[bigmac]

Hello,

Monitoring the state of the input pin within a tight loop should be satisfactory.  The average latency for all transitions would be one half the number of cycles within the monitoring loop, with worst case variation of plus/minus one half the number of cycles.  You would need to monitor for a low-to-high transition, and then monitor for a high-to -low  transition.  At this point you would read the TPM couner value, and calculate the period from the previous transition, before repeating the process for the next data bit.

If one of the TPMCH0 pins (8 or 16/20), or one of the TPMCH1 pins (7 or 15/19) were not currently in use for other purposes, you might consider soldering a wire link between the current pin, and one of the timer pins, so that the TPM module might be directly used for the prototype board..

Regards,

Mac

[PW_CTL]

oh!, ok. Then, I forget about interrupts.

Yes, I´m using a IR module, and I get directly a sequence of bits with a fixed period.

http://www.vishay.com/docs/81732/tsop348.pdf

I see two options:

1. Read the IR pin, wait one period, read, wait .... but this method causes the accumulated error.

2. Read the IR pin, start measuring the time, and detect possible changes in the IR pin.

I have only an implementation of the first method, but it do not work, and this is poor implementation. As you say, the timing should be re-synchronised in every bit.

How to measure the time between bits with the RS08? (for example, how to measure the time between variations in the IR pin, to decide if we have seen one positive bit, or three consecutive positive bits?)

Best regards.

[bigmac]

Hello,

I happened to find a very brief reference to the NEC code timing.  It would appear that this code uses a pulse position modulation (PPM) method where, apart from an initial start pulse, all further pulses are of fixed width 560 microseconds.  A zero bit state is represented by a pulse+gap period of 1125 microseconds, and a one bit state by a pulse+gap period of 2250 microseconds.  The sequence length is 32 bits.  The start pulse is 9 milliseconds duration, followed by a gap of 4.5 milliseconds.  Is this similar to what you are attempting to decode?

Since each carrier burst will cause a low going pulse at the output of the IR receiver, you would measure the time between successive negative transitions.  The MTIM module is not suitable for doing this.  A far better approach would be to use the input capture capability of the TPM module.

Firstly you would need to set the prescale value so that the overflow period of the TPM is greater than the initial start pulse plus gap period (13.5 milliseconds), and to provide an input capture channel that responds to negative edges only, from the output of the IR receiver.  Then by polling the TPM channel flag until it becomes set, you can then read the current 16-bit capture value, and subtract the previous capture value to determine the current timing interval.  From the value obtained, you can then determine whether a start bit, a one, or a zero.  The intermediate processing of each bit needs to be completeted in less than 1125 microseconds, the minimum period between successive edges.

Regards,

Mac

[PW_CTL]

Very good reply, it really helps me.

As you can see, the NEC protocol is not complicated and the only problem is to measure the time. I´ll follow your advice and try the TPM module.

I´ll post my results here if everything works.

Thanks and best regards.

[bigmac]

Hello,

Have you already seen application note AN3402?  This covers IR decode of the Philips RC-5 format with the 'RS08KA2 device.

I am not sure what category the NEC IR code format falls into - maybe it is PWM or PPM type, which are quite different from RC-5.  However, you may get some ideas from this document.  Do you have complete details of the NEC format and protocol requirements?

Regards,

Mac