Re: [Discuss-gnuradio] 100 Msps N210 update

On Apr 23, 2012, at 3:39 PM, Eugene Lee wrote: > >> The FPGA has no transmit logic, so it can only receive. We've tested it > with a DBSRX2, > but other daughterboards should work. > > Does this mean that the update disables the N210's transmit capability? or > that the 100 MSps only works on t

[Discuss-gnuradio] 100 Msps N210 update

I just updated the repository at https://github.com/mepard/N210CeVI. * It's compatible with the latest UHD host library. * It no longer requires a modification to the UHD host library. * uhd_streamer uses the channel API to switch to the 2nd DSP chain for 100 Msps. * uhd_streamer builds and works

[Discuss-gnuradio] Job openings that might interest list members

We have two job openings here at Horizon Analog. We're a small outfit in downtown Lawrence, Kansas, a great college town. One position is more RF hardware oriented and one is more software and DSP related. We're developing non-linear technology and use Ettus radios for a lot of our work, partial

Re: [Discuss-gnuradio] Sample fast and upload after

It's out of date, though. We've had our system and libraries frozen for a while as we were finishing a project. I'm in the process of updating it to the latest UHD and will post when I'm finished. -Marc On Sep 22, 2011, at 3:17 PM, Per Zetterberg wrote: > > Marc E

Re: [Discuss-gnuradio] N210 recovery, no luck

On Jul 5, 2011, at 12:05 PM, Josh Blum wrote: > Strange. Were you (by some chance) streaming samples from the device > while re-programming? I ask because this has always been the cause of > this particular problem. I'm pretty sure we had this happen without streaming, though in one instance st

[Discuss-gnuradio] Anyone else at WWDC?

Want to meet up sometime this week? -Marc (Sent from my iPhone) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Synchronization issue with multiple USRPs

On May 25, 2011, at 9:14 AM, Josh Blum wrote: > 2) Calibrate the setup. After you tune, the daughterboard LOs will have > different constant phase offsets. In my experience (with a WBX in a USRP2 and a DBSRX2 in an N210), the phase offsets can change between bursts, not just when you retune. Is

Re: [Discuss-gnuradio] Cypress publicly announces USB 3.0 FX3 controller

http://www.pcworld.com/article/224995/intel_to_open_up_thunderbolt_development_this_quarter.html Thunderbolt is another possibility. "Up to" 10 gigabits per second per each of two channels. -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gn

Re: [Discuss-gnuradio] USRP Streaming Latency

On Mar 30, 2011, at 4:45 PM, Tom Hendrick wrote: > Does anyone else have any ideas on what I should try? You might try profiling one or both apps or the system to see where they're spending time. I like RotateRight's Zoom better than the free ones I've tried. -Marc __

Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help, (variant for FunCube Dongle?)

On Mar 19, 2011, at 10:34 AM, "Marcus D. Leech" wrote: > There is no automatic gain control in the WBX hardware. The step attenuators > are set when you set the hardware RF gain of the daughter-card. There's AGC on the WBX tx side, but not rx. -Marc ___

Re: [Discuss-gnuradio] 100 Msps FPGA code for USRP N210 - Gnu Spectrum analyzer

On Mar 18, 2011, at 3:58 PM, Moeller wrote: > Thanks for publishing. This is very impressive, using Gnuradio as a spectrum > analyzer. Thanks. It's been a fun project. > - What about compensating the spectral shape within the measurement bandwidth? Seems doable. I'm only now learning signal pr

[Discuss-gnuradio] 100 Msps FPGA code for USRP N210

I posted this to the USRP users list since we're not using GNU Radio proper for this project, but Devin's questions about spectrum sensing make me think it could be useful for GNU USRP users, too. Although we did this on the N210, it might be possible to do something similar on the USRP2. We've

Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved

Hi Scott, You'll find uhd_streamer.cpp at . Some things you should know: * It doesn't use gnu-radio, but uses UHD directly. (We should move to the usrp-users list if you want to continue the discussion.) * It can do two UHD transmits and one receive at the same ti

Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved

Thanks, Jason. I should have posted our observations back when we made them. We're doing okay with the two-USRP setup, but it's good to have options. -Marc On Mar 14, 2011, at 12:30 PM, Jason Abele wrote: However, the WBX has enough internal leakage between tx and rx that we gave up o

Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved

