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

[Eric Blossom]

On Mon, Dec 19, 2005 at 11:03:18PM -0500, Lamar Owen wrote:
> 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.

I disagree.  But we can have the best of both worlds.
When logging lots of binary diagnostic data to files, the last thing I
want is for it to take longer.

There's nothing stopping anyone from writing:

  gr_file_sink_big_endian
  gr_file_sink_little_endian
  gr_file_source_big_endian
  gr_file_source_little_endian

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

Great.

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

Did a lot of it, long ago.  (Wrote a complete WYSIWYG editor for
Unix in the days when a 25 MIPS workstation was a very cool thing to
have).  Not the kind of work I'm particularly interested in doing
these days.  Maybe it was the 90 hr work weeks ;)

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

Sounds like a good application to emulate.  Volunteers?

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

Nicely put.

> Lamar Owen

Thanks,
Eric