Using Input Compare on the ATMega16 Question Calculations.

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello
I wondering how figure out the period or time of a signal using input capture. I have one ATMega16 generating a square wave the period of it is 1920us. 1920us high then 1920us low. I'm the second ATMega16 to capture the siganl.

RisingEdge - FallingEgde = Period

If I capture the falling edge of the signal into the input capture register and save it to the variable FallingEdge
Then setup the input capture interrupt to capture the next rising edge.

Wait for the next input capture interrupt. Save the input capture register to RisingEgde. Then setup the input capture interrupt to capture the next Falling edge. Then do the math RisingEdge - FallingEdge = Period

How do you compute this if the fallingEgde value is greater than 0xd2FF. The Timer will overflow or goto Bottom value.

6Mhz crystal used so 1920us = 0x2d00
Rising - Falling = period
0x0CFF - 0xe000 = 0xffffff2cff wrong ???
0xffff = 0xd2ff = 0x2d00 ok that works fine

I hope I explained this correctly.
Thank you
Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Frisky,

There are many experts on the uC's timers/counters/etc, and I'm not one of them.

But to get your started, a thought or two:

The time interval from the Falling edge to the rising edge will be 1/2 the period. It should be 1920 uS. The Period of a square wave is the total time of the periodic waveform, the sum of the high and the low time. In your case: T = 1920 uS + 1920 uS = 3840 uS. This gives 1/T = F = 260.4 Hz.

Next, do you reset the counter/timer when you detect the Falling Edge?

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about not bothering to fiddle with which edge your capture works on, and just capture the whole durn period of one cycle on each interrupt? Even if you don't use prescaling, 1920 us times 6 ticks/us gives only 11520 counts, which ought to be comfortably within the reach of a 16-bit timer.

Leave your timer in free-run mode. On each input event , compute how many ticks it's been since the previous trigger. Something like this:

volatile uint16_t measuredPeriod;

ISR(TIM1_CAPT_vect)
{
    static volatile uint16_t timeAtLastEdge; 
    uint16_t lastSample = timeAtLastEdge;
    timeAtLastEdge = ICR1;
    measuredPeriod = timeAtLastEdge - lastSample;
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don,

Since you only do a 16bit calculation, the value

0x0CFF - 0xe000 = 0xffffff2cff wrong ???

ends up being truncated to 0x2cff. Being off by 1 or a couple of ticks is expected as your source and the AVR's timer are not synchronised.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello
How do you measure the whole period with one interrupt.
Whouldn't you need 2 begin or rising edge and then then
detect the falling and subract?

I would like to make a NWR SAME Messaging Decoder.
I'm going to use a Exar XR2211 FSK Demodulator ic. The baud rate is presently using is 520.83 or 1920us bit time +/-10%. 1 is hi for 1920us and a 0 is low for 1920us. I wanted to use the input capture to form a PLL. and use the output compare to sample in the center of the bit. I was thinking a sampling 5 times per bit and xoring the result to form a byte of data.

I have built a working NWR SAME Messaging Encoder with a Exar XR2206 FSK Encoder ic. I'm using a AT90S2313 to built and send the message. I had to built the encoder first. NWR only sents data once a week during the test and when there is bad weather. Protocol can be found here
http://www.nws.noaa.gov/directiv...

I will work on the input capture ideas. I would like to thank everyone for the responces.
Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You need two captures to measure! The preamble ensures you get known bit transitions so you can adjust your receive clock to decode the data. As for using a PLL technique to adjust the sample time, the problem is you're not guaranteed a bit transition so the fun becomes determining if your clock is early or late - thus the preamble - you lock to it and assume you won't drift whilst decoding the data. This technique is similar to LIN which uses standard async comms but has a preamble for the receiver to adjust it's clock to. This was to get around the drift of the internal oscillators in the microprocessors in order to avoid using a crystal,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman
How do you lock the clock to the preamble? I don't want to reinvent the wheel. I was going to test the period of the preamble and then sample/period to get average. So there will be 128 periods to measure. Do you thing that 32 is enough to measure? The is 16 bytes of premble sent lasb first 10101011 or 0xAB. Then the header code is sent with is ascii "ZCZC" that signals a message will begining.
Thank you
Don

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pretty much as you describe. Thinking some more, for this you probably don't need to phase lock as the bit time is quite large and your clock drift quite small (assuming you're using a crystal), so all you need to do is approximate the middle of the bit time as you mentioned earlier. In this case, you'd have a timer tick over at a multiple of the bit time, increment a sample count and reset the sample count when you get a bit change. When the sample count gets to the middle of the bit time, you shift a bit in. This ensures you sample mid bit +/- sample time. You would then have a finite state machine to search for the preamble sequence and then grab the data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman
I start writing my interrupt handler for input capture.
Will let you know how it goes.
Don