Capture after exit from sleep

Hi

Our application is to measure the time between one reference signal R1 and two other signals S1 & S2.
We use PIC24FJ128GA106 , the reference signal R1 is connected to extenal interrupt signal and the two other signals S1 & S2 are connected to a capture pin.
the ISR for the extenal iterrupt pin "R1" triggers the two capture finctions by SW trigger and when any of the two other signals S1 & S2 arrives on the capture pin the timer is stopped and it's value is red during the capture ISR.
Capture function is clocked form the main oscillator and we are using an external 32MHz crystal to clock the micor .
in order to svae battery the micro is kept in sleep mode and exits sleep mode by the external interrupt and after measuring the two signals and sendeng them using RF link the micro is returned to sleep mode.
I face two problms
A)when the micro exits from sleep mode it's not operating from the external crystal and it depends on the internal 8MHZ crytal for a while before switching to the external crystal, is the time between exting from sleep mode till switching to the external 32 MHZ crystal determnistic? and How much is it? can we keep the external 32MHZ on during sleep?
b)the vlue of the capture is not accurate and the cariance for the exact value is about 150 count in the timer, How can I get more accurate measurment from the capture when I exit from sleep mode.

Best Regards
Hossam Alzomor

Did you try calibrate the internal oscillator ? As far as I know, doing that it is possible to achieve accuracy in the range of something near to 1%

I think calibration of the oscillator will add/subtract a fixed value to/from the counter.
My problem is that the counter value is varying around the expected value.
on the other hand I prefer to use the 32MHZ for better resolution of time measuring.

You have the option to configure the 32MHz Oscillator to keep running while in sleep mode, but this would not save much energy of the core, making it almost meaningless turn to this mode. Once the PIC family do not allow more than 1 oscillator per chip, what do you think about to add an external RTC to your design ?

Hi,

I don't know how the PIC's capture works.. but with other microcontrollers it is a hardware copy of the counter value at exactely the event. Therefore the expected error of the capture event should be less than +/-1.
It should be very precise.

If you see varying results then there may be one ore more of the folowing issues:
* varying clock speed (not very likely)
* varying capture input signal timing (then you see true, valid values)
* unprecise "start" of the counter. With your description I see thi is the most likely reason. You say a signal triggers an external interrupt and within this ISR you reset the counter value.
But variable delay between external signal and execution of the ISR may be caused by
* currently running interrupts (perventing a new ISR to be executed)
* usual variable delay caused by instructions of different clocks/instruction (conditioned jump, stack processing)
* or by disabled interrupts in main loop

****
You can do some tests.
For this you need a pulse with a stable known timing. Let's say a 1.000kHz signal.
It takes 1.000ms from one falling edge to the next falling edge.
Run your counter with a fixed requency. Lets say 1.000MHz.
Use the sane setup as with your application: one edge via external interrupt, and in the ISR clear the counter value. Next edge capture by the hardware capture feature.
Ideally you expect a counter value of 1000.
If you see a value larger than 1000, then there is a delay cause by the capture periferal (not likely)
If you see a value smaller than 1000, then it us caused by a delay when you clear the counter value.

****
Possible solution:
Don't clear the counter value at all.
With the "start" event use the capture feature and safe the counter value at start.
The next edge triggers the ne t capture and you safe the counter value at "end".
Now you just need to subtract: "end_value" - "start_value". This gives the exact timing between both events.
(Usually you don't have to take care about counter overruns. The subtraction will give the correct result)

Klaus