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: Regarding time aligned samples of a MIMO configuration
(Marcus D. Leech)
2. B200mini/B205mini FPGA Acceleration (Austin Anderson)
3. Re: Regarding time aligned samples of a MIMO configuration
(Martin Braun)
4. Re: E310 AD9361 FIR filter Taps (Ian Buckley)
5. N200 RX center frequency changes ignored (Francisco Albani)
6. Re: N200 RX center frequency changes ignored (Marcus D. Leech)
7. Re: N200 RX center frequency changes ignored (Francisco Albani)
8. Re: N200 RX center frequency changes ignored (Marcus D. Leech)
9. Re: unexpected spikes at multiples of 10Mhz in spectrum (Mei Leng)
10. Re: unexpected spikes at multiples of 10Mhz in spectrum
(Marcus D. Leech)
11. RX input overdrive protection? ([email protected])
12. Re: RX input overdrive protection? (Marcus M?ller)
13. Re: B200mini/B205mini FPGA Acceleration (Marcus M?ller)
14. Re: Best way to change RFNoC block on the fly? (Jason Matusiak)
15. Re: Best way to change RFNoC block on the fly? (Sylvain Munaut)
16. Re: Best way to change RFNoC block on the fly? (Jason Matusiak)
17. uhd unix drivers (Samy CHBINOU)
18. RFNoC Installation Problems (Yin, Charles - 0665 - MITLL)
19. Re: uhd unix drivers (Marcus M?ller)
20. Re: uhd unix drivers ([email protected])
21. Re: uhd unix drivers (Samy CHBINOU)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Jun 2016 15:08:36 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Regarding time aligned samples of a MIMO
configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 06/21/2016 11:29 AM, avinash kalyanaraman via USRP-users wrote:
> Hello All,
>
> Is there a way I can read the time-aligned samples from 2 USRP N210s
> connected via a MIMO cable ?
>
> In other words, I want to be able to run the equivalent of
> uhd_rx_cfile but store the time aligned complex samples of both USRPs?
>
> Will simply connecting the two USRP Sources to FileSinks in GRC (as
> attached) do this for me - for e.g. then, will the Nth sample in
> file1 and Nth sample in file2 be time-aligned samples of the two USRPs?
>
> Thanks!
>
> --
> Avinash
>
>
You'll need to have *BOTH* USRPs in a single, multi-channel block, with
one of them set to use MIMO for reference clock and time synch, and
the other "internal".
Each device should have its own IP address on the same subnet, which
will cause it to use MIMO for the sample-data as well, in
"shared ethernet" mode.
http://files.ettus.com/manual/page_usrp2.html#usrp2_mimocable_shared
http://files.ettus.com/manual/page_usrp2.html#usrp2_
------------------------------
Message: 2
Date: Tue, 21 Jun 2016 13:22:44 -0600
From: Austin Anderson <[email protected]>
To: [email protected]
Subject: [USRP-users] B200mini/B205mini FPGA Acceleration
Message-ID:
<CAF30z8c2ecKO6Y75gjVV-VC+aHhuzig6-EWwdQd=xhw8go+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm interested in trying to get FPGA acceleration in place using the FPGAs
on the B200mini or B205mini. I've got the firmware built for the B200mini
and I'm working to determine path of least resistance:
1. I plan on just replacing the DDCs/DUCs (as this is a suggestion in the
USRP2 firmware notes). This seems like a straightforward path and is
compatible with existing DSP firmware I've developed for Zedboard+AD9361.
With respect to the framing of output data, is there documentation on how
the RX framer/RX control handle packet generation? For example, if I want
to receive a sample window, take a fixed point FFT, and send a complete
frame of FFT samples back to the host, what's the best way to do that? Is
that handled by the host side (ie just request the FFT bin size)?
2. While implementing the DSP looks straightforward enough, what's the
suggested path to adding user configuration? I see there's a user register
setting generate statement that can be enabled with 256 registers mapped.
Is that easily accessed from UHD? I saw some posts on the usrp list that
suggested the poke32 method would be exposed in a future release of UHD,
but it's not clear if that happened. Is that part of the B200/B205 API now?
3. The settings I'd want to configure would be filter taps and maybe some
register level settings. For the taps, is there a faster alternative to
loading through perhaps the AXI stream configuration bus or is that more of
a pain than it's worth?
4. The B205 has a bigger FPGA and is listed under the USRP3 firmware
directory, is RFNoC support planned for the B205?
Thanks,
-Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/97f4e779/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 21 Jun 2016 14:35:35 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Regarding time aligned samples of a MIMO
configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
uhd_rx_cfile allows to record from multiple channels (see the -c option).
M
On 06/21/2016 08:29 AM, avinash kalyanaraman via USRP-users wrote:
> Hello All,
>
> Is there a way I can read the time-aligned samples from 2 USRP N210s
> connected via a MIMO cable ?
>
> In other words, I want to be able to run the equivalent of uhd_rx_cfile
> but store the time aligned complex samples of both USRPs?
>
> Will simply connecting the two USRP Sources to FileSinks in GRC (as
> attached) do this for me - for e.g. then, will the Nth sample in file1
> and Nth sample in file2 be time-aligned samples of the two USRPs?
>
> Thanks!
>
> --
> Avinash
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Tue, 21 Jun 2016 15:45:43 -0700
From: Ian Buckley <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 AD9361 FIR filter Taps
Message-ID:
<cam_0ocfixti7eovzkmgwtfrfk91voyzk-qamm+kckdh6y2h...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
The API provides a nice way to query the configuration of the radio, and
reprogram coeffs on the fly. What it doesn't do is provide a way to
override the configuration decisions made in "_setup_rates"...so you are
"stuck" with whatever FIR configuration the requested master_clock_rate
implies. Hence my comment about needing code edits to do custom filter
configurations.
-Ian
On Tue, Jun 21, 2016 at 1:26 AM, Marcus M?ller <[email protected]>
wrote:
> Hi Jeffrey, hi Ian,
>
> the API for that is filter_info; it seems pretty stable by now. I think I
> have some example for its usage lying around, just don't know where exactly
> right now.
> Anyway, from a usage perspective, not that much magic involved; use
> multi_usrp::get_filter_names() to get the filters that exist for your
> USRP, and
> ::get_filter(name) to get the filter_info object that describes that
> filter.
>
> Best regards,
> Marcus
>
>
> On 06/20/2016 08:26 PM, Ian Buckley via USRP-users wrote:
>
> Jeff,
> The way the programmable FIR works in 9361 is that the H/W implements
> 16taps of filter and runs on the data converter clock which is a multiple
> of the sample clock set by the various interpolation/decimation stages.
> Thus the ratio of the converter clock to sample clock dictates how many
> taps can be implemented in the RX and TX FIR's. The Ettus driver decides
> what that ratio is based on the maximum operating frequencies for the ADC
> and DAC, and the the master_clock_rate requested by the user. The driver
> thus provides filter taps for all possible legal configuration scenarios.
> If you have a certain configuration that you are targeting then work out
> what the resulting ratio is and hence which coefficient set is being picked
> (via code debug), then, yes, replace with your own coefficients...it really
> can be that simple. Remember those FIR filters can run as 1/2/4
> interpolator/decimators and the stock Ettus driver is factoring that into
> its distribution of interpolation/decimation amongst the various filters
> present in the radio when it chooses a configuraton. If you want to change
> the mode it wants to run the FIR in then your edits will need to be more
> intrusive since I don't recall any way you can use the API to do that.
> -Ian
>
>
>
> _______________________________________________
> 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/20160621/6279f189/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 21 Jun 2016 20:13:48 -0300
From: Francisco Albani <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] N200 RX center frequency changes ignored
Message-ID:
<CAAGU92mR7pMPoTu_t8Rtwgm0DkTqDb_3yGKDvDz=5cbda+a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi to all!
We have experienced two times in 3 weeks what seems to be a hard-to-spot
bug. I will try to explain:
- We have two N200 units with this RX daughterboard:
| | | RX Dboard: A
| | | ID: WBX v3, WBX v3 + Simple GDB (0x0057)
| | | Serial: 30CA8AA
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: WBXv3 RX+GDB
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 68.750 to 2200.000 MHz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Bandwidth range: 40000000.0 to 40000000.0 step 0.0 Hz
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p44
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | | | Gain range fine: 0.0 to 0.5 step 0.1 dB
- *Each one of them suffered this bug once at different times.*
- They were both powered for many days and used many times a day.
- The solution was a power cycle.
- The set up is a loopback between TX and RX.
- Flowgraph starts, UHD Source Block sets ~1GHz as center frequency but
we don't see expected input.
- src.get_frequency() returns the frequency set by us. This makes us
think that UHD does not ask N200 for its frequency.
- In one of the opportunities, we attached a Waterfall and saw the noise
floor changed for a fraction of a second (after we attempted a RX frequency
change by command) and then returned to previous value.
We fell like somebody is trying to use our equipment in our back through
the network. :P (we are confident this is not the case)
Is this a known bug for Ettus Research or any user of the list?
We don't know how to further debug this. Can you help us?
Many thanks and bye.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/d133891b/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 21 Jun 2016 19:49:07 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N200 RX center frequency changes ignored
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/21/2016 07:13 PM, Francisco Albani via USRP-users wrote:
> Hi to all!
>
> We have experienced two times in 3 weeks what seems to be a
> hard-to-spot bug. I will try to explain:
>
> * We have two N200 units with this RX daughterboard:
>
> | | | RX Dboard: A
> | | | ID: WBX v3, WBX v3 + Simple GDB (0x0057)
> | | | Serial: 30CA8AA
> | | | _____________________________________________________
> | | | /
> | | | | RX Frontend: 0
> | | | | Name: WBXv3 RX+GDB
> | | | | Antennas: TX/RX, RX2, CAL
> | | | | Sensors: lo_locked
> | | | | Freq range: 68.750 to 2200.000 MHz
> | | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
> | | | | Bandwidth range: 40000000.0 to 40000000.0 step 0.0 Hz
> | | | | Connection Type: IQ
> | | | | Uses LO offset: No
> | | | _____________________________________________________
> | | | /
> | | | | RX Codec: A
> | | | | Name: ads62p44
> | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
> | | | | Gain range fine: 0.0 to 0.5 step 0.1 dB
>
> * *Each one of them suffered this bug once at different times.*
>
> * They were both powered for many days and used many times a day.
> * The solution was a power cycle.
> * The set up is a loopback between TX and RX.
> * Flowgraph starts, UHD Source Block sets ~1GHz as center frequency
> but we don't see expected input.
> * src.get_frequency() returns the frequency set by us. This makes us
> think that UHD does not ask N200 for its frequency.
> * In one of the opportunities, we attached a Waterfall and saw the
> noise floor changed for a fraction of a second (after we attempted
> a RX frequency change by command) and then returned to previous value.
>
> We fell like somebody is trying to use our equipment in our back
> through the network. :P (we are confident this is not the case)
>
> Is this a known bug for Ettus Research or any user of the list?
>
> We don't know how to further debug this. Can you help us?
>
> Many thanks and bye.
>
>
Have you tried this on different N210s? Do you have attenuation in the
loopback cable? If so, how much?
What version of UHD are you using? Have you made any custom
modifications to it, or the FPGA image?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/c1cf49c8/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 21 Jun 2016 22:11:12 -0300
From: Francisco Albani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] N200 RX center frequency changes ignored
Message-ID:
<caagu92kmhahts2wmdgwwm3c7raah9js_yvwf6aeh2uqslm+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
2016-06-21 20:49 GMT-03:00 Marcus D. Leech via USRP-users <
[email protected]>:
> Have you tried this on different N210s? Do you have attenuation in the
> loopback cable? If so, how much?
>
*We didn't try in other N200 (we don't have N210). When everything works,
the RX is a -30dB sample signal from the TX+PA output.*
>
>
>
>
What version of UHD are you using? Have you made any custom modifications
> to it, or the FPGA image?
>
*linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.git-204-g984575c9*
*No modifications.*
*Thanks for your time!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/f502661e/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 21 Jun 2016 21:27:26 -0400
From: "Marcus D. Leech" <[email protected]>
To: Francisco Albani <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] N200 RX center frequency changes ignored
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/21/2016 09:11 PM, Francisco Albani wrote:
>
>
> 2016-06-21 20:49 GMT-03:00 Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>>:
>
> Have you tried this on different N210s? Do you have attenuation
> in the loopback cable? If so, how much?
>
>
> *We didn't try in other N200 (we don't have N210). When everything
> works, the RX is a -30dB sample signal from the TX+PA output.*
Sorry, I meant N200. If you have another N200, you could see if it is
reproducible there.
>
>
> What version of UHD are you using? Have you made any custom
> modifications to it, or the FPGA image?
>
>
> *linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.git-204-g984575c9
>
> *
> *No modifications.
>
> *
> *Thanks for your time!*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/0d3ed31f/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 22 Jun 2016 10:15:36 +0800
From: Mei Leng <[email protected]>
To: Andy Walls <[email protected]>, Marcus M?ller
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] unexpected spikes at multiples of 10Mhz in
spectrum
Message-ID:
<cald5grecbnulf5nsuueq_rakadgw+e6n6mn5chg6lqdfhyu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi, Marcus and Andy:
Thank you for the reply.
The spikes are in things we received.
According to Andy's suggestion, we removed the GPSDO and observed that
spikes at multiples of 10MHz go away. It seems they are indeed caused by
GPS signals, but it is a bit odd since we are receiving indoors and do not
even connect the GPS antenna. Any suggestions how to deal with such spikes?
Thank you.
Also, we noticed that there is a very high spike at the receiving center
frequency, similar to that at DC. Is this normal?
Regards,
Mei
On Mon, Jun 20, 2016 at 10:13 PM, Andy Walls via USRP-users <
[email protected]> wrote:
> On Mon, 2016-06-20 at 09:44 -0400, [email protected]
> wrote:
> > Message: 5
> > Date: Mon, 20 Jun 2016 14:08:33 +0800
>
> > Hi, list:
> >
> > We recently purchased one new NI-USRP 2953R, and in our tests, we
> > found
> > some strange spikes in the signal spectrum at all frequencies multiple
> > of
> > 10 MHz (as shown in the attached pic), it looks like some kind of
> > harmonics, but we cannot figure out where it came from. Does anyone
> > have
> > similar observations?
>
> It's probably 10.23 MHz:
> https://en.wikipedia.org/wiki/GPS_signals#Frequency_information
>
> *If* you have no qualms about and fully understand the risks of touching
> operating electronics equipment:
>
> Put on an ESD wrist strap, touch the metal case of the GPSDO with your
> finger, and watch the level of the harmonics change.
>
> At least that's my observation with a B210 exhibiting similar symptoms.
>
> -Andy
>
> > The specific settings are: NI-USRP 2953R + CBX daughter board, the
> > receiving center frequency is 1.6 GHz (we actually tried different
> > frequencies from 1.2 GHz to 3 GHz, and they all have similar spikes).
> >
> >
> > Regards,
> >
> > Mei
>
>
>
> _______________________________________________
> 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/20160622/4ca6deaf/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 21 Jun 2016 22:30:12 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] unexpected spikes at multiples of 10Mhz in
spectrum
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/21/2016 10:15 PM, Mei Leng via USRP-users wrote:
> Hi, Marcus and Andy:
>
> Thank you for the reply.
>
> The spikes are in things we received.
>
> According to Andy's suggestion, we removed the GPSDO and observed that
> spikes at multiples of 10MHz go away. It seems they are indeed caused
> by GPS signals, but it is a bit odd since we are receiving indoors and
> do not even connect the GPS antenna. Any suggestions how to deal with
> such spikes? Thank you.
>
> Also, we noticed that there is a very high spike at the receiving
> center frequency, similar to that at DC. Is this normal?
>
> Regards,
>
> Mei
The GPSDO produces an output at 10MHz, and your receiver is seeing
harmonics of that every 10Mhz or so. How far above the noise floor
are the 10MHz harmonics?
If you have the antenna right up at the USRP, you'll see them more
strongly than if you have an antenna (plus perhaps a pre-amp) at some
distance from the USRP.
Make certain that you run the uhd_cal_rx_iq_balance tool for both of
your cards, which will improve I/Q balance, and perhaps help to remove
some artifacts.
Also, uhd_cal_tx_dc_offset and uhd_cal_tx_iq_balance for the TX part.
>
> On Mon, Jun 20, 2016 at 10:13 PM, Andy Walls via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> On Mon, 2016-06-20 at 09:44 -0400,
> [email protected]
> <mailto:[email protected]>
> wrote:
> > Message: 5
> > Date: Mon, 20 Jun 2016 14:08:33 +0800
>
> > Hi, list:
> >
> > We recently purchased one new NI-USRP 2953R, and in our tests, we
> > found
> > some strange spikes in the signal spectrum at all frequencies
> multiple
> > of
> > 10 MHz (as shown in the attached pic), it looks like some kind of
> > harmonics, but we cannot figure out where it came from. Does anyone
> > have
> > similar observations?
>
> It's probably 10.23 MHz:
> https://en.wikipedia.org/wiki/GPS_signals#Frequency_information
>
> *If* you have no qualms about and fully understand the risks of
> touching
> operating electronics equipment:
>
> Put on an ESD wrist strap, touch the metal case of the GPSDO with your
> finger, and watch the level of the harmonics change.
>
> At least that's my observation with a B210 exhibiting similar
> symptoms.
>
> -Andy
>
> > The specific settings are: NI-USRP 2953R + CBX daughter board, the
> > receiving center frequency is 1.6 GHz (we actually tried different
> > frequencies from 1.2 GHz to 3 GHz, and they all have similar
> spikes).
> >
> >
> > Regards,
> >
> > Mei
>
>
>
> _______________________________________________
> 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]
> 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/20160621/9d8e866a/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 22 Jun 2016 08:53:22 +0000
From: <[email protected]>
To: <[email protected]>
Subject: [USRP-users] RX input overdrive protection?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I would like to use a B200mini in a TDD mode, where the transmit output is
connected to an RF power amplifier (about 1 Watt), and the output of the power
amplifier is connected to a single antenna over a circulator. Of course, the
circulator, either as single or dual junction, prevents RX input damages from
the power amplifier.
But, the antenna is seldom perfectly matched, e.g., a fraction of the
transmitted power is always reflected back, e.g., -16 dB. The resulting
unwanted RX input power is hence +30dBm-16dB = +14dBm --> this to too high for
the RF front-end chip (about +2dBm maximum rating).
I was looking for RF power limiters, but they commonly limit around +15dBm and
above. Does anyone have an idea how to solve this? Do you know of any overdrive
protection circuits/devices to limit at around 0dBm or even -10dBm?
Regards,
Emanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/14b8e500/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 22 Jun 2016 12:05:48 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RX input overdrive protection?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Emanuel,
the solution to this is not using the circulator as circulator in TDD :)
So the point here is that the USRP has internal microwave switches that
make it possible to either send or receive from the TX/RX port. That
switching can be done by the USRP itself at a very high temporal
accuracy. It's automatically done when you set both the RX and TX
antenna to the TX/RX port, stop the TX streamer, and start the RX
streamer (and of course, vice versa).
If you take a look at our schematics[1] you'll find that switch on the
first overview page, and in detail on the third page. It's U3, a
SKY13350-385LF[2].
Now, the most elegant solution to the problem you're facing would
probably be using the same switching functionality for an external
switch, and using separate RX and TX ports on the USRP:
Simple external switching method
That's relatively easy to do, because exactly the same mechanisms used
for switching the internal microwave switch is applicable to the GPIO
port ? ie. you can tell UHD that "as soon as I start receiving,
automatically make sure the GPIO pin no <insert pin number here> has
state <high/low>".
Now, the above block diagram has two problems:
* The isolation of that switch must be pretty high to protect the RX2
port from the PA output. However, you can get switches that do high
isolation, so this will probably work out.
* Just like antennas, amplifiers aren't inherently perfect ? make sure
your amplifier's input port leakage isn't too high. If it is ? I've
heard you've got a circulator lying around, so abuse it as an
isolator in line between "TX/RX" and your amplifier :)
Best regards,
Marcus
[1] http://files.ettus.com/schematics/b200mini/b200mini.pdf
[2] http://www.skyworksinc.com/uploads/documents/SKY13350_385LF_201174G.pdf
On 22.06.2016 10:53, Emanuel via USRP-users wrote:
>
> Hi all,
>
>
>
> I would like to use a B200mini in a TDD mode, where the transmit
> output is connected to an RF power amplifier (about 1 Watt), and the
> output of the power amplifier is connected to a single antenna over a
> circulator. Of course, the circulator, either as single or dual
> junction, prevents RX input damages from the power amplifier.
>
>
>
> But, the antenna is seldom perfectly matched, e.g., a fraction of the
> transmitted power is always reflected back, e.g., -16 dB. The
> resulting unwanted RX input power is hence +30dBm-16dB = +14dBm ? this
> to too high for the RF front-end chip (about +2dBm maximum rating).
>
>
>
> I was looking for RF power limiters, but they commonly limit around
> +15dBm and above. Does anyone have an idea how to solve this? Do you
> know of any overdrive protection circuits/devices to limit at around
> 0dBm or even -10dBm?
>
>
>
> Regards,
>
> Emanuel
>
> _ _
>
>
>
>
>
> _______________________________________________
> 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/20160622/cc54c9ec/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TDD_PA_simple.png
Type: image/png
Size: 11979 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/cc54c9ec/attachment-0001.png>
------------------------------
Message: 13
Date: Wed, 22 Jun 2016 12:34:10 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200mini/B205mini FPGA Acceleration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Austin,
On 21.06.2016 21:22, Austin Anderson via USRP-users wrote:
> I'm interested in trying to get FPGA acceleration in place using the
> FPGAs on the B200mini or B205mini. I've got the firmware built for the
> B200mini and I'm working to determine path of least resistance:
>
> 1. I plan on just replacing the DDCs/DUCs (as this is a suggestion in
> the USRP2 firmware notes). This seems like a straightforward path and
> is compatible with existing DSP firmware I've developed for
> Zedboard+AD9361. With respect to the framing of output data, is there
> documentation on how the RX framer/RX control handle packet
> generation? For example, if I want to receive a sample window, take a
> fixed point FFT, and send a complete frame of FFT samples back to the
> host, what's the best way to do that? Is that handled by the host side
> (ie just request the FFT bin size)?
The frame format is described in our Compressed vita header format
description[1]. We call that format CHDR.
Requesting only FFT sizes (or multiples thereof) as CVITA packet sizes
should work, if the FFT is the last step before the streamer.
>
> 2. While implementing the DSP looks straightforward enough, what's the
> suggested path to adding user configuration? I see there's a user
> register setting generate statement that can be enabled with 256
> registers mapped. Is that easily accessed from UHD?
It is; you could modify UHD to actually expose something like a function
call to your UHD-using program, or you can go "raw", get the property
tree (which is the software design "approach" we use to make things
accessible) and peek and poke through that.
> I saw some posts on the usrp list that suggested the poke32 method
> would be exposed in a future release of UHD, but it's not clear if
> that happened. Is that part of the B200/B205 API now?
AFAIK, no. I've got to ask *+Martin* about that, though.
>
> 3. The settings I'd want to configure would be filter taps and maybe
> some register level settings. For the taps, is there a faster
> alternative to loading through perhaps the AXI stream configuration
> bus or is that more of a pain than it's worth?
probably the latter. In fact, UHD loads filter taps for the AD9361
through the peek/poke mechanism, too, if I remember correctly
>
> 4. The B205 has a bigger FPGA and is listed under the USRP3 firmware
> directory, is RFNoC support planned for the B205?
No. I think that's technically impossible, but, again, Martin, as the
UHD release manager, will be much more competent in answering that than
I am.
Best regards,
Marcus
[1] http://files.ettus.com/manual/page_rtp.html#rtp_chdr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/62d5576a/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 22 Jun 2016 08:28:09 -0400
From: Jason Matusiak <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Best way to change RFNoC block on the fly?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>There's no message port for rfnoc blocks yet, but that would be a
simple addition and I'll try and get it in soon.
>>The only reason I used the word "message" was that while trying to
>>figure out what was being passed back-and-forth via the cfg port for
>>RFNoC, I noticed in the display port's XML that the cfg port was
>>labeled as type "message". What is being passed through there then?
>The fosphor display and RFNoC blocks interact via messages; i.e. if you
>change trise from the QT GUI, it'll trigger a message to be sent to the
>other block, which it translates into an API call.
Martin, I think I am being dense on something here. You mention above that the
fosphor RFNoC block interacts via messages (which is what I thought was going
on), but in the message you wrote on MON you said "There's no message port for
rfnoc blocks yet, but that would be a simple
addition and I'll try and get it in soon." What am I missing? I am guessing
that there are two different types of messages at play here and only one is
currently implemented within RFNoC (whatever the one that fosphor is using)?
So if I had a regular GR block that determines that an incoming signal's
frequency needs to be shifted by 10kHz, there is no reason why that block can't
send the message type that fosphor is using to my RFNoC block to update my
frequency offset register, right? Or am I totally missing what fosphor is
doing with its "messages"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/7ff96c8a/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 22 Jun 2016 14:42:13 +0200
From: Sylvain Munaut <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Best way to change RFNoC block on the fly?
Message-ID:
<cahl+j09p5jrffe3qe03h4rjdmwe8o0kih+q5jxw87kvw-qn...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Martin, I think I am being dense on something here. You mention above that
> the fosphor RFNoC block interacts via messages (which is what I thought was
> going on), but in the message you wrote on MON you said "There's no message
> port for rfnoc blocks yet, but that would be a simple
> addition and I'll try and get it in soon." What am I missing? I am
> guessing that there are two different types of messages at play here and
> only one is currently implemented within RFNoC (whatever the one that
> fosphor is using)?
He probably means that this is not a feature provided natively by
rfnoc_block_impl but something that's implemented by the rfnoc_fosphor
block itself.
Even though if you look at the actual implementation (
rfnoc_fosphor_c_impl::handle_cfg_message ), there is nothing fosphor
specific at all ...
It just takes the raw message and calls this->set_arg with the
key/value pairs in the message, so this whole thing could be moved to
the rfnoc_block_impl base class and instantly all rfnoc blocks would
have a message port where you can reconfigure registers via GR
messages.
Cheers,
Sylvain
------------------------------
Message: 16
Date: Wed, 22 Jun 2016 08:49:18 -0400
From: Jason Matusiak <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Best way to change RFNoC block on the fly?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
> He probably means that this is not a feature provided natively by
rfnoc_block_impl but something that's
> implemented by the rfnoc_fosphor block itself. Even though if you
look at the actual implementation (
> rfnoc_fosphor_c_impl::handle_cfg_message ), there is nothing fosphor
specific at all ...
Ah, OK, I knew I was missing something. I haven't written any normal GR
blocks (or RFNoC block using C++), so I'll have to mull this over for a bit.
> It just takes the raw message and calls this->set_arg with the
key/value pairs in the message, so this
> whole thing could be moved to the rfnoc_block_impl base class and
instantly all rfnoc blocks would have
> a message port where you can reconfigure registers via GR messages.
Cheers, Sylvain
Interesting. Maybe I am better off sitting tight for a bit and seeing
if the change peculates up sometime in the near future. Thanks for
helping out Sylvain!
------------------------------
Message: 17
Date: Wed, 22 Jun 2016 17:38:20 +0200
From: Samy CHBINOU <[email protected]>
To: [email protected]
Subject: [USRP-users] uhd unix drivers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Hello,
I tried to compile the usrp unix drivers uhd-release_003_009_004.tar.gz
I did a
cd uhd-release_003_009_004/host
mkdir build
cd build/
cmake ..
time make
time make test
sudo make install
sudo ldconfig
uhd_usrp_probe
I got:
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
uhd_usrp_probe: symbol lookup error: uhd_usrp_probe: undefined symbol:
_ZN3uhd6device4makeERKNS_13device_addr_tENS0_15device_filter_tEj
Did I make something wrong?
Samy
------------------------------
Message: 18
Date: Tue, 21 Jun 2016 20:24:38 +0000
From: "Yin, Charles - 0665 - MITLL" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC Installation Problems
Message-ID:
<13657fc12b4974458e8326454370255105e...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="us-ascii"
Hi Neel and Jonathon,
I am having problems building RFNoC with GNU Radio. I am using GNU Radio
Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for the swig package,
and I can confirm that it is there. The error from the build process is as
follows:
Linking CXX executable test-gr-blocks
[ 67%] Built target test-gr-blocks
Scanning dependencies of target _blocks_swig3
[ 67%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
{standard input}: Assembler messages:
{standard input}:380989: Warning: end of file not at end of a line; newline
inserted
{standard input}:381666: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
{standard input}:381669: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
virtual memory exhausted: Cannot allocate memory
{standard input}: Assembler messages:
{standard input}:1273004: Warning: end of file not at end of a line; newline
inserted
{standard input}:1274439: Error: unknown pseudo-op: `.'
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
Error 1
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
Linking CXX shared module _blocks_swig1.so
[ 67%] Built target _blocks_swig1
make: *** [all] Error 2
I'm not entirely sure what I am missing. Please let me know if you find
anything. Thanks!
Charles Yin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/8125ff0a/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 22 Jun 2016 17:44:09 +0200
From: Marcus M?ller <[email protected]>
To: Samy CHBINOU <[email protected]>, Samy CHBINOU via
USRP-users <[email protected]>,
[email protected]
Subject: Re: [USRP-users] uhd unix drivers
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Uninstall your Linux distribution's UHD version first, then build and install
UHD again. Your pre-installed old version of UHD clashes with the new version.
Make sure you don't accidentally install the old version again!
Best regards,
Marcus
Am 22. Juni 2016 17:38:20 MESZ, schrieb Samy CHBINOU via USRP-users
<[email protected]>:
>Hello,
>
>I tried to compile the usrp unix drivers uhd-release_003_009_004.tar.gz
>I did a
>cd uhd-release_003_009_004/host
>mkdir build
>cd build/
>cmake ..
>time make
>time make test
>sudo make install
>sudo ldconfig
>uhd_usrp_probe
>I got:
>linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>
>uhd_usrp_probe: symbol lookup error: uhd_usrp_probe: undefined symbol:
>_ZN3uhd6device4makeERKNS_13device_addr_tENS0_15device_filter_tEj
>
>Did I make something wrong?
>
>Samy
>
>_______________________________________________
>USRP-users mailing list
>[email protected]
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/569f3631/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 22 Jun 2016 11:47:27 -0400
From: [email protected]
To: Samy CHBINOU <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd unix drivers
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
You almost certainly have an instance of UHD installed from your OS
pre-packaged binaries. Remove that first, then re-do the sudo make
install and sudo ldconfig
On 2016-06-22 11:38, Samy CHBINOU via USRP-users wrote:
> Hello,
>
> I tried to compile the usrp unix drivers uhd-release_003_009_004.tar.gz
> I did a
> cd uhd-release_003_009_004/host
> mkdir build
> cd build/
> cmake ..
> time make
> time make test
> sudo make install
> sudo ldconfig
> uhd_usrp_probe
> I got:
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
>
> uhd_usrp_probe: symbol lookup error: uhd_usrp_probe: undefined symbol:
> _ZN3uhd6device4makeERKNS_13device_addr_tENS0_15device_filter_tEj
>
> Did I make something wrong?
>
> Samy
>
> _______________________________________________
> 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/20160622/93f93519/attachment-0001.html>
------------------------------
Message: 21
Date: Wed, 22 Jun 2016 17:51:07 +0200
From: Samy CHBINOU <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: Samy CHBINOU via USRP-users <[email protected]>
Subject: Re: [USRP-users] uhd unix drivers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
yes, there was 2 installations.
Thank you
---
Best Regards - Cordialement
Le 2016-06-22 17:44, Marcus M?ller a ?crit?:
> Uninstall your Linux distribution's UHD version first, then build and
> install UHD again. Your pre-installed old version of UHD clashes with
> the new version. Make sure you don't accidentally install the old
> version again!
>
> Best regards,
> Marcus
>
> Am 22. Juni 2016 17:38:20 MESZ, schrieb Samy CHBINOU via USRP-users
> <[email protected]>:
>
>> Hello,
>>
>> I tried to compile the usrp unix drivers
>> uhd-release_003_009_004.tar.gz
>> I did a
>> cd uhd-release_003_009_004/host
>> mkdir build
>> cd build/
>> cmake ..
>> time make
>> time make test
>> sudo make install
>> sudo ldconfig
>> uhd_usrp_probe
>> I got:
>> linux; GNU C++ version 4.8.2; Boost_105400;
>> UHD_003.005.005-0-unknown
>>
>> uhd_usrp_probe: symbol lookup error: uhd_usrp_probe: undefined
>> symbol:
>> _ZN3uhd6device4makeERKNS_13device_addr_tENS0_15device_filter_tEj
>>
>> Did I make something wrong?
>>
>> Samy
>>
>> -------------------------
>>
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
------------------------------
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 70, Issue 23
******************************************
