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
|