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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio