Oscillators, counts, clock cycles, config settings ......& women

[rsocor01]

Well, I think it goes like this (please, somebody correct me if I'm wrong)

(main program) --> Do the counting (5000 for Comp1Time) Uses TMR1 to count
Comp1 interrupts: store Comp1Time -> clear TMR1
(returns to main program) --> Do the counting (X for Comp2Time) Uses TMR1 to count
Comp2 interrupts: store Comp2Time
(returns to main program) --> Do the counting (5000 for Comp1Time) Uses TMR1 to count
Comp1 interrupts: store Comp1Time -> clear TMR1

and so on ..... This is for the last code that you have posted.

Robert

[Jerson]

Hi Hank

I think You and Robert got the sequence correct.

Now, the counts between 2 Comp1 ints is proportional to the frequency and you have no problems here.

The counts2 that you refer, are these raw counts? or are they converted as per the formula you showed in an earlier post?

this means @1khz, with that error I'm getting a phase shift of about 23 degrees being erroneouly calculated - ie 5000 (1st timer count) divided by 360 (degrees) muyltiplied by 325 (second timer count) - but I know for a fact there's actually no phase shift present at all (I can see this on my scope).

If it is this formula you are using, I think you will need to revise this like so
Phase(degrees) = ( Phase (Counts) * 360 degrees ) / Frequency (Counts)
The sequence of operation is significant and I have bracketed them on purpose.

As to why you cannot go below 325, I was wrong earlier. The latency cannot be so high. The explanation is like this
for a freq count of 500 (100Hz) the equation breaks down to 500/360 * 325
Now, Using integer math, 500/360 = 1, so 1*325

[HankMcSpank]

Hi Robert - yes, that's my take on the overall flow of things - so why on earth does the timer1 count not get any lower than 325 @1khz when the lagged signal causes an interrupt on comp2?(pretty much immediately after comp1 finishes it's interrupt routine)

Hi Jerson - just to confirm - those were raw counts.

The reason being, while debugging this, I didn't want incur any extra PIC 'overhead' calculating the phase in the PIC program itself (ie causing problems with the overall flow of things) ....so I stripped it back bare (for now, I calculate the phase separately on a spreadsheet based on the two timer counts I see onscreen)

My program is very small I'm at work & don't have it with me) but it's literally just ..

set registers up
set interrupts up (as per standard for DT's routines)
a Tiny main program loop ....just to get the stored timer1 count info out the HSEROUT pin onto my PC screen.
the two comp interrupts (as posted in my earlier post)

[HankMcSpank]

Ok, I think I've got to the bottom of the problem - & rather than have the soltuion posted in a thread with an unrelated title, I've tagged it on the end of a more appropriate on that I started...

http://www.picbasic.co.uk/forum/show...4006#post94006

[rsocor01]

Ok, I think I've got to the bottom of the problem - & rather than have the soltuion posted in a thread with an unrelated title, I've tagged it on the end of a more appropriate on that I started...

http://www.picbasic.co.uk/forum/show...4006#post94006

Hmmm, that explains the phase shift part. But, how do you explain getting a reading of 3000 instead of 329 on Comp2 when you change the frequency at Comp1 to 100Hz?

Robert

[HankMcSpank]

Hmmm, that explains the phase shift part. But, how do you explain getting a reading of 3000 instead of 329 on Comp2 when you change the frequency at Comp1 to 100Hz?

Robert

I've not had time to revisit (only had a short while on this again last night), but here's what I was reckon was happening.

I hadn't 'squared' the analogue sine wave signals going into the schmitt trigger (this will be my first port of call wrt solving this) - the schimtt will 'trip' at a predetermined level - and unless it is fed a square wave (with the fastest rising edge possible), then with a signal such as a sine wave, there'll inevitably there'll be some delay (or even 'lead') wrt the timing of the two respective signals coming out of the schmitt - and timing is obviously key if you're trying to measure phase difference!

The shcmitt 'triggers' as a function of signal level & in this case (due to this area being somewhat new ground) I was feeding the two schmitts different signal amplitude levels, it was therefore triggering at different respective times (wrt to one another) & introducing a triggering 'time difference' - this is being picked up as phase delay by my PIC timers.

At 1000Hz, the comp2 count was 329 (which is 32.9%%) at 100hz the comp2 count was 3000 (which is 30%) - the fact it wasn't a set percentage error suggests that this is related to schmitt incurred triggering 'time point' changing with input frequency.

I need to 'square up' the analogue sine waves by feeding them through an identical circuits, prior to feeding them into the schmitt. I'm then in the realm of slew rates for the circuit that squares the sine waves up.....obviously I need the fastest rising edge possible to ensure that the schmitts don't add in their own lags betwen the two signals.

Still...I learnt a whole heap ....& thank you (as ever) for those whoe chimed in....this truly is a great forum.

I'll post results once I crack the all new improved phase measuring method (though the base 'floor' count of 29 when the same signal is "Y"'ed into both PIC comparators - as mentioned in my other thread - is troublesome). Whilst it would have been a bother for other to replicate what I was doing with all pass filters etc, there is something here that others could easily replicate on their own - feed an identical square wave (ie a PWM signal, clock ...whatever) into both PIC comparators use the comp1 & comp2 interrupts as above & see what base floor count you get....it's higher than I'd imagined it would be.

[rsocor01]

Still...I learnt a whole heap ....& thank you (as ever) for those whoe chimed in....this truly is a great forum.

It is not my project, but I'm learning from it too .