[Lf] LF Remote Receiver

[Terry Fox]

Frank:
This morning I was thinking the very same thing, sounds good.  Here is another
idea.  How about using a low-end Pentium (I can probably supply it).  Rather
than using a hardware filter, how about implementing a larger FIR filter on the
digitized audio from the sound card.  Then take the resulting digital data and
sub-sample it.  I think you can sub-sample it because the actual signal will be
narrower than say 1kHz where the filter is.  The resulting data can be
compressed and sent out the PC as digitized audio, but NOT the actual FFT
data.  The data would be received and processed at the receive end.

The reason for the FIR filter is that you should be able to build a very-flat
but also very steep-skirted filter with a many-tap FIR.  The Pentium should be
able to handle an 80-tap or so FIR.

Vittorio, I sort of agree with your earlier comments about digitized LF audio
having significant digitized noise and therefore reducing a lossless
compression scheme's effectiveness.  We can probably still get some efficiency
with run-length or other system.  I was most concerned about NOT using any
lossy compression, as that would probably destroy enough of the signal before
you got a chance to perform any real calculations on it.

Frank Gentges wrote:

> Vittorio,
>
> Your numbers look attractive.  The filter seems to be growing here to 2
> chips and 54 1% resistors.   If we can do it in the processor for free
> that may be a key advantage.  You are suggesting an FFT, a removal of
> unwanted spectral lines and then an inverse FFT if I understand. I am
> note sure a 1000 Hz vs a 1002.2 Hz sample rate is an issue as long as
> you use it on both ends.  Since we will use a sound card on both ends we
> can stuff the sample into the D/A 11 times at the 11025 rate.
>
> I am thinking about transmitting data both ways via a PPP I/P type
> connection to make an internet connection simple.  We are seeing a lot
> of DSL installations now with PPP over Ethernet so it looks like PPP
> will be around a while.
>
> We can also use a direct modem connection and PPP I/P may be the best
> way to go there also.  We need to carry the RX320 control commands from
> the base station to the remote. That is a 1200 bit per second link and
> usually is idle unless the receiver is being tuned or adjusted. We have
> a small amount of signal strength data to come from the remote along
> with the digitized sound.
>
> The third method would use an RF link using VHF FM in place of the
> modem.  The remote transmitter would come up on the air in response to a
> command from the base station.
>
> In addition to the digitized narrowband signal, we could digitize a
> block of wideband stuff and transfer it in non real time for playback.
> This could let us listen to a sample of the European LF broadcast
> signals.  We have had armchair copy at times at Nags Head on them in the
> winter and spring.
>
> I want to redirect the RX320 data port at the base station so the RX320
> control may be via any of the RX320 control programs.  The base station
> will most likely be running a flavor of the Windows  operating system in
> order to run these programs.
>
> The remote station will run Linux so we don't have to drive down and
> clear blue screens of death and reboot every few days.  The remote
> should run for months without attention once we get it debugged.  My
> local linux machine has now been up for 217 day without a reboot.
>
> With a standard internet connection we can place these remotes anywhere
> in the world where we can get a decent internet connection.  A 28.8
> connection should do fine.
>
> There is nothing keeping us from using this on MW or HF either.  N2JEU
> has an RX320 web radio but it uses audio compression and control is
> limited although many can listen at the same time. We are looking for
> something a bit different.
>
> Your comments are providing some good insight and are most helpful.
>
> Frank
>
> Vittorio De Tomasi wrote:
> >
> > Frank,
> >
> > I think that 14 USD are too much for a bandpass filter: a DSP solution
> > is really a free lunch!
> >  You need about 2N(log2(2N) + 1) operations to do the whole filtering
> > process with FFT. Let us say you sample at 11,025 samples/s, and you use
> > a buffer of 1024 samples. It follows you need about 25,000 operations
> > for each buffer to do the filtering, i.e. you can go real time with a
> > system that is able to deliver 250 kFLOPs (if I'm not wrong).
> >
> > Since 1002.2 Hz is a bit odd sampling rate, you can interpolate down to
> > 1000 Hz using nearest-neighbour interpolation (this usually results in
> > some THD, but it needs only a look-up operation) or linear interpolation
> > spending about 3 FLOP for each emitted sample.
> >
> > However I have a question: how do you think to transmit data ? Remember
> > that if you send 16 bit samples, you need to find a way to synch them,
> > otherwise you could put together the wrong sequence on the other side...
> > probably it is better to use some transport layer like TCP/IP: anybody
> > there willing to hack KA9Q code ?!?
> >
> > Vittorio
> > --
> > *************************************************************************
> > Vittorio De Tomasi         ik2czl at 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)
>
> --
> Frank Gentges
> K0BRA, ex AK4R, W3FGL
> Check out our LF web page at <http://amrad.org/projects/lf>
>
> _______________________________________________
> lf mailing list
> lf at amrad.org
> http://www.amrad.org/mailman/listinfo/lf