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

[Joseph DiVerdi]

At 12:03 PM -0700 7/10/2003, Matt Ettus wrote:
>Quoting Joseph DiVerdi <address@hidden>:
>
>> 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.

Quite right. The setup file is very helpful and supportive in "brain-cramp" 
situations - like when one (me?) forgets the previously determined settings.

><snip>
>Sounds like a very nice clean design.  Perhaps a posted schematic on Wiki would
>help others in the same situation.

Will comply with design details on Wiki.

>> 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.

I will migrate to Python in the future but right now I'm holding off because 
I'm up to my eyeballs learning C++. :)

>> 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.

Excellent, I was looking at GrMagnitude and GrArbFunc as code samples for 
writing GrPhase (with an optional embedded "unwrap at 2*pi"). I will be in 
touch shortly - one way or the other.

>> frequency domain "scope" display.
>
>Not sure what you mean here.  Not GrFFTSink?

I mean GrFFTSink without the display. GrSimpleScope has some assumptions in it 
about displaying time domain data. I (humbly) think that a bit more general 
purpose data display would be rather helpful and plan to look into it.

>> 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.

Thanks for the welcome. I'm certain I'll need some help.

>> 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.
><snip>

Thanks for the helpful orientation.
>
>Matt

Best regards,
Joseph
-- 
Joseph A. DiVerdi, Ph.D., M.B.A.          
http://xtrsystems.com/           970.980.5868 (voice) 
PGP Key ID: 0xD50A9E33