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. Re: Tuning latency of DBSRX2 for frequency hopping (Josh Blum)
2. RF daughterboard (SBX) maximum input power (Ian Cullinan)
3. Re: RF daughterboard (SBX) maximum input power (Marcus D. Leech)
4. Re: RF daughterboard (SBX) maximum input power (Ian Cullinan)
5. Re: RF daughterboard (SBX) maximum input power (John Malsbury)
6. Problems building E110 FPGA images (John Buetefuer)
7. SSSSSSSSSSS Errors with E110 and current UHD/GNURadio
(John Buetefuer)
8. Re: SSSSSSSSSSS Errors with E110 and current UHD/GNURadio
(Philip Balister)
9. about the running error in e110 (????)
10. Re: about the running error in e110 (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Mon, 09 Jul 2012 10:46:50 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Tuning latency of DBSRX2 for frequency
hopping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/09/2012 05:40 AM, Birhane Alemayoh wrote:
> dear All,
> I want implement the frequency hopping in GSM on real time bases using N200
> and DBSRX2 doughterboard. That means I want write an application that
> follows the hopping and capture the signal accordingly from the host PC.
> However, I need to know the tuning latency of the DBSRX2 doughterboard if
> this is possible. The dwell time of GSM signal is 4.615 msec.
>
> I could n't get any document that tells the tuning latency of the DBSRX2
> doughterboard.
> So could you please tell me the tuning latency of DBSRX2?
> Can I achieve my requirement using DBRSRX2 doughterboard plus considering
> the OS scheduling, IP-stack, Ethernet transit, USRP command processing
> issues too.
> Thank you
> Birhane
>
>
Basically you cant retune the LO fast enough. The DBSRX2 is I2C based,
and the I2C control transactions are just too slow. On the other hand,
the SPI based daughterboards like SBX and WBX have 300us tune and lock
time and can be programmed just as fast.
However, you can leave the LO fixed and just shift digitally in the
cordic. This assumes that your frequencies of interest are within the
daughterboard's LF bandwidth. This will enable very fast frequency
hopping for you. Probably about 100us latency due to ethernet.
And even faster, if your bandwidth of interest fits into the maximum
host sample rate. You dont have to tune anything, you can just select a
desired chunk of the available spectrum.
-josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Tue, 10 Jul 2012 11:31:02 +1000
From: Ian Cullinan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RF daughterboard (SBX) maximum input power
Message-ID: <1341883862.1812.35.camel@ianpc>
Content-Type: text/plain; charset="UTF-8"
Hi all,
I am looking for information regarding the maximum input power to USRP
daughterboards, specifically the SBX. I can't find any datasheets, and
all I could find on the mailing list was a comment from Marcus Leech
saying he "wouldn't go any higher than" -20 dBm.
What are the official specs on this? The USRP comes with a lot of
warnings not to overload the inputs, but no definition of "overload".
My application is testing GSM transceivers via a direct connection.
Since these GSM transceivers can output +32 dBm, it looks like I'd need
at least 50 dB of attenuation between the transceivers and the USRP. I
wonder if they wouldn't have more than 50 dB of coupling between them
anyway just sitting next to each other on my desk.
Thanks,
Ian
______________________________________________________________________
This communication contains information which may be confidential or
privileged. The information is intended solely for the use of the individual or
entity named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information is
prohibited. If you have received this communication in error, please notify me
by telephone immediately.
______________________________________________________________________
------------------------------
Message: 3
Date: Mon, 09 Jul 2012 21:40:00 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RF daughterboard (SBX) maximum input power
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 07/09/2012 09:31 PM, Ian Cullinan wrote:
> Hi all,
>
> I am looking for information regarding the maximum input power to USRP
> daughterboards, specifically the SBX. I can't find any datasheets, and
> all I could find on the mailing list was a comment from Marcus Leech
> saying he "wouldn't go any higher than" -20 dBm.
>
> What are the official specs on this? The USRP comes with a lot of
> warnings not to overload the inputs, but no definition of "overload".
>
> My application is testing GSM transceivers via a direct connection.
> Since these GSM transceivers can output +32 dBm, it looks like I'd need
> at least 50 dB of attenuation between the transceivers and the USRP. I
> wonder if they wouldn't have more than 50 dB of coupling between them
> anyway just sitting next to each other on my desk.
>
> Thanks,
>
> Ian
>
>
> _
The first two gain stages on the SBX have a maximum rated input power of
+13dBm. The first gain stage has +13.5dBm power gain,
so that means that at maximum gain (there's an attenuator between the
first and 2nd gain stages), 0dBm is right on the damage
threshold.
Which is better than the -20dBm I quoted earlier, but that was based on
other daughtercards with more sensitive input circuits.
In general receivers are less tolerant of high input powers than normal
lab equipment. A standard spectrum analyser, for example, is
"deaf as a post" compared to your average from-the-air receiver
circuit, and the receiver circuits on the Ettus daughtercards are
"tuned" for use with "from the air" signals, which means that they're
less tolerant of higher input powers than usual lab measurement
equipment. -20dBm is still a fairly thundering-loud signal for your
average receiver, so you can't do any harm by thinking of -20dB
as the maximum input level you should use.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 4
Date: Tue, 10 Jul 2012 13:41:26 +1000
From: Ian Cullinan <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] RF daughterboard (SBX) maximum input power
Message-ID: <1341891686.1812.151.camel@ianpc>
Content-Type: text/plain; charset="UTF-8"
On Tue, 2012-07-10 at 11:40 +1000, Marcus D. Leech wrote:
> The first two gain stages on the SBX have a maximum rated input power of
> +13dBm. The first gain stage has +13.5dBm power gain,
> so that means that at maximum gain (there's an attenuator between the
> first and 2nd gain stages), 0dBm is right on the damage
> threshold.
>
> Which is better than the -20dBm I quoted earlier, but that was based on
> other daughtercards with more sensitive input circuits.
Since any "gain" setting of less than 18 dB should have enough
attenuation to at lest cancel out the gain of the first gain stage,
inputs up to +13dBm shouldn't break anything unless you turn the gain
up, right?
Could there be a chance of the gain "defaulting" to less than the
maximum attenuation if a gain is not set via UHD, thus inadvertently
damaging the second with a signal of less than +13dBm at the input?
It looks like 0dBm should be within the normal operating range of the
LNAs, so as long as I keep the gain down I should be right. Or is there
an advantage to using more external attenuation and turning the gain up?
Cheers,
Ian
______________________________________________________________________
This communication contains information which may be confidential or
privileged. The information is intended solely for the use of the individual or
entity named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information is
prohibited. If you have received this communication in error, please notify me
by telephone immediately.
______________________________________________________________________
------------------------------
Message: 5
Date: Mon, 09 Jul 2012 20:51:03 -0700
From: John Malsbury <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RF daughterboard (SBX) maximum input power
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Ian,
The first stage in a SBX is the LNA, and in the few SBX failures we've
seen, this is typically the first LNA to fail. So, we specify < -10 dBm
for the SBX. Although, Marcus' suggestion for -20 dBm would give you
additional margin.
The gain setting controls the variable attenuator, which can be used to
prevent clipping at the high input levels. So, regardless of the
maximum safe input level, you still want to operate in the linear range
of the signal chain. Being below -20 dBm and using a low to medium gain
setting should be best for your application. In short, you should use
an external attenuator.
-John
On 7/9/2012 8:41 PM, Ian Cullinan wrote:
> On Tue, 2012-07-10 at 11:40 +1000, Marcus D. Leech wrote:
>> The first two gain stages on the SBX have a maximum rated input power of
>> +13dBm. The first gain stage has +13.5dBm power gain,
>> so that means that at maximum gain (there's an attenuator between the
>> first and 2nd gain stages), 0dBm is right on the damage
>> threshold.
>>
>> Which is better than the -20dBm I quoted earlier, but that was based on
>> other daughtercards with more sensitive input circuits.
> Since any "gain" setting of less than 18 dB should have enough
> attenuation to at lest cancel out the gain of the first gain stage,
> inputs up to +13dBm shouldn't break anything unless you turn the gain
> up, right?
>
> Could there be a chance of the gain "defaulting" to less than the
> maximum attenuation if a gain is not set via UHD, thus inadvertently
> damaging the second with a signal of less than +13dBm at the input?
>
> It looks like 0dBm should be within the normal operating range of the
> LNAs, so as long as I keep the gain down I should be right. Or is there
> an advantage to using more external attenuation and turning the gain up?
>
> Cheers,
> Ian
>
>
> ______________________________________________________________________
> This communication contains information which may be confidential or
> privileged. The information is intended solely for the use of the individual
> or entity named above. If you are not the intended recipient, be aware that
> any disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you have received this communication in error,
> please notify me by telephone immediately.
> ______________________________________________________________________
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Tue, 10 Jul 2012 15:36:03 +0930
From: John Buetefuer <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Problems building E110 FPGA images
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Has anyone been successful in building and programming the E110 fpga
using the current UHD firmware?
We have both a E100 and E110 units. I've tried building the current UHD
fpga (version 10.1) for both E100 and E110. On the E100 the resulting
image programs succesfully and the system works.
On the E110, I continually get "OSError: INIT_B went high, error
occurred." whenever running a uhd_usrp_probe.
The pre-built images (v10.0) work fine on this unit. The only obvious
difference that I can see between the pre-built .bin files and the files
that "make E110" is generating is that the pre-built are compressed,
whereas the ones I'm building are not.
I'm using ISE 13.4 to build the images.
Any help would be greatfully appreciated.
Cheers
John
------------------------------
Message: 7
Date: Tue, 10 Jul 2012 16:01:41 +0930
From: John Buetefuer <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] SSSSSSSSSSS Errors with E110 and current
UHD/GNURadio
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'm currently trying to get a test transmitter up, and am having
reliability problems with the current UHD and GNURadio release, running
on an E110 board.
I'm regularly, but inconsistently seeing the transmitter stop and then I
get a screen full of "SSSSSS" characters output (presumably by the UHD
driver). So far, it seems that I can't keep the transmitter running for
more than a minute or two before this problem occurs.
The simplest configuration I've got which shows the problem is
constructing a GNURadio "constant source" connected to the "UHD Sink" -
Sample Rate of 125kHz (the lowest there is). By running this, it will
"blow up" anywhere between a few seconds and a few minutes.
Has anyone else seen this problem? I presume this is some failure of the
UHD driver->FPGA interface?
Any help on this would be greatly appreciated. - Version information
follows:
Cheers
John
# gnuradio-config-info -v
3.6.2git-0-ga4632157
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
UHD_003.004.002-171-g7c8fef85
-- Opening device node /dev/usrp_e0...
-- Initializing FPGA clock to 64.000000MHz...
-- USRP-E100 clock control: 10
-- r_counter: 2
-- a_counter: 0
-- b_counter: 20
-- prescaler: 8
-- vco_divider: 5
-- chan_divider: 5
-- vco_rate: 1600.000000MHz
-- chan_rate: 320.000000MHz
-- out_rate: 64.000000MHz
--
-- Performing wishbone readback test... pass
-- Performing wishbone readback test... pass
_____________________________________________________
/
| Device: E-Series Device
| _____________________________________________________
| /
| | Mboard: E110
| | vendor: 3
| | device: 1
| | revision: 4
| | content: 0
| | model: E110
| | serial: E3R10Z8E2
| | FPGA Version: 10.0
------------------------------
Message: 8
Date: Tue, 10 Jul 2012 09:55:02 -0400
From: Philip Balister <[email protected]>
To: John Buetefuer <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] SSSSSSSSSSS Errors with E110 and current
UHD/GNURadio
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 07/10/2012 02:31 AM, John Buetefuer wrote:
> I'm currently trying to get a test transmitter up, and am having
> reliability problems with the current UHD and GNURadio release, running
> on an E110 board.
>
> I'm regularly, but inconsistently seeing the transmitter stop and then I
> get a screen full of "SSSSSS" characters output (presumably by the UHD
> driver). So far, it seems that I can't keep the transmitter running for
> more than a minute or two before this problem occurs.
>
Can you do this:
# wget
http://files.ettus.com/binaries/oe-classic-feeds/ipk/all/uhd-firmware_003.004.000-r0.0.9_all.ipk
# opkg install --force-downgrade uhd-firmware_003.004.000-r0.0.9_all.ipk
and let me know if this clears the problem up. The top minds at Ettus
are looking at this issue.
Philip
> The simplest configuration I've got which shows the problem is
> constructing a GNURadio "constant source" connected to the "UHD Sink" -
> Sample Rate of 125kHz (the lowest there is). By running this, it will
> "blow up" anywhere between a few seconds and a few minutes.
>
> Has anyone else seen this problem? I presume this is some failure of the
> UHD driver->FPGA interface?
>
> Any help on this would be greatly appreciated. - Version information
> follows:
>
> Cheers
>
> John
>
> # gnuradio-config-info -v
> 3.6.2git-0-ga4632157
>
> linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
> UHD_003.004.002-171-g7c8fef85
>
> -- Opening device node /dev/usrp_e0...
> -- Initializing FPGA clock to 64.000000MHz...
> -- USRP-E100 clock control: 10
> -- r_counter: 2
> -- a_counter: 0
> -- b_counter: 20
> -- prescaler: 8
> -- vco_divider: 5
> -- chan_divider: 5
> -- vco_rate: 1600.000000MHz
> -- chan_rate: 320.000000MHz
> -- out_rate: 64.000000MHz
> --
> -- Performing wishbone readback test... pass
>
> -- Performing wishbone readback test... pass
> _____________________________________________________
> /
> | Device: E-Series Device
> | _____________________________________________________
> | /
> | | Mboard: E110
> | | vendor: 3
> | | device: 1
> | | revision: 4
> | | content: 0
> | | model: E110
> | | serial: E3R10Z8E2
> | | FPGA Version: 10.0
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 9
Date: Tue, 10 Jul 2012 23:24:24 +0800 (CST)
From: ???? <[email protected]>
To: [email protected]
Subject: [USRP-users] about the running error in e110
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Dear all:
When I run benchmark_rx.py, I met an running error as follow:
linux; GNU C++ version 4.5.3 20110311 (prerelease); Boost_104500;
UHD_003.004.000-7dc76db
>>> gr_fir_ccf: using armv7_a
-- Opening a USRP2/N-Series device...
Traceback (most recent call last):
? File "./benchmark_rx.py", line 139, in <module>
??? main()
? File "./benchmark_rx.py", line 128, in main
??? tb = my_top_block(demods[options.modulation], rx_callback, options)
? File "./benchmark_rx.py", line 55, in __init__
??? options.verbose)
? File
"/home/root/src/gnuradio.git/gr-digital/examples/narrowband/uhd_interface.py",
line 189, in __init__
??? freq, gain, spec, antenna)
? File
"/home/root/src/gnuradio.git/gr-digital/examples/narrowband/uhd_interface.py",
line 51, in __init__
??? self.u = uhd.usrp_source(device_addr=args,
stream_args=uhd.stream_args('fc32'))
? File "/usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py", line 112,
in constructor_interceptor
??? return old_constructor(*args)
? File "/usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line 2286,
in usrp_source
??? return _uhd_swig.usrp_source(*args)
RuntimeError: RuntimeError: no control response
However, I used to run benchmark_rx.py without error for several times. I do
not know if there is something crashed. By the way, i think that should be --
Opening device node /dev/usrp_e0... other than -- Opening a USRP2/N-Series
device....
I would be appreciated that some one can tell me some ideas.
Best regards
Zan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120710/a262ac8b/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 10 Jul 2012 08:53:04 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] about the running error in e110
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/10/2012 08:24 AM, ???? wrote:
> Dear all: When I run benchmark_rx.py, I met an running error as
> follow: linux; GNU C++ version 4.5.3 20110311 (prerelease);
> Boost_104500; UHD_003.004.000-7dc76db
>
>>>> gr_fir_ccf: using armv7_a
> -- Opening a USRP2/N-Series device... Traceback (most recent call
> last): File "./benchmark_rx.py", line 139, in <module> main() File
> "./benchmark_rx.py", line 128, in main tb =
> my_top_block(demods[options.modulation], rx_callback, options) File
> "./benchmark_rx.py", line 55, in __init__ options.verbose) File
> "/home/root/src/gnuradio.git/gr-digital/examples/narrowband/uhd_interface.py",
> line 189, in __init__ freq, gain, spec, antenna) File
> "/home/root/src/gnuradio.git/gr-digital/examples/narrowband/uhd_interface.py",
> line 51, in __init__ self.u = uhd.usrp_source(device_addr=args,
> stream_args=uhd.stream_args('fc32')) File
> "/usr/lib/python2.6/site-packages/gnuradio/uhd/__init__.py", line
> 112, in constructor_interceptor return old_constructor(*args) File
> "/usr/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", line
> 2286, in usrp_source return _uhd_swig.usrp_source(*args)
> RuntimeError: RuntimeError: no control response
>
>
>
> However, I used to run benchmark_rx.py without error for several
> times. I do not know if there is something crashed. By the way, i
> think that should be -- Opening device node /dev/usrp_e0... other
> than -- Opening a USRP2/N-Series device....
>
-- Opening a USRP2/N-Series device... I see
Is there a USRP on the same network, same subnet? Because the UHD on the
E100 can talk to and find the N210. You may want to pass some extra args
into E100 to limit the search to just the E100. For example
--args="type=e100"
See this for basic identification rules
http://files.ettus.com/uhd_docs/manual/html/identification.html
-josh
> I would be appreciated that some one can tell me some ideas.
>
> Best regards
>
> Zan
>
>
>
>
>
>
> _______________________________________________ USRP-users mailing
> list [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
End of USRP-users Digest, Vol 23, Issue 9
*****************************************
