Problem with signal of tsop1738 in 18f4550

[mash14]

Hi all,

My problem is simple, I have a TSOP1738 sensor connected to RBO to detect the 33 NEC protocol flanks.

My problem is that it is only possible to detect between 12 and 18 bits of the protocol without knowing about the rest.

data:
My pic 18F4550 is designed to work with the internal clock to 8MHz, this will be the main issue?. ie not mind fast enough to detect all interrupts on time and perform program instructions.

Any reference is welcome since I have three years of experience with microcontrollers and I had never seen this.

Thank you very much.


nec protocol....
http://wiki.altium.com/download/attachments/8749270/NECMessageFrame.png?version=1&modificationDate=1228300890343

(and yes, I use a translator my little experience speaking English sorry )

[Ttelmah]

8MHz, is plenty fast enough to handle this protocol.

However you probably need to be changing your approach to how you do it.

I's suggest you use a hardware timer.
In the interrupt, you just want to record the _times_ when the edges happen do nothing more complex than this.
Realistically 'ideal' to use the CCP for this, rather than RB0.
Your diagram on the protocol, could well be misleading you, since it only applies to a device with an address of '0'.
The way the protocol works, you will see a rising edge, followed 13.5mSec latter by the next rising edge. This signals the 'start'. I'd reset the timer when this is seen. Rising edges then come at gaps of either 1.125mSec, or 2.25mSec for either a 0, or a 1. A total of 32bits of data, followed by another 0 to mark the end.

If you setup the hardware timer (say timer1, if using the CCP) to use the peripheral clock/4. So Fosc/16.
Then simply record the time when each rising edge is seen. Do one bit of maths. If the delta from the last record is >20000 reset the timer, and set the index to the recording array back to zero.
In the main, wait for the index to reach 32. At this point you have the times recorded for all the edges. _If_ the timer1 interrupt triggers, then you have missed a packet (will happen if you get to 31% after the last bit should have been seen).

Then decode. Two parts to this. Simply go through the first 32 entries of the array of times, to create four bytes. If the delta<900 store a '0', if greater, a '1'. Then invert the second and fourth bytes of the result, and compare these with the first and second bytes. If they don't match there was an error. If they match, you have the data received.

I'd suspect you are trying to do the decode inside the interrupt. If so, time would be very tight indeed, especially when testing for the inverted bytes.

Best Wishes

[mash14]

Thank you very much, you gave me a very good idea.

and tried to do just this, but with the difference that just try to detect and decode 32 bits.