On Mar 14, 2011, at 8:53 AM, Marcus D. Leech wrote: > On 14/03/2011 9:42 AM, Scott Johnston wrote: >> Does anybody have an example of how to setup a full duplex app? >> >> I am using the uhd with the USRP n210. >> >> Marc Epard wrote: >>> I've been

Re: [Discuss-gnuradio] GNURadio and CUDA reprised

Has anyone thought about something like Apple's Core Image for signal processing? Core Image lets you express image filters in a C-like filter language (a subset of GLSL). You chain a set of filters together to achieve the desired effect and then at runtime Core Image uses an LLVM complier to ge

Re: [Discuss-gnuradio] CPU Utilization and USRP2

This reminds me of a question. What do you guys use for profiling native code on Linux? I have a lot more experience on Mac OS where we have Shark, Instruments and the like. -Marc On Nov 4, 2010, at 2:23 PM, Josh Blum wrote: > Well, there is extra overhead. A "pirate" thread in the the receive

Re: [Discuss-gnuradio] GNU Radio roadmap

It's probably more Ettus than GNU Radio, but I'm interested in the direction of the UHD wire protocol, particularly ethernet host side flow control, which gets mentioned now and then on this list. -Marc ___ Discuss-gnuradio mailing list Discuss-gnura

Re: [Discuss-gnuradio] A very stupid question

On Oct 11, 2010, at 7:50 AM, Thunder87 wrote: > Now the stupid question: If one of machines is laptop with no COM port, how > can I get the same result (connect from laptop to PC , run script, receive > all the data which script would output to terminal)? > No bluetooth or wifi available. This lea

Re: [Discuss-gnuradio] Intel Atom Processor

On Oct 8, 2010, at 1:46 PM, Sharif Shaher wrote: > We are thinking of using a 1.6GHz Intel Atom processor based PC with multiple > gigabit Ethernet ports > to collect data from multiple USPR2s and save that data off to disk. We are > hoping to be able to > use decimation rates as low as 4 for c

Re: [Discuss-gnuradio] File sink causes "S" errors

I ended up writing my own command line tool to get around this. Depending on your particular needs, it might work for you. Instead of filling a buffer and writing it to disk over and over, I allocate a buffer as large as I need, fill it, stop sampling, and write it to disk. There is no point whe

Re: [Discuss-gnuradio] USRP2 1pps synchronization delay

On Oct 1, 2010, at 12:37 PM, David Campbell wrote: > Also, I'm noticing that my sync_and_start_rx_streaming_at command hangs > about > 15 out of 16 tries (the other 1 of 16 times or so everything works) - I > didn't > know if others are seeing this too. I asked about problems with sync_a

Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive

On Sep 23, 2010, at 1:42 AM, George Nychis wrote: > Did you ever get this fixed? I'm seeing the same problem... And later: > However, I'm not using UHD. Do you know a fix for this outside of UHD? Then: > I see the USRP2 send mac pause frames, and then no new data is sent over the > interfac

[Discuss-gnuradio] UHD transmit issues solved

Recently, I've started two threads involving problems using UHD. It turns out they were both on the transmit side and I stumbled onto a solution for both: way smaller send_buff_size. Like 50,000 bytes instead of 50

Re: [Discuss-gnuradio] UHD GRC loopback glitches

On Sep 17, 2010, at 3:44 PM, Josh Blum wrote: > This could very well be underflow on the tx or overflow on the rx. Are you > seeing Us and Os printed to stderr while running? Ah, I forgot to mention that nothing is printed to stderr, nor to the UART. > I suggest: > > 1) reduce the sample rate

[Discuss-gnuradio] UHD USRP2 full duplex mystery solved

I've been attempting to do a full duplex send/recv using UHD on a USRP2 with an XCVR2450. The major problem I had was that issue_stream_cmd nearly always resulted in a runtime error of "usrp2 no control response". It worked fine if I transmitted w/o receiving or received w/o transmitting. The s

[Discuss-gnuradio] recv_async_msg questions

As far as I can tell, EVENT_CODE_SUCCESS (Defined as success: a packet was successfully transmitted) events never seem to happen. That's okay with me and I'd worry about the bandwidth they'd take if I were transmitting and receiving at the same time. Are they just not implemented, yet? I need t

[Discuss-gnuradio] EVENT_CODE_SEQ_ERROR_IN_BURST (was re: UHD host resources and system suggestions)

