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. how to use set_rx_agc in .py file (Ekko)
2. Re: how to use set_rx_agc in .py file (Marcus M?ller)
3. N210 FPGA Memory (Topliff, Charles Alexander)
4. Re: N210 FPGA Memory (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 May 2016 00:45:00 +0800
From: Ekko <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] how to use set_rx_agc in .py file
Message-ID:
<caggob6alxo9m14peeczt-1fgtu+-jerqhdshg3zjrbz1dch...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
hello all
i want to enable the agc function of B210,and i see the
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486
and i want to use this in tunnel.py ,but there is no way to accomplish this,
ao i want to ask is ther another way to enable agc in .py file
thank you
--Ekko
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/38b550c0/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 25 May 2016 19:25:26 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] how to use set_rx_agc in .py file
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Ekko,
Indeed, GNU Radio's gr-uhd doesn't currently expose the set_rx_agc
functionality.
So, without modification of GNU Radio, this is not possible so far.
Another question: are you *sure* you want to use AGC with tunnel.py?
Two things:
* I think it's time we started to move away from tunnel.py, especially
from the OFDM tunnel.py. It's bad, especially compared to the OFDM
examples rx_ofdm.grc and tx_ofdm.grc. Attaching a UDP source/sink to
those examples and using these much better OFDM implementations is
absolutely what you want to do. I don't think GNU Radio will have
tunnel.py for a long time. To put this more extremely: In my private
opinion, tunnel.py should not be used, under no circumstances, anymore.
* AGC with bursts must go wrong, unless you know *very* well how the
attack time of the AGC and the bursts relate, and incorporate an AGC
gain ramp-down compensation into your receiver structure. This might
be possible with the channel state estimators in the more modern
examples I mentioned above, but it would still mean a considerable
effort. It's really impossible to use tunnel.py with AGCs ? there's
no way to react to changing amplitude in the middle of a packet. And
exactly that is what's happening when you use AGC
* an "untamed" AGC in cooperation with OFDM will also be a bad idea ?
see PAPR considerations. That's one of the reasons why an OFDM
receiver is challenging hardware-wise: you'll need quite some
dynamic range, for the signal itself. Now, either you have a fast
AGC, that reacts already within the beginning of a cyclic prefix,
but that would then necessarily lead to a multiplication with the
fast control loop step response in time domain (== strong variation
of distortion in the post-FFT OFDM symbol), which will lead to an
ugly channel state distortion, not to mention that you'll also
increase the likelihood of nonlinearity/clipping in an extreme PAPR
case, and will make the equalizer work much worse, or you've got a
slow AGC that only kicks in after a significant part of the first
OFDM symbol of a frame has been received and is strongly limited in
maximum gain, which is not much better than having a software-side
feedback loop. In fact, for USRPs that support gain-setting via
timed commands, the software-side feedback loop could just adjust
the gain in time for the Nth OFDM symbol, so that you don't change
gain in the middle of a symbol. That'll make it possible that the
channel estimate done on the early part of the OFDM symbol is valid
throughout the symbol.
Best regards,
Marcus
On 25.05.2016 18:45, Ekko via USRP-users wrote:
> hello all
> i want to enable the agc function of B210,and i see the
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#abdab1f6c3775a9071b15c9805f866486
>
> and i want to use this in tunnel.py ,but there is no way to accomplish
> this,
> ao i want to ask is ther another way to enable agc in .py file
>
>
>
>
> thank you
>
> --Ekko
>
>
> _______________________________________________
> 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/20160525/ff360b3f/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 26 May 2016 14:08:54 +0000
From: "Topliff, Charles Alexander" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] N210 FPGA Memory
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello All,
I am interested in capturing samples at 100 MS/s using a USRP N210 at a 16b (or
14-bit ADC) resolution. In the datasheet, it is mentioned that the maximum host
sampling rate N210 is capable of is 50MS/s at 8bit resolution over Gigabit
Ethernet. My understanding is that this is a limitation imposed by the transfer
speed over the Gigabit ethernet interface.
To utilize the full potential of ADC sampling rate, what is the best way to
accumulate only a second (or half a second) worth of data? Specifically, I
would like to know if it is possible to use the FPGA to synthesize memory &
record 1 sec worth of samples (at 14b * 100MS/s) to that. After recording, I
would read it to the host at a slower speed. Are there any constraints in that
path?
Is there a better way of handling this? Any suggestion is appreciated.
Thanks,
Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/15635db5/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 26 May 2016 17:51:09 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N210 FPGA Memory
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Charles,
On 26.05.2016 16:08, Topliff, Charles Alexander via USRP-users wrote:
> Hello All,
>
> I am interested in capturing samples at 100 MS/s using a USRP N210 at
> a 16b (or 14-bit ADC) resolution. In the datasheet, it is mentioned
> that the maximum host sampling rate N210 is capable of is 50MS/s at
> 8bit resolution over Gigabit Ethernet. My understanding is that this
> is a limitation imposed by the transfer speed over the Gigabit
> ethernet interface.
Exactly!
>
> To utilize the full potential of ADC sampling rate, what is the best
> way to accumulate only a second (or half a second) worth of data?
> Specifically, I would like to know if it is possible to use the FPGA
> to synthesize memory & record 1 sec worth of samples (at 14b *
> 100MS/s) to that. After recording, I would read it to the host at a
> slower speed. Are there any constraints in that path?
(14b/real + 14bit/image) * 100 MS/s * 1s = 2.800Gb = 350MB. That's much
more than you could fit in any FPGA, and much more than the N210 has in
on-board RAM ? in fact, the N210 already uses SRAM buffering itself on
an 9Mbit SDRAM chip, but if I'm not mistaken, that's for TX data only.
You could adapt that (it's called ext_fifo, IIRC) for your RX and get up
to let's say 1/350s of buffering on the device.
>
> Is there a better way of handling this? Any suggestion is appreciated.
On the N210, I'm not quite sure.
One thing I wanted to ask was:
Which daughterboard do you intend to use? All our daughterboards either
have <= 40MHz bandwidth, so you gain nothing compared by using 100MS/s
(compared to 50MS/s), according to Nyquist, or >=120 MHz bandwidth, so
that they can't be used even at 100MS/s without aliasing.
The only exception would be an BasicRX daughterboard with your own,
custom, prefiltering that sufficiently band-limits the signal to
something below 50MHz on each I and Q lane.
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160526/258d6be8/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 69, Issue 26
******************************************
