Measuring audio phase shift through a circuit with a PIC

[gadelhas]

Excellent Job. Congratulations!!!

[HankMcSpank]

Excellent Job. Congratulations!!!

Thanks...I've just hit a problem. While larger phase shifts are being measured well, using this method (feeding into 2 x PIC comparators & counting using DT's interrupts) it seems small phase shifts can't be measured accurately. I made a short video to illustrate the problem....

(better to maximise the video to full screen & select 720p towards the right of the youtube video play bar)



Here's the video's accompanying text with the video explaining what's going on....

"Here you'll see two square waves feeding into the two comparators on a PIC...the green signal trace is feeding into comparator 1 (comp1 count is the count on the left & has a static count of about 9992) - the yellow trace is a 'phase lagged' signal feeding into the PIC's comparator 2. (the comparator 2 count is the green text on the right) What you see on screen is me reducing the phase lag of the yellow trace - as I reduce the phase lag, you can see the comp2 count decrement (as expected) BUT ...as the phase lagged signal gets into the small lag region, the comp2 count won't decrement below 336 - this suggests using PIC comparators & interrupts isn't workable for measuring small phase shifts?"

The audio signal frequency in that video is about 500Hz...and due to the Comp2 count not decremeting below 336, it means any phase lag below 12.5 degrees can't be measured At just 1400Hz (Comp1 count = 3,600, comp2 = count 336 minimum) , it means phase lag under 33 degrees can't be measured


Here are the two Comparator simple interrupt handlers...

'Comparator1 Interrupt Handler++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
Comp1_Int:
        Comp1Time.Lowbyte = TMR1L  'Store away the timer1 count - this  will be the non lagged signal 'period' count.
        Comp1Time.Highbyte = TMR1H    
        TMR1H = 0                     'Set timer1 value to 0
        TMR1L = 0                     
@ INT_RETURN

'Comparator2 Interrupt Handler++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
Comp2_Int:
        Comp2Time.Lowbyte = TMR1L    'Store away the timer1 count again (ie once the lagged signal leading edge arrives - this is the lag count)
        Comp2Time.Highbyte = TMR1H    
@ INT_RETURN

EDIT: Following on from the first blurry video I linked to, I re-made the video in HD & uploaded again (the new URL is edited in above)...be sure to view in 720p on youtube! (else the onscreen text will be blurred)

[sinoteq]

What PIC do you use and how fast do you run it?

[HankMcSpank]

What PIC do you use and how fast do you run it?

I use a 16f690 @20Mhz

The 16F690's Comparator 1 receives the non lagged signal (set to internal VREF to trip at about 1/2 VCC)
The 16F690's Comparator 2 receives the phase lagged signal (set to internal VREF to trip about 1/2 VCC too)

Identical signals are fed into both comparators (bar the phase lag)

DT's interrupts enabled for CMP1 & CMP2.

On the scope the lag time measures about 20us - below which Comp2 will not decrement.

I don't know enough about what's going on under the hood wrt interrupts (or timer1 zero-ing) to shine any more light on why the comp2 count won't go below 336...when clearly it should as the leading edge of the lagged signal gets close to zero lag. So being a bit wet nehind the ears, is there any other possible method I can use that circumvent this problem?

[languer]

So on the picture and data on post#15 things were looking honky-dory (you were measuring at least down to 161 counts on CMP2). Your new posts state that now CMP2 will not go below 336. Basic question; what changed?

[HankMcSpank]

So on the picture and data on post#15 things were looking honky-dory (you were measuring at least down to 161 counts on CMP2). Your new posts state that now CMP2 will not go below 336. Basic question; what changed?

Apologies...I've only just seen your question from a day or so ago - firstly that's very sharp of you to pick up on that detail

What changed?

I wish I knew....when it looked hunky dory...I didn't probe to deeply (I guess the - at the time - relief overcame me & I was a bit premature saying all was well!), I sort of put it to one side...a couple of nights later I came back to it & couldn't get the darned count down.

