SV: [Discuss-gnuradio] GRC + N210 + RFX2200 + UHD not working
Just a thought: I see the same warnings, when I "forget" to run grc with correct priviliges (sudo). John Fra: discuss-gnuradio-bounces+jr=iha...@gnu.org [discuss-gnuradio-bounces+jr=iha...@gnu.org] På vegne af Phelps Williams [phel...@gmail.com] Sendt: 25. februar 2011 06:43 Til: discuss-gnuradio@gnu.org Emne: [Discuss-gnuradio] GRC + N210 + RFX2200 + UHD not working 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? When I create a flowgraph directly to a null sink (null.png) I receive the following error: Generating: "/home/pwilliams/gnuradio_test/video_tx/top_block.py" Executing: "/home/pwilliams/gnuradio_test/video_tx/top_block.py" linux; GNU C++ version 4.4.1; Boost_103800; UHD_002.20110219191607.c912463 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. UHD source block got error code 0x1 gr_block_executor: source produced no output. We're marking it DONE. When I create a flowgraph directly to a fftp sink (fft.png) it just silently exits with no errors: Generating: "/home/pwilliams/gnuradio_test/video_tx/top_block.py" Executing: "/home/pwilliams/gnuradio_test/video_tx/top_block.py" linux; GNU C++ version 4.4.1; Boost_103800; UHD_002.20110219191607.c912463 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. >>> Done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
Hi, Paul Thanks for your description. I finally figure out the problem that the Gigabyte Ethernet Card in my computer does not support Gigabyte. Either it is because of driver problem or itself. After using another good Ethernet card, it works smoothly. :) I have another question for FTW OFDM, in which I wanna implement the transmit-wait-transmit scenario. Specifically, I tried to transmit some data stream first, sleep for a few second and then transmit another one. $ sudo python ftw_ofdm_tx.py -e eth1 -f 2.462G -i 5 --regime=3 -g 30 -r 1 However, from the spectrum I have observe, it seems USRP2 keeps generating the same signal, without any sleeping or waiting time. By looking into the codes, I found msgq() seems to be fine. Also, when there is no payload, EOF set to true, telling the msgq() no more messenge. Then, what is the possible reason for my problem? Any suggestions are appreciated! Thanks, Guanbo On Tue, Feb 22, 2011 at 7:40 AM, Paul Fuxjäger wrote: > Guanbo ZHENG wrote on 22.02.11 00:36: > > > The frequency band is correct. Just now, I re-install the repository from > > the CGRAN, and tried again using: > > sudo python ftw_ofdm_tx.py -f 2.462G -i 5 --regime=8 --payload="Here are > > some test messages from WiSeR" -r 1 > > So the only question is, I have NOT updated my firmware. I will try that > as > > well. > > We used the XCVR2450 only so far. In our experience, the most common > reasons > why it fails are: > > 1) channel on the RX side is not set to the one you use at TX > 2) TX gain is too high or too low (depending on what kind of antennas and > "channel environment" you are using) > 3) old USRP2 firmware bug (try also with -s option and see if it changes > the > behavior) see documentation https://www.cgran.org/wiki/ftw80211ofdmtx > 4) try also with -r 1 and -r 0 (the repetition method we used in the code > is > very dirty) > > > By the way, what does the USRP2 generated packet look like in Wireshark > at > > another laptop? > > Ideally, you would tick the "capture using promiscuous mode" and "capture > using monitor mode" in the Wireshark GUI. Then you should see *every > PHY-valid frame whatsoever* the card is able to decode on the channel that > it is currently listening on. Make sure it does work like that. E.g. do you > see beacons of the access-points nearby? > > The link-layer header-type should be "802.11 plus radiotap header" and you > should see the radiotap headers appended to every frame. > > If you have it available you can also use cmd-line tool called athstats to > debug. You can get access to some atheros-specific counters with it, like > how many frame-detected events per seconds are registered by the NIC. > > > > If all of this doesnt help there is this method to find out if the problem > is in HW/GNUradio subsystem or on the encoder/decoder side: > > Try to generate frames using the Atheros NIC and record the signal (a block > of baseband to disk) using the USRP2 with rx_cfile.py. Then put the Atheros > in monitor mode again and transmit this very baseband block using > transmit.py we included in the ftwofdm release (in src/matlab). > > You have to use the same USRP2 for recording/transmission, and you should > not wait too long between RX/TX because of potential frequency offsets. > > If this "record-playback" does not work there is still something wrong in > your current XCVR2450/USRP2/GNUradio subsystem. If it does work our encoder > is the source of the problem :( > > > cheers > paul > > > > > -- > Dipl.-Ing. Paul Fuxjaeger > FTW - Telecommunications Research Center Vienna > http://www.ftw.at callto://:paul.fuxjaeger.at.work > PSTN:+43-1-505283057 | 3GPP:+43-676-4787088 > > -- Regards, Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Adding dual usrp sink block to benchmark_tx.py
Hello everyone, I've added a dual usrp sink block and duplicated the tx flow graphs in benchmark_tx.py example. However, I am unable to transmit packets when I set the following in the flow graph: self.packet_transmitter = \ blks2.mod_pkts(modulator, access_code=None, msgq_limit=4, pad_for_usrp=True) self.packet_transmitter_2 = \ blks2.mod_pkts(modulator_2, access_code=None, msgq_limit=4, pad_for_usrp=True) self.connect(self.packet_transmitter, self.amp, (self, 0)) self.connect(self.packet_transmitter_2, self.amp_2, (self, 1)) I have tried the following 2 codes and were able to transmit packets from the first flow graph, and then the packets from the second flow graph: self.connect(self.packet_transmitter, self.amp, (self, 0)) self.connect(self.null_source, self.amp_2, (self, 1)) self.connect(self.null_source, self.amp, (self, 0)) self.connect(self.packet_transmitter_2, self.amp_2, (self, 1)) Any idea why I am unable to simultaneously transmit packets from both flow graphs? Thanks in advance! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Moeller on 2011-02-25 17:36: > On 24.02.2011 15:46, Patrick Strasser wrote: >> 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. > > But I think it's a big difference in signal quality. For sure. You ged rid of the quality decrease from all the long analog lines. Moreover it frees your computer audio interface for AF input and output. Most computers are not shipped with two audio interfaces. > Do you know the theoretical limits for the sample rate? Common USB Audio adheres to USB Audio Class 1, which was specified for USB 1.1. The data structures allow sample rates to over 4MHz, but USB 1.1 is the limiting factor with its bandwidth: (12MiBit/second)/(16bit/Sample)/(2 Channels)=384kiSPS. That is without protocol overhead, so you can theoretical expect 16bit 192kSPS stereo as maximum. It turns out that not every OS driver supports this data rate, rather 96kiSPS. Moreover you have to deal with different clock speeds and other subtleties. Just putting USB Audio Class 1 on USB 2.0 would not work, because blocks are structured different between 1.1 and 2.0. But back in 2005 USB Audio Class 2 (UAC2) was adopted, offering notably higher sampling rates and bit depths. Apple introduced a UAC2 in Mac OSX 10.6, And Linux has good support since 2.6.34 or .35. Microsoft promised to implement a UAC2 driver for its upcoming Windows incarnations, but nothing on the horizon until now. The SDR widget people sounded every possible combination for the mentioned OSes, with lots of tricks to get the very best out of every driver (especially Windows UAC1). They have different firmware for UAC1 and UAC2. I just read some articles from the SDR widget list and had a conversation with the Linux driver author, maybe I got some details wrong. > Can it fill the full USB bandwidth or does it only accept > "standard audio" sample rates? You can set every integer sampling rate you like withing the capacity limit, but most drivers expect the common sampling rates. The drivers are the limiting factor. And still synchronization of clocks is a big problem. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On 26.02.2011 11:36, Patrick Strasser wrote: > Just putting USB Audio Class 1 on USB 2.0 would not work, because blocks > are structured different between 1.1 and 2.0. That was my hope, but I didn't check the specs if it would be possible. > But back in 2005 USB Audio Class 2 (UAC2) was adopted, offering notably > higher sampling rates and bit depths. Apple introduced a UAC2 in Mac OSX .. > The SDR widget people sounded every possible combination for the > mentioned OSes, with lots of tricks to get the very best out of every > driver (especially Windows UAC1). They have different firmware for UAC1 > and UAC2. UAC2 with USB3 would be a good combination. With the "usb3" "uac2" keywords in Google you find some developments for a "USB Super Speed patch" in USB3 audio drivers. I think it's realistic because UAC2 is supported in Linux and USB3 is now common in modern PC. With about 5 Gbit/s it allows broadband SDR solutions, hopefully also low-cost ones. > You can set every integer sampling rate you like withing the capacity > limit, but most drivers expect the common sampling rates. The drivers > are the limiting factor. At least in Linux you can tune the drivers if you want. > And still synchronization of clocks is a big problem. Sync problems? I thought, the "audio" devices implement a fixed sampling clock and the USB transmission is buffered to achieve a continuous stream without gaps or clock variations. Only the PC audio output has a different clock, but that problem occurs with other external sources too, like the USRPs. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW 802.11 ofdm encoder, sending multiple packages
Hi, i mean different packages. The -r / -- repetition option works well, but i want to send a sequence of different frames later, of course with a modificated parsing later. Sankalp Nimbhorkar wrote: > > You should be able to send multiple packets using -r option (0 for > unlimited). > > On Fri, Feb 25, 2011 at 1:31 AM, Hans-Christian > wrote: > >> >> 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 >> > > > > -- > Sankalp Nimbhorkar > CSC Graduate Student > North Carolina State University > > ___ > 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/FTW-802.11-ofdm-encoder%2C-sending-multiple-packages-tp31010536p31019577.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] Multirate Blocks
Hi, I'm implementing a 2-FSK modulator (I Know that a good one already exists but i have to do it myself for academic purpose). To do so, i produce a given (N) number of samples corresponding to the sampling of a complex exponnetial for each incoming bits. The "sampling rate" (one bit => N samples) is increased by N through the modulator, so i'm doing this Constructor:set_relative_rate(N); set_output_multiple(N); General_work: consume_each(noutput_items/N); Is that correct? and is there anything else to do? Thanks in advance, Antoine Dedave___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multiple tabs
hi can anybody help me out in creating multiple tabs in a single output window.eg.one tab indicating RF spectrum second IF spectrum and so on.. Thanks in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Next Developer's Call RFC
Johnathan and I would like to schedule our next developer's call for Monday, March 7 and soliciting suggestions for the time. Again, it will be done over the SIP bridge and last for an hour. As I have mostly heard back from people in the EU regarding the time of the last call, we expect that this next call will be held at a time more reasonable to the people in and around Europe's timezones. We are currently thinking 6 PM for central Europe, but we would like to hear back from those of you who are interested in joining this call to let us know your time availability/preferences. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Next Developer's Call RFC
On 02/26/2011 11:57 AM, Tom Rondeau wrote: Johnathan and I would like to schedule our next developer's call for Monday, March 7 and soliciting suggestions for the time. Again, it will be done over the SIP bridge and last for an hour. As I have mostly heard back from people in the EU regarding the time of the last call, we expect that this next call will be held at a time more reasonable to the people in and around Europe's timezones. We are currently thinking 6 PM for central Europe, but we would like to hear back from those of you who are interested in joining this call to let us know your time availability/preferences. Can you give times in UTC? This might be handy: http://www.worldtimeserver.com/meeting-planner.aspx Even: http://www.worldtimeserver.com/meeting-planner-times.aspx?&L0=US-VA&L1=US-CA&L2=DE&L3=&L4=&Day=5&Mon=3&Y=2011 Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Next Developer's Call RFC
On Sat, Feb 26, 2011 at 3:00 PM, Philip Balister wrote: > On 02/26/2011 11:57 AM, Tom Rondeau wrote: > >> Johnathan and I would like to schedule our next developer's call for >> Monday, >> March 7 and soliciting suggestions for the time. Again, it will be done >> over >> the SIP bridge and last for an hour. As I have mostly heard back from >> people >> in the EU regarding the time of the last call, we expect that this next >> call >> will be held at a time more reasonable to the people in and around >> Europe's >> timezones. We are currently thinking 6 PM for central Europe, but we would >> like to hear back from those of you who are interested in joining this >> call >> to let us know your time availability/preferences. >> > > Can you give times in UTC? No, I cannot. Actually, I will when a final time is selected. The "6 PM for central Europe" was designed to be annoyingly non-specific. > This might be handy: > > http://www.worldtimeserver.com/meeting-planner.aspx > > Even: > > > http://www.worldtimeserver.com/meeting-planner-times.aspx?&L0=US-VA&L1=US-CA&L2=DE&L3=&L4=&Day=5&Mon=3&Y=2011 > > Philip > Thanks for the links! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Josh, When you say "2x" performance increase, do you mean CPU performance or send()/recv() latency? Do you mind saying a few words on what changes you have made? Andrew On 02/26/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: --- -- highlights of this announcement --- - 2x performance increase - addition of sensors api - re-clocking support - gr-uhd api changes - stability + changes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build error GNU Radio release v3.3.1git-971-ga02bb131
Hi List, I was trying to build the gnuradio on yet another machine running Ubuntu 10.10. from source today after checking out the latest code from the dev trunk: git clone http://gnuradio.org/git/gnuradio.git Then I set the branch to next, so that I can build gr-uhd as well. (Prior to this I'd successfully built and installed UHD) After ./bootstrap, ./configure (reports most of the components (that I want) will be built, including uhd), I run make and get the following error, when make enters the /host/swig directory make[6]: Entering directory `/home/siva/calit2/gnuradio/usrp/host/swig' The reported bunch of errors are: starts from: python/usrp_prims.cc:2850:13: error: ‘ptrdiff_t’ does not name a type ... ... make[6]: *** [_usrp_prims_la-usrp_prims.lo] Error 1 ends after make exits the build tree... Help? Arya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
