[hpsdr] Future projects?

[Naylor Jonathan]

This is a collected reply to points made to me about my ideas. I'm
sorry if I've missed out anyone's comments.
 
On a data transfer protocol:
 
Thank you for the link to netjack, I had seen it a while ago but
couldn't remember it's name. The fact that it already plugs into Jack
is a good start, for my part I'd also implement the protocol within my
programs so they can run standalone, which is an issue on Windows where
Jack currently doesn't exist. I'll look at netjack in more detail, and
see if it can be used as-is or whether it needs some form of upgrading
for our needs.
 
A comment was made about making frequency domain information available,
I disagree. The problem comes down to what sort of frequency
information? If we assume tha output of an FFT, which we use for the
pretty graphics on an SDR console, then it really isn't good enough.
Different programs need different information, for example a program
for VLF would require FFT bins down to the mHz level, while WSJT
requires 6 Hz bins. Then the question exists of how many FFT's to
compute per second. For data reception, if an FFT is used, typically it
is optimal to align the FFT calculation with the beginning of each
symbol and to have the FFT size match the parameters of the signal. So
I would strongly oppose the shipping of frequency information over the
network, instead provide the raw audio so that the receiving
application can do with it what it likes, which may not require an FFT
at all.
 
On digital audio:
 
Indeed there are a lot of codecs around, even an open source version of
AAC which is the DRM standard for voice. It's legality is questionable
unfortunately. By careful design it is easy to make the codec
pluggable, and potentially have the choice of many.
 
Most of the building blocks for such a system exist already, either as
classes written by myself for UWSDR or WS-Tools, or as libraries. I
looked into doing digital audio some time ago, and although I didn't
actually produce anything, I did find a reasonable amount of
documenation from people like G4GUO about how he did it. The basic
building blocks are (I think):
 
Link establishment and control (the bit I know least about)
Audio mixer (easy, exists)
FFT (easy, exists)
FEC (easy, exists)
Codec(s) (easy, exists)
 
The signal would be OFDM, with the phase of individual carriers being
detected by the FFT, and presumably produced by an IFFT. I need to look
into that more.
 
The extras like interfacing to audio devices exist already and can be
reused. In UWSDR I use a common interface so it's possible to have
input/output to a WAV file, a SoundCard or Jack and the choice can
either be made at compile or run-time. Initially output of the software
could be to WAV files for example, and they could be processed to add
noise, QSB, frequency shifts etc. Most of these exist within my old
WS-Tools project.
 
Frank Brickle AB2KT gave a very interesting lecture at the TAPR DCC
last year about identifying Link Establishment data, and I hope we can
build on that. I may have it all wrong though, I was very jet-lagged at
the time.
 
Is anyone interested in joining me on this project? It would be under
the GPL and I'd be happy to help out. I'm a whiz with wxWidgets to
provide a cross platform system, and many of the interfacing elements
can be lifted from the UWSDR project. I have a dormant Yahoo group
(DSPRADIODEV) which could be used to reduce the noise on the other
mailing lists.
 
Jonathan  ON/G4KLX



 
____________________________________________________________________________________
Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

 1173696727.0