Shift left uint64 data type

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
AlVa_264671
Level 5
Level 5
25 sign-ins First like given First like received

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.

0 Likes
7 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
AlVa_264671
Level 5
Level 5
25 sign-ins First like given First like received

Thank you very much Bob

   

I will try your suggestions

   

Best regards,

   

Alex

0 Likes
AlVa_264671
Level 5
Level 5
25 sign-ins First like given First like received

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

   

 

   

 

   

0 Likes
Anonymous
Not applicable

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

0 Likes
AlVa_264671
Level 5
Level 5
25 sign-ins First like given First like received

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

0 Likes
Anonymous
Not applicable

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% .

0 Likes

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

0 Likes