Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. txrx_loopback_to_file test (Raul Casas)
2. Re: X3X0 second channel SBX corrupted samples? (LEMENAGER Claude)
3. Re: USRP-users Digest, Vol 50, Issue 20 (Terry Stevenson)
4. Re: uhd_cal_tx_iq_balance skips wide frequency range
(Michael West)
5. Re: Keep transmitted signal in USRP to overcome the limited
host sample rate of E100/E110 (Jack)
6. Re: USRP-users Digest, Vol 50, Issue 20 (Ralph A. Schmid, dk5ras)
7. N210 WBX annoying spurs while switching (bob wole)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Oct 2014 12:01:24 -0700
From: Raul Casas <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] txrx_loopback_to_file test
Message-ID:
<ffce1b628215dc439579cbc8236527530b90590...@mailsj4.global.cadence.com>
Content-Type: text/plain; charset="us-ascii"
I would like to run a basic TX/RX loopback test on a B200 using the baseline
utility function. I connect an SMA cable with 30dB inline attenuator from RF
A: TX/RX to RF A: RX2 and run the command below. The resulting sample stream
does not look correct - the samples are low in amplitude and look quantized.
I am concerned the antenna and device parameters (tx-and, rx-ant, tx-subdev,
rx-subdev, tx-channels, rx-channels) are not setup properly. Can someone
please tell me if and how those need to be configured and if there is some
documentation available describing this for the B200?
Thanks for the help.
Raul.
txrx_loopback_to_file.exe -tx-rate 2e6 -rx-rate 2e6 -tx-freq 1e9 -wave-type
SINE -wave-freq 100000 -rx_gain 20
Win32; Microsoft Visual C++ version 10.0; Boost_105400; UHD_003.007.002-release
Creating the transmit usrp device with: ...
-- Operating over USB 3.
-- Initialize CODEC control...
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Asking for clock rate 32.000000 MHz
-- Actually got clock rate 32.000000 MHz
-- Performing timer loopback test... pass
Creating the receive usrp device with: ...
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX2
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
Using Device: Single USRP:
Device: B-Series Device
Mboard 0: B200
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX2
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
Setting TX Rate: 2.000000 Msps...
Actual TX Rate: 2.000000 Msps...
Setting RX Rate: 2.000000 Msps...
Actual RX Rate: 2.000000 Msps...
Setting TX Freq: 1000.000000 MHz...
Actual TX Freq: 1000.000000 MHz...
Setting RX Freq: 1000.000000 MHz...
Actual RX Freq: 1000.000000 MHz...
Press Ctrl + C to stop streaming...
Setting device timestamp to 0...
Done!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141020/4f9e27d7/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 21 Oct 2014 17:32:31 +0200
From: LEMENAGER Claude <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X3X0 second channel SBX corrupted samples?
Message-ID:
<17672_1413905582_54467cad_17672_2532_1_59957d668d245c4eb38e8f85c054e90107762d0...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="iso-8859-1"
Hello
New tests with NIUSRPRIO_PCIE==>UHD003.008.000-RC1 ==>Gnuradio 3.7.5
I have attached a file with the results but appears to be the same as
UHD003.007.002:
Channels B:0 are corrupted (sorry for the file which is heavy)
Best regards,
Claude
==========================================
Hello Marcus,
No changes with this other firmware. I am building UHD 003.007.003-RC1 for
further tests.
Regards,
Claude
=========================================
Hello Marcus,
I am working at 950MHz (RF) sampling 25MHz.
One thing is curious: In grc I specify External for both Clock source and Time
but when running I obtain:
...
- References Initialized to internal sources
WARN: Sensor 'lo_locked' failed to lock within timeout on channel 0
... (other channels)
>From UHD-FFT example (QT), I obtain the same but the indicator 'lo_locked' is
>in locked state.
And more curiously, I use an Octoclock as external source, the PPS led is not
synchronized between Octoclock and X310 (even between X310 despite the fact I
set them to External References! (seems not to be aware from the settings)
With the respect of the images, I used the one of the 20 Aug 2014
(003.007.002-48) but have seen it exists one of 21 Aug-2014 (003.007.002-440)
(dates from tags in directory). I will try with this one.
Thank you,
Claude
De : Marcus M?ller [mailto:[email protected]]
Envoy? : jeudi 9 octobre 2014 15:39
? : [email protected]
Objet : Re: [USRP-users] X3X0 SBX corrupted samples?
Hello Mr. Lem?nager,
the warning that the LO is not locked is severe in principle; are you using an
external reference clock?
Could you paste the complete warning?
At which frequencies are you working?
Greetings,
Marcus
On 09.10.2014 15:30, LEMENAGER Claude via USRP-users wrote:
Hello,
I sample at least two channels (SBX 120) from one or multiple X310 boards each
equipped with two SBX radio boards.
I uses NIUSRPRIO_PCIE==>UHD003.007.002 ==>Gnuradio 3.7.5 (built for this UHD
under UBUNTU 14.04LTS).
The input is connected to a CW generator. The channels definition is A:0 B:0,
antenna is RX2 in all cases.
The problems :
1) I receive a warning concerning lo_locked no locked after timeout for each
channel (I read a discuss where this fact was given)
2) When I connect the A:0 channel on a gnuradio scope, this seems OK (I and
Q parts). When I connect a B:0 channel (from any X310 board) I receive the CW
wave plus spurious (sort of dirac through a filter) generally starting on Q
channel but not only. This look like an erroneous sample (digitally speaking
for example just an incorrect bit in the LSBs) before DDC. The spurious looks
like periodic but the period seems to change with radio frequency (to confirm)
Did somebody encounters this problem?
If yes, is there a solution.
I plan to try to reproduce this (or to see if it's the same) with UHD directly
accessed BY a C++ application.
Regards,
Claude Lem?nager
P.S. Conclusion about preceding discussion (june) about PCIe interface: The HP
PC on which I made my firsts experiences was equipped with one of the first
generation PCIe chip. So it failed to interface with X310. I now uses a last
generation pc and then there is no problem except for what I mention above.
Thanks for support.
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/b789ddf5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UHD003.008.00-RC1-Pb.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 3220082 bytes
Desc: UHD003.008.00-RC1-Pb.docx
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/b789ddf5/attachment-0001.docx>
------------------------------
Message: 3
Date: Tue, 21 Oct 2014 11:34:46 -0500
From: Terry Stevenson <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 50, Issue 20
Message-ID:
<CANLZwWt8RB0=jnDB63VbkYpjMRppq0yQX+V2Qj=cf0clknm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Soumen,
This sounds like a problem that I was having a while ago (assuming you're
on Ubuntu, otherwise I have no idea). It appears to be an issue in the UHD
driver, hopefully it is fixed in a future update. My workaround is a bit
weird, but I was able to make it stop crashing by first lowering the sample
rate, then raising it back up. For example, uhd_fft defaults to 1Msps, if I
leave it there, it runs a while and then crashes. If I lower it to 500 ksps
it runs awhile and still crashes. However, if I lower it to 250 ksps, then
raise it back to 500 ksps, it will run for weeks and still not crash. It's
very strange, but it's consistent. For reference, I'm using 3.7.2.
Hope this helps,
Terry
> Greetings!
>
> I managed to install gnuradio and uhd and it seems to be able to detect
> the usrp device. It shows up in the output of lsusb.
>
> I was trying out the simple fm radio demonstration and that one kept
> crashing. No debug output, nothing. It just froze. So I thought Ill look at
> the basics and tried to run the uhd_fft app (from path). I put the sampling
> frequency in the FM band since I know the FM stations over here and I was
> able to see peaks at the expected frequencies, but its not a continuous
> FFT. It just freezes immediately after the first graph is plotted. Is there
> something that Im missing? Im inclined to think that the installation went
> all right because the peaks in the snapshot FFT match so well with the
> expected radio stations!
>
> I noted that someone else has had this problem with a N210 before, and
> they solved it by updating the OS and playing around with the Ethernet
> settings, but Im connected to the B210 over USB, so that method can't be
> tried.
>
> Any suggestions?
>
> Thanks!
> Soumen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/056ae2d1/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 21 Oct 2014 16:51:10 -0700
From: Michael West <[email protected]>
To: Urban Hakansson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
range
Message-ID:
<CAM4xKroNNa8Ahg3W8ar3j8MR22sMdSO58AE1=etsA=t_sop...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Urban,
First, I honestly do not know why the value of 30 was hard coded. I
believe the "initial_suppression" value should be used, which is the
measured value with no correction applied.
Regarding the IQ imbalance you are seeing, I have a few questions. Is it
on TX or RX? How are you measuring it? What is your set up (are you
looping back or connected to a signal generator and/or spectrum
analyzer)? What gain level(s) are you using? Also, sharing the flowgraph
you are using would help.
Best regards,
Michael
On Tue, Oct 21, 2014 at 6:58 AM, Urban Hakansson <[email protected]>
wrote:
> Michael,
>
> Thanks for your reply.
>
> We changed the threshold to 15 and now we get calibration data written to
> file for each freq step.
>
> Q: What is the reason the threshold is set to 30? Is there any reason I
> should not set it to 15 or any other value? Is there is a reason this
> parameter value is hard coded and is not something you can pass in as an
> argument?
>
> Regardless, the original problem I wanted to solve by calibrating in finer
> frequency steps still remains, namely, the residual IQ imbalance is too
> large in certain bands.
>
> I calibrated the entire N210+SBX frequency range from 400 to 4400 MHz in
> 200kHz steps, thinking that should do it.
>
> To check for any residual IQ imbalance I then generated a complex
> exponential with amplitude 0.1 and frequency f = 1.25 MHz, sampled at Fs =
> 6.25 MHz, and set tx gain to 0dB (using GnuRadio flowdiagram).
>
> I varied the center frequency fc (LO) in 100MHz steps from 700 MHz to 3000
> MHz, measured the power-ratio between fc+f and the undesired replica at
> fc-f which is due to residual IQ imbalance.
>
> fc (MHz) P_(fc-f)/P_(fc+f) (dB)
> 700 -40
> 800 -23
> 900 -17
> 1000 -22
> 1100 -27
> 1200 -40
> 1300 -12
> 1400 -15
> 1500 -40
> 1600 -40
> 1700 -21
> 1800 -13
> 1900 -40
> 2000 to small to measure (-infinity)
> 2100 -12
> 2200 -14
> 2300 to small to measure (-infinity)
> ... ...
> 3000 to small to measure (-infinity)
>
> I thought that by calibrating the residual IQ imbalance would result in a
> power ratio of at least < -40dB between the undesired replica at fc-f and
> the original signal at fc+f.
>
> Maybe my expectations are too high, or perhaps I have a bad SBX
> daughterboard?
>
> Q: What results should I realistically be able to expect using the N210 +
> SBX combination?
>
> Regards,
>
> Urban
>
> ------------------------------
> *From: *"Michael West" <[email protected]>
> *To: *"Urban Hakansson" <[email protected]>
> *Cc: *"[email protected]" <[email protected]>
> *Sent: *Thursday, October 9, 2014 3:03:08 PM
> *Subject: *Re: [USRP-users] uhd_cal_tx_iq_balance skips wide frequency
> range
>
>
> Hi Urban,
>
> If I am understanding you correctly, you are saying that there is no
> calibration data for those frequencies in the resulting file. That does
> not mean the frequencies are being skipped by the utility. That only means
> that a suppression of over 30 dB could not be achieved for those
> frequencies, so no correction data was saved. You can set a lower
> threshold for the minimum suppression by changing the value in the
> following line in each IQ calibration utility:
>
> if (best_suppression > 30){ //most likely valid, keep result
>
> Best regards,
> Michael
>
> On Thu, Oct 9, 2014 at 8:57 AM, Urban Hakansson via USRP-users <
> [email protected]> wrote:
>
>> Hi everybody,
>>
>> I am trying to calibrate my N210 SBX daughterboard using the three
>> calibration scripts uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance,and
>> uhd_cal_tx_dc_offset using different values for freq_start, freq_stop, and
>> freq_step.
>>
>> uhd_cal_tx_iq_balance utility that is not behaving as I expected.
>> (uhd_cal_rx_iq_balance and uhd_cal_tx_dc_offset give me no problems).
>>
>> If I run uhd_cal_tx_iq_balance with any other values besides the default
>> values it will skip approximately 300MHz of frequencies from 790 MHz to ~
>> 1100MHz.
>>
>> Here are a few of my attempts.
>>
>> uhd_cal_tx_iq_balance --freq_start 500000000
>> uhd_cal_tx_iq_balance --freq_start 600000000
>> uhd_cal_tx_iq_balance --freq_start 700000000
>> uhd_cal_tx_iq_balance --freq_start 785000000
>> uhd_cal_tx_iq_balance --verbose --freq_step 100000
>> uhd_cal_tx_iq_balance --verbose --freq_step 110000
>> uhd_cal_tx_iq_balance --verbose --freq_step 225000
>> uhd_cal_tx_iq_balance --verbose --freq_step 900000
>> uhd_cal_tx_iq_balance --verbose --freq_step 1000000
>> uhd_cal_tx_iq_balance --verbose --freq_step 1100000
>> uhd_cal_tx_iq_balance --verbose --freq_step 2000000
>> ...
>> uhd_cal_tx_iq_balance --verbose --freq_step 7300000
>>
>> uhd_cal_tx_iq_balance always stops just before 790MHz and just sits
>> there, but does not abort, and after a really long time continues at ~
>> 1100MHz and continues all the way to 4370MHz without any further gaps.
>>
>> I attach the calibration scripts I am using and the three csv files for
>> one example, uhd_cal_tx_iq_balance --verbose --freq_step 225000.
>>
>> General background information about my environment:
>> Fedora 17 Linux; GNU C++ version 4.7.0 20120507 (Red Hat 4.7.0-5);
>> Boost_104800; UHD_003.007.001-0-unknown
>>
>> N210 informationfrom uhd_usrp_probe:
>> | Device: USRP2 / N-Series Device
>> | _____________________________________________________
>> | /
>> | | Mboard: N210r4
>> | | hardware: 2577
>> | | mac-addr: 00:80:2f:0a:e6:15
>> | | ip-addr: 192.168.2.199
>> | | subnet: 255.255.255.255
>> | | gateway: 255.255.255.255
>> | | gpsdo: none
>> | | serial: F4A09C
>> | | FW Version: 12.4
>> | | FPGA Version: 10.1
>>
>> What could the cause of this behaviour be? Are there only certain
>> combination of values that work? What do I need to do to make
>> uhd_tx_iq_balance not hang right before 790MHz?
>>
>> Thanks for you consideration.
>>
>> Regards,
>>
>> Urban Hakansson
>> Senior Software Engineer
>> Tecore Networks
>> Phone: +1 410 872 6315
>> Fax: +1 410 872 6010
>> Email: [email protected]
>>
>>
>> Urban Hakansson Senior Software Engineer Tecore Networks Phone: +1 410
>> 872 6315 Fax: +1 410 872 6010 Email: [email protected]
>>
>> Urban Hakansson
>> Senior Software Engineer
>> Tecore Networks
>> Phone: +1 410 872 6315
>> Fax: +1 410 872 6010
>> Email: [email protected]
>>
>>
>>
>>
>> This e-mail may contain privileged, confidential, copyrighted or other
>> legally protected information, and is intended exclusively for the intended
>> recipient. If you are not the intended recipient (even if the e-mail
>> address above is yours), you may not review, store, use, copy, disclose or
>> retransmit it in any form. If you are not the intended recipient or
>> otherwise have received this by mistake, please immediately notify the
>> sender by return e-mail (or [email protected]), then delete the
>> message in its entirety. Thank you.
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>
> This e-mail may contain privileged, confidential, copyrighted or other
> legally protected information, and is intended exclusively for the intended
> recipient. If you are not the intended recipient (even if the e-mail
> address above is yours), you may not review, store, use, copy, disclose or
> retransmit it in any form. If you are not the intended recipient or
> otherwise have received this by mistake, please immediately notify the
> sender by return e-mail (or [email protected]), then delete the message
> in its entirety. Thank you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141021/c499e841/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 22 Oct 2014 09:49:52 +0900
From: Jack <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Keep transmitted signal in USRP to overcome
the limited host sample rate of E100/E110
Message-ID:
<CAHoWzP00Syj+aN2Jzc5UzU3AOoBP=mif8lsz_wgdq8vibaa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Marcus,
Thank you for your answer.
In my case, I want to sent the periodic signal. It means that I just want
to keep one set of signal in FPGA and send it out repeatedly.
As my calculation, it takes < 100 Kbits. That's why I think that it can be
stored in FPGA of E100/E110.
Best Regards,
Jack
On Tue, Oct 21, 2014 at 8:11 PM, Marcus M?ller <[email protected]>
wrote:
> Jack,
>
> the FPGA is not a storage device, and even if you could use all the block
> RAM on the FPGA and add some more memory by using logic cells, you won't
> store /much/ on the moderately sized E100 FPGA or even on the E110's one.
> So, you'd be limited to short bursts of TX samples.
>
> The question whether something is "simple work" heavily depends on the
> experience of the one doing that work. Since you ask, I assume you're not
> very experienced doing FPGA development; as that seems to exhibit a rather
> steep learning curve, I'm afraid the answer is "it's not simple".
>
> Greetings,
> Marcus
>
>
> On 17.10.2014 09:38, Jack via USRP-users wrote:
>
> Hi -
>
> As you know, embedded series, E100/E110, has the limited host sample rate,
> just only 4MS/s. But I want to send bigger signal bandwidth (ex. 20Mhz).
>
> My idea to overcome this issue is to keep the transmitted signal inside
> FPGA. But I have not started to work on this yet. Have anyone tried to do
> so? Could you share your experience? Is it possible? Simple work? or
> Complicated work?
>
> Best Regards,
> Jack
>
>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/2522740f/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 22 Oct 2014 07:45:00 +0200
From: "Ralph A. Schmid, dk5ras" <[email protected]>
To: "'Terry Stevenson'" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] USRP-users Digest, Vol 50, Issue 20
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Very interesting ? but for me it does not work, going from 250kHz in some steps
up 8M made the thing freeze like when directly starting with 32M.
Ralph.
From: USRP-users [mailto:[email protected]] On Behalf Of Terry
Stevenson via USRP-users
Sent: Tuesday, October 21, 2014 6:35 PM
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 50, Issue 20
Hi Soumen,
This sounds like a problem that I was having a while ago (assuming you're on
Ubuntu, otherwise I have no idea). It appears to be an issue in the UHD driver,
hopefully it is fixed in a future update. My workaround is a bit weird, but I
was able to make it stop crashing by first lowering the sample rate, then
raising it back up. For example, uhd_fft defaults to 1Msps, if I leave it
there, it runs a while and then crashes. If I lower it to 500 ksps it runs
awhile and still crashes. However, if I lower it to 250 ksps, then raise it
back to 500 ksps, it will run for weeks and still not crash. It's very strange,
but it's consistent. For reference, I'm using 3.7.2.
Hope this helps,
Terry
Greetings!
I managed to install gnuradio and uhd and it seems to be able to detect the
usrp device. It shows up in the output of lsusb.
I was trying out the simple fm radio demonstration and that one kept crashing.
No debug output, nothing. It just froze. So I thought Ill look at the basics
and tried to run the uhd_fft app (from path). I put the sampling frequency in
the FM band since I know the FM stations over here and I was able to see peaks
at the expected frequencies, but its not a continuous FFT. It just freezes
immediately after the first graph is plotted. Is there something that Im
missing? Im inclined to think that the installation went all right because the
peaks in the snapshot FFT match so well with the expected radio stations!
I noted that someone else has had this problem with a N210 before, and they
solved it by updating the OS and playing around with the Ethernet settings, but
Im connected to the B210 over USB, so that method can't be tried.
Any suggestions?
Thanks!
Soumen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/53b07040/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 22 Oct 2014 13:25:02 +0500
From: bob wole <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] N210 WBX annoying spurs while switching
Message-ID:
<cagd3ozzo6bq9pmam7gdm1x-gpfa9lvrpapg6shwd635ypra...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I noticed that there are a lot of significant spurs generated in the output
of WBX, on different frequencies randomly, when I use tx_time,
tx_sob_tx_eob tags. I do not see these spurs if I transmit continuously.
These spurs appears only when I start and stop transmission using stream
tags.
How can I get rid of these spurs and what is the cause?
-
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141022/7e2718d2/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 50, Issue 21
******************************************
