Re: [Discuss-gnuradio] Photo of the Beagle Board and USRP
On Fri, Apr 25, 2008 at 9:32 AM, Jeff Brower [EMAIL PROTECTED] wrote: You are talking about the ARM9 core on the OMAP device, right? If so then you can run Linux on the ARM core but overall processing capability will be limited compared to a Xeon or Core2-something PC. Now if you can migrate signal processing tasks to the C55x DSP core on the OMAP, then you're in business. For anyone who is wondering, OMAP series devices are widely used in cellphones and other very low power consumption hand-helds -- the chip series is one of TI's major breadwinners. The OMAP on the beagle board is one of the new OMAP3530 which have a Cortex-A8 and a TMS320C64x+ DSP core. Features of the OMAP can be found here: http://focus.ti.com/docs/prod/folders/print/omap3530.html#features The Cortex-A8 has the NEON SIMD co-processing available to it. Details can be found here: http://www.us.design-reuse.com/articles/11580/architecture-and-implementation-of-the-arm-cortex-a8-microprocessor.html Another interesting tidbit is the graphics accelerator (which I believe is really just another ARM core?) may also be able to offload some of the processing that may want to be done. It may not be able to handle 4MHz bandwidth serial-tone equalized waveforms, but you should be able to take a couple FFTs in real time which is enough for OFDM. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What does the USRP transmit after I've done tx-stop.
Per Zetterberg wrote: Hi All, I am transmitting a stream of buffers from the USRP (based on libusrp with standard .rbf file). After I've done tx-stop (where tx is a pointer to usrp_standard_tx) it seems that the USRP is repeating the last transmitted buffer (or couple of buffers ?). Is this correct ? Continually, until you unplug the board? If so, I've noticed this behavior too as of recent... I used to be able to replicate it 100% of the time, but haven't tried for a couple weeks. Are you using the current GNU Radio trunk? - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Photo of the Beagle Board and USRP
Brian- On Fri, Apr 25, 2008 at 9:32 AM, Jeff Brower [EMAIL PROTECTED] wrote: You are talking about the ARM9 core on the OMAP device, right? If so then you can run Linux on the ARM core but overall processing capability will be limited compared to a Xeon or Core2-something PC. Now if you can migrate signal processing tasks to the C55x DSP core on the OMAP, then you're in business. For anyone who is wondering, OMAP series devices are widely used in cellphones and other very low power consumption hand-helds -- the chip series is one of TI's major breadwinners. The OMAP on the beagle board is one of the new OMAP3530 which have a Cortex-A8 and a TMS320C64x+ DSP core. Features of the OMAP can be found here: http://focus.ti.com/docs/prod/folders/print/omap3530.html#features The Cortex-A8 has the NEON SIMD co-processing available to it. Details can be found here: http://www.us.design-reuse.com/articles/11580/architecture-and-implementation-of-the-arm-cortex-a8-microprocessor.html Another interesting tidbit is the graphics accelerator (which I believe is really just another ARM core?) may also be able to offload some of the processing that may want to be done. It may not be able to handle 4MHz bandwidth serial-tone equalized waveforms, but you should be able to take a couple FFTs in real time which is enough for OFDM. Thanks Brian. Yes the 64x+ core is TI's top of the line. The most powerful device they have is a 6-core 64x+ device (look for TCI6486 or TNETV3020) on the web. But 64x+ sucks more power... so have to see whether the new OMAPs end up in Nokia phones or not. In this case TI's target market can probably be described as more generic wireless terminals. If TI would come out with native, factory-supported Linux running on their DSP devices, then they could get in the open source game. As it stands they're on the sidelines, and people like ADI and Freescale are working their way in. On paper the Beagle board looks like a good candidate for embedded GNU radio, but taking advantage of the 64x+ core would take substantial DSP work -- a level that only would apply for a commercial product. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flexrf AGC sensitive to noise ?
Hi All, I am trying to get some experience of flexrf1800. I am receiving a CW of 1766MHz (from a signal generator) and transmitting a wavefrom at a different frequency. Now, changing the frequency of the outgoing signal from 1800MHz to 1900MHz changes the estimated amplitude of ingoing signal by 0.5dB! (yes, they shouldn't have anything to do with each other, and yes, the SNR is high). Could it be that the level of the AGC control signal (of the AD8347) is affected by the the TX circuitry ? Can the AGC be switched off entirely ? By the way: I am using my own C++ driver for the flexrf1800 that I contribute if somebody wants it. However, it is out of context with the gnu-radio framework, not properly tested, and is not object oriented. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What does the USRP transmit after I've done tx-stop.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't know how relevant this is, but I have fixed similar problems in the past by making sure that the host app sends data that's an even multiple of 512 bytes. (This is harder than you think :)) I found that if you send a number of sample bytes equivalent to 1 same mod 512 bytes, for instance, the last sample is repeated for some time and can be observed as a short pilot tone. I never did too much digging into this, however -- I just modified the transmitting app to pad. - -Dan On Apr 25, 2008, at 7:31 AM, George Nychis wrote: Per Zetterberg wrote: Hi All, I am transmitting a stream of buffers from the USRP (based on libusrp with standard .rbf file). After I've done tx-stop (where tx is a pointer to usrp_standard_tx) it seems that the USRP is repeating the last transmitted buffer (or couple of buffers ?). Is this correct ? Continually, until you unplug the board? If so, I've noticed this behavior too as of recent... I used to be able to replicate it 100% of the time, but haven't tried for a couple weeks. Are you using the current GNU Radio trunk? - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkgSBP4ACgkQy9GYuuMoUJ7gqgCg1D9y0VS5kACJP2n1HNJoLphD u+oAniv+yi/QK3L19WDcRZ077xHh0ebO =LbHy -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM Modification
Hi, I use an array to implement supporting multi-constellation scheme for OFDM system, but I got a problem in modifying the code for /trunk/ gnuradio-core/src/python/gnuradio/blks2impl/ofdm.py in which I generate a parameter multi_modulation[i][j] while i is the ith subcarrier, and j is the used modulation scheme. However, I have no idea how to modify the following : expert.add_option(,--multi_modulation,type =array, default = , help=set the number of use multi_constellation decision [defalut=%default]) where I want to use bpsk as default for whole subcarrier, and type array to assign which subcarrier should use other constellation scheme. For example [2 qpks ; 5 16qam] means the 2nd subcarrier use qpsk, and the 5th subcarrier use 16qam. Another question is, what's the meaning for the parameter arity? I thought I also need to change it to an array for different subcarriers, but I also got stuck there. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flexrf AGC sensitive to noise ?
Per Zetterberg wrote: Hi All, I am trying to get some experience of flexrf1800. I am receiving a CW of 1766MHz (from a signal generator) and transmitting a wavefrom at a different frequency. Now, changing the frequency of the outgoing signal from 1800MHz to 1900MHz changes the estimated amplitude of ingoing signal by 0.5dB! (yes, they shouldn't have anything to do with each other, and yes, the SNR is high). You will get leakage from the transmitter into the receiver. When you bring the TX frequency closer to the RX, more of it will get through and will change the amplitude estimates. The RFX boards can do full duplex, but there are limitations to how close you can have the TX and RX. Could it be that the level of the AGC control signal (of the AD8347) is affected by the the TX circuitry ? Not likely. Can the AGC be switched off entirely ? No, you need to have some voltage going to the variable gain amplifiers. It is not automatically controlled however, unless you make it so. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] m-block timeouts, time passed
Hi George, I browsed through cmac.cc and got a few questions: 1. Can you explain more about Without m block to gr block connection, all raw samples are forced thru the MAC layer? 2. What kind of applications are needed to interface with your MAC code to do CS configuration and data transfer/receive? 3. What are those PMT related macros? Perhaps it's easier if there exists documentations explaining the current mblock implementation. The bottom line is this is interesting enough and I 'd like to give it a try. You can email the directions to me offline. Thanks. - David On Thu, 2008-04-24 at 13:30 -0400, George Nychis wrote: David Li wrote: Hi George, I am interested in your MAC work. Does it run in the kernel or user space? Does it interact with IP? Is there a branch that I can download and play with it? I have two USRP 2400 boxes. Hi David, Put your reading glasses on. To do MAC work in GNU Radio, you need to use the m-blocks which allow meta-data with message passing in the framework. They're extremely flexible blocks. These blocks have been officially released with GNU Radio and I have been using them for quite some time with no issues. However, to do MAC work, you also need to use what we call inband signaling. This functionality is a work in progress within GNU Radio and is scheduled to be released with the next major GNU Radio release. The inband signaling functionality adds a control channel between the host and the USRP, as well as meta-data which as passed on the USB blocks of samples for tighter timing control for TDMA and such. Additionally, my research group at CMU has made additional FPGA and host changes to support time-critical common MAC functionality in the FPGA, with completely control at the host using the control channel. It's sort of like an addon in terms of functionality of the in-band signaling. For example, we implement a 96 coefficient matched filter in the FPGA to support several things: - squelching of samples to the host until a sequence is detected (prevents constant demodulation at the host, great for packet detection) - generation of dependent packets -- for example, when a packet is detected in the FPGA and it's detected that its for this host, trigger the transmission of pending samples (like a pending ACK). This reduces ACK turnaround time, which in turn increases capacity. This could also be used to generate some sort of synchronization responses in TDMA quickly. We also implement carrier sense on the board, with control by the host on a packet basis, to reduce the size of the carrier sense blind spot introduced by the bus latency. Our goal has been to argue against the traditional streaming based architecture of software-defined radios, for a new architecture which can support MAC development. There are 2 more gotchas in terms of GNU Radio. There is no m-block-grblock connection, which means you can't use 99% of what is in GNU Radio with the in-band work or our additional work so far. Lastly, there is no C++ daughterboard control which limits things even further. I wish I could give a timeline of this functionality being available, but I have no clue :) Our group, with the help of Dan (another student at UW), has worked towards temporary work arounds while waiting on this functionality. We implemented a hacked up version of GMSK in an m-block, so its the only PHY currently supported, and we hacked up initialization of the daughterboards in python and passing the reference to our m-blocks via SWIG. We have a simple file transfer application working on the USRP with any daughterboard using a basic CSMA protocol: https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/macs/cmusdrg_macs/trunk/src/lib/cmac.cc It does addresses, ACK's, ACK timeouts, and carrier sense. Some students in a class are working on extending it to random exponential backoff (fairness) and sequence numbers (ACK-loss resilience). I'm also working on a TDMA MAC right now, sort of layed out here: https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/wiki/TMAC If you're interested in playing around with it until the missing GR functionality is implemented, you can contact me off list and I can pass you a series of patches. That's my own personal support towards my own work which I want people to use. Once it hits GNU Radio mainstream, then you will be able to find support on the list. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_complex and gr_complex to xxx
I am not sure the fine gr_complex to xxx is the same as the gr_complex which I found in the ofdm_mapper_bcv.cc const std::vectorgr_complex constellation I thought they are different, aren't they? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 65, Issue 45
Message: 6 The OFDM system uses fft_length number of subcarriers and occupied_tones number of used subcarriers. The used subcarriers are mapped to the middle of the fft_length subcarriers leaving the same number of guardband subcarriers on either side. The middle two subcarriers are also nulled to avoid DC affects. The mapping is done in gr_ofdm_mapper_bcv.cc. If you want to play with this, I'd make a copy of this one as a different version of the mapping. Tom Thanks Tom. Do you mean mapping to the fft_length? But, my questions is when received a packet, I saw the code in gr_ofdm_mapper_bcv.cc that the bits in the packet is sequentially to the subcarrier in order, and then do modulation according to desired constellation. Do I misunderstand anything? Regards. Yaya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] m-block timeouts, time passed
David Li wrote: Hi George, I browsed through cmac.cc and got a few questions: 1. Can you explain more about Without m block to gr block connection, all raw samples are forced thru the MAC layer? Ahhh I need to change that comment. That comment is no longer true. The samples hit the PHY first, and the PHY sends the MAC a bit stram. 2. What kind of applications are needed to interface with your MAC code to do CS configuration and data transfer/receive? Right now there is nothing to actually connect with the TCP/IP stack. The test applications are GNU Radio applications. 3. What are those PMT related macros? Perhaps it's easier if there exists documentations explaining the current mblock implementation. Right... the PMT is a polymorphic type that was implemented in GNU Radio to simplify data passing in the m-blocks. It's not actually in any of the m-block documentation. I think this is documentation that would be extremely beneficial. I will write up some documentation on PMT in the GNU Radio wiki and send out a link tonight or tomorrow. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 GigE MAC module - 10Mbps?
Hi there, I'd like to use the GigE MAC module for the USRP2 on a piece of (non-USRP2) hardware, but due to project constraints am not able to use GigE or 100Mbps. Does the module support 10Mbps? From the comments in the change logs, I'm guessing not, but just wanted to make sure. From an earlier post on this discussion board it looked like the USRP2 itself might be able to handle 100Mbps or 10Mbps, so I was curious about the implications for the MAC module... If by some chance it does support 10Mbps, would the signal labeled .Clk_125M still need to be a 125Mhz clock? Does .Clk_user need to be a 100Mhz clock, as in the demo code? Thanks much! Jennifer ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] any recommendation? debug tools and IDE on cygwin
guys, I just got GR installed on cygwin. It runs. But don't know what debugging tools and IDE that I can use to play with it. Eclipse for windows seems not support cygwin. I couldn't run debugging or any other code navigation function. do you have any suggestions and recommendations on cygwin debugging tools and IDE? really appreciate it!! Bob Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX900 Gain
Hi all, Is there a way to reduce the gain of the RFX900 board? Using the self.subdev.set_gain(self.subdev.gain_range()[1]/Att) function does not seem to change anything. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Photo of the Beagle Board and USRP
Philip Balister wrote: I've received a Beagle board and started testing the USRP connection. (Still needs work) I've had several requests for more information so I thought a photo would help people understand the possibilities. http://www.flickr.com/photos/[EMAIL PROTECTED]/2439256116/ Philip Hello, The Beagle board looks interesting. I have looked at the OMAP 5912 processor. Is it available yet? The webpages I found indicate this is a future product. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] polymorphic type documentation (PMT)
Hi all, I've added documentation on the new polymorphic type in GNU Radio, PMT, to the GNU Radio wiki: http://gnuradio.org/trac/wiki/TypePMT It has full details of many of the methods, how to use a PMT, how to assign it values, how to do type conversions, etc... For more difficult PMT types (lists, dictionaries, etc...), I have added detailed sections. This is all part of my attempt to make a better wiki... http://gnuradio.org/trac/wiki/WikiStartNew ... I'm branching out from the m-block info, slowly but surely! - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