On Sep 7, 2010, at 1:10 PM, Marc Epard wrote: > On Sep 7, 2010, at 11:46 AM, Josh Blum wrote: > >> sequence errors are not normal, something may be wrong with the fpga image. >> we are trying to duplicate it out over here -josh > > Thanks, Josh. If it's helpful,

Re: [Discuss-gnuradio] UHD host resources and system suggestions

On Sep 7, 2010, at 11:46 AM, Josh Blum wrote: > sequence errors are not normal, something may be wrong with the fpga image. > we are trying to duplicate it out over here -josh Thanks, Josh. If it's helpful, you'll find the source to my app at . -Marc ___

Re: [Discuss-gnuradio] UHD host resources and system suggestions

On Sep 3, 2010, at 5:57 PM, Marcus D. Leech wrote: > I'll comment that a 1.6GHz machine that's getting close to 4 years old > isn't particularly "beefy" by todays standards. Certainly not > beefy enough to sustain two 25Msps threads without "problems". Thanks, Marcus. That was helpful and as I

Re: [Discuss-gnuradio] UHD host resources and system suggestions

PM, Marc Epard wrote: > I'm a puzzled by some UHD behavior and wondering if I need a new host system. > I'm not doing any signal processing in the host -- just transmitting from a > buffer and/or receiving from a buffer. Later, we'll be wanting to do more > proc

[Discuss-gnuradio] UHD host resources and system suggestions

I'm a puzzled by some UHD behavior and wondering if I need a new host system. I'm not doing any signal processing in the host -- just transmitting from a buffer and/or receiving from a buffer. Later, we'll be wanting to do more processing with two USRP2s both transmitting and receiving at the sa

Re: [Discuss-gnuradio] UHD recv timestamp differs from stream command time spec

On Sep 2, 2010, at 1:02 PM, Matt Ettus wrote: > [An excellent answer.] Thanks! -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Detecting transmit underruns on UHD

On Sep 2, 2010, at 12:23 PM, Josh Blum wrote: > See recv async message: > http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605 > > And the async metadata: > http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html Thanks, J

[Discuss-gnuradio] UHD recv timestamp differs from stream command time spec

I'm using a USRP2 with UHD and starting a receive a short time in the future. I have an external reference and PPS. Below is the pertinent code, slightly simplified. The timestamp returned in the metadata by recv is always off a little from the time I requested in the stream command. The amount

[Discuss-gnuradio] Detecting transmit underruns on UHD

With UHD, how can I programmatically detect when transmit underruns have occurred? I see Us in the output both on the host and from the USRP2 serial port, but I haven't spotted an API to test for this condition. -Marc ___ Discuss-gnuradio mailing li

[Discuss-gnuradio] GNU Radio + UHD install

Yesterday I did a ground-up install of GNU Radio for UHD. Since all the steps were kind of scattered around various websites and list posts, I thought I'd post them all in one place. Hopefully this'll make it easier for the next guy. This was on Ubuntu 10.04. You'll need all the prerequisites (e

[Discuss-gnuradio] No data from start_rx_streaming_at, sync_and_start_rx_streaming_at

I can't seem to get sync_to_pps + start_rx_streaming_at or sync_and_start_rx_streaming_at to work. The methods return true, but my receive handler never gets called. start_rx_streaming works fine. I've waited well past the time the overflow period of the 32-bit timestamp. I've tried scheduling t

Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive

On Aug 24, 2010, at 11:16 PM, George Nychis wrote: > I don't think I've had this issue with my WBX and USRP2. I will check > tomorrow for you Thanks! I'd appreciate it. I've now replicated the problem with a XCVR2450, so I don't think it's WBX-specific. I've altered my code to support separa

Re: [Discuss-gnuradio] MIMO cable and timestamps (raw ethernet)

Oops. The code got cut off. Here's the full routine. -Marc bool operator()(const uint32_t *items, size_t numItems, const usrp2::rx_metadata *metadata) { if (_numFrames == 0) { // The expected time prediction for the second frame is always off by 19 ticks, // suggesting

[Discuss-gnuradio] MIMO cable and timestamps (raw ethernet)

With rx_streaming_samples.cc as a starting point, I created a new usrp2::rx_sample_handler that simply buffers samples in memory. The handler's operator() is shown below. I need precise timing data between receives, so it counts sample clock overflows to form a 64-bit time. To make sure it was

Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive

