[Discuss-gnuradio] How can I read byte by byte from a file and send it to input stream of a block.
Hi, I want to read a byte from a file and send it to an input stream. Each time I read one byte from the file i want to send it onto the input stream of a particular block and then read the next byte and do the same. I looked at gr.message_source() which does similar work to what I need. But I see that when we use gr.message_from_string(databyte) and then do msgq().insert_tail(msg) we add some more information to the data byte. I just want to send the particular byte read onto the stream. How can I do this? Thanks Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Intel Atom is NICE.
The intel graphics chip set and northbridge are power hungry. I think the idea is optimize code for the 330 and not the peripherals with this ine ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "And yes I said, yes I will Yes", Molly Bloom -Original Message- From: Daniel O'Connor [mailto:dar...@dons.net.au] Sent: Sunday, December 28, 2008 6:12 PM To: discuss-gnuradio@gnu.org Cc: Bob McGwier; hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz Subject: Re: [Discuss-gnuradio] Intel Atom is NICE. On Monday 29 December 2008 06:53:30 Bob McGwier wrote: > I am running GnuRadio, SDRMAX, and PowerSDR on my new Intel ATOM 330 > MiniITX motherboard. I had to put a firewire card in the single PCI slot. > The integrated intel graphics are nice and spiffy (glxgears is at 800 > fps if you turn off the desktop enhancements, no wiggly windows please). > > > > At 96000 PowerSDR is running under 15% CPU. The ATOM burns EIGHT > watts and has dual hyperthread cores (shows up as four processors in task > manager). Unfortunately the 945 chipset eats ~20W - god knows why Intel lumbered the Atom with it :( Toms Hardware (and others) did a test of the Atom vs an underclocked Athlon and the later won most of the tests http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997-1.html I think the Atom combo is cheaper and smaller though :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Intel Atom is NICE.
The intel graphics chip set and northbridge are power hungry. I think the idea is optimize code for the 330 and not the peripherals with this inexpensive and easy to use Mobo. The disk drive is hungry as well. The Intel ATOM Z500 family are mobile processors that have the same SIMD registers, support LCD, good GigE support, and the potential wart (POTENTIAL) is the 100 or 133 MHz FSB. http://www.axiomtek.com.tw/Products/ViewProduct.asp?view=680#3 The Virginia Tech Mobile (SDR/CR) groups are looking at these (largest SDR/CR department in the world I think). I think we want to optimize SIMD code and see what we can get running on these prepackaged, easy to get up and running systems as well as the SoC parts such as that family of TI OMAP parts carried on the Beagleboard. One does NOT need to spend thousands of dollars on an SDR computer for most operations. That is a convenient excuse for me to justify my computer budget for "development" and get high end things to play with (so I can kill aliens from another galaxy or FSU laboratory with impressive graphics in my "spare time"). But most people need to really justify the need for the high end computer in my mind and they cannot. That is my point in all of this. SDR wants to be on consumer/commodity level processors and SoC to be in everyone's "coffee budget" and taken for granted in the ideal world in my book. There seems to be little gained by optimizing this for Quad core extreme processors with massive GPU's sitting on them, tons of expensive high speed memory, and the world's fastest drives and costing well upwards of $1000 US. Lightweight, easy to distribute, with browser level GUI's and distributed everything on inexpensive processors and we rule the world. You can call me Dr. No. and SDR Working group chairman stands for SPECTRE DUMB RESEARCH working group. Cheers, Bob ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "And yes I said, yes I will Yes", Molly Bloom -Original Message- From: Daniel O'Connor [mailto:dar...@dons.net.au] Sent: Sunday, December 28, 2008 6:12 PM To: discuss-gnuradio@gnu.org Cc: Bob McGwier; hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz Subject: Re: [Discuss-gnuradio] Intel Atom is NICE. On Monday 29 December 2008 06:53:30 Bob McGwier wrote: > I am running GnuRadio, SDRMAX, and PowerSDR on my new Intel ATOM 330 > MiniITX motherboard. I had to put a firewire card in the single PCI slot. > The integrated intel graphics are nice and spiffy (glxgears is at 800 > fps if you turn off the desktop enhancements, no wiggly windows please). > > > > At 96000 PowerSDR is running under 15% CPU. The ATOM burns EIGHT > watts and has dual hyperthread cores (shows up as four processors in task > manager). Unfortunately the 945 chipset eats ~20W - god knows why Intel lumbered the Atom with it :( Toms Hardware (and others) did a test of the Atom vs an underclocked Athlon and the later won most of the tests http://www.tomshardware.com/reviews/Atom-Athlon-Efficient,1997-1.html I think the Atom combo is cheaper and smaller though :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
On Monday 29 December 2008 21:41:03 Bob McGwier wrote: > The intel graphics chip set and northbridge are power hungry. I think the > idea is optimize code for the 330 and not the peripherals with this I think that unfortunately the power consumption is high regardless of wether you actually use the video or not :( > inexpensive and easy to use Mobo. The disk drive is hungry as well. Well you could use an SSD ;) > One does NOT need to spend thousands of dollars on an SDR computer for most > operations. That is a convenient excuse for me to justify my computer I think the Athlon would be quite competitive, it has higher memory bandwidth I believe and the boards aren't limited in connectivity like the Atom. Basically my point was that it should be considered rather than just assuming the Atom is best :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
Bob McGwier wrote: > One does NOT need to spend thousands of dollars on an SDR computer for most > operations. That is a convenient excuse for me to justify my computer > budget for "development" and get high end things to play with (so I can kill > aliens from another galaxy or FSU laboratory with impressive graphics in my > "spare time"). But most people need to really justify the need for the high > end computer in my mind and they cannot. That is my point in all of this. > > SDR wants to be on consumer/commodity level processors and SoC to be in > everyone's "coffee budget" and taken for granted in the ideal world in my > book. There seems to be little gained by optimizing this for Quad core > extreme processors with massive GPU's sitting on them, tons of expensive > high speed memory, and the world's fastest drives and costing well upwards of > $1000 US. Lightweight, easy to distribute, with browser level GUI's and > distributed everything on inexpensive processors and we rule the world. You > can call me Dr. No. and SDR Working group chairman stands for SPECTRE DUMB > RESEARCH working group. > > While I can heartily agree that for the expansion of SDR into the consumer space, you want it to run on low-power processors, etc, I can't agree that "for most operations" you don't need a high-end CPU. For example, 802.11 at anywhere approaching 802.11b bitrates needs some serious iron, and yet in our world (the world of SDR geeks), wanting to build SDR/GnuRadio-based 802.11b implementations seems a fairly common goal. In my work in radio astronomy, I've found that despite the relative simplicity of the basic functions my software provides--full-bandwidth spectral display, and total power, for one or two channels, big iron is necessary. I recently upgraded to a quad-core Q6600 to replace a dual-core Pentium D 940. The quad core loses against the dual-core because of a difference in maximum clock speed. I can run the D 940 at 3.2Ghz forever, and it can process a full 8Mhz of dual-channel, complex bandwidth. The Q6600, on the other hand, is unstable above 2.85Ghz or so, and can't sustain more than about 5.3Mhz of dual-complex-channel bandwidth without incurring massive USRP overruns. Despite the wonderful new multi-threaded Gnu Radio framework, it seems that at least one of those threads really needs as many MIPs as the processor can throw at it, because it has to keep up with a real-time data source. Any time you're dealing with having to suck in (or send out) as much bandwidth as the USRP can tolerate, and *actually doing something* with the entire bandwidth, you need ManyMIPS(tm). Which means spending $$$ (although, my dual/quad-core system was much less than the $1000.00 you quote above). -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I read byte by byte from a file and send it to input stream of a block.
On Mon, Dec 29, 2008 at 03:48:15AM -0600, Mir Ali wrote: > Hi, > I want to read a byte from a file and send it to an input stream. Each time > I read one byte from the file i want to send it onto the input stream of a > particular block and then read the next byte and do the same. I looked at > gr.message_source() which does similar work to what I need. But I see that > when we use gr.message_from_string(databyte) and then do > msgq().insert_tail(msg) we add some more information to the data byte. I > just want to send the particular byte read onto the stream. How can I do > this? > > Thanks > Ali gr.file_source(gr.sizeof_char, "/path/to/my/file") ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Intel Atom is NICE.
There are many more ways than just lumping everything onto a single GPP. A good example is a recent thread on the GNU radio mailing list where the poster is using the USRP2 as a standalone radio with no PC. Pushing key elements to other reconfigurable processors, e.g. the USRP2 FPGA, will greatly ease the burden of the GPP. My point is that "big iron" isn't always necessary if you're willing to put some work into distributing the work load to other processors (a major research issue currently). Tim > -Original Message- > From: discuss-gnuradio-bounces+trnewman=vt@gnu.org > [mailto:discuss-gnuradio- > bounces+trnewman=vt@gnu.org] On Behalf Of Marcus D. Leech > Sent: Monday, December 29, 2008 8:14 AM > To: Bob McGwier > Cc: hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz; > discuss- > gnura...@gnu.org > Subject: Re: [Discuss-gnuradio] Intel Atom is NICE. > While I can heartily agree that for the expansion of SDR into the > consumer space, you want it to run on low-power processors, etc, I can't > agree that "for most operations" you don't need a high-end CPU. > > For example, 802.11 at anywhere approaching 802.11b bitrates needs some > serious iron, and yet in our world (the world of SDR > geeks), wanting to build SDR/GnuRadio-based 802.11b implementations > seems a fairly common goal. > > In my work in radio astronomy, I've found that despite the relative > simplicity of the basic functions my software provides--full-bandwidth > spectral display, and total power, for one or two channels, big iron > is necessary. I recently upgraded to a quad-core Q6600 to replace > a dual-core Pentium D 940. The quad core loses against the dual-core > because of a difference in maximum clock speed. I can > run the D 940 at 3.2Ghz forever, and it can process a full 8Mhz of > dual-channel, complex bandwidth. The Q6600, on the other hand, > is unstable above 2.85Ghz or so, and can't sustain more than about > 5.3Mhz of dual-complex-channel bandwidth without incurring > massive USRP overruns. > > Despite the wonderful new multi-threaded Gnu Radio framework, it seems > that at least one of those threads really needs as many > MIPs as the processor can throw at it, because it has to keep up with > a real-time data source. > > Any time you're dealing with having to suck in (or send out) as much > bandwidth as the USRP can tolerate, and > *actually doing something* with the entire bandwidth, you need > ManyMIPS(tm). > Which means spending $$$ (although, my dual/quad-core system was much > less than the $1000.00 you quote above). > > -- > Marcus Leech > Principal Investigator, Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Stand-alone USRP2: Modifying FPGA design
On Mon, Dec 29, 2008 at 1:24 AM, Yongsang Kim wrote: > Hi, all. > > I plan a stand-alone USRP2 transmitter (without using PC). > So, it is required to modify the Spartan3 ISE project(s) and add some > HDL source codes for the transmitter. > However, there are many sub-blocks in the project(s) so that it is hard > to figure out that which block should be modified. > It would be very helpful for me if anyone could notify that which part > (or block) should be modified. There is a port that feeds the interpolation DSP chain. If you're making a transmitter, this is probably where you want to feed the samples you create. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help:about the website http://comsec.com/wiki
Hallo Everyone, i want to get some infos from the website http://comsec.com/wiki, but i can not open it. can anyone tell me how to open it? Thanks a lot! slimchao -- View this message in context: http://www.nabble.com/Help%3Aabout-the-website-http%3A--comsec.com-wiki-tp21205752p21205752.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help:about the website http://comsec.com/wiki
On Mon, Dec 29, 2008 at 08:50:40AM -0800, slimchao wrote: > > Hallo Everyone, > > i want to get some infos from the website http://comsec.com/wiki, but i can > not open it. can anyone tell me how to open it? It was replaced with http://gnuradio.org/trac/wiki Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Some usrp_spectrum_sense.py code Explanation
Hi Everybody, and Merry Christmas I received many emails requesting some explanation for usrp_spectrum_sense.py gnuradio example program. The following link contains the code with some explanation and one bug fix (in self.max_center_freq equation): http://rapidshare.com/files/177960860/usrp_spectrum_sense.py usrp_spectrum_sense.py Explanation : === Introduction: - 1) This program can be used as a basic code for implementing wideband spectrum analyzer. 2) As we know, the USRP cannot examine more than 8 MHz of RF spectrum due to USB bus limitations. 3) So, to scan across a wide RF spectrum band (bigger than 8 MHz) we have to tune USRP RF front end in suitable steps so that we can examine a lot of spectrum, although not all at the same instant. 4) The usrp_spectrum_sense shows the way how it can be done.It steps across the spectrum and make the RF measurements. This application can sense a large bandwidth, but not in real time, and it can do the frequency sweep over the required frequency range, Theory: --- 1) To use N points complex FFT X(W) analysis, we have to get N time samples x(t) which are sampled at Fs. 2) These N time samples must be time windowed using a known window function to reduce spectral leakage. 3) Performing N points complex FFT analysis. 4) The output of the complex FFT will represent the frequency spectrum contents as follows: a) The first value of the FFT output (bin 0 == X[0]) is the passband center frequency. b) The first half of the FFT (X[1] to X[N/2-1] contains the positive baseband frequencies,which corresponds to the passband spectrum from the center frequency out to the maximum passband frequency (from center frequency to +Fs/2). c) The second half of the FFT (X[N/2] to X[N-1]) contains the negative baseband frequencies,which correspond to the lowest passband frequency up to the passband center frequency (from -Fs/2 to center frequency). Example --- Let us assume that we have 1024 (I and Q) samples gathered using a tuner centered at 20MHz. And let us assume that the sampling frequency was 8MHz. Doing 1024 points complex FFT means: 1) FFT Frequency resolution is : 8MHz / 1024 = 7812.5 KHz 2) The output of the FFT X[0] represents the spectrum at 20MHz. 3) The output of the FFT X[1] to X[511] represents the frequencies from 20.0078125 MHz to 23.9921875 MHz (about 4MHz above center frequency). 4) The output of the FFT X[512] to X[1023] represents the frequencies from 16.0078125 MHz to 19.9921875 MHz (about 4MHz bellow center frequency). RF Frequency Sweeping - 1) Let us suppose that we want to scan RF spectrum band from 10MHz to 52 MHz. 2) Let us remember that USRP can analyze 8MHz of frequency at a time. 3) So theoretically we have to step our RF center frequency as follows: First step is 14MHz (it will cover frequency band from 10MHz to 18MHz), Second step is 22MHz (it will cover frequency band from 18MHz to 26MHz), Third step is 30MHz (it will cover frequency band from 26MHz to 34MHz), Fourth step is 38MHz (it will cover frequency band from 34MHz to 42MHz), Fifth step is 46MHz (it will cover frequency band from 42MHz to 50MHz), and finally the Sixth step is 54MHz (it will cover frequency band from 50MHz to 58MHz). Remember that we want the frequencies up to 52MHz only, so we have to discard some FFT points from the Sixth analysis. 4) Paralytically we have to use FFT overlapping to reduce the non linearity response of the Digital Down Converter (the DDC frequency response is not Flat from -Fs/2 to + Fs/2) and to fill the frequency holes that will be present at the FFT analysis edges (10MHz, 18MHz, 26MHz, 34MHz, 42MHz, 50 MHz). So if we choose to use an overlap of 25%, this means that our step size will be 6MHz (8MHz*(1-.25)), thus practically we have to step our RF center frequency as follows: First step is 13MHz (it will cover frequency band from 9MHz to 17MHz), Second step is 19MHz (it will cover frequency band from 15MHz to 23MHz), Third step is 25MHz (it will cover frequency band from 21MHz to 29MHz), Fourth step is 31MHz (it will cover frequency band from 27MHz to 35MHz), Fifth step is 37MHz (it will cover frequency band from 33MHz to 41MHz), Sixth step is 43MHz (it will cover frequency band from 39MHz to 47MHz), and Finally the Seventh step is 49MHz (it will cover frequency band from 45MHz to 53MHz), Changing RF center Frequency 1) To change USRP RF center frequency we have to send a tunning command to the USRP every time we complete the analysis of the current frequency chunk. 2) Before gnuradio revision [10165], all USRP RF daughterboards tunning were done using Python functions and classes. After that revision, tunning the USRP daughterboards from withen C++ code is possible. 3) In usrp_spectrum_sense.py, the DSP C++ written code is allowed to transparently invoke Python code USRP tune
Re: [Discuss-gnuradio] How can I read byte by byte from a file and send it to input stream of a block.
Hi Eric ,
I know what file_source does but I was looking for something else. Please
look at the code below to know what i am looking for.
tb.start()
fil=open("/home/murtuza/t",'r') # I first open a file to read
n=0
while n<1:
data = fil.read(gr.sizeof_char) # then read one byte only
n=n+1
send_pkt(data) # then send it over the stream to a block that
processes that particular byte.
print "called"
tb.wait()
If you look at benchmark_tx.py program data is read from a file and then
send_pkt() is called. send_pkt() module in transmit_path.py calls
"self.packet_transmitter.send_pkt(payload, eof)" which then calls send_pkt()
in mod_pkts. Here, the payload is inserted into the message queue by the
statement self._pkt_input.msgq().insert_tail(msg). I want to do something
similar except for the fact that I want to put the unmodified byte in the
queue unlike mod_pkts which first uses message_from_string and then inserts
the msg on to the queue.
If this can be done using file_source then can u tell how?
I am working on something that requires me to do this. May be this is not an
ideal way of doing it but still I want to know if it is possible.
Thanks,
Ali
On Mon, Dec 29, 2008 at 8:35 AM, Eric Blossom wrote:
> On Mon, Dec 29, 2008 at 03:48:15AM -0600, Mir Ali wrote:
> > Hi,
> > I want to read a byte from a file and send it to an input stream. Each
> time
> > I read one byte from the file i want to send it onto the input stream of
> a
> > particular block and then read the next byte and do the same. I looked at
> > gr.message_source() which does similar work to what I need. But I see
> that
> > when we use gr.message_from_string(databyte) and then do
> > msgq().insert_tail(msg) we add some more information to the data byte. I
> > just want to send the particular byte read onto the stream. How can I do
> > this?
> >
> > Thanks
> > Ali
>
>
> gr.file_source(gr.sizeof_char, "/path/to/my/file")
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Faulty USRP microprocessor?
G'day, I'm glad to inform that replacing the FX2 chip resolved the problem and the USRP appears to be fully operational, e.g. usrp_benchmark and usrp_wfm work out of the box. I since tried to connect the board using a USB2.0 cable of 5m in length and can't establish communication with it. The cable length is within the USB2.0 specifications. It may just be a poor quality or bad cable, but would like to hear if anyone else has been successful in using a long USB cable. Using an oscilloscope, I can see a pulse train of about 0.5Vpp with channel A (D+) and channel B (D-) at the USRP connector. Does this sound right? cheerio Berndt On Thursday 13 November 2008 08:49:40 Berndt Josef Wulf wrote: > G'day, > > I haven't made any progress in finding a solution to my problem. A direct > email to Matt (Ettus) explaining my predicament didn't receive a reply. It > was hoped that the manufacturer of the USRP would provide some after sale > techmical support for their products. > > The USRP is no longer communicating when it was powered up after being in > storage for the past 6 month. As mentioned in my previous email, see below, > my suspect is the co-processor that hosts the USB interface, although I > can't be sure. Perhaps someone on this list knows a procedure that would > lead to an accurate diagnosis. > > At this stage I'm contemplating to replace the processor. What needs to be > considered prior to replacing this processor, e.g. does it need to be > flashed? I'm also looking for a supplier for this chip. > > Any help is very much appreciated. > > 73, Berndt > VK5ABN > > On Tuesday 04 November 2008 22:28:38 Berndt Josef Wulf wrote: > > G'day, > > > > today I discovered that my USRP appears to have a problem. The USRP > > device is nolonger detected when connected to a PC (i386) running WinXP, > > Linux or NetBSD. I tried different systems and cables to no avail. This > > is with GNU-Radio current, but also tried with the last stable release. > > > > Power supply rail measures 3.3V after the regulator and the LED is fast > > flashing, which normally would indicate that the processor is running, > > but firmware hasn't been loaded. Signal lines from processor pins to > > connector/cable have continuity. I'm now suspecting the USB interface on > > the microprocessor chip. > > > > Has anyone had similar experience and what was the solution to your > > problem? If so, what was your solution? > > > > I really would hate the idea of having to replace the microprocessor > > because of lack of spares and in particular its package size. > > > > Any help is very much appreciated. > > > > 73, Berndt > > VK5ABN > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Intel Atom is NICE.
And GPU's are going to become commodity priced quickly and possibly even move into the GPP and replace older ways of doing floating point. With Nvidia CUDA, you can write code for your GPP, call GPU with intrinsics to get pretty quick payback while a better longer term strategy is worked on. The future of really hard to program heterogeneous/not symmetric multiple core processors, irrespective of how great the bandwidth is, I don't think is looking all that rosy. It simply cannot take months and months to get speed to make the processor pay or the cost per flop, when ALL COSTS are amortized (expensive people, etc.) begins to look bad. Bob ARRL SDR Working Group Chair Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "And yes I said, yes I will Yes", Molly Bloom -Original Message- From: Newman, Timothy [mailto:trnew...@vt.edu] Sent: Monday, December 29, 2008 10:05 AM To: Marcus D. Leech; Bob McGwier Cc: hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz; discuss-gnuradio@gnu.org; tim.newman...@gmail.com Subject: RE: [Discuss-gnuradio] Intel Atom is NICE. There are many more ways than just lumping everything onto a single GPP. A good example is a recent thread on the GNU radio mailing list where the poster is using the USRP2 as a standalone radio with no PC. Pushing key elements to other reconfigurable processors, e.g. the USRP2 FPGA, will greatly ease the burden of the GPP. My point is that "big iron" isn't always necessary if you're willing to put some work into distributing the work load to other processors (a major research issue currently). Tim > -Original Message- > From: discuss-gnuradio-bounces+trnewman=vt@gnu.org > [mailto:discuss-gnuradio- > bounces+trnewman=vt@gnu.org] On Behalf Of Marcus D. Leech > Sent: Monday, December 29, 2008 8:14 AM > To: Bob McGwier > Cc: hp...@lists.hpsdr.org; q...@yahoogroups.com; flexra...@flex-radio.biz; > discuss- > gnura...@gnu.org > Subject: Re: [Discuss-gnuradio] Intel Atom is NICE. > While I can heartily agree that for the expansion of SDR into the > consumer space, you want it to run on low-power processors, etc, I can't > agree that "for most operations" you don't need a high-end CPU. > > For example, 802.11 at anywhere approaching 802.11b bitrates needs some > serious iron, and yet in our world (the world of SDR > geeks), wanting to build SDR/GnuRadio-based 802.11b implementations > seems a fairly common goal. > > In my work in radio astronomy, I've found that despite the relative > simplicity of the basic functions my software provides--full-bandwidth > spectral display, and total power, for one or two channels, big iron > is necessary. I recently upgraded to a quad-core Q6600 to replace > a dual-core Pentium D 940. The quad core loses against the dual-core > because of a difference in maximum clock speed. I can > run the D 940 at 3.2Ghz forever, and it can process a full 8Mhz of > dual-channel, complex bandwidth. The Q6600, on the other hand, > is unstable above 2.85Ghz or so, and can't sustain more than about > 5.3Mhz of dual-complex-channel bandwidth without incurring > massive USRP overruns. > > Despite the wonderful new multi-threaded Gnu Radio framework, it seems > that at least one of those threads really needs as many > MIPs as the processor can throw at it, because it has to keep up with > a real-time data source. > > Any time you're dealing with having to suck in (or send out) as much > bandwidth as the USRP can tolerate, and > *actually doing something* with the entire bandwidth, you need > ManyMIPS(tm). > Which means spending $$$ (although, my dual/quad-core system was much > less than the $1000.00 you quote above). > > -- > Marcus Leech > Principal Investigator, Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Faulty USRP microprocessor?
On Tue, 2008-12-30 at 12:07 +1030, Berndt Josef Wulf wrote: > I'm glad to inform that replacing the FX2 chip resolved the problem and the > USRP appears to be fully operational, e.g. usrp_benchmark and usrp_wfm work > out of the box. Glad to hear it! > I since tried to connect the board using a USB2.0 cable of 5m in length and > can't establish communication with it. The cable length is within the USB2.0 > specifications. It may just be a poor quality or bad cable, but would like to > hear if anyone else has been successful in using a long USB cable. While 5m is indeed the spec, my experience with many USRPs and USB cables has been that only high quality cables that have been USB 2.0 certified can be depended upon. I've had brand new cables that would otherwise be in spec, but lack the 2.0 certification logo, completely fail. On other occasions, they'll work fine, but then fail mysteriously at odd times. I don't think I've ever seen a 3m cable fail, or a certified 5m cable fail, so it just looks like there isn't much margin. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [hpsdr] [Discuss-gnuradio] Intel Atom is NICE.
The new I7 intel processors have a really amazing amount of horsepower but a tremendous amount of onboard stuff is designed to work intimately with the peripherals to bring on high speed graphics. Now if your argument is that all of this is going to be moved into the GPP, I might agree that we will see some of this. If you are arguing that the demand for an almost exponential increase in capabilities in graphics hardware for the purposes of virtual reality and rendering live and without memorex is not going to be happening, we are in profound disagreement. John, can you give me (and the others here) a pointer to the list of GPIB, etc. devices your fantastic stuff currently supports? I went from seeing it in the early days with a handful of things supported to seeing friends of mine (like W2GPS) running their labs with your code. Bob On Mon, Dec 29, 2008 at 8:31 PM, John Miles wrote: > Larrabee, I'm thinking, will be the real SDR platform of choice. A Larrabee > box with USB 3.0 is going to put a staggering amount of DSP power into > peoples' hands. It won't even make sense to mess with FPGAs at that point, > I hope. > > GPUs are unquestionably an interim hack; I don't think they'll live to see > the next decade. They'll go the way of the Weitek. > > -- john, KE5FX > >> -Original Message- >> From: hpsdr-boun...@lists.hpsdr.org >> [mailto:hpsdr-boun...@lists.hpsdr.org]on Behalf Of Bob McGwier >> Sent: Monday, December 29, 2008 4:40 PM >> To: 'Newman, Timothy'; 'Marcus D. Leech' >> Cc: hp...@lists.hpsdr.org; flexra...@flex-radio.biz; >> q...@yahoogroups.com; tim.newman...@gmail.com; discuss-gnuradio@gnu.org >> Subject: Re: [hpsdr] [Discuss-gnuradio] Intel Atom is NICE. >> >> >> * High Performance Software Defined Radio Discussion List * >> >> And GPU's are going to become commodity priced quickly and >> possibly even move into the GPP and replace older ways of doing >> floating point. With Nvidia CUDA, you can write code for your >> GPP, call GPU with intrinsics to get pretty quick payback while a >> better longer term strategy is worked on. >> >> The future of really hard to program heterogeneous/not symmetric >> multiple core processors, irrespective of how great the >> bandwidth is, I don't think is looking all that rosy. It simply >> cannot take months and months to get speed to make the processor >> pay or the cost per flop, when ALL COSTS are amortized (expensive >> people, etc.) begins to look bad. >> >> Bob >> >> >> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Intel Atom is NICE.
Bob McGwier wrote: And GPU's are going to become commodity priced quickly and possibly even move into the GPP and replace older ways of doing floating point. With Nvidia CUDA, you can write code for your GPP, call GPU with intrinsics to get pretty quick payback while a better longer term strategy is worked on. The future of really hard to program heterogeneous/not symmetric multiple core processors, irrespective of how great the bandwidth is, I don't think is looking all that rosy. It simply cannot take months and months to get speed to make the processor pay or the cost per flop, when ALL COSTS are amortized (expensive people, etc.) begins to look bad. Bob Hello, I bought the earlier version of the motherboard with just the 10/100 ethernet. I put it in a MI-100 case and it is a nice little system. I have not gotten a chance to use it with GNURadio much so I have not commented about it on the list. I am thinking of using it as a car computer. However, I have tried it under Windows XP with my AutumnWave OnAir GT USB HDTV tuner. I understand this tuner uses the computer to decode the HDTV signal. On my older Thinkpad z60t (1.73 GHz Pentium M) the HDTV decode takes about 80% CPU and there are ocassional gliches. I was not happy. With the Intel Atom (1.60 GHz), the HDTV decode takes about 40% CPU and decode is excellent. I suspect the hyperthreading feature of the CPU is causing the improved decoding. I recently bought a Acer Aspire One (Intel Atom and 120GB HD) on sale. I plan to put Linux on it and see how it works with GNURadio and the USRP. I feel the advantage of the Intel Atom is reasonable performance in a small package. The Atom-based netbook may be useful for dealing with ham and conventional narrow-bandwidth signals in a portable/mobile SDR package. The 945 chipset is power hungry but I heard there is another chipset for the Atom in the works. Hopefully the new chipset will allow using the GPU for SDR work. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Marvell Yukon 88E8039 PCI-E Ethernet - USRP2
Hi I recently installed fedora 9 and GNU radio on laptop computer (COMPAQ Presario V3700, Marvell Yukon 88E8039 PCI-E Ethernet) but USRP2 is not recognized. (Running "find_usrp" keeps printing "No USRP2 found.") I have been using USRP2 with other desktop PCs and laptop PCs and I think there is no problem with USRP2 nor with ethernet on the laptop PC. (I am using latest GNU radio in trunk and updated FPGA progamming file and firmware.) I suspect that the problem is that USRP2 is incompatible with the ethernet. Is there anyone who succeeded in working USRP2 with "Marvell Yukon 88E8039 PCI-E Ethernet?" Is there anything that I can try to get those working? Any comments would be appreciated. Changkyu Seol -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Marvell Yukon 88E8039 PCI-E Ethernet - USRP2
Hi, 1) Use static IP address 2) Run find_usrps with sudo 3) Post your ifconfig Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
