Hi All, Does anyone have any ideas how to implement an efficient phase unwrap algorithm (for use in FPGA) that will allow me to take the output of a cordic arc tan conversion and recover the unwrapped phase. After doing the phase unwrap I will need to differentiate the signal so I was thinking it may be simpler to combine these steps and perhaps differentiate first, ir differentiate in a mannor that accounts for the occasional 2pi shifts.. perhaps I could just differentiate and if the change is greater then pi then subtract 2pi in the opposite direction.. do people know if this would work? If anyone has done this before or has any ideas I would appreciate guideance. Regards, Paul Solomon
Phase unwrap for FM demod
Started by ●July 28, 2005
Reply by ●July 28, 20052005-07-28
Paul Solomon wrote:> Hi All, > > Does anyone have any ideas how to implement an efficient phase unwrap > algorithm (for use in FPGA) that will allow me to take the output of a > cordic arc tan conversion and recover the unwrapped phase. After doing the > phase unwrap I will need to differentiate the signal so I was thinking it > may be simpler to combine these steps and perhaps differentiate first, ir > differentiate in a mannor that accounts for the occasional 2pi shifts.. > > perhaps I could just differentiate and if the change is greater then pi then > subtract 2pi in the opposite direction.. do people know if this would work? > > If anyone has done this before or has any ideas I would appreciate > guideance.Provided you don't differentiate across a wrap, there's no need to unwrap. Differentiating discards the absolute shift. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 28, 20052005-07-28
"Jerry Avins" <jya@ieee.org> wrote in message news:fLGdnaE6WsOA5nTfRVn-iw@rcn.net...> Paul Solomon wrote: >> Hi All, >> >> Does anyone have any ideas how to implement an efficient phase unwrap >> algorithm (for use in FPGA) that will allow me to take the output of a >> cordic arc tan conversion and recover the unwrapped phase. After doing >> the phase unwrap I will need to differentiate the signal so I was >> thinking it may be simpler to combine these steps and perhaps >> differentiate first, ir differentiate in a mannor that accounts for the >> occasional 2pi shifts.. >> >> perhaps I could just differentiate and if the change is greater then pi >> then subtract 2pi in the opposite direction.. do people know if this >> would work? >> >> If anyone has done this before or has any ideas I would appreciate >> guideance. > > Provided you don't differentiate across a wrap, there's no need to unwrap. > Differentiating discards the absolute shift. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > �����������������������������������������������������������������������Ok, so if I just do a differentiator that has a check to confirm if it has passed a wrap and adjust for that then it should all be ok?
Reply by ●July 28, 20052005-07-28
Paul Solomon wrote:> "Jerry Avins" <jya@ieee.org> wrote in message > news:fLGdnaE6WsOA5nTfRVn-iw@rcn.net... > >>Paul Solomon wrote: >> >>>Hi All, >>> >>>Does anyone have any ideas how to implement an efficient phase unwrap >>>algorithm (for use in FPGA) that will allow me to take the output of a >>>cordic arc tan conversion and recover the unwrapped phase. After doing >>>the phase unwrap I will need to differentiate the signal so I was >>>thinking it may be simpler to combine these steps and perhaps >>>differentiate first, ir differentiate in a mannor that accounts for the >>>occasional 2pi shifts.. >>> >>>perhaps I could just differentiate and if the change is greater then pi >>>then subtract 2pi in the opposite direction.. do people know if this >>>would work? >>> >>>If anyone has done this before or has any ideas I would appreciate >>>guideance. >> >>Provided you don't differentiate across a wrap, there's no need to unwrap. >>Differentiating discards the absolute shift. >> >>Jerry >>-- >>Engineering is the art of making what you want from things you can get. >>����������������������������������������������������������������������� > > > Ok, so if I just do a differentiator that has a check to confirm if it has > passed a wrap and adjust for that then it should all be ok?I can't see how not, but be warned that I haven't actually done it. Wait a day to see if anyone shoots me down. Clay? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 29, 20052005-07-29
Paul Solomon wrote:> Hi All, > > Does anyone have any ideas how to implement an efficient phase unwrap > algorithm (for use in FPGA) that will allow me to take the output of a > cordic arc tan conversion and recover the unwrapped phase. After doing the > phase unwrap I will need to differentiate the signal so I was thinking it > may be simpler to combine these steps and perhaps differentiate first, ir > differentiate in a mannor that accounts for the occasional 2pi shifts.. > > perhaps I could just differentiate and if the change is greater then pi then > subtract 2pi in the opposite direction.. do people know if this would work? > > If anyone has done this before or has any ideas I would appreciate > guideance. > > Regards, > > Paul Solomon > >If you know that you'll never have a phase shift greater than 1/2 circle, then it's easy: just represent your phase as an n-bit 2's complement number, with bit weighting of 2^{-n} circles. Then the phase difference is just the current phase minus the previous phase, and any wrap is taken care of automagically. Representing angles so they fit evenly into a binary number is about the only time that wrap will work for you instead of helping you shoot off your foot -- I always get as much milage out of it as I can. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 29, 20052005-07-29
Tim Wescott wrote:> Paul Solomon wrote: > >> Hi All, >> >> Does anyone have any ideas how to implement an efficient phase unwrap >> algorithm (for use in FPGA) that will allow me to take the output of a >> cordic arc tan conversion and recover the unwrapped phase. After doing >> the phase unwrap I will need to differentiate the signal so I was >> thinking it may be simpler to combine these steps and perhaps >> differentiate first, ir differentiate in a mannor that accounts for >> the occasional 2pi shifts.. >> >> perhaps I could just differentiate and if the change is greater then >> pi then subtract 2pi in the opposite direction.. do people know if >> this would work? >> >> If anyone has done this before or has any ideas I would appreciate >> guideance. >> >> Regards, >> >> Paul Solomon >> >> > If you know that you'll never have a phase shift greater than 1/2 > circle, then it's easy: just represent your phase as an n-bit 2's > complement number, with bit weighting of 2^{-n} circles. Then the phase > difference is just the current phase minus the previous phase, and any > wrap is taken care of automagically. > > Representing angles so they fit evenly into a binary number is about the > only time that wrap will work for you instead of helping you shoot off > your foot -- I always get as much milage out of it as I can.Unwrapping consists of adding a constant to a segment of the phase curve that lies between jumps. Differentiation ignores the constant. Since real differentiation at a point isn't possible, differences are taken in practice. If the interval used by the digital "differentiator" straddles a jump, there's trouble. The case is easily spotted, because of the large error. With a reasonably clean signal, finding where (and which way) the derivative has glitches is a good way to unwrap the phase, if you need it unwrapped. If noise makes the wrap points ambiguous, the demodulated signal isn't likely to be of much use anyway. Or so I think. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 29, 20052005-07-29
Jerry Avins wrote:> Tim Wescott wrote: > >> Paul Solomon wrote: >> >>> Hi All, >>> >>> Does anyone have any ideas how to implement an efficient phase unwrap >>> algorithm (for use in FPGA) that will allow me to take the output of >>> a cordic arc tan conversion and recover the unwrapped phase. After >>> doing the phase unwrap I will need to differentiate the signal so I >>> was thinking it may be simpler to combine these steps and perhaps >>> differentiate first, ir differentiate in a mannor that accounts for >>> the occasional 2pi shifts.. >>> >>> perhaps I could just differentiate and if the change is greater then >>> pi then subtract 2pi in the opposite direction.. do people know if >>> this would work? >>> >>> If anyone has done this before or has any ideas I would appreciate >>> guideance. >>> >>> Regards, >>> >>> Paul Solomon >>> >>> >> If you know that you'll never have a phase shift greater than 1/2 >> circle, then it's easy: just represent your phase as an n-bit 2's >> complement number, with bit weighting of 2^{-n} circles. Then the >> phase difference is just the current phase minus the previous phase, >> and any wrap is taken care of automagically. >> >> Representing angles so they fit evenly into a binary number is about >> the only time that wrap will work for you instead of helping you shoot >> off your foot -- I always get as much milage out of it as I can. > > > Unwrapping consists of adding a constant to a segment of the phase curve > that lies between jumps. Differentiation ignores the constant. Since > real differentiation at a point isn't possible, differences are taken in > practice. If the interval used by the digital "differentiator" straddles > a jump, there's trouble. The case is easily spotted, because of the > large error. With a reasonably clean signal, finding where (and which > way) the derivative has glitches is a good way to unwrap the phase, if > you need it unwrapped. If noise makes the wrap points ambiguous, the > demodulated signal isn't likely to be of much use anyway. Or so I think. > > JerryBut with a binary full-circle = 2^n representation there's no need to detect the jump, or take any special action at all. It all just comes out in the wash. Take an 8-bit phase measurement, with a phase change of 0x23 each step: step phase difference 0 0 -- 1 23 (23 - 0) mod 100 = 23 2 46 (46 - 23) mod 100 = 23 3 69 (69 - 46) mod 100 = 23 4 8c (8c - 69) mod 100 = 23 // even though 8c is -74 5 af (af - 8c) mod 100 = 23 6 d2 (d2 - af) mod 100 = 23 7 f5 (f5 - d2) mod 100 = 23 8 18 (18 - f5) mod 100 = 23 // even though you've wrapped -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●July 29, 20052005-07-29
Tim Wescott wrote:> Jerry Avins wrote: > >> Tim Wescott wrote: >> >>> Paul Solomon wrote: >>> >>>> Hi All, >>>> >>>> Does anyone have any ideas how to implement an efficient phase >>>> unwrap algorithm (for use in FPGA) that will allow me to take the >>>> output of a cordic arc tan conversion and recover the unwrapped >>>> phase. After doing the phase unwrap I will need to differentiate the >>>> signal so I was thinking it may be simpler to combine these steps >>>> and perhaps differentiate first, ir differentiate in a mannor that >>>> accounts for the occasional 2pi shifts.. >>>> >>>> perhaps I could just differentiate and if the change is greater then >>>> pi then subtract 2pi in the opposite direction.. do people know if >>>> this would work? >>>> >>>> If anyone has done this before or has any ideas I would appreciate >>>> guideance. >>>> >>>> Regards, >>>> >>>> Paul Solomon >>>> >>>> >>> If you know that you'll never have a phase shift greater than 1/2 >>> circle, then it's easy: just represent your phase as an n-bit 2's >>> complement number, with bit weighting of 2^{-n} circles. Then the >>> phase difference is just the current phase minus the previous phase, >>> and any wrap is taken care of automagically. >>> >>> Representing angles so they fit evenly into a binary number is about >>> the only time that wrap will work for you instead of helping you >>> shoot off your foot -- I always get as much milage out of it as I can. >> >> >> >> Unwrapping consists of adding a constant to a segment of the phase >> curve that lies between jumps. Differentiation ignores the constant. >> Since real differentiation at a point isn't possible, differences are >> taken in practice. If the interval used by the digital >> "differentiator" straddles a jump, there's trouble. The case is easily >> spotted, because of the large error. With a reasonably clean signal, >> finding where (and which way) the derivative has glitches is a good >> way to unwrap the phase, if you need it unwrapped. If noise makes the >> wrap points ambiguous, the demodulated signal isn't likely to be of >> much use anyway. Or so I think. >> >> Jerry > > > But with a binary full-circle = 2^n representation there's no need to > detect the jump, or take any special action at all. It all just comes > out in the wash. Take an 8-bit phase measurement, with a phase change > of 0x23 each step: > > step phase difference > 0 0 -- > 1 23 (23 - 0) mod 100 = 23 > 2 46 (46 - 23) mod 100 = 23 > 3 69 (69 - 46) mod 100 = 23 > 4 8c (8c - 69) mod 100 = 23 // even though 8c is -74 > 5 af (af - 8c) mod 100 = 23 > 6 d2 (d2 - af) mod 100 = 23 > 7 f5 (f5 - d2) mod 100 = 23 > 8 18 (18 - f5) mod 100 = 23 // even though you've wrappedCertainly. Still, there is that MOD step. This approach is nicest when the MOD is achieved at no cost in hardware, but that's too fine grained for a 32-bit machine. The next best way to compute the MOD is ANDing with a mask. At the end of http://users.erols.com/jyavins/typek.htm, there's a crude sine generator where 360 degrees = 8192. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●July 29, 20052005-07-29
Jerry Avins wrote:> Tim Wescott wrote: > >> Jerry Avins wrote: >> >>> Tim Wescott wrote: >>> >>>> Paul Solomon wrote: >>>> >>>>> Hi All, >>>>> >>>>> Does anyone have any ideas how to implement an efficient phase >>>>> unwrap algorithm (for use in FPGA) that will allow me to take the >>>>> output of a cordic arc tan conversion and recover the unwrapped >>>>> phase. After doing the phase unwrap I will need to differentiate >>>>> the signal so I was thinking it may be simpler to combine these >>>>> steps and perhaps differentiate first, ir differentiate in a mannor >>>>> that accounts for the occasional 2pi shifts.. >>>>> >>>>> perhaps I could just differentiate and if the change is greater >>>>> then pi then subtract 2pi in the opposite direction.. do people >>>>> know if this would work? >>>>> >>>>> If anyone has done this before or has any ideas I would appreciate >>>>> guideance. >>>>> >>>>> Regards, >>>>> >>>>> Paul Solomon >>>>> >>>>> >>>> If you know that you'll never have a phase shift greater than 1/2 >>>> circle, then it's easy: just represent your phase as an n-bit 2's >>>> complement number, with bit weighting of 2^{-n} circles. Then the >>>> phase difference is just the current phase minus the previous phase, >>>> and any wrap is taken care of automagically. >>>> >>>> Representing angles so they fit evenly into a binary number is about >>>> the only time that wrap will work for you instead of helping you >>>> shoot off your foot -- I always get as much milage out of it as I can. >>> >>> >>> >>> >>> Unwrapping consists of adding a constant to a segment of the phase >>> curve that lies between jumps. Differentiation ignores the constant. >>> Since real differentiation at a point isn't possible, differences are >>> taken in practice. If the interval used by the digital >>> "differentiator" straddles a jump, there's trouble. The case is >>> easily spotted, because of the large error. With a reasonably clean >>> signal, finding where (and which way) the derivative has glitches is >>> a good way to unwrap the phase, if you need it unwrapped. If noise >>> makes the wrap points ambiguous, the demodulated signal isn't likely >>> to be of much use anyway. Or so I think. >>> >>> Jerry >> >> >> >> But with a binary full-circle = 2^n representation there's no need to >> detect the jump, or take any special action at all. It all just comes >> out in the wash. Take an 8-bit phase measurement, with a phase change >> of 0x23 each step: >> >> step phase difference >> 0 0 -- >> 1 23 (23 - 0) mod 100 = 23 >> 2 46 (46 - 23) mod 100 = 23 >> 3 69 (69 - 46) mod 100 = 23 >> 4 8c (8c - 69) mod 100 = 23 // even though 8c is -74 >> 5 af (af - 8c) mod 100 = 23 >> 6 d2 (d2 - af) mod 100 = 23 >> 7 f5 (f5 - d2) mod 100 = 23 >> 8 18 (18 - f5) mod 100 = 23 // even though you've wrapped > > > Certainly. Still, there is that MOD step. This approach is nicest when > the MOD is achieved at no cost in hardware, but that's too fine grained > for a 32-bit machine. The next best way to compute the MOD is ANDing > with a mask. At the end of http://users.erols.com/jyavins/typek.htm, > there's a crude sine generator where 360 degrees = 8192. > > JerryCheck out Sandia Labs. They published a book on 2D phase unwrapping. Their application is Synthetic Aperture Radar. The book contains a few algorithms (and code). Cheers, David
Reply by ●July 29, 20052005-07-29
Jerry Avins wrote:> Tim Wescott wrote: > >> Jerry Avins wrote: >> >>> Tim Wescott wrote: >>> >>>> Paul Solomon wrote: >>>> >>>>> Hi All, >>>>> >>>>> Does anyone have any ideas how to implement an efficient phase >>>>> unwrap algorithm (for use in FPGA) that will allow me to take the >>>>> output of a cordic arc tan conversion and recover the unwrapped >>>>> phase. After doing the phase unwrap I will need to differentiate >>>>> the signal so I was thinking it may be simpler to combine these >>>>> steps and perhaps differentiate first, ir differentiate in a mannor >>>>> that accounts for the occasional 2pi shifts.. >>>>> >>>>> perhaps I could just differentiate and if the change is greater >>>>> then pi then subtract 2pi in the opposite direction.. do people >>>>> know if this would work? >>>>> >>>>> If anyone has done this before or has any ideas I would appreciate >>>>> guideance. >>>>> >>>>> Regards, >>>>> >>>>> Paul Solomon >>>>> >>>>> >>>> If you know that you'll never have a phase shift greater than 1/2 >>>> circle, then it's easy: just represent your phase as an n-bit 2's >>>> complement number, with bit weighting of 2^{-n} circles. Then the >>>> phase difference is just the current phase minus the previous phase, >>>> and any wrap is taken care of automagically. >>>> >>>> Representing angles so they fit evenly into a binary number is about >>>> the only time that wrap will work for you instead of helping you >>>> shoot off your foot -- I always get as much milage out of it as I can. >>> >>> >>> >>> >>> Unwrapping consists of adding a constant to a segment of the phase >>> curve that lies between jumps. Differentiation ignores the constant. >>> Since real differentiation at a point isn't possible, differences are >>> taken in practice. If the interval used by the digital >>> "differentiator" straddles a jump, there's trouble. The case is >>> easily spotted, because of the large error. With a reasonably clean >>> signal, finding where (and which way) the derivative has glitches is >>> a good way to unwrap the phase, if you need it unwrapped. If noise >>> makes the wrap points ambiguous, the demodulated signal isn't likely >>> to be of much use anyway. Or so I think. >>> >>> Jerry >> >> >> >> But with a binary full-circle = 2^n representation there's no need to >> detect the jump, or take any special action at all. It all just comes >> out in the wash. Take an 8-bit phase measurement, with a phase change >> of 0x23 each step: >> >> step phase difference >> 0 0 -- >> 1 23 (23 - 0) mod 100 = 23 >> 2 46 (46 - 23) mod 100 = 23 >> 3 69 (69 - 46) mod 100 = 23 >> 4 8c (8c - 69) mod 100 = 23 // even though 8c is -74 >> 5 af (af - 8c) mod 100 = 23 >> 6 d2 (d2 - af) mod 100 = 23 >> 7 f5 (f5 - d2) mod 100 = 23 >> 8 18 (18 - f5) mod 100 = 23 // even though you've wrapped > > > Certainly. Still, there is that MOD step. This approach is nicest when > the MOD is achieved at no cost in hardware, but that's too fine grained > for a 32-bit machine. The next best way to compute the MOD is ANDing > with a mask. At the end of http://users.erols.com/jyavins/typek.htm, > there's a crude sine generator where 360 degrees = 8192. > > JerryOn a 32-bit machine (or an anything-bit machine) you just left-justify the angle, insuring that the angle fills the word. Then the mod operation is just a natural consequence of truncation. On an FPGA you get to select the word size for each and every piece of data, so you have even more freedom. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
