- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi everyone
I need some help with the following code.
This code is based on RC5 protocol for Irda communication.
I just take from it the bit time, half bit time and the 36 khz modulation frequency.
The idea is implement a 64 bit infrared link. The two first high byte send to the receiver start with 0xFFFF at MSB and MSB-1.
The emitter is implemented with a regular infrared emitter diode and the receiver with
TSOP38436.
To synchronize I wait for the first high to low transition at Demod_input which is the first clock transition of Manchester encoding.
After a Delay of 0.445 ms I can say that the reading at Demod_Input is "1".
After successive sampling of Demod_Input at intervals of 1.778 ms I would say that I am recovering each bit of payload received.
I can get the code running and I suspect about left shift 64 bits data.
The the scopes' screenshot show the TSOP38436 yellow trace and the inverted output as blue trace.
Thank you in advance for any help.
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your shifts seem to be ok, at first sight I cannot see that something is wrong.
But:
You try resetting the timer using a control register. The reset input is synchronous, so there is a clock l->h transition needed to reset the timer.
Way out:
Write a function Timer_Reset() that
- stops the timer (in isr_1 interrupt handler to avoid one-shot which requires a reset)
- reloads the timer counter
- starts the timer
or:
- Set the control register output type to "Pulse"
- use a toggle ff to divide the timer_clock by 2 (two) and feed that into the control register clock
- only write a 1 (0x01) to the control register, do not write the 0 (zero)
This will ensure a clean reset of the one-shot timer.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much Bob
I will try your suggestions
Best regards,
Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob
I have tried your suggestions and sorry but they doesn't seems to be the solution to get the code working.
Please see attached Terminal's screenshot to show you the payload received and you will see that for test payload (0xFFFF007892430000), the code receive OK the first 16 bits.
Regarding those 16 bits, I have a code working with a very similar algorithm and 16 bits payloads which work fine.
With this code I am also using the same TSOP38436 device and without take care about the asynchrony Timer Reset.
I can use that code but isn't efficient , because to send (0xFFFF007892430000), you should send 8 16 bit packet and previously get the Payload's CRC, and at the receiver recover the data byte.
Really I spent almost more two weeks trying to get working this code.
May be you can give me more suggestion I will appreciate them very much.
Best regards,
Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What main clock source are you using on your sender and receiver ?
It looks to me like the sending and receiving clocks are drifting relative to each others.
One way to check this is to time a sequence of received high to low transitions and measure if they really are 1.778 ms apart as measured by the receiver board.
/Magnus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Magnus
Thank you by your suggestion.
I'll try that of course.
In my code the half bit which is 889 us and the full bit which is 1,778 us have #defines which allows for 30% tolerance to account differences in timer or other delays.
So those constants set up boundaries to check the Timex variable out regarding those values +/- 30%
Thank you for your help.
Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the decoder, starting at midpoint of a halfbit, reads 20 bits correctly, and then shifts to the wrong polarity, a time error of 445uS, the relative timing error is 445uS in 20x1778us = 1.24% .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Yes, Magnus you are wright, it is that you said.
I am working on that.
Also, apparently there is some influence regarding the time interval between the last bit sent and the first bit received with the next packet.
On the TX side I send a packet or Payload every 300 ms.
At the RX side I am capturing a Payload every 150 ms.
After one Payload was received a function wait for input pin be idle (logic "1"), for at least 5 ms to start to start over the whole process .
As a result of wait 150 ms to capture the next Payload, I am getting continuously the correct one but with wrong MSB byte and LSB byte.
I think that what you said is related with this lost of MSB and LSB bytes.
This is just a code to get running the Infrared link.
With the definitive code there will be just a capture every 30 sec.
Then it is a testing code.
So I am working to workout that issue.
I very appreciate very much your interest to help me.
Best regards,
Alex