[Discuss-gnuradio] software radio job post
In case anyone's interested, here's a USRP-related job post I came across: http://www.careerbuilder.com/JobSeeker/Jobs/JobDetails.aspx?job_did=J8E16D61YH5N8KVT9YY&cbRecursionCnt=1&cbsid=6846d2a4324a4baeae5432e37feb851b-319280912-x2-6 Posted the same thing to our LinkedIn group Dimitris Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Rebuilding the USRP2 Firmware in ISE 11.4
Just curious, Has anyone actually been able to rebuild the fpga bitfile using ISE 11.4? I loaded the files from the latest git and the .ucf, and I had 239 timing errors when the process completed. I just thought before I started ripping through it I would ask. Thanks, TMB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit
Hi Ed - Thanks for the feedback, it's useful; I don't mind being wrong! I'll have to set up my Mac to do multi-boot (10.5 and 10.6) in order to further test this issue out. That said, the kernel bit-tage doesn't really matter since it's the compiler that determines the applications bit-tage. My guess is that, just like under 10.5, one can compile and execute 64-bit applications ... but under 10.5, 32-bit was the default while under 10.6, 64-bit is the default. !...@#$% Apple for making all of this so %$#! complex ... I guess that's *&^% progress; not that I'm giving Linux cudos here for making the 32/64 bit "easy" I'll see if I can put some changes into the wxgui portfile so that it disallows 64-bit compiling for now, since that seems to be the common factor in the feedback I've received and in my testing. - MLD On Feb 12, 2010, at 10:00 AM, Ed Criscuolo wrote: Looks like you're wrong. I checked in system profiler, and under the software tab it shows 64-bit Kernel and Extensions:No Time since boot: 3 days 11:34 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Rohde and Schwarz ridiculous patent app. Sorry Ulrich
This patent must be fought tooth and nail. It is loaded with art which has been done MANY times before. I will be personally taking this on as a battle for my employers but we need all guns blazing at the patent office. Lockheed, General Dynamics, and more have done SDR units with red side/black side in it for JTRS but we just don't want R&S to be able to patent something so basic as this in a communications system. This should be on the radar for cellular telephone companies and more. Bob http://www.faqs.org/patents/app/20100027782 Inventors: Ingo Voll Boyd Buchin Dieter Soergel Agents: MARSHALL, GERSTEIN & BORUN LLP Assignees: Rohde & Schwarz GmbH & Co. KG Origin: CHICAGO, IL US IPC8 Class: AH04L918FI USPC Class: 380 42 Patent application number: 20100027782 Abstract: The invention relates to a device for processing datastreams in a communications unit with two mutually-separate data-processing regions, which provide at least two separate message paths. The message paths are connected respectively to a message transmitter and a message receiver, wherein, in each message path, an encoding module is provided, which is connected both to a first data-processing region and also to a second data-processing region. Furthermore, in the second data-processing region, a distribution unit is provided, which is connected to the message paths of the first data-processing region and to all encoding modules of the corresponding message paths in order to distribute given messages in a targeted manner. Claims: 1. Device for processing datastreams in a communications unit with two mutually-separate data-processing regions, which provide at least two separate message paths, which are connected respectively to a message transmitter and respectively to a message receiver,comprising,an encoding module in each message path connected both to a first data-processing region and to a second data-processing region, anda distribution unit connected to the message paths of the second data-processing region and to all encoding modules of the corresponding message paths for the targeted distribution of given messages. 2. Device according to claim 1, whereinthe first data-processing region is provided for processing of sensitive data, and the second data-processing region is provided for a processing of non-sensitive data. 3. Device according to claim 1, whereintest rules for data exchange between the various message paths of the first data-processing region are provided in each encoding module. 4. Device according to claim 1, whereinin a relay operating mode, a selective distribution of the datastream to the various message paths is provided. 5. Device according to claim 4, whereinthe selective distribution of the datastream is provided on the basis of different domains with an addressing and/or different classification with regard to confidentiality. 6. Device according to claim 1, whereintest rules for a configurable data exchange between the first data-processing region and the second data-processing region of a message path are provided in each encoding module. 7. Device according to claim 6, whereinthe test rules are address lists and/or other confidentiality tables. 8. Device according to claim 1, whereinin the case of an error, a data leakage from the first data-processing region is prevented. 9. Device according to claim 1, whereinan automatic testing of the incoming and/or outgoing communication between the message paths is provided in the encoding modules. 10. Device according to claim 1, whereina differentiation of the datastreams on the basis of a degree of confidentiality is provided. 11. Device according to claim 1, whereinthe distribution unit is connected to a configuration unit. 12. Device according to claim 6, whereinthe test rules are selectively configurable in the encoding modules. 13. Device according to claim 1, whereinat least one key capable of being read in from externally is stored in each encoding module. 14. Device according to claim 13, whereinthe key can be read in by a memory element. 15. Device according to claim 1, whereinthe various message paths meet different and/or the same communications standards. 16. Device according to claim 1, whereinthe communications unit is a radio device. 17. Device according to claim 1, whereineach message path is connected at a first end to an antenna and at a second end to a user interface. 18. Device according to claim 1, whereina bi-directional operating mode is provided at least for a subset of the message paths. 19. Method for processing datastreams in a communications unit, comprising processing the datastreams in two separate data-processing regions, and transporting the datastreams in at least two separate message paths between respectively a message transmitter and respectively a message receiver and are encoded or decoded in each case by an encoding modul
Re: [Discuss-gnuradio] installing new modules
Hi Affan - Glad to hear you're up and running, and using PPC and
10.5. If you're planning on using a USRP, I hope you have a USB 2.0
adapter ... those older PPC Macs didn't do USB 2.0 very well.
Hmm ... that's all quite strange; by default how-to is installed into /
usr/local , with the python stuff being in /usr/local/lib/
python{version}/site-packages , and {version} being 2.5 or 2.6 or
whatever. Unless you specifically told configure to install in a
strange location (e.g, via 'configure --prefix={somewhere}'), then the
only way how-to could be installed elsewhere is via symlink(s).
Can you reply with the following (off list, for now; we can summarize
if it's important):
* What is the command you used to configure the how-to module?
* Can you return the full output of 'make -n install' from the how-to.
* Can you run the following and return their outputs?
ls -ld /usr/local
ls -ld /usr/local/lib
ls -ld /usr/local/lib/python2.6
ls -ld /usr/local/lib/python2.6/site-packages
ls -l `which python`
env
- MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FPGA code for USRP2
Hi All, I need to make some modifications on the USRP2 board. It seems I cannot download the code from: git clone git://git.ettus.com/ettus/fpga.git. I don't know why. Does anyone know where I can get the Verilog codes and rebuild them? -- Best Regards! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Rohde and Schwarz ridiculous patent app. SorryUlrich
Bob, Having been down this road in a past life, this looks like a team of patent snakes cobbling together numerous individual claim parts so as to confuse the Patent Examiners into granting what used to be called a "Sales" Patent. You probably will have to argue that this is nothing more than a "Sales Patent" application using an underlying core concept (same as your Network Router) that the claims are dependent on, and that the core concept has been in "The Public Domain" for many years, so anyone "sufficiently skilled in the art" would be able to come up with the same or similar arrangement. Phil, K3IB - Original Message - From: "Bob McGwier" To: Cc: "GNURadio Discussion List" ; "openhpsdr" Sent: Friday, February 12, 2010 10:21 AM Subject: [Discuss-gnuradio] Rohde and Schwarz ridiculous patent app. SorryUlrich > This patent must be fought tooth and nail. It is loaded with art which > has been done MANY times before. I will be personally taking this on as > a battle for my employers but we need all guns blazing at the patent > office. Lockheed, General Dynamics, and more have done SDR units with > red side/black side in it for JTRS but we just don't want R&S to be able > to patent something so basic as this in a communications system. > > This should be on the radar for cellular telephone companies and more. > > > Bob > > > > > > http://www.faqs.org/patents/app/20100027782 > > Inventors: Ingo Voll Boyd Buchin Dieter Soergel > Agents: MARSHALL, GERSTEIN & BORUN LLP > Assignees: Rohde & Schwarz GmbH & Co. KG > Origin: CHICAGO, IL US > IPC8 Class: AH04L918FI > USPC Class: 380 42 > Patent application number: 20100027782 > > Abstract: > The invention relates to a device for processing datastreams in a > communications unit with two mutually-separate data-processing regions, > which provide at least two separate message paths. The message paths are > connected respectively to a message transmitter and a message receiver, > wherein, in each message path, an encoding module is provided, which is > connected both to a first data-processing region and also to a second > data-processing region. Furthermore, in the second data-processing > region, a distribution unit is provided, which is connected to the > message paths of the first data-processing region and to all encoding > modules of the corresponding message paths in order to distribute given > messages in a targeted manner. > Claims: > 1. Device for processing datastreams in a communications unit with two > mutually-separate data-processing regions, which provide at least two > separate message paths, which are connected respectively to a message > transmitter and respectively to a message receiver,comprising,an > encoding module in each message path connected both to a first > data-processing region and to a second data-processing region, anda > distribution unit connected to the message paths of the second > data-processing region and to all encoding modules of the corresponding > message paths for the targeted distribution of given messages. > > 2. Device according to claim 1, whereinthe first data-processing region > is provided for processing of sensitive data, and the second > data-processing region is provided for a processing of non-sensitive data. > > 3. Device according to claim 1, whereintest rules for data exchange > between the various message paths of the first data-processing region > are provided in each encoding module. > > 4. Device according to claim 1, whereinin a relay operating mode, a > selective distribution of the datastream to the various message paths is > provided. > > 5. Device according to claim 4, whereinthe selective distribution of the > datastream is provided on the basis of different domains with an > addressing and/or different classification with regard to confidentiality. > > 6. Device according to claim 1, whereintest rules for a configurable > data exchange between the first data-processing region and the second > data-processing region of a message path are provided in each encoding > module. > > 7. Device according to claim 6, whereinthe test rules are address lists > and/or other confidentiality tables. > > 8. Device according to claim 1, whereinin the case of an error, a data > leakage from the first data-processing region is prevented. > > 9. Device according to claim 1, whereinan automatic testing of the > incoming and/or outgoing communication between the message paths is > provided in the encoding modules. > > 10. Device according to claim 1, whereina differentiation of the > datastreams on the basis of a degree of confidentiality is provided. > > 11. Device according to claim 1, whereinthe distribution unit is > connected to a configuration unit. > > 12. Device according to claim 6, whereinthe test rules are selectively > configurable in the encoding modules. > > 13. Device according to claim 1, whereinat least one key capable of > being read in from externally is stored in each encodin
[Discuss-gnuradio] Using OFDM
Hello, I'm a begginer in GNU Radio and I need use the OFDM block. There is a OFDM.py (ofdm modulator and demodulator), but I don't kwon how use them and the examples are very confusing for me. Thanks -- Christian Pérez Fajardo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using OFDM
You can start from gnuradio-example/src/python/benchmark_ofdm_tx.py or benchmark_ofdm_rx.py. Bin 2010/2/12 Christian Pérez > Hello, I'm a begginer in GNU Radio and I need use the OFDM block. There is > a OFDM.py (ofdm modulator and demodulator), but I don't kwon how use them > and the examples are very confusing for me. > > Thanks > > -- > Christian Pérez Fajardo > > ___ > 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] high-level OFDM question
Hi there, before delving into the details of the OFDM implementation in GNURAdio I wanted to ask a high-level question: What is the method used for initial timing/frequency acquisition? Is there one or two training OFDM symbols that precede the transmission of data? and how many OFDM data symbols are following? Is this number determined by the first training symbols or is it fixed? Also, my understanding is that each data OFDM symbol has pilot tones for continuous frequency/timing tracking, right? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Firmware / FPGA bitstream for USRP2 Rev 4
Thanks for your response. Please find detailed explanations below. On Thu, Feb 11, 2010 at 8:50 PM, Matt Ettus wrote: > > On 02/11/2010 05:47 PM, Omid F wrote: >> >> Hi, >> >> I get a new Rev4 USRP2 two weeks ago, and have not yet been able to >> connect to it. >> >> I tried both the binary and the source code on different machines >> running different versions of Ubuntu (9.4, 9.10). I simply get "No USRP2 >> found." when I call find_usrps. > > Is there only one line of output that says No USRP2 found, or are there other lines of output? Are you using a release of GNU Radio or a build from git? I do "sudo find_usrps" and I only get one line of output that says No USRP2 found. I have tried both the binary and the git builds, but for the rest of this email I am using GNU Radio 3.2.2 installed from the binary distribution on Ubuntu 9.10 from the following source repositories: deb http://gnuradio.org/ubuntu stable main deb-src http://gnuradio.org/ubuntu stable main deb http://mirrors.kernel.org/ubuntu jaunty main universe >> >> I have reached a point that I am almost certain there is something wrong >> on the USRP2 side. The LEDs look fine though (6 of them flash at >> startup, 2 remain on). > > It is extremely unlikely that there is nothing wrong with your USRP2, as they are all 100% tested before shipping. There are many other variables. Is the USRP2 connected directly to the ethernet card? Are you certain it is a gigabit ethernet card? Can you send the output of dmesg after connecting the USRP2? Do you have a TTL serial adapter? I have connected the ethernet card (which is a gigabit one) directly to the USRP2 and assign a manual IP using "ifconfig eth0 10.0.0.2." This is the output from $lspci | grep Ethernet: 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03) 03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01) The output from dmesg | egrep '(eth0|Intel)' after connecting to USRP2: [0.00] Intel GenuineIntel [0.01] Performance Counters: Core2 events, Intel PMU driver. [0.139852] CPU0: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz stepping 0a [0.291578] CPU1: Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz stepping 0a [1.243274] e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2 [1.243279] e1000e: Copyright (c) 1999-2008 Intel Corporation. [1.522705] :00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1a:6b:3a:0c:ee [1.522708] :00:19.0: eth0: Intel(R) PRO/1000 Network Connection [1.522744] :00:19.0: eth0: MAC: 6, PHY: 6, PBA No: ff-0ff [ 25.421065] HDA Intel :00:1b.0: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 25.421094] HDA Intel :00:1b.0: setting latency timer to 64 [ 26.450512] ADDRCONF(NETDEV_UP): eth0: link is not ready And this is from ifconfig: eth0 Link encap:Ethernet HWaddr 00:1a:6b:3a:0c:ee inet addr:10.0.0.2 Bcast:10.255.255.255 Mask:255.0.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Memory:fe20-fe22 Please note that with the original SD-card, despite the lights being on, I don't see anything going out of my machine when I call find_usrps (using wireshark). But when I connect the USRP2 to my laptop without the SD-card, the light on the ethernet interface on the laptop goes on and for every call to find_usrps I can see an ethernet packet going out (on wireshark). >> >> As a last resort, I tried to reprogram (a new) SD card. I followed the >> instructions on USRP2FAQ and copied txrx.bin and u2_rev3.bin on the new >> SD card. This time, even the LEDs don't light up, and of course I still >> cannot connect to the USRP2. > > Then you did not copy the files correctly. You'll need to follow the instructions again, as those instructions work. If the LEDs don't light up, then the files are not on there and nothing will work. I will re-do this with a new SD-card and report the results. >> >> How do I know which version of firmware and FPGA bitstream I should use? >> Is there a u2_rev4.bin available (since my USRP2 is revision 4)? >> Any hints on what I might be doing wrong? > > No, rev3 and rev4 use the same .bin files. > > Matt I highly appreciate your time. Thanks, Omid ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question on rx_streaming_samples/libursp2
Hi,
(I am using the VRT code but I don't think it matters for the questions
below)
In rx_streaming_samples.cc one finds the following code:
while (!signaled &&
!handler->has_errored_p() &&
!handler->has_finished_p()) {
bool ok = u2->rx_samples(handler.get());
if (!ok){
fprintf(stderr, "u2->rx_samples failed\n");
return 1;
}
}
Does every call of u2->rx_samples(handler.get()) result in one call of
e.g. file_writer_32fc ?
Is there any way of receiving samples from the usrp2 that doesn't
involve calling "start_rx_streaming" ?
BR/
Per
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] high-level OFDM question
On Fri, Feb 12, 2010 at 10:34 AM, Achilleas Anastasopoulos wrote: > Hi there, > > before delving into the details of the OFDM implementation in GNURAdio I > wanted to ask a high-level question: > > What is the method used for initial timing/frequency acquisition? We use, by default, the standard Schmidl and Cox. There are two other methods that we wrote which you can use to varying degrees of success. My presentation from the wirel...@vt symposium, 2007, has details of all of these methods and why we use the one we do. > Is there one or two training OFDM symbols that precede the transmission of > data? and how many OFDM data symbols are following? Is this number > determined by the first training symbols or is it fixed? We use a method that only requires 1 training symbol. The much of the code is actually set up to allow you to put in however many you want, but you'll need to redesign some of the the receiver blocks to make use of them. The number of symbols following depends on the frame length you specify. In the benchmark_ofdm* examples, we default to 400 bytes with 200 occupied tones per symbol, so for BPSK this is (400*8/200) = 16 symbols. So there are 16 symbols between preambles. > Also, my understanding is that each data OFDM symbol has pilot tones for > continuous frequency/timing tracking, right? > > Thanks > Achilleas While I wrote the transmitter to allow for pilot tones, we don't actually make use of them in the receiver. Instead, we use a decision feedback equalizer to keep on track. Making use of the pilot tones in the receiver is definitely something we need done, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] high-level OFDM question
Tom, thanks for the info. So to clarify, the frame length is fixed for the transmission to a certain number (say 400 bytes) so the system waits until it collects 400 bytes worth of data and then it generates and transmits it using a burst of 1 training and 16 data OFDM symbols. If the number of data in the queue at a give time is say 500 bytes it will first process the first 400 and then wait until an additional 300 bytes (or more) comes in to generate the next burst. Is that right? Achilleas Tom Rondeau wrote: On Fri, Feb 12, 2010 at 10:34 AM, Achilleas Anastasopoulos wrote: Hi there, before delving into the details of the OFDM implementation in GNURAdio I wanted to ask a high-level question: What is the method used for initial timing/frequency acquisition? We use, by default, the standard Schmidl and Cox. There are two other methods that we wrote which you can use to varying degrees of success. My presentation from the wirel...@vt symposium, 2007, has details of all of these methods and why we use the one we do. Is there one or two training OFDM symbols that precede the transmission of data? and how many OFDM data symbols are following? Is this number determined by the first training symbols or is it fixed? We use a method that only requires 1 training symbol. The much of the code is actually set up to allow you to put in however many you want, but you'll need to redesign some of the the receiver blocks to make use of them. The number of symbols following depends on the frame length you specify. In the benchmark_ofdm* examples, we default to 400 bytes with 200 occupied tones per symbol, so for BPSK this is (400*8/200) = 16 symbols. So there are 16 symbols between preambles. Also, my understanding is that each data OFDM symbol has pilot tones for continuous frequency/timing tracking, right? Thanks Achilleas While I wrote the transmitter to allow for pilot tones, we don't actually make use of them in the receiver. Instead, we use a decision feedback equalizer to keep on track. Making use of the pilot tones in the receiver is definitely something we need done, though. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] packet interarrival time
Hi, I'm using two USRP2 with XCVR2450s, gnuradio 3.2.2 and Ubuntu 9.10. I ran the benchmark_tx/rx example from gnuradio-examples/ofdm and measured packet inter-arrival times at the receiver. I also modified the sender to wait for some time (like 200ms) between individual packets. I also set the msg queue size to one. In python code I'm printing a bunch of time.time() values to keep the timeline of the events. What I observe is the following: - inter-departure times are constant, the packet size and the bit rate would of course influence the time spent sending, but that would still be a relatively small value. - at the receiver, most packets are received with the inter-arrival time comparable to the inter-departure time at the sender, however, occasionally I would see a huge lag between two consecutive packets (almost a second). I read the NSDI'09 paper (http://portal.acm.org/citation.cfm?id=1558984) that talks about USRP1 performance, however, what I observe is way higher delay and it's USRP2. Thus, I'm sure that there's something I can do to fix this delay. Any hints? Cheers, Veljko ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
Matt, There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I compensated for it and it worked!. The settings I am using is as follows: ./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128 ./benchmark_ofdm_rx.py -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80 -d 64 --rx-gain=20 --cp-length=128 I calculate the data-rate for OFDM as follows Data rate R = (ADC sampling rate x Occupied Tones) / (Nfft x Decimation) For the above setting it is 244 KHz. Am I right with the data rate calculation ? Thanks very much for your time, On Thu, Feb 11, 2010 at 10:26 PM, Matt Ettus wrote: > On 02/11/2010 04:45 PM, Srinivas wrote: > >> Hi All, >> >> I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On >> one pair I am able to successfully run OFDM (benchmark_ofdm_tx & rx) >> with almost 95+% packet success rate. However on the other pair I am not >> receiving even 1 packet! >> >> I am using the same host machines and scripts. I also tried swapping the >> daughtercards (XCVR2450) and the firmwares with the working pair, but >> the problem remains. >> >> Does any one have a clue of where the problem might be ? >> >> PS: The received signal spectrum (usrp2_fft.py) on one of the >> non-working USRP2s is attached herewith. Besides this I plotted the >> spectrum of the received data from usrp2_rx_cfile.py at the receiver >> using MATLAB. The spectrum is of the same shape and strength as >> usrp2_fft.py displays. >> > > > Srinivas, > > It looks like you are using a very narrow signal. The frequency offset of > the USRP2s giving you trouble may be enough that you are outside of the > search range of the OFDM receiver (which is a percentage of the bandwidth of > the signal). > > You could try any or all of the following: > > - increasing the data rate by a factor of 2 or 4 > - modifying the OFDM code to widen the search range > - locking the usrps to a common reference > - measure the frequency offset of the transmitter, and run the receiver > with the actual frequency. For example, if the receiver sees the signal 30 > kHz high using usrp2_fft.py, call the ofdm receiver with > >-f 2.450030G > on the command line > > > Matt > -- Srinivas WINLAB, Rutgers University New Jersey ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on rx_streaming_samples/libursp2
On Fri, Feb 12, 2010 at 07:31:57PM +0100, Per Zetterberg wrote:
> Hi,
>
> (I am using the VRT code but I don't think it matters for the
> questions below)
>
> In rx_streaming_samples.cc one finds the following code:
>
>
> while (!signaled &&
> !handler->has_errored_p() &&
> !handler->has_finished_p()) {
>bool ok = u2->rx_samples(handler.get());
>if (!ok){
> fprintf(stderr, "u2->rx_samples failed\n");
> return 1;
>}
> }
>
> Does every call of u2->rx_samples(handler.get()) result in one call
> of e.g. file_writer_32fc ?
No. It could be called many times.
> Is there any way of receiving samples from the usrp2 that doesn't
> involve calling "start_rx_streaming" ?
Somebody's got to tell it to start streaming.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] packet interarrival time
On Fri, Feb 12, 2010 at 12:52:00PM -0800, Veljko Pejovic wrote: > Hi, > > I'm using two USRP2 with XCVR2450s, gnuradio 3.2.2 and Ubuntu 9.10. > > I ran the benchmark_tx/rx example from gnuradio-examples/ofdm and > measured packet inter-arrival times at the receiver. I also modified > the sender to wait for some time (like 200ms) between individual > packets. I also set the msg queue size to one. In python code I'm > printing a bunch of time.time() values to keep the timeline of the > events. > > What I observe is the following: > - inter-departure times are constant, the packet size and the bit rate > would of course influence the time spent sending, but that would still > be a relatively small value. > - at the receiver, most packets are received with the inter-arrival > time comparable to the inter-departure time at the sender, however, > occasionally I would see a huge lag between two consecutive packets > (almost a second). > > I read the NSDI'09 paper > (http://portal.acm.org/citation.cfm?id=1558984) that talks about USRP1 > performance, however, what I observe is way higher delay and it's > USRP2. Thus, I'm sure that there's something I can do to fix this > delay. Any hints? Are packets getting dropped? Is the USRP2 on a dedicated ethernet port? Is there a switch between the host and the USRP2? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] article: "No-knob" radio: the future of Warfighter communications?
http://www.army.mil/-news/2010/01/27/33577-no-knob-radio-the-future-of-warfighter-communications/ > "No-knob" radio: the future of Warfighter communications? Jan 27, 2010 By Sharon Rushen, CERDEC Public Affairs FORT MONMOUTH, N.J. - U.S. Army engineers in collaboration with their Navy counterparts hope to open the gates of cognitive radio development to academia, industry and other DoD organizations by building a universal radio test-bed this year. The Communications-Electronics Research, Development and Engineering Center's Software Defined Radio lab will work with the Navy Research Lab to transfer previous development done on the Joint Tactical Radio System to the GNU Radio's open source, free software environment. Through the GNU platform which is inexpensive and universally accessible, universities, contract companies and government agencies can use a common platform to advance the state of cognitive radio software. The transition to the GNU platform will help ease collaboration efforts with other organizations who frequently opt to use 'grass-roots' hardware for programming due to the comparably high-cost and limited accessibility of JTRS radios. Additionally, the GNU platform will enable the SDR lab to conduct large lab tests and field tests, rather than having to simulate larger-scale network testing. The cost constraints associated with the JTRS radio prohibit larger-scale networking, limiting the number of radios they can test at one time, explained SDR lab team lead, Tim Leising. Through funding provided by the Office of the Secretary of Defense, Director of Defense, Research and Engineering, the SDR lab team will collaborate with the Navy Research Lab, to start building a universal GNU radio test bed this year. Once the test-bed is completed, they will work together to make it remote-accessible using the Defense Research Engineering Network to house the software platform, allowing DoD organizations and external research partners to test their software on it from any location. CERDEC will facilitate a dial-in Q&A session for media participants to interact with leading U.S. Army researchers involved in developing the GNU test-bed. To participate in the media round table, contact CERDEC Public Affairs: (732) 427-1926. The Communications-Electronics Research, Development and Engineering Center (CERDEC) is one of the research and development centers under the U.S. Army's Research, Development and Engineering Command (RDECOM). The Software-Defined Radio (SDR) lab is part of CERDEC's Space and Terrestrial Communications Directorate. -- de Ken N9VV ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] packet interarrival time
Hi Eric, 2010/2/12 Eric Blossom : > On Fri, Feb 12, 2010 at 12:52:00PM -0800, Veljko Pejovic wrote: >> Hi, >> >> I'm using two USRP2 with XCVR2450s, gnuradio 3.2.2 and Ubuntu 9.10. >> >> I ran the benchmark_tx/rx example from gnuradio-examples/ofdm and >> measured packet inter-arrival times at the receiver. I also modified >> the sender to wait for some time (like 200ms) between individual >> packets. I also set the msg queue size to one. In python code I'm >> printing a bunch of time.time() values to keep the timeline of the >> events. >> >> What I observe is the following: >> - inter-departure times are constant, the packet size and the bit rate >> would of course influence the time spent sending, but that would still >> be a relatively small value. >> - at the receiver, most packets are received with the inter-arrival >> time comparable to the inter-departure time at the sender, however, >> occasionally I would see a huge lag between two consecutive packets >> (almost a second). >> >> I read the NSDI'09 paper >> (http://portal.acm.org/citation.cfm?id=1558984) that talks about USRP1 >> performance, however, what I observe is way higher delay and it's >> USRP2. Thus, I'm sure that there's something I can do to fix this >> delay. Any hints? > > Are packets getting dropped? I don't get any overruns/underruns reported, but, yes, there's some packet loss. However, I'm only considering the interarrival time of those packets with consecutive packet numbers. > Is the USRP2 on a dedicated ethernet port? yes, it is. > Is there a switch between the host and the USRP2? no > > Eric > cheers Veljko ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] article: "No-knob" radio: the future ofWarfighter communications?
Ettus Guys- > http://www.army.mil/-news/2010/01/27/33577-no-knob-radio-the-future-of-warfighter-communications/ > > "No-knob" radio: the future of Warfighter communications? After as week, this brings up a question: is there supposed to be an official PR or other announcement about the acquisition on NI's website? I don't see anything yet. I would think that some statement from NI clarifying continuation of open source status and GPL licensing for GNU radio software (and hardware and FPGA logic, very crucial) would be re-assuring to GNU radio developers and users, as well as users-in-planning -- such as US Army guys mentioned below. Unless the acquisition hasn't actually closed yet, then the only thing I can guess that might be holding up NI is if they need to tweak their wording, for example mention items that might be excepted from GNU licensing if they conflict with one of their many patents. The block diagram user interface in GRC would be one possible example. -Jeff > Jan 27, 2010 > > By Sharon Rushen, CERDEC Public Affairs > > FORT MONMOUTH, N.J. - U.S. Army engineers in collaboration with > their Navy counterparts hope to open the gates of cognitive radio > development to academia, industry and other DoD organizations by > building a universal radio test-bed this year. > > The Communications-Electronics Research, Development and > Engineering Center's Software Defined Radio lab will work with the > Navy Research Lab to transfer previous development done on the > Joint Tactical Radio System to the GNU Radio's open source, free > software environment. > > Through the GNU platform which is inexpensive and universally > accessible, universities, contract companies and government > agencies can use a common platform to advance the state of > cognitive radio software. The transition to the GNU platform will > help ease collaboration efforts with other organizations who > frequently opt to use 'grass-roots' hardware for programming due > to the comparably high-cost and limited accessibility of JTRS radios. > > Additionally, the GNU platform will enable the SDR lab to conduct > large lab tests and field tests, rather than having to simulate > larger-scale network testing. The cost constraints associated with > the JTRS radio prohibit larger-scale networking, limiting the > number of radios they can test at one time, explained SDR lab team > lead, Tim Leising. > > Through funding provided by the Office of the Secretary of > Defense, Director of Defense, Research and Engineering, the SDR > lab team will collaborate with the Navy Research Lab, to start > building a universal GNU radio test bed this year. Once the > test-bed is completed, they will work together to make it > remote-accessible using the Defense Research Engineering Network > to house the software platform, allowing DoD organizations and > external research partners to test their software on it from any > location. > > CERDEC will facilitate a dial-in Q&A session for media > participants to interact with leading U.S. Army researchers > involved in developing the GNU test-bed. To participate in the > media round table, contact CERDEC Public Affairs: (732) 427-1926. > > The Communications-Electronics Research, Development and > Engineering Center (CERDEC) is one of the research and development > centers under the U.S. Army's Research, Development and > Engineering Command (RDECOM). > > The Software-Defined Radio (SDR) lab is part of CERDEC's Space and > Terrestrial Communications Directorate. > -- > de Ken N9VV ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] article: "No-knob" radio: the future ofWarfighter communications?
Jeff, We have repeatedly made statements about our commitment to continue developing GNU Radio and to open source, both in our original announcement and in several following emails. We employ three GNU Radio developers full time, including Josh Blum who created GRC. I don't know what else you could possibly want, or how else we could possibly state it. If you read the GPL, you would know that nobody can take GPL'ed code away from you. If the US Army guys in the article below have any concerns, I'm sure they know how to contact me. I don't understand your concern about the lack of a press release. The acquisition has closed and we are continuing to go about our normal business. Right now Tom and I are working on MIMO OFDM code. You can follow our ofdm branches in git if you like. Still all GPL. I understand the concern about any significant change like this. However, I would ask you to look at Ettus Research's 5 and a half year commitment to GNU Radio and open source, my personal 9 year commitment to GNU Radio, my personal 12 year track record of contributions to multiple open source projects, the tens of thousands of lines of open source code we have produced, and our multiple affirmative statements of continued support. Matt Ettus President, Ettus Research LLC On 02/12/2010 04:43 PM, Jeff Brower wrote: Ettus Guys- http://www.army.mil/-news/2010/01/27/33577-no-knob-radio-the-future-of-warfighter-communications/ "No-knob" radio: the future of Warfighter communications? After as week, this brings up a question: is there supposed to be an official PR or other announcement about the acquisition on NI's website? I don't see anything yet. I would think that some statement from NI clarifying continuation of open source status and GPL licensing for GNU radio software (and hardware and FPGA logic, very crucial) would be re-assuring to GNU radio developers and users, as well as users-in-planning -- such as US Army guys mentioned below. Unless the acquisition hasn't actually closed yet, then the only thing I can guess that might be holding up NI is if they need to tweak their wording, for example mention items that might be excepted from GNU licensing if they conflict with one of their many patents. The block diagram user interface in GRC would be one possible example. -Jeff Jan 27, 2010 By Sharon Rushen, CERDEC Public Affairs FORT MONMOUTH, N.J. - U.S. Army engineers in collaboration with their Navy counterparts hope to open the gates of cognitive radio development to academia, industry and other DoD organizations by building a universal radio test-bed this year. The Communications-Electronics Research, Development and Engineering Center's Software Defined Radio lab will work with the Navy Research Lab to transfer previous development done on the Joint Tactical Radio System to the GNU Radio's open source, free software environment. Through the GNU platform which is inexpensive and universally accessible, universities, contract companies and government agencies can use a common platform to advance the state of cognitive radio software. The transition to the GNU platform will help ease collaboration efforts with other organizations who frequently opt to use 'grass-roots' hardware for programming due to the comparably high-cost and limited accessibility of JTRS radios. Additionally, the GNU platform will enable the SDR lab to conduct large lab tests and field tests, rather than having to simulate larger-scale network testing. The cost constraints associated with the JTRS radio prohibit larger-scale networking, limiting the number of radios they can test at one time, explained SDR lab team lead, Tim Leising. Through funding provided by the Office of the Secretary of Defense, Director of Defense, Research and Engineering, the SDR lab team will collaborate with the Navy Research Lab, to start building a universal GNU radio test bed this year. Once the test-bed is completed, they will work together to make it remote-accessible using the Defense Research Engineering Network to house the software platform, allowing DoD organizations and external research partners to test their software on it from any location. CERDEC will facilitate a dial-in Q&A session for media participants to interact with leading U.S. Army researchers involved in developing the GNU test-bed. To participate in the media round table, contact CERDEC Public Affairs: (732) 427-1926. The Communications-Electronics Research, Development and Engineering Center (CERDEC) is one of the research and development centers under the U.S. Army's Research, Development and Engineering Command (RDECOM). The Software-Defined Radio (SDR) lab is part of CERDEC's Space and Terrestrial Communications Directorate. -- de Ken N9VV ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] article: "No-knob" radio: the future ofWarfighter communications?
On Fri, 2010-02-12 at 18:43 -0600, Jeff Brower wrote: > I would think that some statement from NI clarifying continuation of open > source status and GPL licensing for GNU > radio software (and hardware and FPGA logic, very crucial) would be > re-assuring to GNU radio developers and users, as > well as users-in-planning -- such as US Army guys mentioned below. Unless > the acquisition hasn't actually closed yet, > then the only thing I can guess that might be holding up NI is if they need > to tweak their wording, for example > mention items that might be excepted from GNU licensing if they conflict with > one of their many patents. The block > diagram user interface in GRC would be one possible example. See prior email from me regarding GNU Radio software status. In short, GNU Radio is a product of the Free Software Foundation, not Ettus Research, and will continue to be licensed for use and distribution under the terms of the GPLv3. The USRP1/2 host driver software that exists today is part of that, and will be maintained. NI/Ettus Research announced they will develop a new driver for USRP2 and will dual-license under GPL and non-GPL. GNU Radio will be able to use it. Corgan Enterprises, Blossom Research, and Ettus Research are all working together to make this transition smooth. Johnathan Corgan Corgan Enteprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] article: "No-knob" radio: the future ofWarfightercommunications?
Matt- > We have repeatedly made statements about our commitment to continue > developing GNU Radio and to open source, both in our original > announcement and in several following emails. We employ three GNU Radio > developers full time, including Josh Blum who created GRC. I don't know > what else you could possibly want, or how else we could possibly state it. Everything I'm hearing sounds good, your statements are re-assuring and passionate. Please forgive me, but I'm just asking where's NI's official statement? Is that not a reasonable question to ask? I checked their website every day this week. I doubt I'm the only one who was doing that. > If you read the GPL, you would know that nobody can take GPL'ed code > away from you. If the US Army guys in the article below have any > concerns, I'm sure they know how to contact me. Not to quibble, but like anything else, GPL code cannot infringe an existing patent. > I don't understand your concern about the lack of a press release. The > acquisition has closed and we are continuing to go about our normal > business. Right now Tom and I are working on MIMO OFDM code. You can > follow our ofdm branches in git if you like. Still all GPL. > > I understand the concern about any significant change like this. > However, I would ask you to look at Ettus Research's 5 and a half year > commitment to GNU Radio and open source, my personal 9 year commitment > to GNU Radio, my personal 12 year track record of contributions to > multiple open source projects, the tens of thousands of lines of open > source code we have produced, and our multiple affirmative statements of > continued support. Yes I know. I recognize this fully. I'm a 50 yr old guy with a long track record in engineering and business in DSP, telecom, and software since I started writing Apple II programs in 1980. In my day we didn't have open source (or the Internet) so we started small companies and learned the hard way about patents and IP rights and acquisitions. When I was a few years younger than you are now I was founding a company after leaving another one I had co-founded, which eventually got acquired in Jan 2004 by NI. So yes I'm old curmudgeon who's seen a lot, which is why I insist on asking such questions. I can see I'm probably being annoying, so I'll keep my questions about an NI announcement to myself from this point. -Jeff > On 02/12/2010 04:43 PM, Jeff Brower wrote: >> Ettus Guys- >> >>> http://www.army.mil/-news/2010/01/27/33577-no-knob-radio-the-future-of-warfighter-communications/ >>> >>> "No-knob" radio: the future of Warfighter communications? >> >> After as week, this brings up a question: is there supposed to be an >> official PR or other announcement about the >> acquisition on NI's website? I don't see anything yet. >> >> I would think that some statement from NI clarifying continuation of open >> source status and GPL licensing for GNU >> radio software (and hardware and FPGA logic, very crucial) would be >> re-assuring to GNU radio developers and users, >> as >> well as users-in-planning -- such as US Army guys mentioned below. Unless >> the acquisition hasn't actually closed >> yet, >> then the only thing I can guess that might be holding up NI is if they need >> to tweak their wording, for example >> mention items that might be excepted from GNU licensing if they conflict >> with one of their many patents. The block >> diagram user interface in GRC would be one possible example. >> >> -Jeff >> >>> Jan 27, 2010 >>> >>> By Sharon Rushen, CERDEC Public Affairs >>> >>> FORT MONMOUTH, N.J. - U.S. Army engineers in collaboration with >>> their Navy counterparts hope to open the gates of cognitive radio >>> development to academia, industry and other DoD organizations by >>> building a universal radio test-bed this year. >>> >>> The Communications-Electronics Research, Development and >>> Engineering Center's Software Defined Radio lab will work with the >>> Navy Research Lab to transfer previous development done on the >>> Joint Tactical Radio System to the GNU Radio's open source, free >>> software environment. >>> >>> Through the GNU platform which is inexpensive and universally >>> accessible, universities, contract companies and government >>> agencies can use a common platform to advance the state of >>> cognitive radio software. The transition to the GNU platform will >>> help ease collaboration efforts with other organizations who >>> frequently opt to use 'grass-roots' hardware for programming due >>> to the comparably high-cost and limited accessibility of JTRS radios. >>> >>> Additionally, the GNU platform will enable the SDR lab to conduct >>> large lab tests and field tests, rather than having to simulate >>> larger-scale network testing. The cost constraints associated with >>> the JTRS radio prohibit larger-scale networking, limiting the >>> number of radios they can test at one time, explained SDR lab team >>> lead, Tim Lei
[Discuss-gnuradio] was no-knob
(N9VV probably didn't mean to create a new thread under V. Pejovic's thread so starting a fresh thread.) BTW what future war fighter is needed? I thought the water-bag was obsoleted by UA drones? But to J. Brower I too looked at NI's site for some announcement. Really all we can do is take a wait-and-see approach because it seems that anything goes in these times we've all found ourselves. Question to M. Ettus. What's the #1 thing that the NI deal does for you and/or USRP? Can you say? If not I understand, just curious. FWIW I'm making no judgement call on anyone or anything. Been around long enough to know that there are many ends to all things. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
