Re: [Discuss-gnuradio] some progress and some questions

[MiB]

Hi This is marcel / sweden / SM0UGT - I wonder of someone have thought on a
conjuctive sdr design
for the GNUradio project? I know Matt has - I self have done some work in
the area. I have a very strong
concept i am working on. I need some math people to work on things.




----- Original Message ----- 
From: "Matt Ettus" <address@hidden>
To: "Joseph DiVerdi" <address@hidden>
Cc: <address@hidden>
Sent: Thursday, July 10, 2003 9:03 PM
Subject: Re: [Discuss-gnuradio] some progress and some questions


> Quoting Joseph DiVerdi <address@hidden>:
>
> > I am pleased to report some good progress in setting up and using
gnuradio
> > which has, in turn, spawned a few questions. In no particular order:
>
> Great!
>
> > aumix and aumix-X11 are pretty snappy and useful programs for
controlling
> > sound cards under ncurses and X windows environments, respectively. I've
used
> > them to "tame" my sound card so it behaves sensibly (mostly). Source is
> > readily available so inclusion of initialization and control code into
> > home-rolled applications is an option.
>
> Yes, I'd like to get that code somehow into GNU Radio.  It would make
things
> much more convenient.  In the mean time, I think you can save a setup file
from
> the mixer once you have it as you like, and then send that file back to
it, so
> you don't have to do it manually every time.
>
> > The "home-rolled" VLF complex frequency translator (CFT) is doing its
job
> > very nicely. FWIW, it translates a 20-60kHz (balanced) input into a
complex
> > pair of (balanced) signals 0-20kHz (although the sound card is
single-ended).
> > The LO generator is a crystal controlled, TTL walking ring counter with
final
> > resynchronizer providing four phases of 40kHz which deliver accurate,
> > balanced, quadrature drive to the mixers. The LO generator can operate
up to
> > 40MHz without modification. Higher LOs are available with this scheme
using
> > different logic families. The mixers are commutating mixers based on
CMOS
> > 4PST switches (fully balanced, of course). These mixers are limited to
> > operation to only a few MHz but other mixers are suitable for higher
> > frequencies. A single pole of low pass filtering at 25kHz on each
channel
> > limits the signals emitted from the XFT and delivered to the sound card.
>
> Sounds like a very nice clean design.  Perhaps a posted schematic on Wiki
would
> help others in the same situation.
>
> > I've stuck with the straight forward scheme of using the examples
directory
> > as my working directory and modifying Makefile.am when new programs are
> > added. It works well and is stable.
>
> Good, although I must again suggest you try using Python.  It will make
your
> life much easier.  Right now not all blocks are wrapped into Python, and
there
> really isn't a good fft or oscope block yet, but once those are there, I
can't
> see a reason not to use python.
>
> > It looks like
> > some of the functionality that I need is not available, e.g., FT
processing
> > without an attached display (GrFFTSink without the display),
>
> Very true.  This should be coming soon, especially now that we are looking
to do
> the displays in Python, and to deprecate the use of Qt in favor of
Wxwindows.
>
> > real<->polar
> > representation conversion,
>
> That should [partially] be there.  You can use GrReal, GrImag, and
GrMagnitude.
> GrPhase is not there yet, but should be simple, and a block to create
complex
> numbers is not there yet.  Also, take a look at GrArbFunc.  I find it very
> useful, but there are no examples of its use.  Let me know if you have
problems
> with it.
>
> > frequency domain "scope" display.
>
> Not sure what you mean here.  Not GrFFTSink?
>
> > Alternately, I
> > just haven't yet found them yet. I will try my hand at writing some
modules
> > and offering them to the repository.
>
> That would be great.  I can offer suggestions and help if you need it.
>
> > Is there a "road map" noting the characteristics of the various
families,
> > e.g., Gr vs. Vr, gr_, qa_, atsc_, etc.?
>
> Gr stands for GNU Radio, and all the new blocks we create fall in that
category.
>
> Vr blocks are originally from the old pSpectra/Spectrumware code.  Any
ones that
> you see used in the examples directory should be fine, but many of those
not
> used (even those not in a "needs-work" directory may not work anymore due
to
> api changes.  Point these out if you need to use one.
>
> qa_ files are for QA or quality assurance.  The idea is that you would
write a
> corresponding qa file to perform unit testing on each regular file to
automate
> the testing process.  There aren't always qa_ files for each other file
that
> there should be.  I haven't been good about keeping up with this.
>
> gr_ files are more library functions, but are not gnuradio blocks.  Very
often,
> these are simply wrapped in a corresponding Gr file (see the GrConvertSF
and
> gr_convert_SF files for example).  The atsc_ files are similar, except
they are
> mostly specific to ATSC (HDTV), and might need some changes to make them
more
> generally useful.
>
> Matt
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/discuss-gnuradio
>