[hpsdr] Panadapter scrolling in PowerSDR...

[n3evl]

The variation in user experiences is interesting.  In my case, the only 
thing that changed was the version of PowerSDR.  Based on that I was 
concluding that the changes in the display to accommodate some of the 
new features must have been responsible.  It seems unlikely to be a cpu 
or graphics performance issue since neither of these have changed and 
I've never noticed any performance issues on this particular machine. 
It's odd that various users have had different experiences in this area.

Pete, N3EVL

On 3/27/2012 10:43 PM, wbr at verizon.net wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
>   Hello guys,   I noticed this while using a P4 2.4GHz machine.
>    Noticed both with Windows 7 (32bit) and Windows XP.   I've since upgraded to a
> i7 Quad Core Sandy Bridge 3.4 GHz and I've not noticed this effect.
> The latency is much less and the processor hardly feels the load.
> Where as I was seeing the P4 maxed out at 100% almost all the time
> The new i7 is showing only 8 to 10% and very occasionally 12% processor load.
> I don't know if the difference between 32 bit and 64 bit made the biggest
> difference or not.  I had 2GB of ram in old machine, and now have 16 GB in
> new machine.  Everything is lovely.
>
> 73, Bill, wf4r
>
>
> On 03/27/12, Glenn Thomas wrote:
>
> ***** High Performance Software Defined Radio Discussion List *****
>
> Here's a datapoint that may or may not be relevant.
>
> I've been running PowerSDR for several years over several different
> versions on my SDR-1000, followed by my Flex-3000. The behavior
> described has been present in all versions of the Flex software I've
> used, from v1.8.x through v2.3.5.
>
> My assumption is that as I tune, the sum being made to compute the
> average level in each frequency bin doesn't have time to collect the
> requisite number of samples in each bin while I'm tuning. The method of
> tuning (wheel or 'grab&  grope') doesn't seem to matter. The speed of
> tuning does.
>
> If the computation of the average for each bin assumes a fixed number of
> samples, the resulting value with fewer samples will look lower,
> depending on how many samples were actually added to each bin. Assuming
> a fixed number of samples instead of keeping a separate count for each
> bin would be computationally more efficient - my assumption is that is
> why this effect on the display is seen.
>
> I don't 'wheel tune' very much with the SDR. I find the 'point and
> shoot' method, coupled with an appropriate frequency step size and
> display size, to be much more effective.
>
> If this display calculation does not depend on which hardware is being
> serviced (Flex or HPSDR), I would expect to see the same behavior with
> PSDR/HPSDR that I do with PSDR/Flex.
>
> 73 de Glenn WB6W
>
> On 3/21/2012 3:44 PM, n3evl wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>>
>>
>> Re: PowerSDR v 2.2.3 (W5WC - 2/10/12) RX2 versus 2.2.3 (B) (W5WC -
>> 9/25/11)
>>
>> I've noticed an apparent change in the behavior of the Panadapter when
>> scrolling left or right when tuning.
>>
>> I typically run the Panadapter with some amount of averaging (750mS)
>> and typically use a 1KHz or 500Hz step size when using SSB.
>>
>> I've noticed when tuning/scrolling e.g. using the mouse wheel, that
>> the signal levels across the display area momentarily drop making it
>> hard to estimate if you've moved the mouse wheel enough clicks to
>> bring the signal of interest into the passband - so I find myself
>> overshooting or doing click-stop-click-stop to determine where the
>> signal now is relative to the passband. If I turn averaging off, the
>> real-time response to tuning adjustments is better.
>>
>> I've experimented with different amounts of averaging time but cannot
>> find a suitable value.
>>
>> I've compared behavior with the older version of PowerSDR mentioned
>> above and the behavior is quite different.
>>
>> I'm wondering if something changed in how the display is refreshed to
>> accommodate the 2nd RX window (although this behavior is apparent
>> even when RX2 is not activated.
>>
>> I'm using WinXP SP3, single Mercury, Penelope, Metis, Excalibur -
>> usual suspects.
>>
>> 73, Pete, N3EVL
>


 1332962435.0