Re: [Discuss-gnuradio] Help with USRP wire?
On Oct 17, 2010, at 2:07 AM, Thunder87 wrote: Which type is this small wire, which connects USRP daughterboard with antenna? The coaxial cables that came with my USRP set appear to be made of type RG-316 cable. The LFTX and LFRX boards have SMA connectors. I think that the antenna connectors on the WBX board are MMCX connectors. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WBX and USRP1 on GnuRadio 3.3
Is it possible to use a WBX daughtercard on a USRP1 with the 3.3 stable release of GnuRadio, or is it necessary to go to the latest development code (or the UHD code)? @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBX and USRP1 on GnuRadio 3.3
On Oct 17, 2010, at 11:27 PM, Ed Criscuolo wrote: Is it possible to use a WBX daughtercard on a USRP1 with the 3.3 stable release of GnuRadio Yes. I am presently using my WBX in my USRP with the 3.3 release of GNU Radio via macports on my Mac. -- Mark J. Blair, NF6X n...@nf6x.net Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Trying to find a stable copy of the FPGA code for the USRP2
Hi I am looking for a stable copy of the FPGA code for the USRP2 board. I have tried the code that come when you run the command git clone git://git.ettus.com/ettus/fpga.git The builds fine Xilinx ISE 12.2 but when it copy it onto the SD card and try run the build on the USRP2 board I only get LED F turning on and when i run the command find_usrp it dose not find the board. If anyone knows where I can get a stable release of the FPGA code it would be great. Please note that I don't know my way around with the git commands so if you please give full command line inputs with would be great. Regards Alan Jones Master Student in the RRSG Research Group University of Cape Town ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trying to find a stable copy of the FPGA code for the USRP2
Hello,
you can find the newest code (for the UHD driver) here:
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki
You can also find a tool with graphical user interface in host/utils to flash
the card.
The link
git.ettus.com/ettus/fpga.git
should be correct with the raw ethernet host driver, but I think it is
included in the UHD repo above as well, so the UHD repository is recommended.
LED D indicates that the firmware is up and running, if it does not light up
it means that (i) the FPGA is not set up or (ii) that the firmware is not
running.
The problem is probably an error on the SD card. Several issues come to mind
here:
- both firmware and FPGA bitstream must be flashed on the card. That is,
txrx.bin and u2_rev3.bin. You have to use the flash tool twice.
- SDHC card are not supported, they must be SD.
- you must flash directly to the beginning of the card, so use /dev/sdX instead
of /dev/sdX{1,2,3,4,...}. This nukes the filesystem and (possibly) the master
boot record, so you cannot have other data on the SD card, and old data will
disappear.
- mismatch between FPGA and firmware version (but this leads mostly to strange
behavior)
I have posted more info some weeks ago, and there is a wiki page with more info:
http://gnuradio.org/redmine/wiki/1/USRP2UserFAQ#How-do-I-change-the-firmware-and-FPGA-code-on-the-SD-Card
Regards,
Matthias
Am 18.10.2010 um 14:17 schrieb Alan Jones:
Hi
I am looking for a stable copy of the FPGA code for the USRP2 board. I have
tried the code that come when you run the command
git clone git://git.ettus.com/ettus/fpga.git The builds fine Xilinx ISE 12.2
but when it copy it onto the SD card and try run the build on the USRP2 board
I only get LED F turning on and when i run the command find_usrp it dose not
find the board. If anyone knows where I can get a stable release of the FPGA
code it would be great. Please note that I don't know my way around with the
git commands so if you please give full command line inputs with would be
great.
Regards
Alan Jones
Master Student in the RRSG Research Group
University of Cape Town
___
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] Re: Lots of mallocs in my gnuradio block ... is it safe?
It looks like only about 7 MB of memory... (204 + 5 + 204) * 2046 * 8 + 2046 * 8 = 6,776,352 bytes. It probably won't play too well with your CPU cache, but that still shouldn't be too much, right? Also, since you only need to calculate once, I assume you will be mallocing these arrays only once (e.g. in the constructor)... if you're not mallocing every time general_work is called, it should be even less of a problem. I myself haven't had to malloc more than about 1MB of arrays in a block, though, but I think it may be worth trying out. Kunal On Mon, Oct 18, 2010 at 1:01 AM, John Andrews gnu.f...@gmail.com wrote: haha! I just realized that this is a great deal of memory used. 250*2046*4. I am so dumb. :) I guess I will have to calculate this on each iteration i use that data. On Sun, Oct 17, 2010 at 9:08 PM, John Andrews gnu.f...@gmail.com wrote: Hi, I am writing the code for a gnuradio block and I use a lot of dynamic memory allocation. The code isn't finished yet but I thought I would ask this question anyways. For an idea this is how the mallocs look like. 1. (204 + 5 + 204) gr_complex arrays of size 2046 each 2. 1 double array of size 2046 The reason why I have this is most of the data allocated in these arrays is reused and I don't have to calculate it again and again. i thought having this data ready when the block is initialized will speed up the processing. Being pessimistic programmer I am circumspect about my method. What are your thoughts? Thanks, John ___ 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] How to use UHD with gr_block?
Hi all, I've used USRP1 and GR 3.1.3 since 2007. Now I try to move to USRP2 and GR 3.3 version. The most important reason is that I hope to have more bandwidth and to access timestamp information of sampled data. The thing is that GR and USRP2 architecture looks evolved so much since two years ago. I've written my own codes based on benchmark_rx.py and benchmark_tx.py Python codes. I'm sure that this is an initial gr_block and flowgraph architecture of GR. Can I use this gr_block architecture with UHD? What I've done so far are 1) having USRP2 and WBX d'board 2) update firmware and fpga codes for raw_Ethernet to support USRP2+WBX 3) run usrp2_fft.py to check USRP2 connection 4) checkout UHD codes from http://code.ettus.com/redmine/ettus/projects/uhd 5) build UHD codes 6) update new firmware and fpga codes for UHD 7) run a simple example in /opt/uhd/build/example Now, what I want to do is to build a simple example such as 'benchmark_rx' and 'benchmark_tx' using UHD with gr_block. Would you please give me a hint how to build this system? If you have any so simple example, it would be helpful for me. Thanks, Yong -- View this message in context: http://old.nabble.com/How-to-use-UHD-with-gr_block--tp29991623p29991623.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] usrp2_card_burner_guy.py
Hello all, Does anybody knows why I get this error when trying to execute the card burner tool? $ python usrp2_card_burner_gui.py File usrp2_card_burner_gui.py, line 1 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; ^ SyntaxError: invalid syntax Many thanks, Jorge. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2_card_burner_guy.py
Hello, it seems that you downloaded the file and received an html file linking to the .py file instead the file itself. Download the uhd git repository, or use the save as text in redmine/trac Try editing the file, its not a python file. Matthias Am 18.10.2010 um 18:17 schrieb Jorge Miguel: Hello all, Does anybody knows why I get this error when trying to execute the card burner tool? $ python usrp2_card_burner_gui.py File usrp2_card_burner_gui.py, line 1 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; ^ SyntaxError: invalid syntax Many thanks, Jorge. ___ 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] Trying to find a stable copy of the FPGA code for the USRP2
If you are using ISE12.x you need to use the ise12 branch in git. Go into the repo and type: git co ise12 Then do a make clean and make bin. Matt On 10/18/2010 05:17 AM, Alan Jones wrote: Hi I am looking for a stable copy of the FPGA code for the USRP2 board. I have tried the code that come when you run the command git clone git://git.ettus.com/ettus/fpga.git http://git.ettus.com/ettus/fpga.git The builds fine Xilinx ISE 12.2 but when it copy it onto the SD card and try run the build on the USRP2 board I only get LED F turning on and when i run the command find_usrp it dose not find the board. If anyone knows where I can get a stable release of the FPGA code it would be great. Please note that I don't know my way around with the git commands so if you please give full command line inputs with would be great. Regards Alan Jones Master Student in the RRSG Research Group University of Cape Town ___ 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] usrp2_card_burner_guy.py
On 10/18/2010 12:17 PM, Jorge Miguel wrote: Hello all, Does anybody knows why I get this error when trying to execute the card burner tool? $ python usrp2_card_burner_gui.py File usrp2_card_burner_gui.py, line 1 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; ^ SyntaxError: invalid syntax Many thanks, Jorge. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio My guess is that you downloaded that tool incorrectly--my local instance (from the up-to-date) UHD, has no occurrence of that line in it at all, and works fine. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Transmitter's bizarre behavior on 64 bit workstation
Eric, I found a puzzling fact about running GNU Radio on the 64-bit Lenovo workstation D20. Basically, the maximum packet size (payload at the transmitter side in the benchmark_tx.py) must be less than or equal to 221. Below this size, packets from the workstation can be correctly received by either a laptop or another workstation; above this size, no packet can be received correctly on either a laptop or another workstation. I was using 500kb data rate and GMSK modulations. The same code works perfectly on a laptop as the transmitter, no matter the receiver side is on a laptop or a workstation. At first, I thought it might be a result of the quad core (8 CPUs) architecture. So I disable 3 cores and only one core was left. However, I got the same result. Also, the CPU usage for a transmitter doesn't make sense to me either. It was above 90% on the workstation (2 Intel Xeon X5550 cpus at 2.67 GHz). However it was only around 35% on the laptops (2 Intel T9550 CPUs at 2.66GHz). I could not understand what might be the problem. Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Costas parameter in DPSK2 grc block not in .py?
When I try to use the DPSK2 demod block in grc, I get the below error. The issue seems to be that the grc block has different arguments than dqpsk2_demod() in dqpsk2.py (see below). Am I missing something here? I am using the gnuradio version 3.3.0. Thanks, Ben === (GRC ERROR) Traceback (most recent call last): File /gnuradio/gnuradio-3.3.0/gnuradio-examples/grc/usrp/usrp_rx_dpsk.py, line 211, in module tb = usrp_rx_dpsk() File /gnuradio/gnuradio-3.3.0/gnuradio-examples/grc/usrp/usrp_rx_dpsk.py, line 125, in __init__ sync_out=True, TypeError: __init__() got an unexpected keyword argument 'costas_alpha' = (BLK2_DXPSK2_DEMOD.XML) block nameDPSK2 Demod/name keyblks2_dxpsk2_demod/key importfrom gnuradio import blks2/import makeblks2.$(type)2_demod( samples_per_symbol=$samples_per_symbol, excess_bw=$excess_bw, costas_alpha=$costas_alpha, timing_alpha=$timing_alpha, timing_max_dev=$timing_max_dev, gray_code=$gray_code, verbose=$verbose, log=$log, sync_out=$sync_out, = (DQPSK2.PY) class dqpsk2_demod(gr.hier_block2): def __init__(self, samples_per_symbol=_def_samples_per_symbol, excess_bw=_def_excess_bw, freq_alpha=_def_freq_alpha, phase_alpha=_def_phase_alpha, timing_alpha=_def_timing_alpha, timing_max_dev=_def_timing_max_dev, gray_code=_def_gray_code, verbose=_def_verbose, log=_def_log, sync_out=False): ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Costas parameter in DPSK2 grc block not in .py?
diff attached It looks like the guts of the dqpsk2 demod changed but the grc file was not updated. I vote for keeping the grc files with the python/c++ source. -Josh On 10/18/2010 02:06 PM, Benjamin Lonske wrote: When I try to use the DPSK2 demod block in grc, I get the below error. The issue seems to be that the grc block has different arguments than dqpsk2_demod() in dqpsk2.py (see below). Am I missing something here? I am using the gnuradio version 3.3.0. Thanks, Ben === (GRC ERROR) Traceback (most recent call last): File /gnuradio/gnuradio-3.3.0/gnuradio-examples/grc/usrp/usrp_rx_dpsk.py, line 211, inmodule tb = usrp_rx_dpsk() File /gnuradio/gnuradio-3.3.0/gnuradio-examples/grc/usrp/usrp_rx_dpsk.py, line 125, in __init__ sync_out=True, TypeError: __init__() got an unexpected keyword argument 'costas_alpha' = (BLK2_DXPSK2_DEMOD.XML) block nameDPSK2 Demod/name keyblks2_dxpsk2_demod/key importfrom gnuradio import blks2/import makeblks2.$(type)2_demod( samples_per_symbol=$samples_per_symbol, excess_bw=$excess_bw, costas_alpha=$costas_alpha, timing_alpha=$timing_alpha, timing_max_dev=$timing_max_dev, gray_code=$gray_code, verbose=$verbose, log=$log, sync_out=$sync_out, = (DQPSK2.PY) class dqpsk2_demod(gr.hier_block2): def __init__(self, samples_per_symbol=_def_samples_per_symbol, excess_bw=_def_excess_bw, freq_alpha=_def_freq_alpha, phase_alpha=_def_phase_alpha, timing_alpha=_def_timing_alpha, timing_max_dev=_def_timing_max_dev, gray_code=_def_gray_code, verbose=_def_verbose, log=_def_log, sync_out=False): ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio diff --git a/grc/blocks/blks2_dxpsk2_demod.xml b/grc/blocks/blks2_dxpsk2_demod.xml index ce8305c..5d6ae9f 100644 --- a/grc/blocks/blks2_dxpsk2_demod.xml +++ b/grc/blocks/blks2_dxpsk2_demod.xml @@ -11,7 +11,6 @@ makeblks2.$(type)2_demod( samples_per_symbol=$samples_per_symbol, excess_bw=$excess_bw, - costas_alpha=$costas_alpha, timing_alpha=$timing_alpha, timing_max_dev=$timing_max_dev, gray_code=$gray_code, @@ -19,8 +18,6 @@ log=$log, sync_out=$sync_out, )/make - callbackclock_recov.set_alpha($costas_alpha)/callback - callbackclock_recov.set_beta(0.25*$costas_alpha**2)/callback callbacktime_recov.set_alpha($timing_alpha)/callback param nameType/name @@ -48,12 +45,6 @@ typereal/type /param param - nameCostas Alpha/name - keycostas_alpha/key - value0.175/value - typereal/type - /param - param nameTiming Alpha/name keytiming_alpha/key value0.100/value ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - October 15th 2010
Hello list, I would like to announce additional daughterboard support and API changes in regards to the UHD. As of this announcement, all Ettus hardware is supported under UHD. --- Daughter board features and support --- TVRX support DBSRX fixes and ability to set the filter bandwidth XCVR2450 ability to set the filter bandwidth Notes on the bandwidth ranges can be found here: http://www.ettus.com/uhd_docs/manual/html/dboards.html --- API Changes --- The device::send() call now has an optional timeout parameter. Meaning: a call to send() can timeout if there is not an available buffer to fill with data. In the case of USRP2, send() currently blocks regardless of the timeout. This will be fixed with host-based flow control; or if you really need it, there is a #define waiting to be uncommented. The send timeout for USRP1 functions properly. All device timeouts are now doubles, and in units of seconds. For device::recv() and device::recv_async_msg(), this is an API breakage. The reason for the change being: to provide maximum precision to the underlying implementation of the timeout should the need to do so arise. If you were not using timeouts, then just rebuild your application (this includes gr-uhd). If you were using the recv timeouts, convert from units of milliseconds to seconds. --- On buffer resizing --- I believe the warning about buffer resizing has lead to some confusion and misuse so I would like to clarify some things: A UDP socket has re-sizable kernel buffers for send and receive. A large receive buffer improves performance (reduces data overflows). However, a large send buffer actually seems to hurt performance (increases data underflow). By default, the UHD will automatically resize the receive buffer to something large, and print a warning if it cannot. On linux, the *fix* is to change a sysctl value that caps the max receive buffer size. There was some confusion as to how to deal with this warning and resizing buffers with special device parameters. To clarify this, the warning now prints the sysctl command that you should run, its even polite. The notes about resizing the socket buffers has been moved to the transport application notes and marked for advanced users: http://www.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers --- Feedback is welcome! -Josh OK, so did a git pull on both my Gnu Radio and UHD local repos today, to update everything. Did a make clean; make; sudo make install in both UHD and Gnu Radio. I have a GRC-based application that uses a SingleUSRP UHD object. On startup, I now get this error: terminate called after throwing an instance of 'std::runtime_error' what(): usrp2: unhandled clock configuration pps source Now, my GRC-based application doesn't even specify the clock configuration, and indeed, the generated python code has no reference to the clock configuration in it. So my guess is that the default initialization code now has an improper value in it. HELP! -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
I've noticed latency issues with one of the applications I'm working on. Latencies of up to tens of seconds have been observed, which I tried to combat by specifying recv_buff_size in the parameter list. Right now, I'm running with 4096 bytes, which at 400Ksps, gives me a roughly 1 second latency between input and output (where output is both an audio sink, and a couple of different file sinks as well as a scopesink2, and an FFT sink). But increasing it beyond 4096 bytes causes the latency to go up very quickly, and if I drop it to 1024 bytes, I start seeing over-runs. If you do the math, however, 4096 bytes is nowhere near 1 second worth of buffer. One second is 1.6Mbytes (400Ksps x 4bytes per sample). How is downstream buffer allocation policy affected by settings of recv_buff_size in UHD::SingleUsrp? This is probably the same can of worms I was talking about a few weeks ago, with trying to understand latency issues, and where they'd bite you for various classes of applications. For purposes of data recording, my current application can't really tolerate several seconds of latency--since events recorded will potentially need to be cross-correlated with other receivers (although not phase-synchronous, just event correlation down to one or two seconds of accuracy). -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote: I've noticed latency issues with one of the applications I'm working on. Latencies of up to tens of seconds have been observed, which I tried to combat by specifying recv_buff_size in the parameter list. Right now, I'm running with 4096 bytes, which at 400Ksps, gives me a roughly 1 second latency between input and output (where output is both an audio sink, and a couple of different file sinks as well as a scopesink2, and an FFT sink). But increasing it beyond 4096 bytes causes the latency to go up very quickly, and if I drop it to 1024 bytes, I start seeing over-runs. If you do the math, however, 4096 bytes is nowhere near 1 second worth of buffer. One second is 1.6Mbytes (400Ksps x 4bytes per sample). Since you've got a usrp* source and an audio_sink, what you're seeing could be related to the two different clocks in the flow graph. Do you see the problem if the audio_sink is NOT in the graph? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote: Since you've got a usrp* source and an audio_sink, what you're seeing could be related to the two different clocks in the flow graph. Do you see the problem if the audio_sink is NOT in the graph? Eric Hard to get objective numbers, but it seems like there's no difference whether I have the audio sub-graph enabled or disabled. The absolute minimum latency I can observe is about 1 second or so, with an input recv_buff_size=2500. I know that there's buffering in the USRP2, but not that much--32K? Less? More? Even so, at my sample rate, 32K is only about 20ms of latency. I'm happy that I've gotten it down to ~1sec. At that latency, cross-site event correlation will be possible. At 10s of seconds, it would be more of a challenge. But this really does reinforce my notion that some kind of latency policy machinery needs to be implemented, and I'm quite happy to toss ideas around. I totally understand the need for big buffers to amortize scheduling/function-call/whatever costs, but I'm thinking that things need to be tunable in a way that is exposed to the (perhaps more sophisticated) applications developer. Interestingly enough, I did some tests on my app to see how filter parameters affected latency. They didn't appear to noticably affect it, at least in subjective tests. My pre-detector filter can have a user-tunable bandwidth anywhere from 5KHz to 250KHz, with an input sample rate of 400Ksps. That results in a fairly-large range of filter lengths, which I assume would get factored into buffer calculations, but clearly, there's enough quantizing in buffer calculations going on that it doesn't matter a hoot. Filter lengths vary from 38 taps to 1850 taps, depending on pre-detector bandwidth. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
Hard to get objective numbers, but it seems like there's no difference whether I have the audio sub-graph enabled or disabled. The absolute minimum latency I can observe is about 1 second or so, with an input recv_buff_size=2500. I know that there's buffering in the USRP2, but not that much--32K? Less? More? Even so, at my sample rate, 32K is only about 20ms of latency. The host cannot back-pressure the USRP2, and the buffering in the USRP2 itself if negligible. So, all of the backing-up that is going to happen occurs in the host when you dont read data out fast enough. The UHD-USRP2 receive path has two buffers that fill when calls to recv() dont keep up. One is the socket buffer in the kernel, and the other is a UHD allocated buffer that hangs onto frames from the socket-receive() call. Both of those drop when filled, so any further buffering/latency you are seeing is happening in gnuradio. You can manipulate the socket buffer size and the number of frames: http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
