Lin,
To clarify my earlier post, the processing delay of the DSP does not
exactly indicate the amount of "work" the DSP has to do (although it
is related). An N-tap filter has to wait N sample times before it
delivers its first "correct" output. That's where the filter delay
mostly comes from, I expect. Of course, the DSP processor has to be
fast enough to handle the necessary computations (~N multiply &
accumulate ops for the bandpass filters) before the next sample comes
along.
I did not check the AN, NR, etc. That would be interesting.
I did find that for AM & FM modes, the receiver delay was 6 ms,
independent of tap number. These modes use a simpler filtering scheme,
where the tap number setting may not be used. (See Doug Smith's
overview at http://www.doug-smith.net/kf6dx1.pdf .)
73 Martin AA6E
On 3/17/06, Lin Davis <linbdavis@earthlink.net> wrote:
> For the 1.xxx code, I was wondering if the DSP was having over-run issues; the
> time it took the DSP to do all the calculations per sample was longer than the
> sample period. But I suppose that would have been caught early on...
>
> Did you happen to notice if the delay increase with one or more of the other
> DSP
> functions on, such as NB, NR and AN?
>
>
> 73,
> Lin
> WB1AIW
>
> Martin, AA6E wrote:
>
> > Besides, the DSP workload happens in the DSP (Sharc) processors, not
> > the Dragonball control processor. So, fancy filtering, NR, etc.
> > should not impact the user control response, at least to first order.
> > The sweep is the only function where actual receive data (from DSP
> > land) ends up on the LCD (via Dragonball), apart from the SubRx
> > S-meter.
> >
> > If you measure the receiver delay, you will see the effect of changing
> > the DSP "workload" as you change the number of filter taps. This
> > delay is one factor limiting QSK performance, for example. My tests
> > on the Orion (1.372) show the delay is 14 ms at 199 taps, and 8 ms at
> > 32 taps for CW and SSB modes.
> >
> > There should be a lot of unused Dragonball CPU power on the O 2,
> > especially, that could be used for signal analysis, modulation
> > monitors, and what have you. All you need is software developer time
> > -- but that's a scarce commodity. (Another argument for an open source
> > development program?)
> >
> > 73 Martin AA6E
> >
>
>
> _______________________________________________
> TenTec mailing list
> TenTec@contesting.com
> http://lists.contesting.com/mailman/listinfo/tentec
>
--
martin.ewing@gmail.com - Ask me if you'd like a free Google Mail account
http://blog.aa6e.net
_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec
|