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. Determination of received power in USRP N210
(Touseef Ali via USRP-users)
2. Re: Determination of received power in USRP N210
(Marcus D. Leech via USRP-users)
3. Ettus B2x0 enclosure group buy/machining?
(Armand Sperduti via USRP-users)
4. B210 Benchmark_rate (Robert Kossler via USRP-users)
5. 3D printing B210 enclosure (Usrp IITM via USRP-users)
6. Re: B210 Aliasing and Sampling Rate Precision
(Sabathy Mischa via USRP-users)
7. USRP B210 (ali hanif via USRP-users)
8. (no subject) (Habibur Rahman via USRP-users)
9. Re: B210 Aliasing and Sampling Rate Precision
(Matt Ettus via USRP-users)
10. Re: USRP B210 (Matt Ettus via USRP-users)
11. Re: [Discuss-gnuradio] X300 PCIe issues
(Lapointe, Benjamin - 1008 - MITLL via USRP-users)
----------------------------------------------------------------------
Message: 1
Date: Sun, 27 Apr 2014 21:52:05 +0500
From: Touseef Ali via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Determination of received power in USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi
How can I determine how much power the USRP is receiving in dBm with LFRx
daughterboard?
Regards
Touseef Ali
------------------------------
Message: 2
Date: Sun, 27 Apr 2014 13:24:51 -0400
From: "Marcus D. Leech via USRP-users" <[email protected]>
To: Touseef Ali <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Determination of received power in USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/27/2014 12:52 PM, Touseef Ali via USRP-users wrote:
> Hi
> How can I determine how much power the USRP is receiving in dBm with LFRx
> daughterboard?
>
> Regards
> Touseef Ali
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Mathematically, the instantaneous power is *proportional* to AVG(I*I +
Q*Q), wrap a sqrt around that for computing RMS power. But note
that I said *proportional*.
If you want to measure absolute power levels, you'll have to calibrate
using an RF source with a known power level, over several different
frequencies, and input power levels, because the LFRX response isn't
completely flat across its frequency ranges (it's *nearly* flat, but if
you want precision
power measurements, you have to understand the frequency response).
------------------------------
Message: 3
Date: Sun, 27 Apr 2014 14:23:20 -0700
From: Armand Sperduti via USRP-users <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Ettus B2x0 enclosure group buy/machining?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Another possibility would be for someone to lay out the panels for the
Hammond enclosure in Front Panel Express' software.
I've used them in the past and was pleased with the results.
I've been kicking around the idea, but haven't had the time to do it (I'm
not a great mechanical design type :-().
If someone does do it, please make it available to the group!
- Armand
Date: Sat, 26 Apr 2014 21:16:12 -0700
From: "Robert J. McIntyre via USRP-users" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Ettus B2x0 enclosure group buy/machining
interest?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm going to have to put this on hold for a while, for a couple of reasons:
- I haven't gotten much interest expressed, and bulk/volume only
works if there's more than 2 people. :)
- There's (apparently) pending changes to the boards coming, which
will affect the enclosure penetrations, negating any work done now
Thanks!
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140427/a843dfc7/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 27 Apr 2014 19:52:31 -0400
From: Robert Kossler via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B210 Benchmark_rate
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"
I am using a B210 with the benchmark_rate utility. If I set the cpu format to
"fc32" I can stream 2 channels at 25 MS/s with no overflows. However, if I set
the cpu format to "sc16", I always get one overflow that occurs near the
beginning of the 10 sec test. This seems odd to me given that the wire format
is "sc16" so I wouldn't expect an issue with the cpu format at "sc16". Does
anyone have a suggestion as to why this occurs?
The following is the command line I used;
./benchmark_rate --args="master_clock_rate=25e6" --rx_rate=25e6
--channels="0,1" --rx_cpu=sc16
I have run this several times and it seems very repeatable (i.e., "fc32"
produces no overflows and "sc16" produces one overflow). I then modified the
benchmark_rate utility to print out the place where the overflow occurs. It
seems to happen after about 80K samples have been received (about 40K per
channel), but the remaining 497M samples come through with no overflows.
I have attached the redirected output of the modified benchmark_rate utility
for each of the two cases.
For reference, my system is:
- Lenovo Thinkpad T430S
- Intel? Core? i5-3320M CPU
- Intel 7 USB
- Ubuntu 13.10
Rob Kossler
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: b210_benchmarkrate_sc16.txt
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140427/392634b3/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: b210_benchmarkrate_fc32.txt
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140427/392634b3/attachment-0003.txt>
------------------------------
Message: 5
Date: Mon, 28 Apr 2014 09:44:34 +0530
From: Usrp IITM via USRP-users <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] 3D printing B210 enclosure
Message-ID:
<CAPkh=_9=u+48bspsqjmradl1kk4v7mipbpruemn7xcbfesc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all
I have an access to a 3D printer and the guy who operates that said he can
get the enclosure printed if I could provide him .stl files. I do not know
much about 3D printing, so the following questions might be stupid. Sorry
There is a B210_PLATE_REV1.2_101113 NER.dxf file in
http://files.ettus.com/b2x0_enclosure/, can we convert this into .stl file
format?
Also how difficult is it to make STL file? Please suggest any software.
Thank you all.
Regards
Arjun Nadh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140428/6d04710a/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 28 Apr 2014 11:56:54 +0000
From: Sabathy Mischa via USRP-users <[email protected]>
To: Marcus Leech <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear all,
I investigated again on my sampling rate precision issue.
First I measured ?xo_out? coming from the external PLL at R113. I always
measured 40e6 Hz regardless of which ?clock rate? and ?sampling rate? I
configured in GNU Radio.
I checked then the BBPLL in the ?AD9361_Reference_Manual_UG-570.pdf? on page 20.
There I saw that for my case, F_VCO must be configured to 984.04e6 Hz (15.36e6
Hz sampling rate, LTE 15) on page 19.
This is done with the Fractional and Integer Word of Figure 7 on page 20.
If I calculate the F_VCO with the Frac and Int word modulus 2088960 and a F_ref
of 40e6 Hz it gives me the following results as the matlab code shows:
--Matlab Start
clear all;
clc;
f_vco = 983.04e6;
f_ref = 40e6; % 30.72e6;
f_sample = 15.36e6;
modulus = 2088960;
div = f_vco/f_ref;
div_int = floor(div);
div_frac = mod(div,1);
frac_new1 = div_int + floor(div_frac*modulus)/modulus;
frac_new2 = div_int + ceil(div_frac*modulus)/modulus;
frac_new3 = div_int + round(div_frac*modulus)/modulus;
f_err1 = frac_new1/div*f_sample-f_sample;
f_err2 = frac_new2/div*f_sample-f_sample;
f_err3 = frac_new3/div*f_sample-f_sample;
fprintf('f_error (floor) = %f Hz\n', f_err1); fprintf('f_error (ceil) = %f
Hz\n', f_err2); fprintf('f_error (round) = %f Hz\n', f_err3);
--Matlab end
Console OUTPUT:
f_error (floor) = -0.287224 Hz
f_error (ceil) = 0.011968 Hz
f_error (round) = 0.011968 Hz
Now it seems to be clear where my .012 Hz sampling rate error come from. Exact
LTE sampling rates with a 40e6 Hz clock reference source will never get reach
precisely, due to the limitation of the fractional modulus in the internal
BBPLL of the AD9361.
To solve this, I suggest that the external PLL should be set to 30.72e6 Hz or
61.44e6 Hz, in case of a LTE sampling rate request.
This should be possible with the N and R counter of the external ADF4001 PLL.
Ben do you agree? Will this be fixed soon?
Thanks for your response.
Mischa
From: Marcus Leech [mailto:[email protected]]
Sent: Freitag, 25. April 2014 16:09
To: Sabathy Mischa
Cc: [email protected]
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Ben:
Any comments on the information below?
on Apr 25, 2014, Sabathy Mischa <[email protected]<mailto:[email protected]>> wrote:
Hello Marcus,
No it is not statistically measured. It is a constant frequency offset in the
sampling rate. The B210 is locked to Rubidium freq standard with a accuracy of
at least 5*10^-11.
The precision was measured, splitting a reference signal and record it with a
N210 + WBX and a B210 in parallel. The recorded reference signal of both
devices got afterwards auto-correlated in GRC. The auto-correlation peak
position got interpolated, extracted and recorded for 4 hours to 3 days
(measured multiple times). The correlation repeats every 10msec. Both devices
were locked to the same rubidium. So the 0.012 Hz is the difference between the
N210 and the B210.
As it looks, the N210 is locked properly to the reference but on the B210 is
constant drift in the correlation peak which is generated by a 0.012 Hz
sampling error.
If I do the same measurement above with two N210, no drift can be observed. So
this must be a clear error caused by the B210, the sampling frequency is not
set properly to 15.36e6 Hz.
BR
Mischa
From: Marcus Leech [mailto:[email protected]]
Sent: Donnerstag, 24. April 2014 18:06
To: Sabathy Mischa
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
So, unless I'm mis-understanding what you're saying here, you've observed,
statistically, a 0.012Hz error in a sample-stream at 15.36Msps.
So, doing a bit of math, that's
0.012 / 15.e6e6
Or a residual sample-rate error of about 0.7PPB. That's actually
rather-better than I would expect from a GPSDO.
Please let me know if I've misunderstood what you're saying.
on Apr 24, 2014, Sabathy Mischa via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Thanks Ian for your update.
Regarding my issue #2 I found out that the sampling rate error is 0.012 Hz.
Does anybody has an idea what can cause this error? I saw in the schematic that
the PLL should be able to properly produce 15.36e6 Hz sampling rate with a 10e6
Hz source: 15.36e6 = 10e6*192/125. The ADF4001 has according to its datasheet a
R counter of 12 bit and a N counter of 13 bit. So 192 and 125 shouldn?t be a
problem at all. This clock is also the sampling clock of the AD9361, am I
right? I saw that the AD9361 has also an internal PLL for the sampling clock?
How is this managed? Can it be bug of wrong register setting in one of the two
chips? Has anybody made the same observation?
Thanks for your help.
Mischa
From: Ian Buckley [mailto:[email protected]]
Sent: Donnerstag, 17. April 2014 21:31
To: Sabathy Mischa
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Sabathy,
So I looked at issue #1 further. What I saw yesterday turned out to be a bug in
the new unreleased filter design specificly for the B200, the current public
B200 behaves as I expected for an interpolation ratio of 2.
When used in isolation the current 7 tap interpolation filter can only do so
much to suppress aliasing as is shown by this shot of the current 7 tap filter
overlaid on the new 47tap filter (Fs=11.52MHz for reference):
http://ianbuckley.net/hb7_vs_hb47.jpg
You'll see the new interpolation filters rolling out across B2x0 and X3x0 in
the next few weeks. Until then if the relatively poor performance of the 7tap
filter is affecting peoples applications badly, I recommend using
configurations that daisy chain the 7 tap filter with the 31 tap filter
(interpolation 4 or factorable by 4) or to interpolate by 1 (master_clock_rate
= Fs) and allow the B2x0 Radio to do all the interpolation with it's digital
filters.
-Ian
On Apr 17, 2014, at 5:30 AM, Sabathy Mischa
<[email protected]<mailto:[email protected]>> wrote:
Hello Ian,
Ok I?m glad you could reproduce it. If you need further support please let me
know, but I have to mention that I never looked at the FPGA code.
Best Regards,
Mischa
From: Ian Buckley [mailto:[email protected]<http://ionconcepts.com>]
Sent: Donnerstag, 17. April 2014 01:02
To: Sabathy Mischa
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Sabathy,
I've reproduced your issue #1. I see the alias very clearly. We need to work
out what the regression is now.
-Ian
On Apr 16, 2014, at 2:01 AM, Sabathy Mischa
<[email protected]<mailto:[email protected]>> wrote:
Thanks for your answer Ian,
Honestly it doesn?t look like that there is a 7 tap filter active in my
configuration. The aliasing is not attenuated it is fully visible. The
attenuation starts just at the end of the 30.72e6/2.
At the moment it is simply not possible to use two channels on two different
center frequencies using the tune_request possibility, since aliasing destroys
everything :P
Has somebody an idea about my second question?
Thanks
From: Ian Buckley [mailto:[email protected]<http://ionconcepts.com>]
Sent: Dienstag, 15. April 2014 22:00
To: Sabathy Mischa
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
In answer to your first question, that is expected behavior, you would also see
it if you used N210 @ 50Msps (8bit) mode. This is because there are two half
band interpolating filters in both designs, one is 31tap, the other 7 tap. The
7 tap design can run at 1 output sample per clock, the 31 tap at 1 output
sample for every two clocks. Thus in this configuration the only filter that
can be used is the 7 tap, which as you might expect being so short is less
effective at suppressing aliasing than the 31 tap. In N210 @ 25Msps you have
both of these filters cascaded with good performance.
The next B2x0 UHD release will contain a new interpolation filter design that
will greatly improve this performance. In the mean time you could reduce
master_clock_rate to 15.36MHz so that all FPGA filters are bypassed which
should improve your measured system performance.
-Ian
On Apr 15, 2014, at 7:38 AM, Sabathy Mischa
<[email protected]<mailto:[email protected]>> wrote:
Dear All,
I have two questions regarding the B210 performance.
1. If I use the Clock Rate 30.72e6 Hz and Sampling Rate 15.36e6 (set in GRC) i
have aliasing effects. I think there was already a discussion about it. Will
this be fixed soon? I pulled today the latest UHD from git and I still have
this issue. I need to use this when I want to have two seperate channel on two
different centre frequencies using the tune_request possibility. I also have
aliasing issue when I only use one channel with a clock rate of 30.72e6 Hz and
the sampling rate of 15.36e6 Hz. It seems that the lowpass filter is not
enabled.
2. I made some tests correlating with a reference signal in the time domain.
The B210 was set to 15.36e6 Hz clock and sampling rate. The B210 was
configured to the centre frequency of ~1.85e9 Hz. I used a rubidium freq
standard which is locked to a GPS 1pps as external reference (10 MHz and 1
PPS). If I observing my interpolated correlation peak, I see a significant
higher drift in the time domain as I am used to see when I use N210 with a WBX
board installed (locked to the same rubidium) measuring in parallel the same
signal. Of course the N210 was configured to 25e6 Hz sampling rate but I used
the rational resampler in gnuradio to resample to 15.36e6 Hz.
It seems that the sampling rate is not as precise (not 15.36e6 Hz) as in the
N210+WBX, does anybody made a similar observations or has an idea what causes
this error? I don't really get why this can happen on the B210 since there is a
PLL as well :P
I appreciate your comments and your help.
Best Regards
Mischa
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
________________________________
_______________________________________________
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/20140428/e592c9f4/attachment-0001.html>
------------------------------
Message: 7
Date: Sat, 26 Apr 2014 07:50:04 +0500
From: ali hanif via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP B210
Message-ID:
<CAEjvF3SR4oJK1az5Y3yCziCyckjxY8yFEn=3Lq+DxcNcaw9=n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,I am using USRP B210...I am new to this field and I wanted to ask
certain basic questions:
1) I have read that B210 has 56MHz of instantaneous bandwidth..does this
mean that if i am transmitting or receiving a signal at 2.4GHz then this
signal will have a bandwidth of 56 MHz? OR The Intermediate frequency after
down conversion or before up conversion(in which low pass filters and
ADC/DAC in the USRP are operating) is 56 MHz?(as GNU Radio companion
operates in baseband frequencies)
2) Is it possible to simultaneously transmit at a different frequency and
receive at another frequency from USRP?
3)What is the output power of B210??
Thnx in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140426/88b4b198/attachment-0001.html>
------------------------------
Message: 8
Date: Sat, 26 Apr 2014 22:56:57 -0700
From: Habibur Rahman via USRP-users <[email protected]>
To: [email protected]
Subject: [USRP-users] (no subject)
Message-ID:
<cajz8lhj2so-trh4oyoy0kkzavj6hoowlnsgnpfiszmnegbb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I want to buy a usrp B200. is here anyone, who is interested to sell this
unite? Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140426/911af8bf/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 28 Apr 2014 14:21:12 +0200
From: Matt Ettus via USRP-users <[email protected]>
To: Sabathy Mischa <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 Aliasing and Sampling Rate Precision
Message-ID:
<CAN=1kn-3=S6pSQ8Snr_t-b6C+aysEXEfa3+ve905=kj-1kl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Apr 28, 2014 at 1:56 PM, Sabathy Mischa via USRP-users <
[email protected]> wrote:
> Dear all,
>
>
>
> I investigated again on my sampling rate precision issue.
>
>
>
> First I measured ?xo_out? coming from the external PLL at R113. I always
> measured 40e6 Hz regardless of which ?clock rate? and ?sampling rate? I
> configured in GNU Radio.
>
> I checked then the BBPLL in the ?AD9361_Reference_Manual_UG-570.pdf? on
> page 20.
>
> There I saw that for my case, F_VCO must be configured to 984.04e6 Hz
> (15.36e6 Hz sampling rate, LTE 15) on page 19.
>
> This is done with the Fractional and Integer Word of Figure 7 on page 20.
>
> If I calculate the F_VCO with the Frac and Int word modulus 2088960 and a
> F_ref of 40e6 Hz it gives me the following results as the matlab code shows:
>
>
>
> --Matlab Start
>
> clear all;
>
> clc;
>
>
>
> f_vco = 983.04e6;
>
> f_ref = 40e6; % 30.72e6;
>
> f_sample = 15.36e6;
>
> modulus = 2088960;
>
>
>
> div = f_vco/f_ref;
>
> div_int = floor(div);
>
> div_frac = mod(div,1);
>
>
>
> frac_new1 = div_int + floor(div_frac*modulus)/modulus;
>
> frac_new2 = div_int + ceil(div_frac*modulus)/modulus;
>
> frac_new3 = div_int + round(div_frac*modulus)/modulus;
>
>
>
> f_err1 = frac_new1/div*f_sample-f_sample;
>
> f_err2 = frac_new2/div*f_sample-f_sample;
>
> f_err3 = frac_new3/div*f_sample-f_sample;
>
>
>
> fprintf('f_error (floor) = %f Hz\n', f_err1); fprintf('f_error (ceil) = %f
> Hz\n', f_err2); fprintf('f_error (round) = %f Hz\n', f_err3);
>
>
>
> --Matlab end
>
>
>
> Console OUTPUT:
>
> f_error (floor) = -0.287224 Hz
>
> f_error (ceil) = 0.011968 Hz
>
> f_error (round) = 0.011968 Hz
>
>
>
> Now it seems to be clear where my .012 Hz sampling rate error come from.
> Exact LTE sampling rates with a 40e6 Hz clock reference source will never
> get reach precisely, due to the limitation of the fractional modulus in the
> internal BBPLL of the AD9361.
>
> To solve this, I suggest that the external PLL should be set to 30.72e6 Hz
> or 61.44e6 Hz, in case of a LTE sampling rate request.
>
> This should be possible with the N and R counter of the external ADF4001
> PLL.
>
>
>
> Ben do you agree? Will this be fixed soon?
>
> Thanks for your response.
>
> Mischa
>
Mischa,
The ADF4001 PLL cannot be set for 30.72 MHz because it is controlling a 40
MHz VCXO. This is nothing to fix. This works just fine -- there are
actually 2 completely separate LTE implementations which work with B200 and
B210.
As Marcus said, this is a frequency difference of 0.7 parts per billion,
which is far more accurate than the actual oscillators themselves. To give
you an idea of how small this error is, if you were to walk at 1 meter per
second (a very slow walking pace of about 2.25 Miles per hour), you would
have a doppler shift of 3.33 parts per billion, or more than 4 times as
much. LTE works at much higher velocities than that, even from in a car on
the highway, so this is not a problem in the real world. You should just
write your code to accept that the actual frequency is the 15.36 MHz you
requested.
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140428/4455b253/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 28 Apr 2014 15:35:20 +0200
From: Matt Ettus via USRP-users <[email protected]>
To: ali hanif <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP B210
Message-ID:
<CAN=1kn-pqknaofzkktu38ym2opa6gbebxobivkqyepxo_ic...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sat, Apr 26, 2014 at 4:50 AM, ali hanif via USRP-users <
[email protected]> wrote:
> Hi,I am using USRP B210...I am new to this field and I wanted to ask
> certain basic questions:
> 1) I have read that B210 has 56MHz of instantaneous bandwidth..does this
> mean that if i am transmitting or receiving a signal at 2.4GHz then this
> signal will have a bandwidth of 56 MHz? OR The Intermediate frequency after
> down conversion or before up conversion(in which low pass filters and
> ADC/DAC in the USRP are operating) is 56 MHz?(as GNU Radio companion
> operates in baseband frequencies)
>
It means that your signals can be 56 MHz wide. You could receive from
2.400 to 2.456 MHz at once, for example. There is no IF per se, since this
is direct conversion, but you can think of it like a 56 MHz wide IF.
> 2) Is it possible to simultaneously transmit at a different frequency and
> receive at another frequency from USRP?
>
Yes.
> 3)What is the output power of B210??
>
About 50 mW, but this varies with frequency.
> Thnx in advance
>
> _______________________________________________
> 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/20140428/7c6d1421/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 28 Apr 2014 10:39:20 -0400
From: "Lapointe, Benjamin - 1008 - MITLL via USRP-users"
<[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] X300 PCIe issues
Message-ID:
<mailman.76.1398700815.27404.usrp-users_lists.ettus....@lists.ettus.com>
Content-Type: text/plain; charset="utf-8"
Does the 10 Gigabit Ethernet PCI-express adapter card sold by Ettus work with
Ubuntu 14.04 LTS? From the previous discussion, it sounds like the PCIe
interface does not work with the new kernel, but that 10GigE might work.
-Ben
From: [email protected]
[mailto:[email protected]] On Behalf Of
Robert McGwier
Sent: Monday, April 28, 2014 7:26 AM
To: Marcus D. Leech
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] X300 PCIe issues
It needed to be said, but my only goal is to
ACCEPT AND LOVE 10GigE until and unless you demand the low latency afforded by
the PCIe interface. The things I am working on demand that we meet the tight
timing requirements of open specification waveforms. PCIe was required. The
x3x0 series are major accomplishments for Ettus and should they just get past
the major changes that 14.04 LTS and then BE EXPLICIT about which kernels they
will support, etc. They should be good until the next LTS comes out.
Bob
On Sun, Apr 27, 2014 at 5:48 PM, Marcus D. Leech <[email protected]> wrote:
On 04/27/2014 05:32 PM, Sylvain Munaut wrote:
While the "top side" API is
very stable so that applications hardly *ever* experience API changes
that require on-going tedious maintenance, the same cannot be said of code
that runs in the kernel. Quite the contrary. Linus and friends
*routinely and regularly* change critical APIs within the kernel,
sometimes even across minor version revs of the same codebase.
Come on, it's not _that_ bad ...
Kernel API are stable inside the maintenance release, so they can only
change like every 2 month at most.
And when they change, finding the relevant commit is pretty easy with
git and it will show exactly what need to be changed in your driver
(because that commit fixed every other driver in-tree for the same
change). And searching LKML will also give all the gory details. It's
like half a day or one day of work at the most.
So 1 day of code maintenance every 2 month to keep your codebase
current is not what I'd call a nightmare.
And if you want to avoid even that, just get your module merged
upstream, it will be adapted for you free of charge when APIs change.
And wrt to maintaining the same code building for several kernel,
that's just the wrong approach. Just maintain different version in
different branches. When the code is well written, the driver specific
part will be decoupled enough from the kernel api part that there will
hardly be any conflicts. And when your driver "core function" doesn't
change (and for the NI driver, it seems it hasn't changed it's
functionality for a while AFAICT, just added new kernel support, but I
could be wrong on that), then it's even easier to just release a new
code for each new kernel.
For only a few revisions appart, you might be ok with #ifdef, but if
you're trying to go back to ancient times, like the NI module which
seems to support 2.6.0 (that's 11 years ago !!!!), yeah there is
going to be some serious changes ...
Cheers,
Sylvain
PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver
for a FPGA board, so I did experience that.
So, would we accept an applications-layer API that changed roughly every two
months? I would argue, no, we wouldn't. But
people developing in kernel land seem to accept it as some kind of necessary
gospel. I reject that notion.
Just because kernel-land is where "all the kewl kids play" is not a good
reason to break things on a regular basis.
Anyway, this thread is now going fairly far afield....
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLC
Professor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140428/357fe51b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5414 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140428/357fe51b/attachment.p7s>
------------------------------
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 44, Issue 28
******************************************
