[linrad] Re: 'Linrad'-philosophy (future features)

[<leif@xxxxxxxxxx>]

> Thanks for the comments on the audio aspects. My remarks
> regarding the 192 kHz realizations were in relation to the
> Abit IC7.
Yes, I understood that - and my comments were for that particular
hardware:-)

> Personally I have worked with 2 x 3 MHz base-band
> sampling instruments already in 1990, so there is indeed no
> inherent difficulty with I/Q-receivers for this limited range.
No, but for Linrad the first fft will overload the CPU at some point
but I think modern computers could do 2x250 kHz easily.

> The only practical issue to be remembered is, that the wider
> the bandwidth, the more chance there is for an utterly strong
> signal to enter the pass-band, thus challenging the weakest
> signals among the "crowd".
Absolutely.
.
.
.
> Also it is true that the "dithering" may be able to cover
> certain aberrations of the sampling. Actually an intriguing
> question is whether the 'Linrad'-algorithms would be able to
> correct occasional erratic sampling (I mean isolated offsets).
Not particularly well at the present time. It depends on
the characteristics of the hardware because that affects
the digital filter that compensates for the frequency response
of the hardwar. If no anti-alias filter is used or if an extreme
filter as in the WSE units is used, the frequency response
is nearly flat. With an ordinary anti-alias filter that is intended
to protect the A/D from signals just outside the passband,
the flat region may be as small as 60% and then the calibration
routine could be used to extend the response which would lead
to incorrect shape (oscillations) on a single sample error.

Now, isolated saturation points typically mean the peak of a really
strong interference pulse and some error at the peak is not
really a problem. More problematic is periodic saturations. They
generate false frequencies and render the rx practically useless.
I am pretty sure one could make algorithms that handle such
problems pretty well but I did not put any effort in that direction
since an attenuator at the front end is equally good. Any station
on an amateur band that might saturate a good soundcard emits
noise sidebands that are high above the internal noise floor of
a Linrad system (the AD) so an attenuator will reduce both S and N
and leave S/N unchanged. A good operator would have to be quick
switching the attenuator on/off as the strong signal goes on and
off though;-)


> To be more specific: 'Linrad' uses a subtraction scheme to
> eliminate spike-noise. Due to the limited bandwidth even a
> very short spike will be elongated over multiple samples.
Not really. Optimised hardware uses nearly the full bandwidth.
You get about 92 kHz flat bandwidth with the WSE units when
Delta44 samples at 96 kHz for example.

> Now, if the motherboard would induce an interfering spike
> to ONE isolated sample, so that it would be offset by say
> a value 489 (out of 32768, or whatever the max. scale is),
> would 'Linrad' be able to subtract this error already now,
> or could it be implemented?
See above.

> I see this as a very important
> philosophical/practical question/issue (relating to real
> reception, given the imperfection of all series-produced
> equipment). This may not be a priority issue, but indeed
> a very funny/serious side-track for product development.
Yes - but not for isolated events. The real problem is for
example HF bands with AM stations every 5 kHz. When a few
carriers are really strong their amplitudes will add
periodically and cause periodic overflows. I am sure such a
problem could be handled pretty well:-)

> As such I do not think that the IC7 is "properly" designed,
> as a possible 24 kHz limitation still allows the appearance
> of sampling aliases of the out-of-band input spectra....
What did you do with this card? Did you set it to 192 kHz
with Linrad-01.33 and then fed it with an audio generator?
Did a signal at 26 kHz look as if it were at 22 kHz?

Maybe your device driver has a resampling routine like the
one OSS introduced recently? Older versions of Linrad are
unaware of that and a hardware that can do 48 kHz only would
answer it can do 192 kHz because the old specification of OSS
said one can interrogate the true hardware characteristics
by asking the device driver. Nowadays one has to use
the COOKEDMODE option to get the true answer from OSS.
I have no idea how ALSA behaves in this respect.

If you really see aliasing at 24 kHz, your soundcard
(which most certainly samples in the MHz region) makes
a downconversion to 48kHz with an appropriate anti-
aliasing filter which means that 26 kHz will look as
it were 22 kHz - but attenuated by perhaps 6 dB.
The resampling in the device driver would just interpolate
the data points and anything above 24 kHz is just
false signals;-)


> I still need to study quite a lot to be able to use the
> various audio-mixers within Linux. So, the line-input of
> the IC7 will possibly get its turn one of these days.
>
> Actually it has not been all "virtual"-audio over here,
> but I have processed the output of a Yaesu FT-990 on a
> few occasions recently (and with very impressive results).
>
> Given the inability to choose 1-channel input on some of
> the integrated audio, I have fed the signal in-phase into
> both I and Q channels. Question: is 'Linrad' able to do
> the noise-cancelling when both (I and Q) signals are
> identical?
You should set up the system for two RX channels with real data.
You will find that everything has the same polarisation:-)

Then everything will work perfectly normal with two channels
of real-valued data. The combined signal from both channels
will have S increased by 6 dB (double voltages) but the
noise will increase by 3 dB only since the noise from the
soundcard is uncorrellated between the channels for a 3 dB
dynamic range improvement:-)

The orthogonal channel will show the noise from the soundcards
only since signals cancel as well as noise originating in the
antenna.

73

Leif / SM5BSZ





#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL