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. [EMAIL PROTECTED] for the two plate circuits, and [EMAIL PROTECTED] 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
