[Discuss-gnuradio] fm blocks
I am trying to do sdr radar. I will send linear fm modulated signal and then take it. I am seaching fm modulating blocks in grc. I ran some examples but could not understand it is true or not. I also looked nbfm and wbfm transmitter and receiver blocks in grc but i could not find any documents about these blocks. For example what do audio_rate and quadrature_rate mean? I must do linear fm transmitter and receiver for our project. Could you help me if you have any documents or opion? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bluetooth implementation frequency hopping restrictions
Hello all! My name is Kresimir Dabcevic and am currently a masters student at Mälardalen University in Sweden, starting my masters thesis on Software defined radio. We are looking to do a research on power consumption of technologies that operate in the 2.4 GHz ISM band, primarily Bluetooth and ZigBee. We are looking to purchase Ettus' USRP N200 with RFX2400 daughterboard for our research, and therefore use GNU Radio as our software. My understanding is that implementing ZigBee should be possible via the UCLA ZigBee PHY project, however implementation of Bluetooth presents a problem because of the frequency-hopping characteristic of this technology - there are some threads in the mailing lists' archives which state that implementation of BT is not possible since USRP does not have enough bandwidth possibility to encompass the whole 79 MHz band BT uses for FH. However, if I understood correctly, this applies to USRP1 platform (these threads date a few years back), which only had 8 MHz instantenous bandwidth, whereas USRP N200 should have 50 MHz (8-bit mode), and I presume that it also supports working in a 4-bit mode, which should allow for a 100 MHz bandwidth, which should be sufficient? Also, the following article by Dominic Spill and Andrea Bittau: http://darkircop.org/bt/gnuradio/Bluesniff.pdf states that "Bluetooth devices retune their radios 1,600 times per second in order to communicate with each other, but unfortunately tuning at such a rate is not an easy task with the USRP. The 2.48GHz daughterboard is able to retune within 200?s, which is not fast enough to follow a Bluetooth hopping pattern since each time slot is 600?s. Hopping with a tuning delay of 200?s would cause up to one third of each packet to be lost." which would imply that the hardware restrictions are not only tied to the platform itself, but also to the daughterboard? On the other hand, I have come upon the implementation GR-Bluetooth, http://darkircop.org/bt/gnuradio/ which states "An implementation of the Bluetooth baseband layer for GNU Radio for experimentation and teaching students about Software Defined Radio, it should not be used for Bluetooth communications as it is not a complete software stack." Could this implementation suffice for the research and/or are there other implementations of BT's PHY layer available for GNU Radio? We are just starting to look into the GNU Software (and SDR in general) problematics, so any help and feedback would be much appreciated. Best regards, Kresimir Dabcevic ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard
On 02/23/2011 11:25 PM, Almohanad Fayez wrote: I was wondering about people's experience with the UHD driver on the E100 or the Beagleboard. I am able to use it to receive IQ data from the USRP but I can't seem to transmit anything from it ... if I take the same flowgraph to a laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD driver however when I try to run the same transmitter on the Beagleboard and I check my spectrum analyzer I don't see anything Data comes out of the E100 fine, I assume you have a USRP1 attached to a beagle via USB? Philip I already did a signal capture before sending to the USRP and made sure that there is data getting pushed through ... is there a problem with UHD/USRP sinking on the E100 and the Beagleboard ??? I also made sure that I'm using the latest UHD firmware on the beagleboard. The following is the version info printed when I run the flowgraph: linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; UHD_0001.20110224034946.1 thanks al fayez ___ 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
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Moeller am 2011-02-24 00:33: > On 22.02.2011 15:26, Patrick Strasser wrote: > Not exactly. The FCB is not passing the IQ to the analog sound interface. > ADC is done within the dongle and the digital samples are transmitted via USB > to an emulated "virtual" sound card. > > However, for the application it's just another "sound card". Just like every USB sound interface it does not matter where the signal comes, where it is going and how things behind the interface work. It makes no difference to your application if you connect a converter via cable to your sound interface in your computer or if you have the sound interface built into your converter. If it implements the USB Audio Class, its a USB Audio device. A headset works the same. That's the nice thing about abstract interfaces. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bluetooth implementation frequency hopping restrictions
On Thu, Feb 24, 2011 at 02:06:41PM +0100, Kresimir Dabcevic wrote: > > My name is Kresimir Dabcevic and am currently a masters student at > M??lardalen University in Sweden, starting my masters thesis on > Software defined radio. Hi, Kresimir. I'm Michael Ossmann, one of the gr-bluetooth developers and also developer of the new Ubertooth hardware platform: http://ubertooth.sourceforge.net/ > We are looking to do a research on power consumption of technologies > that operate in the 2.4 GHz ISM band, primarily Bluetooth and ZigBee. > We are looking to purchase Ettus' USRP N200 with RFX2400 daughterboard > for our research, and therefore use GNU Radio as our software. Can you tell us more about what you hope to accomplish with the USRP / GNU Radio platform? > However, if I understood correctly, this applies to USRP1 platform > (these threads date a few years back), which only had 8 MHz > instantenous bandwidth, whereas USRP N200 should have 50 MHz (8-bit > mode), and I presume that it also supports working in a 4-bit mode, > which should allow for a 100 MHz bandwidth, which should be > sufficient? Theoretically, yes, but development will be required on the FPGA to accomplish this. Also you'll run into daughterboard bandwidth limitations. The RFX2400 has a 20 MHz low pass filter on both the I and Q receive paths, resulting in 40 MHz of baseband bandwidth at the ADC. In my talk with Dominic Spill (the other gr-bluetooth developer and one of the authors of the paper you mention below) at ShmooCon 2009, I talked about how I removed that filter to achieve all-channel monitoring with intentional aliasing. You should watch the video: http://shmoocon.org/2009/videos/Bluetooth-Ossman.m4v That was a fairly crude proof-of-concept. A better approach would be to modify the filter to pass 80 to 100 MHz of bandwidth rather than removing it entirely. Even then you would probably have a fairly non-flat frequency response which you would have to take into account if, for example, you are trying to use the received waveform to estimate transmit power. The XCVR2450 has even narrower bandwidth restrictions, and the filters are implemented on-chip, so I don't think you'd be able to modify them. > Also, the following article by Dominic Spill and Andrea Bittau: > states that > "Bluetooth devices retune their radios 1,600 times per second in order > to communicate with each other, but unfortunately tuning at such a > rate is not an easy task with the USRP. The 2.48GHz daughterboard is > able to retune within 200?s, which is not fast enough to follow a > Bluetooth hopping pattern since each time slot is 600?s. Hopping with > a tuning delay of 200?s would cause up to one third of each packet to > be lost." Rereading this after years of working on Bluetooth, I realize that this should be revisited. Bluetooth time slots are 625 microseconds long, but the maximum length single-slot packet is 393 microseconds, leaving 232 microseconds of tuning time. Looking at the multi-slot packet types, they all leave at least that much time for tuning. It looks like the XCVR2450 can tune faster than the RFX2400, so it should be possible to hop, even accounting for extra time to determine the next frequency and issue the command to the daughterboard. The trickiest problem to deal with here is the latency of the control path. It would not be possible to control the hopping from the host computer due to the USB or Ethernet latency, so you'd have to do the control on the USRP motherboard. If I recall correctly, the daughterboard tuning commands on the USRP1 are issued by the USB controller, not the FPGA, so the relatively straightforward approach of hopping controlled by the FPGA would not work. I'm not sure about the situation on the newer USRP models, but it is worth looking into. You would certainly have to do FPGA and/or firmware development to accomplish this, but it would be a valuable contribution to the community. > I have come upon the implementation GR-Bluetooth, The gr-bluetooth link you included is an ancient release. You should check out the current code from the git repo here: http://gr-bluetooth.sourceforge.net/ > Could this implementation suffice for the research and/or are there > other implementations of BT's PHY layer available for GNU Radio? Possibly, but it's hard to say without knowing exactly what you hope to accomplish. It may be that your needs would be better met by the Ubertooth platform which has frequency hopping capability (the code for hopping is not finished yet but will be soon). If you would like a board, I'm doing an initial production run of Ubertooth One hardware that you can get in on for four more days: http://www.kickstarter.com/projects/mossmann/ubertooth-one-an-open-source-bluetooth-test-tool Since your research is on power consumption, are you looking at Bluetooth Low Energy? That is an area I'm starting to look at more, and I hope to have BLE sniffing code in Ubertooth soon. M
Re: [Discuss-gnuradio] Bluetooth implementation frequency hopping restrictions
On Thu, Feb 24, 2011 at 02:06:41PM +0100, Kresimir Dabcevic wrote: > > and I presume that it also supports working in a 4-bit mode, which > should allow for a 100 MHz bandwidth, which should be sufficient? Oh, and perhaps this goes without saying, but 4 bits of dynamic range is extremely low for digital modulations. If you just want to detect transmissions, it should be sufficient, but, if you want to decode Bluetooth packets, the likelihood of decoding errors would be very high. You could operate with 100 MHz bandwidth at the full dynamic range of the ADC if you do your demodulation on the FPGA. This was a direction Dominic and I thought about pursuing but never did. You don't necessarily have to implement packet decoding on the FPGA; you could just channelize the waveform into 79 channels, demodulate each one into a 1 Mbps stream, and dump them all over Ethernet to a host computer to do the packet detection and decoding. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] operation order in freq_xlating_fir
Hello Just to make sure, may anybody please confirm the sequence of operations within the freq_xlating_fir_filter? Is it: in --->XLATE--->FILTER--->DECIM---> out When defining the FIR taps with firdes, shall I consider the input sampling freq or the output sampling freq (= input sampling freq / decim) ? Thanks in advance Alberto Supera i limiti: raddoppia la velocità da 10 a 20 Mega! Risparmia con Tutto Incluso: telefono + adsl 20 mega a soli 29,95 € al mese per due anni!SCONTO DI 240 EURO!http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso/?WT.mc_id=01fw ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [ANN] UHD support for the Bitshark USRP RX daughterboard
Epiq Solutions is pleased to announce that their Bitshark USRP RX (BURX) daughterboard is now supported by the UHD. Similar to other hardware supported by the UHD, this will provide a common PC-based driver controlling the BURX daughterboard, and should work across the entire suite of USRP platforms. The BURX driver support in the UHD is currently part of a separate git repo hosted at github. This repo is a clone of the UHD main repo from 2/22/2011, with a burx_support branch added in containing the BURX support updates. Full details on cloning and setting up the burx_support branch can be found on our wiki: http://www.epiq-solutions.com/twiki/bin/view/Main/WebHome Lastly, additional details of the BURX daughterboard can be found here: http://www.epiq-solutions.com/product_detail.php?line=Bitshark&product=Bitshark%20USRP Comments and testing feedback is welcome. We appreciate the patience of everyone who has been waiting for this support to be added in, and stay tuned for additional hardware and software announcements throughout 2011. -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard
On 02/23/2011 11:25 PM, Almohanad Fayez wrote: I was wondering about people's experience with the UHD driver on the E100 or the Beagleboard. I am able to use it to receive IQ data from the USRP but I can't seem to transmit anything from it ... if I take the same flowgraph to a laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD driver however when I try to run the same transmitter on the Beagleboard and I check my spectrum analyzer I don't see anything I already did a signal capture before sending to the USRP and made sure that there is data getting pushed through ... is there a problem with UHD/USRP sinking on the E100 and the Beagleboard ??? I also made sure that I'm using the latest UHD firmware on the beagleboard. The following is the version info printed when I run the flowgraph: linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; UHD_0001.20110224034946.1 Al, Which USB port are you using to connect the USRP1? What kernel version? Can you run dmesg and see if there are any usb related messages at the end? Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fm blocks
If I remember correctly the audio rate is literally the data rate your sound card is sampling at eg 32kHz or 44.1kHz and quad rate is the incoming rf sampling rate. For example you may have sampled your RF at 128kHz and be running your audio (or whatever) at 32kHz. On 24/02/2011 11:45 PM, ömer günay wrote: I am trying to do sdr radar. I will send linear fm modulated signal and then take it. I am seaching fm modulating blocks in grc. I ran some examples but could not understand it is true or not. I also looked nbfm and wbfm transmitter and receiver blocks in grc but i could not find any documents about these blocks. For example what do audio_rate and quadrature_rate mean? I must do linear fm transmitter and receiver for our project. Could you help me if you have any documents or opion? ___ 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] UHD Driver in E100/Beagleboard
1- I'm using the host USB not the OTG 2- I'm using the 2.6.37 kernel with Angstrom 2010 3- The following is the dmesg output which looks ok ... at least to me :) [ 108.369293] usb 1-2.3.1: USB disconnect, address 4 [ 108.770874] usb 1-2.3.1: new high speed USB device using ehci-omap and address 6 [ 108.889404] usb 1-2.3.1: New USB device found, idVendor=fffe, idProduct=0002 [ 108.889434] usb 1-2.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 108.889465] usb 1-2.3.1: Product: USRP Rev 4 [ 108.889465] usb 1-2.3.1: Manufacturer: Free Software Folks [ 108.889495] usb 1-2.3.1: SerialNumber: 4bd1d69b I think I'll try to attempt to redo your libusb hack by copying it from the older gnuradio recipes and attempt to use the original USRP USB driver if the problem ends up being too major ... unless you want to do that as a favor to me and push the recipe into the openembedded tree !!! pretty please :) al fayez -Original Message- From: Philip Balister To: Almohanad Fayez Cc: discuss-gnuradio Sent: Thu, Feb 24, 2011 2:20 pm Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard On 02/23/2011 11:25 PM, Almohanad Fayez wrote: > I was wondering about people's experience with the UHD driver on the E100 or the Beagleboard. I am able to use it to receive IQ data from the USRP but I can't seem to transmit anything from it ... if I take the same flowgraph to a laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD driver however when I try to run the same transmitter on the Beagleboard and I check my spectrum analyzer I don't see anything > > I already did a signal capture before sending to the USRP and made sure that there is data getting pushed through ... is there a problem with UHD/USRP sinking on the E100 and the Beagleboard ??? I also made sure that I'm using the latest UHD firmware on the beagleboard. > > > The following is the version info printed when I run the flowgraph: > linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; UHD_0001.20110224034946.1 Al, Which USB port are you using to connect the USRP1? What kernel version? Can you run dmesg and see if there are any usb related messages at the end? Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FM Receiver
Hi I am using an USRP N210 with GNU radio, UHD and GRC on Ubuntu 10.10. I have connected a WBX daughterboard to the USRP. I want to receive and, of course, listen the radio thanks to this system. I have built a flow graph and when I execute it, I only heard noise and can see this message in the terminal : linux; GNU C++ version 4.4.5; Boost_104200; UHD_002.20110206225409.aea6ac1 >>> gr_fir_fff: using SSE Current recv sock buff size: 5000 bytes Warning: error in pthread_setschedparam Failed to set thread priority 0.5 (realtime): Performance may be negatively affected. See the general application notes. Warning: error in pthread_setschedparam Failed to set thread priority 0.5 (realtime): Performance may be negatively affected. See the general application notes. mboard0 MIMO master Warning: error in pthread_setschedparam Failed to set thread priority 0.5 (realtime): Performance may be negatively affected. See the general application notes. >>> gr_fir_ccc: using SSE aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU I have looked on the internet and tried different things but nothing has changed. Could someone give me an hand to solve with problem ? Thank you very much, Francois -- View this message in context: http://old.nabble.com/FM-Receiver-tp31009069p31009069.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] FM Receiver
gr_fir_ccc: using SSE > aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU > These characters being printed means that you have mismatched sample rates between your USRP device and sound card. Could this be the case? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CALL FOR PAPERS -- IEEE GLOBECOM 2011 Signal Processing for Communications Symposium
Please accept our apologies if you receive multiple copies of this Call for Papers (CFP). _ IEEE GLOBECOM 2011 - Signal Processing for Communications Symposium 5-9 December, Houston, Texas, USA Paper Submission Deadline: 1 March 2011 Authors are invited to submit original technical papers in the following and other related topics. Adaptive Antennas and Beamforming Blind Signal Processing for Communications Channel Characterization, Estimation, Modeling and Equalization Multi-user Systems SISO, SIMO, MISO, MIMO Systems Single-carrier, OFDM and Multi-carrier Systems Novel Signal Processing in LTE/LTA and Other Emerging Systems New Signal Processing Techniques in CDMA or WCDMA Space-Time Processing and Decoding Signal Detection and Synchronization Software Defined and cognitive Radio Text, Speech, Image and Video Signal Processing Multimedia Communication Technologies Spectrum Shaping and Filters Signal Processing for Spatial, Temporal, Code and Spectral Diversities Transmitter, Receiver, Modulation and Coding Techniques Adaptive Signal Processing and Processing for Security Privacy Collaborative Communication and Positioning Cognitive and Affective Computing Human Communication Behavior, Emotion and Feeling Recognition Sensor Information Fusion Green and Sustainable Communication Techniques For guidelines and submission instructions, please visit http://www.ieee-globecom.org/2011/cfp.html Yunxin (Jeff) Li (Ph.D.) Principal Researcher NICTA, 13 Garden Street Eveleigh, NSW 2015 Australia Tel: +61 2 8306 0741 Fax: +61 2 9376 2027 E-mail: jeff...@nicta.com.au The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM Receiver
Hi Josh, Yes, I have already though about that and I tried to match the sample and sound card rates without success (but I might made a mistake). I have also read on the Internet that it might come from the sound card which cannot support all rates but I did not find anything more about that subject. Here the python code generated by GRC : http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py Francois Josh Blum-2 wrote: > > > gr_fir_ccc: using SSE >> aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU >> > > These characters being printed means that you have mismatched sample > rates between your USRP device and sound card. Could this be the case? > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/FM-Receiver-tp31009069p31009164.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] FM Receiver
I have run into this problem on the Beagleboard ... here's my explanation for what I think is happening and the fix. What's happening is GNU Radio is trying to run as a real time thread which if you're root or you've given your Linux username permission to have rtprio privileges but for some reason I also ran into the problem where I can't get realtime scheduling privileges. The parametes of interest to fix this problem are cat /proc/sys/kernel/sched_rt_runtime_us output = 95 cat /proc/sys/kernel/sched_rt_period_us output = 100 now sched_rt_period_us controls the scheduling period in your processor and sched_rt_runtime_us controls how much of that period is reserved for realtime processing. When you read the associated driver documentation it says to disable this segmenting for the realtime period partitioning you need to set sched_rt_runtime_us to -1 or you can completely disable this feature in your kernel by "make menuconfig" in your kernel driver directory ... my preference is not to mess with drivers so I set it to -1 with echo -1 > sched_rt_runtime_us now when you run cat /proc/sys/kernel/sched_rt_runtime_us output = -1 Now you should be able to use realtime scheduling in GNU Radio. I'm not sure if this is a good fix because it might give background processes realtime privileges which would defeat the purpose of the realtime designation ... for me I'm running console Linux on the Beagleboard so it's an acceptable solution. As an alternative approach you might try to use the Linux "nice" and "renice" programs to tweak thread priority but I personally wans't successful with this approach. al fayez -Original Message- From: Anoth To: Discuss-gnuradio Sent: Thu, Feb 24, 2011 6:59 pm Subject: [Discuss-gnuradio] FM Receiver Hi I am using an USRP N210 with GNU radio, UHD and GRC on Ubuntu 10.10. I have connected a WBX daughterboard to the USRP. I want to receive and, of course, listen the radio thanks to this system. I have built a flow graph and when I execute it, I only heard noise and can see this message in the terminal : linux; GNU C++ version 4.4.5; Boost_104200; UHD_002.20110206225409.aea6ac1 >>> gr_fir_fff: using SSE Current recv sock buff size: 5000 bytes Warning: error in pthread_setschedparam Failed to set thread priority 0.5 (realtime): Performance may be negatively affected. See the general application notes. Warning: error in pthread_setschedparam Failed to set thread priority 0.5 (realtime): Performance may be negatively affected. See the general application notes. mboard0 MIMO master Warning: error in pthread_setschedparam Failed to set thread priority 0.5 (realtime): Performance may be negatively affected. See the general application notes. >>> gr_fir_ccc: using SSE aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU I have looked on the internet and tried different things but nothing has changed. Could someone give me an hand to solve with problem ? Thank you very much, Francois -- View this message in context: http://old.nabble.com/FM-Receiver-tp31009069p31009069.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Periodically varying channel gain mesurements
Hi, I'm using Ubuntu 10.04 with a recent gnuradio-next branch and the UHD driver on USRP2/WBX boards. In an outdoor setup I have two receiving nodes about 40m away from each other and from the transmitter. The transmitter is a PC with two USRP2s connected with a MIMO cable. It is sending two different PN sequences every 120ms on both interfaces at the same time. I correlate the known sequences at the receivers to measure the channel gain. The results can be seen here (x-axis is the packet number, y is the absolute gain): http://cs.ucsb.edu/~veljko/downloads/channel_gains_outdoor.jpg The gain seems to be varying with around 2 Hz frequency. Since the setup is static and the tx/rx gain is not modified during the course of the experiment I'm almost certain that the artefact comes from the system rather than from the environment. Does anyone have a good explanation for this? Perhaps there is some sort of a gain control in the USRP2 that I'm not aware of? I got similar behavior when I tried the same experiment indoors. Thanks, Veljko ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Periodically varying channel gain mesurements
> The gain seems to be varying with around 2 Hz frequency. Quite possible, the WBX transmit has an analog power control loop formed by the ADL5386. The "gain" setting on WBX transmit is really more of a setpoint for the power control loop than gain Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM Receiver
On Thu, Feb 24, 2011 at 7:17 PM, Anoth wrote: > > Hi Josh, > > Yes, I have already though about that and I tried to match the sample and > sound card rates without success (but I might made a mistake). I have also > read on the Internet that it might come from the sound card which cannot > support all rates but I did not find anything more about that subject. Here > the python code generated by GRC : > http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py > > Francois I think Josh is right and it's a sampling rate error. When you set the sampling rate of the USRP, ask the UHD driver what the current sampling rate is. Use what it returns to you to adjust the sampling rate properly. I ran into this same issue and solved it by using the pfb_arb_resampler block (Polyphase Resampler in GRC) to adjust the rates correctly. Tom > Josh Blum-2 wrote: >> >> >> gr_fir_ccc: using SSE >>> aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU >>> >> >> These characters being printed means that you have mismatched sample >> rates between your USRP device and sound card. Could this be the case? >> >> -josh >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > -- > View this message in context: > http://old.nabble.com/FM-Receiver-tp31009069p31009164.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 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to stop the top_block and restart signal transmission
> The version of GNUradio that I'm using is GNURadio 3.2svn > I think there was some work in 3.3 for this sort of issue, but thats just from memory, as I mostly use UHD these days. Things you might look for: python -c "from grc_gnuradio import usrp as grc_usrp; help(grc_usrp.simple_usrp.simple_sink_c)" there should be a set_enable() function on simple_sink_c which to the best of my recollection would enable/disable the transmitter Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fm blocks
2011/2/24 Ingmar Meins : > If I remember correctly the audio rate is literally the data rate your sound > card is sampling at eg 32kHz or 44.1kHz and quad rate is the incoming rf > sampling rate. For example you may have sampled your RF at 128kHz and be > running your audio (or whatever) at 32kHz. Yes, that's it. If, for a simple example, you have: sig_source_f -> nbfm_tx -> usrp_sink_c The audio rate would be the rate from the signal source and the quadrature rate would be the output rate of the nbfm_tx that you send to the URSP sink (usrp ADC rate / interp). Tom > On 24/02/2011 11:45 PM, ömer günay wrote: > > I am trying to do sdr radar. I will send linear fm modulated signal and > then take it. I am seaching fm modulating blocks in grc. I ran some examples > but could not understand it is true or not. I also looked nbfm and wbfm > transmitter and receiver blocks in grc but i could not find any documents > about these blocks. For example what do audio_rate and quadrature_rate mean? > I must do linear fm transmitter and receiver for our project. Could you help > me if you have any documents or opion? > > ___ > 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 > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] operation order in freq_xlating_fir
On Thu, Feb 24, 2011 at 12:18 PM, Alberto Trentadue wrote: > Hello > > Just to make sure, may anybody please confirm the sequence of operations > within the freq_xlating_fir_filter? > > Is it: > in --->XLATE--->FILTER--->DECIM---> out > > When defining the FIR taps with firdes, shall I consider the input sampling > freq or the output sampling freq (= input > sampling freq / decim) ? > > Thanks in advance > > Alberto Alberto, Not having looked at the guts of this block for a while, I would hope that it's: > in--->FILTER--->DECIM --->XLATE---> out Since we would want to perform the frequency shift at the lower sampling rate (it's easy enough to translate an LPF to a BPF). But the implementation doesn't really matter for you main question. Either way will work and will work the same. You'll want to specify the taps based on the input sampling rate. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Periodically varying channel gain mesurements
On Thu, Feb 24, 2011 at 16:54, Veljko Pejovic wrote: > > I'm using Ubuntu 10.04 with a recent gnuradio-next branch and the UHD > driver on USRP2/WBX boards. > In an outdoor setup I have two receiving nodes about 40m away from > each other and from the transmitter. The transmitter is a PC with two > USRP2s connected with a MIMO cable. It is sending two different PN > sequences every 120ms on both interfaces at the same time. I correlate > the known sequences at the receivers to measure the channel gain. The > results can be seen here (x-axis is the packet number, y is the > absolute gain): > > http://cs.ucsb.edu/~veljko/downloads/channel_gains_outdoor.jpg > > The gain seems to be varying with around 2 Hz frequency. Since the > setup is static and the tx/rx gain is not modified during the course > of the experiment I'm almost certain that the artefact comes from the > system rather than from the environment. Does anyone have a good > explanation for this? Perhaps there is some sort of a gain control in > the USRP2 that I'm not aware of? I got similar behavior when I tried > the same experiment indoors. > This looks like the effect of timing skew between the transmitters and receivers. Your correlation magnitude will vary in time with a period related to how long it takes for the receiver sample times to "slide" through one PN chip length. One way to test whether this is the case is to (temporarily) lock both the transmitter and receiver to the same external 10 MHz reference; your correlation magnitudes should then be the same (with some small noise variance.) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] High CPU usage
On Thu, Feb 24, 2011 at 12:20 AM, peng senl wrote: > Hello, > > I am using a C++ interface with the USRP2 board. I found the CPU usage is > about 30% for dual core 3.2G CPU with 5M sample frequency while about 60% > usage for 20M sample frequency. I am just keep running the rx_sample() > function without any other operation. Is this CPU usage normal? I think it > is too high. Is there any method to optimize it? The legacy driver or UHD? Are you using 32-bit complex floats or 16-bit complex shorts for you data? I'd be very interested to hear your benchmarking of the different types here. That is UHD/32fc vs. USRP2/32fc and UHD/16sc vs. USRP2/16sc. Also, UHD/32fc vs. UHD/16sc. One of the issues is that the samples are coming over the wire in 16-bit shorts and must be converted from big to little endian and then from short to float. There is some vectorization we can do for this (SIMD stuff) to speed up both parts of this conversion. Having played with it in the USRP2 driver (pre-UHD), I remember seeing a 20% improvement by vectorizing the endian and short to float conversions. You could potential squeak even more out of it. I'm not sure, but Josh might have already vectorized this process in UHD. If not, I'm sure he will soon. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem editing GNURadio C++ Files
Hello, I'm interested in editing some of the source and sink .cc files. On my older laptop I have obtained GNURadio from the terminal using the build instructions. I am able to locate the .cc files I am interested in editing. On my newer laptop I installed GNURadio and GRC using the synaptic package manager. I can get GRC to work just great but I am interested in modifying the .cc files. I have searched extensively in the entire file system on my new laptop and I cannot find the same .cc files that are on my older laptop with the manual installation. The only thing I could find was the header files and the .xml files but not the .cc C++ files. Does anyone know if I have to work with a manual installation if I am interested in modifying the C++ files? Will the modified .cc files still work with GRC generated scripts? The dilemma is that I like using GRC because it is easy for a beginner who doesn't have much python experience but I need to make some modifications to some of the sink and sources like gr_file_source and gr_file_sink Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM Receiver
Yes, you must be right, I must have made a mistake when I set up the flow graph. How do you know the sample rate delivered by the UHD and how is the Polyphase Resampler implemented into the flow graph ? Francois Tom Rondeau wrote: > > On Thu, Feb 24, 2011 at 7:17 PM, Anoth wrote: >> >> Hi Josh, >> >> Yes, I have already though about that and I tried to match the sample and >> sound card rates without success (but I might made a mistake). I have >> also >> read on the Internet that it might come from the sound card which cannot >> support all rates but I did not find anything more about that subject. >> Here >> the python code generated by GRC : >> http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py >> >> Francois > > I think Josh is right and it's a sampling rate error. When you set the > sampling rate of the USRP, ask the UHD driver what the current > sampling rate is. Use what it returns to you to adjust the sampling > rate properly. I ran into this same issue and solved it by using the > pfb_arb_resampler block (Polyphase Resampler in GRC) to adjust the > rates correctly. > > Tom > > >> Josh Blum-2 wrote: >>> >>> >>> gr_fir_ccc: using SSE aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU >>> >>> These characters being printed means that you have mismatched sample >>> rates between your USRP device and sound card. Could this be the case? >>> >>> -josh >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/FM-Receiver-tp31009069p31009164.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 >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/FM-Receiver-tp31009069p31010011.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] FM Receiver
On Thu, Feb 24, 2011 at 10:28 PM, Anoth wrote: > > Yes, you must be right, I must have made a mistake when I set up the flow > graph. How do you know the sample rate delivered by the UHD and how is the > Polyphase Resampler implemented into the flow graph ? > > Francois Not entirely sure how to do this in GRC... When you set the sample rate of the UHD device, you can request back what it was actually set to using "get_samp_rate". So if you were doing this just in Python, you can have: req_sr = SR act_sr = uhd.get_samp_rate() resamp_rate = req_sr / act_sr resampler = blks2.pfb_arb_resampler(resamp_rate) Unless, of course, it's "resamp_rate = act_sr/req_sr". I've been working too long today to reason that out. I'm sure there is a way to do this in GRC by knowing the name of the UHD device and using it; I've just never done it. Tom > Tom Rondeau wrote: >> >> On Thu, Feb 24, 2011 at 7:17 PM, Anoth wrote: >>> >>> Hi Josh, >>> >>> Yes, I have already though about that and I tried to match the sample and >>> sound card rates without success (but I might made a mistake). I have >>> also >>> read on the Internet that it might come from the sound card which cannot >>> support all rates but I did not find anything more about that subject. >>> Here >>> the python code generated by GRC : >>> http://old.nabble.com/file/p31009164/wfm_rx.py wfm_rx.py >>> >>> Francois >> >> I think Josh is right and it's a sampling rate error. When you set the >> sampling rate of the USRP, ask the UHD driver what the current >> sampling rate is. Use what it returns to you to adjust the sampling >> rate properly. I ran into this same issue and solved it by using the >> pfb_arb_resampler block (Polyphase Resampler in GRC) to adjust the >> rates correctly. >> >> Tom >> >> >>> Josh Blum-2 wrote: gr_fir_ccc: using SSE > aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU > These characters being printed means that you have mismatched sample rates between your USRP device and sound card. Could this be the case? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/FM-Receiver-tp31009069p31009164.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 >>> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > -- > View this message in context: > http://old.nabble.com/FM-Receiver-tp31009069p31010011.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 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Weird (or maybe not) received signal amplitude behaviour
Hi List, I'm transmitting a pure sinusoid of 50kHz using the tx_waveforms UHD example and receiving the same using rx_samples_to_file example. I'm using N210/WBXs for Tx and Rx at 250MHz, at 500 ksps, --ampl=1.0, buffer size of 200 at Tx, and 0 dB for Rx,Tx gain. I plot the received file (the I stream, after de-interleaving the complex shorts) using gnuplot and here's what I see. The peak to peak amplitude is 40. The wave's dancing nicely about 0 and its a spectacular sine wave at almost precisely 50 kHz. But here's the catch: I can see this happening only after about sample # 8000 thereabouts in the graph. Before this, the wave starts out (at sample # 10 ) at 1400-1440 peak to peak and gradually makes its way down(maintaining its sinusoidal shape during the descent) to settle at -20 to +20 peak to peak. It takes 8000 samples for this to happen, or 8000*2us = 16ms. Why is this happening? Arya P.S. At Tx/Rx gains of 15 dB, same thing happens but the signal starts at around 1000-2000 p2p and settles at -500 to 500 at around sample #6000. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC + N210 + RFX2200 + UHD not working
On 02/24/2011 09:43 PM, Phelps Williams wrote: > I'm using grc to generate some extremely simple flowgraphs but I'm seeing > very odd performance. Any idea why I can't seem to get this combination to > work? I have had success with a GRC + USRP2 + WBX + UHD, anybody know why > I'm having issues here? > Are you saying that if you run the same flow graph, host pc, ethernet port, and software install on the USRP2 + WBX, you do not see this problem? I am confused about the one hardware not working while the other does, because its functionally identical. Just wondering if we can isolate this problem to a particular machine, software install, etc... instead. > UHD source block got error code 0x1 > gr_block_executor: source produced no > output. We're marking it DONE. > This is the call to recv() on the udp socket timing out. Either data isnt coming over the ethernet cable for some reason recv()/select() error-ed. In any case, do you mind trying the next branch? In the uhd repo: git remote update git branch --track next origin/next git checkout next cd host/build && make install.. and for gnuradio git remote add jblum git://gnuradio.org/jblum.git git remote update git branch --track gr_uhd_next jblum/gr_uhd_next git checkout gr_uhd_next make install... -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Weird (or maybe not) received signal amplitude behaviour
On 02/24/2011 10:13 PM, Arya Santini wrote: > Hi List, > > I'm transmitting a pure sinusoid of 50kHz using the tx_waveforms UHD > example and receiving the same using rx_samples_to_file example. I'm > using N210/WBXs for Tx and Rx at 250MHz, at 500 ksps, --ampl=1.0, > buffer size of 200 at Tx, and 0 dB for Rx,Tx gain. > Can you repeat the results with the default amplitude? An amplitude of 1.0 is maximum, and could lead to clipping in the FPGA DUC. -josh > I plot the received file (the I stream, after de-interleaving the > complex shorts) using gnuplot and here's what I see. The peak to peak > amplitude is 40. The wave's dancing nicely about 0 and its a > spectacular sine wave at almost precisely 50 kHz. But here's the > catch: I can see this happening only after about sample # 8000 > thereabouts in the graph. Before this, the wave starts out (at sample > # 10 ) at 1400-1440 peak to peak and gradually makes its way > down(maintaining its sinusoidal shape during the descent) to settle at > -20 to +20 peak to peak. It takes 8000 samples for this to happen, or > 8000*2us = 16ms. > > Why is this happening? > > Arya > > P.S. At Tx/Rx gains of 15 dB, same thing happens but the signal starts > at around 1000-2000 p2p and settles at -500 to 500 at around sample > #6000. > > ___ > 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
[Discuss-gnuradio] FTW 802.11 ofdm encoder, sending multiple packages
Hello @All, i’m working on a project using the FTW 802.11 ofdm encoder Project from Cgran on Ubutntu 10.04 and Gnuradio3.2.2, Python 2.6 , USRP2 RFx2400. Transmitting single Frames works fine. I want to send multiple packages, so i modified the send_pkt function in the ftw.ofdm.py file and call the “self._pkt_input.msgq().insert_tail(msg) twice. ( and only EOF is send) Both messages from the msgq are consumed, but only the first frame is transmittet. The script stops at tb.wait(). After reading a bit about the GR scheduler i guess there is a problem with the set_output_rate in the ftw_ofdm_preamble.cc ( line 52 ) Is there a way to set the output_rate without knowledge about the numbers of symbols per frame? (or is everything ok with the set_output_rate, and the error is somewhere else?) My frame consists of 2 symbols, each a vector of 80 elements after the passing the ofdm_mapper, pilot,cmap,ifft, cpadder, scale and strem2vec. (64QAM and 9 Byte payload) The preamble has 320 items. Divided by 80 the preamble is 4 symbols long. So the output is 6 symbols. Is that right? Has anybody else tried to send multiple frames? (without calling the whole script again) Where can I find more information about the output_rate and scheduler? Thanks for your help, Hans -- View this message in context: http://old.nabble.com/FTW-802.11-ofdm-encoder%2C-sending-multiple-packages-tp31010536p31010536.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
