Hi Mike, Alberto has optimised the sampling to make best use for each QRSS
speed. In my experience the only reason for choosing something different has
to do with the bandwidth of the receive screen. I rarely use a longer dot
mode than 30 sec, but I do select the "slow" option. This compromise allows
me to cover the "T/A watering hole" an does not give me a overwhelming
number of screens to scan next morning (its about an hour per screen). BUT
in theory I am thowing away a S/N enhancement because the longer dot modes
would use a higher resolution or narrower bandwidth. Likewise using 120sec
mode on faster speeds is "more sensitive" but the faster information cannot
be read.
The optimum DFCW shift is actually has a lot to do with as John says "how it
looks" The shift needs to be several times the line width as a minimum.
However, if the shift is made "as wide as a dash is long" the two streams
start to become visually detached and it is not so easy to decode a noisy
signal. Personally I do not find any advantage in the inter-element
spaces.....but then I have been copying this stuff since Rik first flew the
idea. I certainly do not find any advantage in what little I have seen of
Castle, in fact it may be sub-optimum...... throwing away some of the power
for increased speed.
Cheers de Alan G3NYK
----- Original Message -----
From: Mike Dennison <[email protected]>
To: <[email protected]>
Sent: 29 March 2007 14:26
Subject: LF: Argo settings
> When receiving a DX signal, many people use a faster Argo screen than
> the transmitted dot length. For instance, setting Argo to 60s dot
> when receiving a QRSS120 signal. But this is not common practice with
> more local contacts with faster speeds.
>
> Is this effect because Argo does not work well at very slow speeds?
> Or is it something to do with DX propagation? Is it that Argo has to
> compromise between best S/N on a dash and the dot, and the dot loses
> out (which would affect DFCW worst)? Do other people experience this
> effect on other spectrograms (eg SpecLab)?
>
> I am not attempting to rubbish any software. I am just trying to
> understand why this deliberate mis-match of Tx and Rx speeds is done
> in practice when theory suggests that it should make things worse.
>
> Mike, G3XDV
> ==========
>
>
>
>
|