On Aug 23, 2010, at 10:10 PM, George Nychis wrote: > If you stop transmitting, does your RX sample stream then begin again? Alas, no. Once it stops receiving, it never starts again. Time to dig into the firmware. -Marc ___ Discuss-gnuradio mailin

[Discuss-gnuradio] USRP2+WBX full duplex doesn't receive

I'm trying to simultaneously transmit and receive with a USRP2 and WBX in a C++ command line tool. I'm using txrx_wbx_raw_eth_20100608.bin and u2_rev3-20100603.bin on the USRP2 and have tried GNU Radio version 3.3.0 and 3.3.1 on the Ubuntu 10.04 host. I have a spectrum analyzer on TX/RX and an

Re: [Discuss-gnuradio] Octave/MATLAB code for USRP2 DDC ?

On Aug 18, 2010, at 7:42 PM, Johnathan Corgan wrote: > On Fri, Aug 13, 2010 at 12:06, Marc Epard wrote: > >> Does anyone happen to have Octave or MATLAB code that models the USRP2's DDC >> (CIC and HBFs)? > > This covers the CIC portion: > > http://gnuradi

[Discuss-gnuradio] Octave/MATLAB code for USRP2 DDC ?

Does anyone happen to have Octave or MATLAB code that models the USRP2's DDC (CIC and HBFs)? -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2- Timestamp

On Aug 3, 2010, at 8:42 PM, Ashish Bansal wrote: > I am using USRP2. The newer version of GNU 3.3 contains timestamp code. > 1. What do you exactly mean by timestamp. Does it mean it will output the 64 > bit timer value with each sample. What is the command on the host side to see > these time

Re: [Discuss-gnuradio] USRP2 and DBSRX compatibility (?)

On Aug 3, 2010, at 4:15 PM, Moeller wrote: > did anybody manage to get this combination working together? Yes, after updating the EEPROM (using the USRP2 firmware) and moving the resister, this combination is working fine for us. OS: Ubuntu 10.04 GNU Radio: 3.0.3 FPGA: u2_rev3-20100603.bin F

Re: [Discuss-gnuradio] USRP2 start/stop issues redux

I've solved the problem with my own app. My sample handler had an uninitialized member and was sometimes finished before it started. The test app from the previous thread still has the failing assertion, but that might be a red herring. -Marc ___ Di

[Discuss-gnuradio] USRP2 start/stop issues redux

I'm having a problem similar to the one discussed in this thread: http://lists.gnu.org/archive/html/discuss-gnuradio/2009-09/msg2.html aka http://www.ruby-forum.com/topic/194488 If I run the test program from that post, it works sometimes, but occasionally an assertion goes off as shown in

Re: [Discuss-gnuradio] Can't set center frequency of USRP2 w/DBSRX

On Jul 26, 2010, at 4:56 PM, Marcus D. Leech wrote: > Something that would be useful would be a place for people to pick up > the necessary burn_dbsrx_eeprom.bin > without having to compile the C code. Just sayin' I found it at http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binari

Re: [Discuss-gnuradio] Can't set center frequency of USRP2 w/DBSRX

On Jul 26, 2010, at 11:29 AM, Marcus D. Leech wrote: > Did you do the conversion steps necessary to get a DBS_RX to work with the > USRP2? On Jul 26, 2010, at 11:24 AM, Josh Blum wrote: > Did you do the hardware mod where you move the resistor? > > http://gnuradio.org/redmine/wiki/gnuradio/USRP

[Discuss-gnuradio] Can't set center frequency of USRP2 w/DBSRX

We're new to gnuradio and have a shiny USRP2 with a DBSRX daughterboard. More details are below. The system is kind of working, but usrp2_fft.py reports Failed (or Invalid if there's a typo) for every frequency we enter regardless of whether it's in the supported range or not. Oddly, the entere

Re: [Discuss-gnuradio] Block from gr-howto-write-a-block-3.3.0.tar.gz doesn't work

On Jul 24, 2010, at 6:14 PM, Thunder87 wrote: > after successful installation without any errors, when launched in grc gives > this: > > ...ImportError: libgnuradio-howto-3.3.0.so.0: cannot open shared object file: > No such file or directory I just had the same problem. Try this: sudo ldconfi