I've not changed the circuit....and have only window dressed the code (I can't genuinely say what I might have benn window dressed - but it will have been minimal!), but early indications here since getting home is that it might be related to the amount of text I'm squirting out with the HSEROUT command (which I queried myself the other night...and acetronics spotted earlier today!)

I only had a slim window of opprtunity before domestic commitments kicked in....but when 1000Hz (a nice round number to work with) was fed into comp1 I saw the count drop from 5,000 to something like 4600 when I put an Hserout in amongst the count storing! So is it related to amount of debug text I wonder?

I'm using Paul's excellent idea of keeping it simple & plagiarising the simple code he kindly provided (less his one typo! ) ...first step is to get a good solid Comp 1 derived timer count for 1000Hz (which @20Mhz should be 5000 - and indeed it is using paul's code )...I'll then augment from there (ie bring comp2 into play)

[HankMcSpank]

Ok, success (of sorts)

By keeping it simple, this code works (many thanks to Paul, whose code sample I used, albeit in McSpank-esque form here)...

PIR2.5 = 0    'Clear the Comp1 interrupt flag
Comp1Time = 0

Main_Loop:
        WHILE PIR2.5 = 0       
        GOTO Main_Loop
        WEND
        TMR1H = 0                    
        TMR1L = 0
        PIR2.5 = 0
        Comp1_count:
        WHILE PIR2.5 = 0
        goto Comp1_count
        wend 
        Comp1Time.Highbyte = TMR1H  
        Comp1Time.Lowbyte = TMR1L
        TMR1H = 0                    
        TMR1L = 0
        PIR2.6 = 0
        'HSEROUT [dec Comp1Time,13, 10]  
        Comp2_count:
        WHILE PIR2.6 = 0
        goto Comp2_count
        wend
        Comp2Time.Highbyte = TMR1H  
        Comp2Time.Lowbyte = TMR1L
        TMR1H = 0                    
        TMR1L = 0
        HSEROUT ["C1=",dec Comp1Time,9,"C2=", dec comp2time, 13, 10]
        PIR2.5 = 0
        goto Main_Loop

ie the C2 count decrements nice & smoothly (& below 336 - yay!) & totally in line with the amount of phase lag....

(green trace is comp1 - non lagged, yellow trace is into comp2 & lagged a miniscule amout)



.....I can get all the way down to 13-14(ish) below which the C2 count gets very jittery (ie successive counts eg 5, 11, 6, 12, 5, - you can see some 19s in that stream above)....but a comp2 count of 13 @1kHz is granular enough for me (accuracy to within 0.936 degrees @1kHz). I'm elated...*BUT*

Quite clearly my original way is causing some issues (p& almost certainly to do with my poor sequence &/or coding), so if this way of doing it works, how can I integrate it into my main program?

My first attempt just now failed...

Here's the screen output...

C1=4909 C2=13
C1=4903 C2=13
C1=4909 C2=13
C1=4909 C2=13
hello
C1=4903 C2=13
C1=4909 C2=13

ie that C1 count has dropped?!! (even though the incoming frequency has remained at 1Khz)

here's what I did (disclaimer: I didn't know how to get the main body of program to 'jump' to to the interrupt handler when Comp1 interrupted, so I deferred back to DT's method as the initial 'trigger')...

Comp1Time       var  word    ' used to amalgamate TMR1 High & Low Bytes.
Comp2Time       var  word

      
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   CMP1_INT,  _Comp1_Int,   PBP,  yes
    endm
    INT_CREATE               ; Creates the interrupt processor
ENDASM

T1CON.0= 1  'start timer

Comp1Time = 0 'clear down Comp1Time, prior to starting.
comp2Time = 0  'clear down Comp2Time, prior to starting

@ INT_ENABLE  CMP1_INT     ; enable Comparator 1 interrupts
PIR2.5 = 0    'Clear the Comp1 interrupt flag
Comp1Time = 0
Comp2Time = 0

'Main body of Code****************************************************************

Main:
hserout ["hello", 13, 10]
pause 20
goto Main

END

'**********************Comp1 interrupt handler*********************************************************
Comp1_Int:
Comp1_Loop:
        WHILE PIR2.5 = 0       
        GOTO Comp1_Loop
        WEND
        TMR1H = 0                    
        TMR1L = 0
        PIR2.5 = 0
        Comp1_count:
        WHILE PIR2.5 = 0
        goto Comp1_count
        wend 
        Comp1Time.Highbyte = TMR1H  
        Comp1Time.Lowbyte = TMR1L
        TMR1H = 0                    
        TMR1L = 0
        PIR2.6 = 0
        'HSEROUT [dec Comp1Time,13, 10]  
        Comp2_count:
        WHILE PIR2.6 = 0
        goto Comp2_count
        wend
        Comp2Time.Highbyte = TMR1H  
        Comp2Time.Lowbyte = TMR1L
        TMR1H = 0                    
        TMR1L = 0
        HSEROUT ["C1=",dec Comp1Time,9,"C2=", dec comp2time, 13, 10]
        PIR2.5 = 0
        
@ INT_RETURN

[languer]

This is most excellent.

You may have already corrected this, but on the original code the analog inputs for the comparators are not enabled (ANSEL.6 and ANSEL.7). Minor thing, but shouldn't hurt to follow the datasheet.

I do agree with other suggestions, since the inputs are already digital there is not need to use the comparators. But to use the IOC (interrupt-on-change) you would most likely need to go for PORTA or PORTB (which have individual IOC bits for each input).

General suggestion for interrupt use: keep everything short; do only the absolute minimum inside the interrupt routine.

Even though the use of the HW USART (HSEROUT) is a plus, you should still try to do this outside the interrupt routine. Do the timer stuff inside the interrupt (i.e. clear and set timer, etc). Make a flag that tells you the interrupt "fired"; and in the main loop manipulate the data to be sent out (and send it out). I think the CCP module maybe a much better candidate for what you are doing (duh, except you would need a PIC with two CCP modules - never mind).

[prstein]

I use a 16f690 @20Mhz

The 16F690's Comparator 1 receives the non lagged signal (set to internal VREF to trip at about 1/2 VCC)
The 16F690's Comparator 2 receives the phase lagged signal (set to internal VREF to trip about 1/2 VCC too)

Identical signals are fed into both comparators (bar the phase lag)

DT's interrupts enabled for CMP1 & CMP2.

On the scope the lag time measures about 20us - below which Comp2 will not decrement.

I don't know enough about what's going on under the hood wrt interrupts (or timer1 zero-ing) to shine any more light on why the comp2 count won't go below 336...when clearly it should as the leading edge of the lagged signal gets close to zero lag. So being a bit wet nehind the ears, is there any other possible method I can use that circumvent this problem?

I'm coming into this sort of late, although I've been more-or-less following this thread. Very interesting stuff!

Anyway, here's an idea that may help--just use a single interrupt. When the first comparator causes the interrupt, get your tmr1 count and zero it, then wait in a tight loop, checking PIR2.6. That should reduce latency to an absolute minimum.

something like

'Make sure the Comparator 2 interrupt handler is disabled!
'Comparator1 Interrupt Handler++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
Comp1_Int:
        Comp1Time.Lowbyte = TMR1L  'Store away the timer1 count - this  will be the non lagged signal 'period' count.
        Comp1Time.Highbyte = TMR1H    
        TMR1H = 0                     'Set timer1 value to 0
        TMR1L = 0
        PIR2.6 = 0                     'Clear the Comparator C2 Interrupt Flag bit
Keep_Waiting:
        WHILE  PIR2.6 = 0         'Check to see if the Comparator 2 interrupt flag has flipped
            goto Keep_Wating
        WEND
        Comp2Time.Lowbyte = TMR1L    'Store away the timer1 count again (ie once the lagged signal leading edge arrives - this is the lag count)
        Comp2Time.Highbyte = TMR1H    
@ INT_RETURN

You could also add some sort of check so that it would exit the loop if an unreasonable amount of time has elapsed.

Best Regards,
Paul

[HankMcSpank]

H Paul,

Thank you very much for your input - truthfully, I was was getting too wrapped up in this over the weekend, but after drawing a blank with every avenue explored, I'm taking a self enforced mini break from that particular problem (I often find coming back to a project after a rest sparks new ideas & approaches). re your specific idea...I'll freely admit that I'm sort of out my depth when it comes to the inner working of interrupts (ie Picbasic interrupts vs ASM interrupts vs DT interrupts), but at one stage I do recall getting intensely intimate with the datasheet & having a "what the hell" pop at something *very* similar to what you mention - I saw no difference (but I will revisit in the light of your input)

I could really do with some interrupt big hitters to chime in & outline a little a bit about how to get such time sensitive interrupt timings down to the bare minimum (assuming your suggestion isn't the only attack) ....becuase as it stands right now, I have *NO* (zilch, nada, zero, scratch) idea why that comparator2 interrupt count will not register below 336 when I feed a very slightly phase lagged signal into comp2 ...and alas, the my future (parked) status as a multimillionaire who invented widget X depends on getting that count to reflect the time lag between comp1 & comp2 tripping


I'm in part slightly reticent to even push this one too much in the (highly possible) case there's something inherently wrong in my PIC /PICBasic approach - what I am convinced about is that the inputs to the comparators are without question correct - I may be pants at programming, but I know how to drive a scope, sig gen etc! (I think my youtube video illustrates the issue seems to be a valid one)

if anyone out their in the global 'PIC interest land' feels up to the challenge - they could see themselves what happens when they feed near identically phased signals (ie a clock?) into comparator1 & comparator2 (that said an identical signal might cause problems with a race scenario?...but I concede that most don't have the faciilities or interest to setup an all pass to phase shift the two signals!)...in principle, with identical (phase) signals into both comparators, the count for comparator 2 ought to be very close to zero (like single digits)

But I will come back to this (& first on the list will be your suggestion..if for no other reason thatn your is the only suggestion I have, lol) - I'm presently now working on Project Y - it's not gonna be the blockbuster that Widget X will be ...but got to keep keep my kids in Nike trainers somehow or other

Edit: While I'm publicily declaring my woeful lack of grasp of time sensitive h/w & corresponding code....I also wonder if changing my PIC might help to get that comp2 count down? (I'm using a 16F690 not becuase it's necessarily the most suitable - but it came bundled with my PIKIT2 starter kit & I've stuck with it from new and have started to get the hang of it a little - when your grappling in the dark as often as am, you need a torch that's familiar!), but I see a chart like this http://www.microchip.com/en_us/technology/xlp/ & then wonder, is there a more efficient PIC for doing this type of stuff out there...??? (eg pics optimised for single instructions - not even sure what that means but the bar chart looks like a shocker!)

[Jerson]

Hi Hank

Since you're stuck, I wonder if you could post/PM your code of now so that I can take a whack at it. I'll see if I can find your problem with the min value of comp2 value.

The barest minimum code which will compile and show the problem is sufficient. I should be able to run it.

Regards

[cncmachineguy]

'Make sure the Comparator 2 interrupt handler is disabled!
'Comparator1 Interrupt Handler++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
Comp1_Int:
        Comp1Time.Lowbyte = TMR1L  'Store away the timer1 count - this  will be the non lagged signal 'period' count.
        Comp1Time.Highbyte = TMR1H    
        TMR1H = 0                     'Set timer1 value to 0
        TMR1L = 0
        PIR2.6 = 0                     'Clear the Comparator C2 Interrupt Flag bit
Keep_Waiting:
        WHILE  PIR2.6 = 0         'Check to see if the Comparator 2 interrupt flag has flipped
            goto Keep_Wating
        WEND
        Comp2Time.Lowbyte = TMR1L    'Store away the timer1 count again (ie once the lagged signal leading edge arrives - this is the lag count)
        Comp2Time.Highbyte = TMR1H    
@ INT_RETURN

You could also add some sort of check so that it would exit the loop if an unreasonable amount of time has elapsed.

Best Regards,
Paul

I like Pauls approach, Seems to be the least amount of time between Comp1 and 2. one thing I would do, is program his while loop in ASM. This is because I have no idea how many instructions it takes using PBP. I think this will mask the issue of how long it takes to actually enter the handler. Which is what I think above folks are reffering to with the PBP include.

heres the while loop in asm:

     BCF PIR2,6       --> clears the comp 2 int flag
HERE                    --> label to jump to
     BTFSS PIR2,6  --> test if comp 2 int flag is set
     GOTO HERE     --> not set, go back to test
CONTINUE            --> Comp 2 int occured, do what ever needs to be done

The above will take exactly 1 instruction to enter the loop, then 3 inscrutions to to run per loop. now for some math:

you are running a 20mHz clock, so thats 5MIPS. so 1 instruction takes .0000002 sec to execute. At 1400 htz, each cycle takes .0071428 sec. that devided by 360 = .00000198sec per degree. so you should be able to measure to almost .5 degree. assuming comp2 fires between BCF and BTFSS, thats 3 instrution cycles, or .0000006 sec.(I think BTFSS may take 2 cycles when true)

Someone please check my math, but these numbers show you have far too much overhead somewhere that can only be explained by the above posts.

[HankMcSpank]

I like Pauls approach, Seems to be the least amount of time between Comp1 and 2. one thing I would do, is program his while loop in ASM. This is because I have no idea how many instructions it takes using PBP. I think this will mask the issue of how long it takes to actually enter the handler. Which is what I think above folks are reffering to with the PBP include.

heres the while loop in asm:

     BCF PIR2,6       --> clears the comp 2 int flag
HERE                    --> label to jump to
     BTFSS PIR2,6  --> test if comp 2 int flag is set
     GOTO HERE     --> not set, go back to test
CONTINUE            --> Comp 2 int occured, do what ever needs to be done

The above will take exactly 1 instruction to enter the loop, then 3 inscrutions to to run per loop. now for some math:

you are running a 20mHz clock, so thats 5MIPS. so 1 instruction takes .0000002 sec to execute. At 1400 htz, each cycle takes .0071428 sec. that devided by 360 = .00000198sec per degree. so you should be able to measure to almost .5 degree. assuming comp2 fires between BCF and BTFSS, thats 3 instrution cycles, or .0000006 sec.(I think BTFSS may take 2 cycles when true)

Someone please check my math, but these numbers show you have far too much overhead somewhere that can only be explained by the above posts.

I agree with the maths...and I agree with the summary (something somewhere is taking way too long). Now that I have a few people interested & feeding in ideas , I will pull the breadboard out of cold storage tonight & try Paul's code.


Bert, re this...

     BCF PIR2,6       --> clears the comp 2 int flag
HERE                    --> label to jump to
     BTFSS PIR2,6  --> test if comp 2 int flag is set
     GOTO HERE     --> not set, go back to test
CONTINUE            --> Comp 2 int occured, do what ever needs to be done

That looks like what will happen when comp2 interrupts....but within my program, how do I setup the 'trigger' condition ...ie to get the program to go and do that when a comp2 interrupt has arrived?

I will feedback the results (it might be late - ie 21.30 GMT-ish .....got to do the 'kids off to bed' rigamrole first! Hey there's an idea...rather than read them Noddy goes to the Seaside, I could read them some of the ASM code put forward by Bert!! )