On Tuesday 20 December 2005 01:04, Eric Blossom wrote: > 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.
The time to swap bytes or words in the output stream will be insignificant by three or four orders of magnitude compared to the disk's write performance. Yes, three or four orders of magnitude; byte-swapping is a single instruction, typically. Disk write performance is the killer, and one or even a hundred instructions in the pipe aren't going to make a dent in the slow speed of disk. And this is regardless of the caching used by the disks: I found by experimentation with a dual Xeon 3 GHz box, with a PCI Express caching U320 SCSI RAID controller, that the system is I/O (disk and USB, which have to share the same processor bus, unfortunately) bound, even when performing work on the data in the pipe. > 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 Certainly. But if I save a file on one arch it should be able to be played back on another without me having to write anything. One of the keys of GNUradio is the fact that the scripts themselves are arch agnostic and portable across platforms; requiring different I/O blocks per platform breaks that. I mean, I could easily see something like an Xscale or MIPS embedded processor running a stripped down kernel and GNUradio for a portable software radio device. A USB2 capable pocket PC or similar could actually have something like the SSRP or a half-USRP embedded, and with a color LCD could become a portable spec-an/oscope/etc. So I think the byte-ordering thing is important, and I further think that regardless of platform that the input and output files always have the same byte order regardless of platform. > 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 ;) The toolkits today are much better, but I agree with you. My frontpanels on equipment I have made aren't works of art; the circuits inside might be, but the frontpanels certainly are not. > Sounds like a good application to emulate. Volunteers? FWIW, I can provide screenshots of SpectraVue in operation. Given time I might be able to emulate it; but I'd like to go past it, and that's where my abilities in graphics design fall apart. And I'm more of a backend person, too, and much more interested in the radio astronomy aspects, which aren't even necessarily GUI in nature. I did have a brainstorm early this morning, in that a GUI block-building app would be way cool, something like those Lego building apps where you can drag and drop blocks around. Doing that for GNUradio would be seriously cool. I don't have the foggiest idea at this point how to implement such a thing, but it would still be cool. An IDE for GNUradio, with the Boa Constructor GUI builder, and a backend flowgraph builder that would let you wire GUI elements to block signals, or something like. What one would do is be able to choose from a pallet of blocks, wire them together, and have the app generate the code to plug the GUI into. What I envision is something like what Xcircuit does for schematic capture and SPICE analysis (Xcircuit can generate the netlists to feed spice)... hmmm, Xcircuit is scriptable in Python...perhaps Xcircuit is already the frontend, but needs glue to tell it how to generate a flow graph rather than a spice netlist. Take the circuit emulation of GNUradio to the next level, and design using circuit-level tools. Of course, GNUradio is much higher level than spice, but I think the analogy holds pretty well. > > 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. Thank you. What I see GNUradio's niche, as the code currently stands, is a kit of lots of parts that you can wire together. You need to learn how to solder (Python), you need to learn what each component does, and you need to a have a grasp of what you want the result to do. Building devices from parts is non-trivial; image having to build those parts. GNUradio is like a kit of IC's ready made that you need to wire together and solder (and test, and package, and...). It makes software radio easier to do, but it is still a kit. -- 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 [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
