Re: [Discuss-gnuradio] sparc <--> x86 data exchange

[Lamar Owen]

On Friday 16 December 2005 20:12, John Gilmore wrote:
>   *  GNU Radio should be processing data in the local machine's native
>      byte order and data format (e.g. IEEE float).  You should have to
>      explicitly tell it to do something about byte order (e.g. convert
>      samples to little-endian).

Agreed.

>   *  Any conversions we offer should say nothing about machine types

In my opinion, GNUradio should save files in one standard byte order 
irrespective of machine arch.  I'd nominate network byte order, as it's a 
standard of sorts.

> (My opinions on byte order come from having co-designed and maintained
> the "BFD" library that the GNU binutils use to read and write object
> files, which require pervasive and specific attention to byte order.
> We changed our byte-order API several times until we got it right and
> easy to use.)

Is this something that GNUradio could use at the low level, or is it too 
specific to binutils?

>   *  I'm hesitant to make GNU Radio depend on Yet Another random
>      library package like liboil.  Building it is already an exercise
>      in frustration, as is trying to package it for a distribution.

You ain't a kiddin'.  I'm working towards easy to install RPMs now; the real 
kicker is the FFTW single precision, as most distributions of FFTW aren't 
built that way.  But GNUradio is intensive software that is doing a complex 
job; complex software requires more other pieces than simple software (if, 
that is, the basic tenet of software reuse fostered by the GNU philosophy 
holds true).  

The GNUradio dependencies aren't as common as other packages' dependencies, 
that's all.  When I was maintaining the PostgreSQL RPM's, I had it much 
easier, but not because of the number of dependencies (PostgreSQL has a slew 
of them, too, in fact probably about twice what GNUradio does): PostgreSQL's 
dependencies (especially the build-time dependencies) were common ones. 

GNUradio's (well, the USRP's) need for sdcc, for instance, is pretty rare.  Or 
cppunit.  Or a couple other of the baseline packages required to build 
GNUradio.  So you end up distributing more packages that are configured more 
unusually than most already distributed packages.  The binaries won't require 
all those devel package, though, and, while I've not done the full analysis, 
it may not be too bad after all.  Just have to get time to focus for a couple 
of days to churn the RPM's out.

> Can't we skip some premature optimization and get back to making the
> program do real things that real people want to do?  I don't see the
> "obvious" GUI-operable scanners, recorders, radar screens, etc, that
> our capabilities are supposed to make it easy to create.

Chuck Swiger is doing a marvelous job on his stuff, but you're very right.  
The GUI's lack polish.  But GUI polish requires someone familiar with 
polishing GUI's - there's two great low level guys at the core here (Eric and 
Matt), but I don't know (just from my short exposure to them) if they are 
'GUI guys'.  The GUI isn't bad, by no means, but it isn't great either.  And, 
no, I'm not a GUI guy either, but I'm learning.

GNUradio is already developing a reputation as a toolkit, but not as a 
complete package, as opposed to the SpectraVue program distributed with the 
RFspace SDR-14.  SpectraVue makes the SDR-14 usable.  A SpectraVue for the 
USRP would be killer (won't happen from that source, obviously); all the 
pieces to make it happen exist now in the GNUradio core, wx-gui, etc classes.

And, as much as I hate saying this, an easy to install Windows version with a 
good GUI 'killer RF toolkit app' will be what we need to gain mainstream 
amateur radio/ amateur radio astronomy/ hobbyist (non-linux) acceptance.

> We're how 
> many years into this package?, and still re-re-rewriting the guts.

As a broadcast engineer by training, and after 14 years of experience, I am 
glad the gut work is still being done; the best GUI in the world without a 
stable foundation wouldn't, to use an old Appalachian expression, be worth a 
hill of beans.  

The fact is, GNUradio is a large piece of software, and a rather complex one 
to boot.  Getting the foundation right is important; the 2.6 code is looking 
real good, and I really like the flowgraph method of coding; just like radio 
breadboarding (which I have done, with far larger power levels at stake, in 
particular I wired up a 10KW AM transmitter once from parts; having the right 
pieces made the difference, especially when the four output tubes cost over 
$1,500 each.  It was a jury-rig, of course, but while the main transmitter 
was down it served its purpose.  The main was a hybrid solid-state/tube job 
made by Continental Electronics; a 30 watt exciter driving a pair of 
4CX15,000's in Doherty configuration.  address@hidden for the two plate 
circuits, 
and address@hidden for the filaments).  Sorry for the tangent.

> Let's rather make it something that tens of thousands of people
> would use to record multiple FM stations, or scan and log police and
> ambulance frequencies, or TiVo the ham bands, or avoid DRM on
> over-the-air TV transmissions.  Even our FM decoding is inferior to
> what cheap transistor radios do.  Six months' focus on polish and
> applications would make a world of difference.

Agreed, wholeheartedly.  I'm looking here at a new USRP, a Flex400 transciever 
board, and a USB headset (and a Linux laptop, of course) that would make a 
killer multimode QRP 440 rig.  I just need to make a frontpanel, so to speak.  
But ergonomic engineers and designers are paid small fortunes for good 
frontpanels from the hardware radio manufacturers.  Frontpanel and 
functionality design are non-trivial.  But with its solid foundation, 
GNUradio has the potential to make the guts less of an issue, and the 
frontpanel/functionality can become the prime goal.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu