|
Hi all, for too long already, I'm fighting against a spurious peak on a signal which comes from an AD1836 SigmaDeltaConverter. I hope that somebody can help me to trace this down or at least find out where I'd look for the origin. Basically I have a noisy signal with very low levels . This signal is converted and brought into a SHARC 21161 DSP. Method is the same as in the talkthru example ADI provides. Sample rate is 48kS, hardware is EZ-LITE-Board. Depending on external interrupts and a timer based processing, a resulting signal stream leaves the DSP, again via SPORT link. For debuggin purposes I switched the processing off, except amplification by a factor of 800 to make the issue visible on a scope. In software, there's the DMA interrupt (SP0) which transports the signal streams in and out. Then there's an external interrupt IRQ1, which is triggered once per millisecond. Third, there's a periodic timer (TMZL), which is retriggered every 30ms. The strange thing is, that the spurious peak appears exactly at the frequency of the timer, this is every 30ms. If I change the timer frequency, the peak changes its frequency accordingly. If I switch the timer off, the peak fades. I cut away all processing which directly influences the signal, so that the signal is only amplified and passed through the ISR. Most of the othe processing, I did move it to a main loop, so that the three ISRs would cause least interference. Strange thing is that the problem is not only on the output, which might mean it has to do with program failures like faulty memory or register sharing. Instead, the fault seems to enter from the ADC (or at least from DMA). If I invert the signal directly after it comes in, peak is inverted, too. However, despite what I try, the peak persists. Does anybody have similar experiences? There should be an explanation, though I can't find it. Quite a little in despair, eagerly waiting for some hints... Bernhard Here a series of samples taken around the peak. The usual values should be around -0.04....-0.07 peak (undesired) where level is below -0.1 @@Floating Point 32 bit -0.058313467 -0.054451086 -0.048174717 -0.042091466 -0.053678609 -0.060437776 -0.054257967 -0.03929124 -0.060341217 -0.055127002 -0.037842847 -0.11055217 -0.12223587 -0.13053998 -0.14878973 -0.14251336 -0.14106497 -0.15052781 -0.14888629 -0.14183745 -0.14347896 -0.14145121 -0.1596044 -0.14627919 -0.15332803 -0.14965877 -0.14541015 -0.15352115 -0.15892848 -0.13498172 -0.13855442 -0.14270648 -0.15052781 -0.15815601 -0.15728697 -0.14850006 -0.14685854 -0.15641794 -0.14048561 -0.14541015 -0.13633355 -0.14521703 -0.14038906 -0.11422143 -0.1388441 -0.15390739 -0.14367208 -0.14463767 -0.16626701 -0.15583858 -0.15265211 -0.16182527 -0.14270648 -0.13671979 -0.13237461 -0.1316987 -0.12155996 -0.12745008 -0.12387738 -0.12059436 -0.17640576 -0.13614044 -0.077432252 -0.10533796 -0.076080419 -0.11306272 -0.089695312 -0.099930622 -0.11509047 -0.13382301 -0.083901741 -0.21541581 -0.23820385 -0.10794506 -0.10591731 -0.099640943 -0.12020812 -0.10263429 -0.11818037 -0.1245533 -0.120015 -0.11373863 -0.13469204 -0.16703948 -0.1479207 -0.13990626 -0.13469204 -0.13227805 -0.12107716 -0.13005719 -0.14203057 -0.13652667 -0.13633355 -0.12938127 -0.12947783 -0.13092622 -0.12793288 -0.13324365 -0.12300835 -0.1347886 -0.14154777 -0.12300835 -0.12648448 -0.12378082 -0.12629136 -0.13498172 -0.13053998 -0.13160214 -0.13797507 -0.13633355 -0.13845786 -0.15313491 -0.14994845 -0.14405832 -0.14038906 -0.13797507 -0.14212713 -0.12851223 -0.14598951 -0.14009938 -0.13720259 -0.14193401 -0.13710603 -0.13034686 -0.14164433 -0.15284523 -0.1438652 -0.13758883 -0.14492735 -0.13237461 -0.1484035 -0.13749227 -0.13681635 -0.14096841 -0.12600169 -0.13015375 -0.13324365 -0.14241681 -0.15352115 -0.13391957 -0.12542233 -0.13536796 -0.1357542 -0.13420925 -0.15236244 -0.136237 -0.14318928 -0.136237 -0.14019594 -0.12677416 -0.13227805 -0.1316987 -0.11982188 -0.128126 -0.1316987 -0.1276432 -0.13894066 -0.12339459 -0.14328584 -0.136237 -0.12918815 -0.1343058 -0.12358771 -0.12387738 -0.1302503 -0.12426362 -0.1352714 -0.12271867 -0.12754664 -0.13295397 -0.12194619 -0.12368426 -0.13556108 -0.13343677 -0.12378082 -0.13343677 -0.16858444 -0.12783632 -0.11972532 -0.1240705 -0.11006937 -0.12020812 -0.11064873 -0.12213931 -0.11016593 -0.12629136 -0.12349115 -0.14927253 -0.14077529 -0.13488516 -0.12725696 -0.12600169 -0.10920034 -0.13160214 -0.11084185 -0.12368426 -0.11750446 -0.12165651 -0.091143705 -0.11489735 -0.1047586 -0.11441455 -0.11933909 -0.12291179 -0.10031686 -0.12474642 -0.10977969 -0.1316987 -0.1245533 -0.12551889 -0.13140902 -0.12996063 -0.11422143 -0.1383613 -0.10485516 -0.11383519 -0.096068241 -0.12735352 -0.10968313 -0.12976751 -0.10640011 -0.12300835 -0.12484298 -0.13160214 -0.11566982 -0.1174079 -0.11509047 -0.11624918 -0.10591731 -0.11151776 -0.10891066 -0.12822255 -0.11769757 -0.1321815 -0.13923034 -0.13700947 -0.1343058 -0.13305053 -0.11470423 -0.12484298 -0.11557326 -0.12262211 -0.1123868 -0.10050998 -0.10862098 -0.11373863 -0.10668979 -0.11895285 -0.12493954 -0.10437236 -0.11489735 -0.10678635 -0.11103497 -0.089791872 -0.12127028 -0.098675348 -0.1011859 -0.10331021 -0.10977969 -0.095682003 -0.10871754 -0.093943931 -0.10369644 -0.095971681 -0.11006937 -0.10060654 -0.10891066 -0.085157014 -0.097130395 -0.087860681 -0.096551038 -0.097902872 -0.10292397 -0.096551038 -0.094330169 -0.082549907 -0.096840717 -0.08003936 -0.11074529 -0.086798526 -0.11113153 -0.090757467 -0.11180744 -0.08197055 -0.10485516 -0.075211383 -0.085350133 -0.074632026 -0.10688291 -0.085157014 -0.1092969 -0.083322383 -0.092302419 -0.075694181 -0.097033836 -0.079363443 -0.099351265 -0.066907264 -0.086701967 -0.071059324 |
|
|
ADC and/or SHARC-DSP spurious effect
Started by ●June 24, 2004
Reply by ●June 24, 20042004-06-24
|
On Thu, 24 Jun 2004, Bernhard Holzmayer wrote: > > for too long already, I'm fighting against a spurious peak on a > signal which comes from an AD1836 SigmaDeltaConverter. > > I hope that somebody can help me to trace this down or at > least find out where I'd look for the origin. > > Basically I have a noisy signal with very low levels . > This signal is converted and brought into a SHARC 21161 DSP. > Method is the same as in the talkthru example ADI provides. > > Sample rate is 48kS, hardware is EZ-LITE-Board. > > Depending on external interrupts and a timer based processing, > a resulting signal stream leaves the DSP, again via SPORT link. > > For debuggin purposes I switched the processing off, except > amplification by a factor of 800 to make the issue visible on a > scope. > > In software, there's the DMA interrupt (SP0) which transports the > signal streams in and out. > Then there's an external interrupt IRQ1, which is triggered once per > millisecond. > Third, there's a periodic timer (TMZL), which is retriggered every > 30ms. > > The strange thing is, that the spurious peak appears exactly at the > frequency of the timer, this is every 30ms. > If I change the timer frequency, the peak changes its frequency > accordingly. If I switch the timer off, the peak fades. > > I cut away all processing which directly influences the signal, > so that the signal is only amplified and passed through the ISR. > > Most of the othe processing, I did move it to a main loop, so that > the three ISRs would cause least interference. > > Strange thing is that the problem is not only on the output, > which might mean it has to do with program failures like faulty > memory or register sharing. Instead, the fault seems to enter from > the ADC (or at least from DMA). > > If I invert the signal directly after it comes in, peak is inverted, > too. > > However, despite what I try, the peak persists. > > Does anybody have similar experiences? > There should be an explanation, though I can't find it. > > Quite a little in despair, eagerly waiting for some hints... I had to plot the data to see it, it's not that far out of line with your data. I'd say it has to be some kind of current draw, when the processor hits the 30ms timer it must be hitting your power supply which hits your ADC which stomps on your data. Put in bigger bypass caps around the ADC and the processor, and just for the hell of it put more capacitance on your power supply leads going into the board. It's real data, not software. Patience, persistence, truth, Dr. mike |
Reply by ●June 25, 20042004-06-25
|
I agree with Dr. Mike, it sure sounds like the glitch is real. The other thing you can do is assess what's happening as a result of the 30 ms interrupt. Are you writing to FLASH or doing something that causes a step change to your power consumption (blinking LEDs, turning on line drivers, that kind of thing). If so, try not doing those things or at least try not to do things that cause the power demands to change suddenly. You might need to get real cute and try to do the "bad" thing when you are not sampling the converter (such as sync'ing it to the "conversion done" signal), but that will only work if things can settle down before the next conversion starts -- at 48 kHz sample rate though, you do have some time. |
|
|
Reply by ●June 28, 20042004-06-28
|
This may be another effect, but I will pass on the experience anyway. I am using the ADSP21161 with the AD1839 and the DSP internal timer. I saw 2 unwanted effects 1) The timer output pin had a 1 count jitter on it and 2) My sinewave generation would sometimes have an audible "glitch" at regular intervals. In the end the solution was found by luck, just by switching Visual DSP from debug to release mode. Maybe that can help others who get the same problem. Cheers, Steve --- In , k.hansen@p... wrote: > I agree with Dr. Mike, it sure sounds like the glitch is real. The other > thing you can do is assess what's happening as a result of the 30 ms > interrupt. Are you writing to FLASH or doing something that causes a step > change to your power consumption (blinking LEDs, turning on line drivers, > that kind of thing). If so, try not doing those things or at least try not > to do things that cause the power demands to change suddenly. You might > need to get real cute and try to do the "bad" thing when you are not > sampling the converter (such as sync'ing it to the "conversion done" > signal), but that will only work if things can settle down before the next > conversion starts -- at 48 kHz sample rate though, you do have some time. |
|
|
Reply by ●June 29, 20042004-06-29
|
On Monday 28 June 2004 23:18, steveoid53 wrote: > This may be another effect, but I will pass on the experience > anyway. > > I am using the ADSP21161 with the AD1839 and the DSP internal > timer. I saw 2 unwanted effects 1) The timer output pin had a 1 > count jitter on it and 2) My sinewave generation would sometimes > have an audible "glitch" at regular intervals. > > In the end the solution was found by luck, just by switching > Visual DSP from debug to release mode. > > Maybe that can help others who get the same problem. > > Cheers, Steve > Hi Steve, thanks for sharing this. Indeed, this looks similar - and maybe it is. Did you investigate the differences between debug and release mode, then? As I understand VDSP, there's no generic difference. Instead, it's only that users can set up two (or even more) distinct setups and just have a fancy switch to toggle between them. I usually use it to enable/disable optimization levels, because highly optimized code is difficult to trace. If that's what you do by toggling between debug and release mode, there's a chance, that it has to do with SIMD side effects, or alike spurious effects. If you have the code still at hand, and it's of further interest for you, it might be helpful to find out how both setups differ. Bernhard |
