[Lf] Re: lf digest, Vol 1 #146 - 1 msg
Frank Gentges
fgentges@mindspring.com
Sun, 25 Jun 2000 21:07:51 -0400
Vittorio et al,
I am hoping there is a free lunch out there in the compression schemes
that are becoming so common. Your reply, another reply from David
Borden (AMRAD Texas), and my own experimentation lead me to believe that
MP3 is too speech specific and it does "strange things" to weak LF
signals. I suspect the others to a lesser degree will also introduce
bad artifacts into the signal but also compress less. "Less tasty and
less nutrition."
Doing a strong job of getting down to nyquist on a band narrowed signal
seems the most likely way to get there now.
Your suggestion of remotely computing the spectrogram and then
transmitting the "spectrum picture" had occurred to me. For now I think
even reducing bandwidth to 200 Hz to meet our goals would give more
flexibility at the local site without losing the signal.
My current thinking is to use a 750 Hz BFO frequency. Then filter the
audio data through a 600-900 Hz FIR bandpass filter to cut energy way
down, (60 db?) below 500 and above 1000 Hz.
Initially sample this audio at 2000 samples per second to go into the
digital FIR filter. This is based on there being no energy above 1000
Hz to avoid that alias.
Then we have a 2000 samples per second rate of the output data stream of
the FIR. We take every other FIR output sample to achieve a 1000 sample
per second rate and throw the rest on the floor as they have no new
information. We would have a mirror image alias on the other side of
500 Hz that would just be ignored or filtered out with a high pass
filter.
That gets us 16000 bits per second if we transmit 16 bit samples. The
FIR filter may be a bit too much computation for a PC but I don't have
experience with that yet.
Any thoughts anyone? Does this work? Can we do it in background on a
486 "Dumpster Grade" Linux PC or should we build a dedicated filter?
Can the sound card be run at 2000 samples per second under Linux or do
we take every nth sample?
Thanks Vittorio for helping us kick the ball forward on this.
Frank
Vittorio De Tomasi wrote:
>
> Hi Frank and the list,
>
> here are my opinions on your problem:
>
> if you want to digitize a receiver outbut and still be able to detect
> very faint signals buried under the noise, forget about audio
> compression, like MP3, RA, GSM, and so on!
>
> The reason is quite simple: compression (as well as denoising!) is done
> designing a suitable mathematical model that is fitted to the signal.
> Best fit is obtained by minimizing the energy of the difference signal
> (input minus modeled signal): computationally efficient methods exist to
> compute the signal model that fits at its best the incoming data. The
> difference between input signal and the model is simply discarded, and
> the transmitted information is the one needed to build up the model.
>
> MP3 adds to the best fitting process a psychoacoustic model: suppose
> that you listen to a 1000 Hz signal. Now add a 1500 Hz signal, and
> increase its amplitude until you hear it. Turn it off, and do the same
> for a tone at 1010 Hz: you will need quite a larger amount of signal to
> become aware that the tone at 1010 Hz is played with the steady 1000 Hz
> tone. MP3 encoders recognize the presence of tone pairs, and apply
> dynamic compression, i.e. they use a coarser signal quantization when a
> weak tone is close to a strong one. Imagine this kind of processing
> applied to VLF signals....
>
> The best compression to do is Nyquist compression: if you have B Hz of
> bandwidth, sample them at a rate equal to 2B (maybe a little more, just
> to avoid aliasing), and use a suitable number of bits to get the needed
> dynamic range. So for a data stream of 16 kbit/s, you can transmit 500
> Hz of bandwidth with 16 bit (i.e. about 96 dB of dynamic range, not
> bad...).
>
> Amplitude data can be encoded into the data stream replacing say a
> sample every 16k, so getting an amplitude measurement every second. The
> "lost" sample will be silently ignored also by the most sophisticated
> DSP engine.
>
> However there is a more efficient method: why don't you simply transmit
> the frequency spectrum ?!? I suppose you have a two way data channel, so
> you can think of sending commands to the "DSP server" in order to
> transmit you the desired frequency slice. What do you think about this
> ?!?
>
> vy 73
>
> Vittorio IK2CZL
>
> > Today's Topics:
> >
> > 1. Digitized Audio (Frank Gentges)
> >
> > ------------------------------------------------------------------------
> >
> > Subject: [Lf] Digitized Audio
> > Date: Sat, 24 Jun 2000 20:02:20 -0400
> > From: Frank Gentges <fgentges@mindspring.com>
> > Organization: K0BRA
> > To: LF@AMRAD.org, tacos@AMRAD.org
> >
> > Hi,
> >
> > At tacos today I mentioned that I was looking for a good method to
> > digitize the 300 Hz bandwidth CW output of the RX320 to transmit
> > remotely at something around 16 kilobits per second. I have looked at a
> > few available options in WIN98 and at Xing's MP3 encoder.
> >
> > I would like to find the best option that will provide a good
> > spectrogram with Spectran at the remote end.
> >
> > If I were to set the RX320 BFO for a 250 Hz, then the band should extend
> > from 100 Hz to 100 + 300 = 400 Hz. But, the RX320 at 300 Hz bandwidth
> > has quite a bit of energy beyond 500 Hz and you can hear the beat note
> > come through zero which means significant artifacts could creep into the
> > spectrogram. Simply put, the 300 Hz bandwidth has quite a bit of
> > transition band beyond the 300 Hz edges before the signal is far enough
> > down to ignore.
> >
> > One option would be to set the BFO for a 1 kHz center frequency like we
> > do now for driving Spectran. The signal could be digitized and further
> > filtered digitally in real-time yielding a 16 kilobit per second
> > stream. A reverse process could then be used on the remote end. If
> > this could have limited processing load it could be done in the PC.
> > While we are at it we need to multiplex into the stream the RX320 signal
> > strength data, but lets not get ahead of ourselves.
> >
> > Another option would be to use a streaming audio process like MP3 or the
> > like to encode the audio. MP3 is an open specification and we should be
> > able to use it freely.
> >
> > RealAudio might be an option but it is proprietary and does not seem to
> > have a low rate option. Neither do we know the impact on Spectran of
> > its artifacts. It would be nice to know how much we might be missing
> > here.
> >
> > In the end, I would like to be able to put a remote RX320 and computer
> > anywhere in the world and with a modem based internet (or modem direct)
> > connection, be able to listen to the LF band.
> >
> > Any thoughts? Even better, any volunteers to work on this problem so we
> > can put your solution in our handbook?
> >
> > Frank
> > --
> > Frank Gentges
> > K0BRA, ex AK4R, W3FGL
> > Check out our LF web page at <http://amrad.org/projects/lf>
> >
> > ------------------------------------------------------------------------
> > _______________________________________________
> > lf mailing list
> > lf@amrad.org
> > http://www.amrad.org/mailman/listinfo/lf
>
> --
> *************************************************************************
> Vittorio De Tomasi ik2czl@amsat.org
> Home page: http://space.tin.it/scienza/vdetomas
> My DSP page: http://www.freeyellow.com/members/padan
>
> "Wir muessen wissen; wir werden wissen" (David Hilbert)
>
> _______________________________________________
> lf mailing list
> lf@amrad.org
> http://www.amrad.org/mailman/listinfo/lf
--
Frank Gentges
K0BRA, ex AK4R, W3FGL
Check out our LF web page at <http://amrad.org/projects/lf>