[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] sparc <--> x86 data exchange
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] sparc <--> x86 data exchange |
Date: |
Mon, 19 Dec 2005 22:04:26 -0800 |
User-agent: |
Mutt/1.5.6i |
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
- [Discuss-gnuradio] sparc <--> x86 data exchange, cswiger, 2005/12/15
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Dave Dodge, 2005/12/15
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Chuck Swiger, 2005/12/16
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Eric Blossom, 2005/12/16
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Matt Ettus, 2005/12/16
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Stephane Fillod, 2005/12/16
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, John Gilmore, 2005/12/16
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Chuck Swiger, 2005/12/17
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Lamar Owen, 2005/12/19
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange,
Eric Blossom <=
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Lamar Owen, 2005/12/20
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Matt Ettus, 2005/12/20
- Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Greg Troxel, 2005/12/21
- Message not available
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Chuck Swiger, 2005/12/19
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, cswiger, 2005/12/19
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, michael taylor, 2005/12/19
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Eric Blossom, 2005/12/19
- Message not available
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Chuck Swiger, 2005/12/20
- Re: [Discuss-gnuradio] LW/MW/SW TiVo, Eric Blossom, 2005/12/20
Re: [Discuss-gnuradio] sparc <--> x86 data exchange, Eric Blossom, 2005/12/15