Measuring audio phase shift through a circuit with a PIC


Closed Thread
Results 1 to 40 of 50

Hybrid View

  1. #1
    Join Date
    Nov 2005
    Location
    Bombay, India
    Posts
    967


    Did you find this post helpful? Yes | No

    Default

    I haven't checked your code, but, from the description, I think you need to look at it differently to get the correct results. Try it this way.

    enable comparator1 and 2 interrupts

    when comparator1 interrupts,
    clear timer1
    clear timer2
    start timer1 and timer 2 running

    when comparator1 interrupts again, do the following....

    stop timer1 running & store the 'count' (this gives a clock pulse 'count' for the arriving frequency, but since I'm only after phase shift...which is a time based measurement, I don't calculate the frequency)

    when comparator2 interrupts, stop timer2 & store the count

  2. #2
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Jerson View Post
    I haven't checked your code, but, from the description, I think you need to look at it differently to get the correct results. Try it this way.

    enable comparator1 and 2 interrupts

    when comparator1 interrupts,
    clear timer1
    clear timer2
    start timer1 and timer 2 running

    when comparator1 interrupts again, do the following....

    stop timer1 running & store the 'count' (this gives a clock pulse 'count' for the arriving frequency, but since I'm only after phase shift...which is a time based measurement, I don't calculate the frequency)

    when comparator2 interrupts, stop timer2 & store the count
    Thanks for you input....seems reasonable - I'll be revisiitng this tonight (last night I got waylaid trying to get PIC to control a digital pot via SPI .....failed - http://www.picbasic.co.uk/forum/show...3540#post93540 )

    Using your revised approach, I reckon to calculate the phase change it's this....

    time lag (ie phase difference) = timer2 - timer1

    then to work out the phase ....time lag x 360/timer1/


    So an example, lets say timer1 = 2000 & timer2 = 2,200

    this would give a difference (time lag) of 200 clock pulses

    Now bearing in mind timer1 = 360 degrees (one complete cycle)

    Therefore to establish out how many single degrees of phase...

    200 * 360 /2000 ....which means in this example the phase shift is a 36 degrees lag.


    Putting that into actual frequency ....

    clock = 2us
    one 'wave' period = 2000 x 2us = 4ms
    In Hertz = 1/0.004 = 250hz

    time lag of second waveform = 200 x 2us = 400us

    Now being lazy, to verify, using an online phase calculator & inputing 250Hz & a lag time of 400us...

    http://www.sengpielaudio.com/calcula...delayphase.htm

    = 36 degrees.
    Last edited by HankMcSpank; - 7th September 2010 at 10:28.

  3. #3
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Jerson View Post
    I haven't checked your code, but, from the description, I think you need to look at it differently to get the correct results. Try it this way.

    enable comparator1 and 2 interrupts

    when comparator1 interrupts,
    clear timer1
    clear timer2
    start timer1 and timer 2 running

    when comparator1 interrupts again, do the following....

    stop timer1 running & store the 'count' (this gives a clock pulse 'count' for the arriving frequency, but since I'm only after phase shift...which is a time based measurement, I don't calculate the frequency)

    when comparator2 interrupts, stop timer2 & store the count
    Actually, just re-reading your sequence - that sequence will give me the lag time direct (eg wrt a small phase lag, then comp2 will interrupt shortly after comp1)

    the upper frequency that I'm hoping to measure phase shift is about 1.4Kz - a 1 deg phase shift in time for 1.4Khz is just 2us (ie 1/1440 divided by 360). At 8Mhz Osc, I'm not sure there'll be sufficient time to do much at all before the Comp2 interrupt arrives!

  4. #4
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default

    Ok. I've hit a wall - & I can't get passed it - I need a leg up!

    Te recap, I'm using a PIC to measure frequency (80Hz thru 1.4Khz) by counting the number of clock pulses between successive comparator interrupts. It works well.

    I now need to measure phase shift .....but how to actually use the PIC hardware options available, to detect the amount of clock pulse between the non phase shifted signal & phase shifted signal's leading edges?

    Here's a schematic of my test circuit...



    I detect frequency as follows...

    DT's Comp1 interrupt - start a timer
    DT's Comp1 interrupts again - stop a timer.

    so want to add in phase shift detect by bringing in another timer and measuring the clock counts until the second (lagging) signal's leading edge arrives, therefore the enlarged picture....

    Comp1 interrupt - start a timer
    Comp1 interrupts again - stop a timer.
    start another timer
    second (phase shifted) signal's leading edge arrives - stop the other timer.




    here's the bit I'm using for frequency detection (for clarity I've ommited the config/registers as this bit works)...

    Code:
    INCLUDE "DT_INTS-14.bas"     ' Base Interrupt System  PO90OOO9
    INCLUDE "ReEnterPBP.bas"     ' Include if using PBP interrupts
    
    ASM
    INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
            INT_Handler   CMP2_INT,  _Comp2_Int,   PBP,  yes
        endm
        INT_CREATE               ; Creates the interrupt processor
    ENDASM
    
    @ INT_ENABLE  CMP1_INT     ; enable Comparator 1 interrupts
    @ INT_ENABLE  CMP2_INT     ; enable Comparator 1 interrupts
    
    Comp1Time = 0 'clear down Comp1Time, prior to starting.
    comp2Time = 0  'clear down Comp2Time, prior to starting
    
    'Main body of Code*********************************************************************************************
    Main:
    
            HSEROUT ["comp2=", dec comp2Time,9,"comp1=", dec Comp1Time, 13, 10]
            goto Main
            end
       
    'Comparator1 Interrupt Handler+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++        
    Comp2_Int:
            if T1CON.0= 0 then 'if timer1 is not running then...
            TMR1H = 0 'Set the high part of the timer value to 0
            TMR1L = 0 'Set the low part of the timer value to 0 
            T1CON.0= 1  'start timer
            else        
            T1CON.0= 0  'stop timer1
            Comp2Time.Lowbyte = TMR1L            'puts the timer's low byte in Comp1Time's lower 8 bits 
            Comp2Time.Highbyte = TMR1H           'puts the timer's high byte in Comp1Time's upper 8 bits
            Comp2Time = Comp2Time
            endif
    @ INT_RETURN
    but when I add in a little bit extra (bolded below in red), the HSEROUT chokes....
    Code:
    @ INT_ENABLE  CMP1_INT     ; enable Comparator 1 interrupts
    @ INT_ENABLE  CMP2_INT     ; enable Comparator 1 interrupts
    
    Comp1Time = 0 'clear down Comp1Time, prior to starting.
    comp2Time = 0  'clear down Comp2Time, prior to starting
    
    'Main body of Code*********************************************************************************************
    Main:
    
            HSEROUT ["comp2=", dec comp2Time,9,"comp1=", dec Comp1Time, 13, 10]
            goto Main
            end
       
    'Comparator1 Interrupt Handler+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++        
    Comp2_Int:
            if T1CON.0= 0 then 'if timer1 is not running then...
            TMR1H = 0 'Set the high part of the timer value to 0
            TMR1L = 0 'Set the low part of the timer value to 0 
            T1CON.0= 1  'start timer1
            else        
            T1CON.0= 0  'stop timer1
            TMR2 = 0 'clear tmr2
            T2CON.2 = 1  'start tmr2
            Comp2Time.Lowbyte = TMR1L            'puts the timer's low byte in Comp1Time's lower 8 bits 
            Comp2Time.Highbyte = TMR1H           'puts the timer's high byte in Comp1Time's upper 8 bits
            Comp2Time = Comp2Time
            endif
    @ INT_RETURN
    
    Comp1_Int:  ' store the amount of clock pulses elapsed since routine above finished
            T2CON.2 = 0
            COMP1TIME = TMR2
            TMR2= 0
    @ INT_RETURN
    Last edited by HankMcSpank; - 11th September 2010 at 15:43.

  5. #5
    Join Date
    Nov 2005
    Location
    Bombay, India
    Posts
    967


    Did you find this post helpful? Yes | No

    Default

    Hi Hank

    I'm sorry, I did not reply earlier. I thought you would find a way

    Ok, I will not get into the code you wrote nor will I write some, but, this is how I do a phase comparison on my projects. A 16 bit timer is free running all the time. No start/stop sequences. Comparator interrupts too are always enabled. No need to start/stop them. Remember Timer always counts up and rolls over, so CurrTimer nearly always is > PrevTimer. On rollover, the result of CurrTimer-PrevTimer is still valid since the bits are limited to a word size. So, 1000-500 is still same as 465-65500 (+ 1) when you do the 16 bit subtract.

    Define CurrTimer TMR1 ' alias CurrTimer as timer1
    PrevTimer var word
    FreqCount var word
    PhaseCount var word

    On comp1 interrupt
    FreqCount = CurrTimer - PrevTimer ' timer ticks between 2 edges of the same input give time proportional to the frequency
    PrevTimer = CurrTimer ' This is the new reference for phase measurement

    On comp2 interrupt
    PhaseCount = CurrTimer - PrevTimer ' gives the time between non shifted and shifted waves

    Convert phasecount to corresponding time as
    Phase(Degrees) = PhaseCount(uS)*180(degrees) / (180deg counts(us))

    Convert freqcount to corresponding freq similarly

    I hope this give you some hint. It's near bedtime and I can barely keep my eyes open. If you need some more hints, let me know, I'll try to help

    This code is definitely not PBP as I've just put the ideas forth.

    Regards

  6. #6
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default

    Many thanks...I'll study your post in detail tonight (after I've got the kids off to bed!)

    I wasn't expecting anyone to analyse my code - I only offered it up in case someone wants to get an overall vibe for my approach. Equally, I wouldn't want anyone to write it for me (else I'll never learn) - I seek exactly what you've brought to the table....ideas wrt general approach from those that have trodden similar paths! (the detail, I'll try & work out myself!)

    thanks once again.

  7. #7
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default

    Hi Jerson,

    Ok, had a bit of time to try & get my head around your method. I'd like to break each of you sentences down a little....

    A 16 bit timer is free running all the time. No start/stop sequences. Comparator interrupts too are always enabled. No need to start/stop them.
    I'm struggling with why you're letting them free run?

    The comparators first - they're gonna be generating a crazy amount of interrupts (to my simple brain, I actually wonder how the code will have time to do anythig else?! lol). Imagine a 1.4khz signal at the comparator pin - that's gonna be an interrupt every 700 us, but wait, there's the other signal presented at the other comparator pin (ie the one I want to measure the phase lag of) & it's generating interrupts too - so that's two interrupts arriving every 700us?!! (potentially the comparator might need to handle much higher frequencies...as high as 5Khz ....my mind boggles at the interrupt rate).The more I ponder this one (I'm into my 3rd night on this & nowhere near a result!), I do woder if there should be some other hardware I shopuld bring into play - to front end some of the work (I was looking at parrallax propellors - http://www.parallax.com/Portals/0/Im...lerBlock-L.jpg .....something like that architecture lends it self more to what I'm trying to do here?!)

    Now I'm inexperienced & that might not tax the PIC one iota, but bearing in mind my program already uses other interrupts (Interrupt on Change, INT_PIN etc), and it's to my mind my program is getting a bit interrupt busy!

    Ok, next (wrt allowing the timer to roll over) - I just can't get this clear in my head...

    Remember Timer always counts up and rolls over, so CurrTimer nearly always is > PrevTimer. On rollover, the result of CurrTimer-PrevTimer is still valid since the bits are limited to a word size. So, 1000-500 is still same as 465-65500 (+ 1) when you do the 16 bit subtract.
    I'm sure this is becuase I've not grasped the intracacies!

    If you reference my schematic above, once again - I'm measuring two signals for phase lag - what happens if if the first signal comes in before the timer rolls over, but by the time the lagged signal come in, the timer has rolled over?

    How does the maths work out for that scenario?

    Ok, to your code ideas for me to using...

    On comp1 interrupt
    FreqCount = CurrTimer - PrevTimer ' timer ticks between 2 edges of the same input give time proportional to the frequency
    Bearing in mind the source signal is a guitar - the frequency is forever moving (with periods where it's static), so I can't grasp how a moving target so to speak will work with that code approach?

    PrevTimer = CurrTimer ' This is the new reference for phase measurement
    This is about the one line I can grasp (!) - ie we need to put a stake in the ground to start timing until the second (phase lagged) signal arrives.

    On comp2 interrupt
    PhaseCount = CurrTimer - PrevTimer ' gives the time between non shifted and shifted waves
    Again, what if the phase has moved (becuase the incoming frequency changed) - couldn't you have a situation where the current Timer hasn't rolled over, but the previous timer (with the stored value) did?

    BTW - I really do appreciate you taking the time to explain to a dunderbrain like me!
    Last edited by HankMcSpank; - 12th September 2010 at 01:25.

  8. #8
    Join Date
    Nov 2005
    Location
    Bombay, India
    Posts
    967


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by HankMcSpank View Post
    Hi Jerson,
    I'm struggling with why you're letting them free run?
    Look at it a bit like you look at a stopwatch. I use the timer as a lap counter. I could choose to start / stop the timer, but it might increase the time spent in the interrupt a bit.

    The comparators first - they're gonna be generating a crazy amount of interrupts (to my simple brain, I actually wonder how the code will have time to do anythig else?! lol). Imagine a 1.4khz signal at the comparator pin - that's gonna be an interrupt every 700 us, but wait, there's the other signal presented at the other comparator pin (ie the one I want to measure the phase lag of) & it's generating interrupts too - so that's two interrupts arriving every 700us?!! (potentially the comparator might need to handle much higher frequencies...as high as 5Khz ....my mind boggles at the interrupt rate).
    Yes, you are right about the interrupts hogging all the time your processor has. But, you could always run the processor at say 20Mhz, makes it 5 times as fast than the default 4MHz. 5 times more that can be done. I've used this technique at 50Hz to check phase lag on mains signals.

    If you reference my schematic above, once again - I'm measuring two signals for phase lag - what happens if if the first signal comes in before the timer rolls over, but by the time the lagged signal come in, the timer has rolled over?

    How does the maths work out for that scenario?
    Ok, in the case of rollover, let us assume the first reading was 65500. Assume a phase shift of 500 counts. The new value is 66000. After rounding to 16 bits, you get 464 (66000-65536). So, current reading 464 - previous reading 65500 will give you your phase counts as 464-65500 = 01F4 in 16 bits (use the F5/F6 buttons on calc to see the Hex/Dec values). So, for an error of 1 count, you still get the same phase diff.

    Bearing in mind the source signal is a guitar - the frequency is forever moving (with periods where it's static), so I can't grasp how a moving target so to speak will work with that code approach?
    A phase diff measurement is just that. How you process it after you've found it out is up to you. I can suggest you put the phase count readings through a low pass filter to smooth out the variations.

    This is about the one line I can grasp (!) - ie we need to put a stake in the ground to start timing until the second (phase lagged) signal arrives.
    Precisely. That is what I am doing when I keep track of the last zero crossing of the first input. Comp1 interrupt. That is your pole in the ground.

    Again, what if the phase has moved (becuase the incoming frequency changed) - couldn't you have a situation where the current Timer hasn't rolled over, but the previous timer (with the stored value) did?
    It is possible in the real world scenario. For this, you can use an overflow mechanism to weed out this case. Any number bigger than expected range indicates the signal has died out.

    BTW - I really do appreciate you taking the time to explain to a dunderbrain like me!
    I am glad to help out as I was once in your shoes

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts