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: Problem using message port (Jason Matusiak)
2. Re: B205i transient behavior (Michael West)
3. Does USRP N200 contains Programmable Gain Amplifier?
(Muhammad Munir)
4. Re: Does USRP N200 contains Programmable Gain Amplifier?
(Robin Coxe)
5. Re: Does USRP N200 contains Programmable Gain Amplifier?
(Fernando)
6. Re: Does USRP N200 contains Programmable Gain Amplifier?
(Marcus M?ller)
7. Re: SBX initial saturation (Julian Arnold)
8. Multiple B210 in the same PC (pablo.colodron)
9. Re: Multiple B210 in the same PC (Derek Kozel)
10. Re: Multiple B210 in the same PC (Marcus M?ller)
11. x310 fpga (Lihua Ren)
12. Re: x310 fpga (Jason Matusiak)
13. unable to set remote file system path (deepa kumar)
14. Re: x310 fpga (Jonathon Pendlum)
----------------------------------------------------------------------
Message: 1
Date: Mon, 1 May 2017 12:53:16 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problem using message port
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
List, I am still struggling to come up with a solution to this. Does
anyone know how to get past the "RuntimeError: invalid msg port in
connect() or disconnect()" error?
On 04/21/2017 11:34 AM, Jason Matusiak wrote:
> So I am a little confused with an error I am getting while using the
> message port for my RFNoC block. When not connect, my GRC script runs
> fine. When I connect a message strobe to it, I get a weird error. I
> can find the error elsewhere, but I don't usually see a good fix
> (except for update your GR, but I have a pretty new version).
>
> My message strobe has a Message PMT of "pmt.from_long(1)". My port
> input on the RFNoC block expects an int, but there doesn't seem to be
> a from_int option.
>
> The error I see is:
> Could not find port: cfg in:
> rfnoc
> system
>
> Traceback (most recent call last):
> File "/home/jmatusiak/rfnoc-multiaperture/examples/CPremoval.py",
> line 252, in <module>
> main()
> File "/home/jmatusiak/rfnoc-multiaperture/examples/CPremoval.py",
> line 240, in main
> tb = top_block_cls()
> File "/home/jmatusiak/rfnoc-multiaperture/examples/CPremoval.py",
> line 195, in __init__
> self.msg_connect((self.blocks_message_strobe_0, 'strobe'),
> (self.multiaperture_cpremoval_0, 'cfg'))
> File
> "/home/jmatusiak/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
>
> line 59, in wrapped
> func(self, src.to_basic_block(), srcport, dst.to_basic_block(),
> dstport)
> File
> "/home/jmatusiak/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py",
>
> line 131, in msg_connect
> self.primitive_msg_connect(*args)
> File
> "/home/jmatusiak/rfnoc/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
>
> line 3489, in primitive_msg_connect
> return _runtime_swig.top_block_sptr_primitive_msg_connect(self,
> *args)
> RuntimeError: invalid msg port in connect() or disconnect()
>
> >>> Done
>
> Now, cfg is the name of my message port of my RFNoC block (which is
> what fosphor calls theirs as well), but it looks like GR isn't happy
> with it. Does someone know where to look into this error more closely?
>
> This seems like a VERY similar issue, but I am not writing any
> C++/python, nor am I using foo:
> https://lists.gnu.org/archive/html/discuss-gnuradio/2017-01/msg00105.html
>
------------------------------
Message: 2
Date: Mon, 1 May 2017 16:41:47 -0700
From: Michael West <[email protected]>
To: Dominik Eyerly <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<CAM4xKrom9Hna3UoE5=sfnz4pwpctwr0k+91yizk5pqdandv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dominik,
My apologies for the delayed response. I have not had the opportunity to
look into this any further. We can certainly test it out and let you know
if we see the same results. I think the best way to proceed is for you to
contact [email protected] and provide a code sample to reproduce the issue
along with a link to this thread.
Regards,
Michael
On Wed, Apr 26, 2017 at 6:16 AM, Dominik Eyerly <
[email protected]> wrote:
> Hi Michael,
>
> Unfortunately, this did not resolve the issue. It seemed to have no effect
> on the waveform. What else could be causing this behavior? Would you be
> able to test this on a board you have available to rule out the possibility
> that I have a bad batch?
>
> cheers,
> Dominik
>
> On 04/25/2017 08:25 PM, Michael West wrote:
>
> Hi Dominik,
>
> To keep the PA on all the time on the B205mini, change STATE_OFF to
> TX_ENABLE1 on this line: https://github.com/EttusResearch/uhd/blob/maint/
> host/lib/usrp/b200/b200_impl.cpp#L1178
>
> I am still not convinced that is the main source of long ramp up in
> power. Some transient due to PA warm up is expected, but it is usually on
> the order of microseconds and not milliseconds.
>
> Regards,
> Michael
>
> On Mon, Apr 24, 2017 at 12:44 AM, Dominik Eyerly <
> [email protected]> wrote:
>
>> Hi Michael,
>>
>> Would you be able to point out where in the code I need to make this
>> modification to keep the PA on at all times? Padding with zeros is a very
>> undesirable workaround for my application. I will set the tx gain down to
>> minimize the switch isolation issue.
>> Thanks,
>> dominik
>>
>>
>> On 04/15/2017 12:37 AM, Michael West wrote:
>>
>> Hi Dominik,
>>
>> Creating the streamer connects the blocks in the FPGA, creates the
>> transports, and does some initialization for the stream. It shouldn't (and
>> probably doesn't) matter whether you create the streamer or do the other
>> operations first. I just recommend creating the streamers first as a best
>> practice to be on the safe side.
>>
>> As for the PA, 100ms is longer than I would expect for the warm up time.
>> I suspect the slow rise is partially due to PA warm up, but there may be
>> other factors involved as well. I recommend trying varying amounts of
>> leading zeros to see what the minimum amount is to see a clear signal.
>> Keeping the PA on all the time should be possible, but it will take UHD
>> code changes and could have side effects like higher noise on the RX side
>> due to leakage across the RF switch.
>>
>> Regards,
>> Michael
>>
>> On Wed, Apr 12, 2017 at 6:29 AM, Dominik Eyerly <
>> [email protected]> wrote:
>>
>>> Hi Michael,
>>>
>>> Thank you for your response. Padding the end with zeros clears some of
>>> the garbage that is played at the beginning of the waveform.
>>>
>>> Creating the streams at the beginning should be no problem for me. One
>>> follow up question, you mentioned explicitly to create the streamer prior
>>> to tuning, setting bandwidth etc, do these operations have a specific
>>> effect on the streamer? Or in other words, what adverse effects, if any,
>>> exist if I perform these operations before creating the streamer?
>>>
>>> As per the PA behavior, this is an issue that is extremely undesirable
>>> for my application. I understand all PAs will have some rise time, however,
>>> 100ms seems excessive. Is it perhaps possible to power up the PA earlier
>>> via some modification to the host / fpga code? Simply pre-pending 100ms of
>>> zeros to my waveform won't work because I need the waveform to play with
>>> minimal delay. I don't have any low power constraints so it would not be a
>>> problem to keep the PA permanently enabled, if that is possible.
>>>
>>> cheers,
>>> dominik
>>> On 04/11/2017 08:40 PM, Michael West wrote:
>>>
>>> Hi Dominik,
>>>
>>> I can confirm that the creation of the streamers is very intrusive. It
>>> changes the active chains in the AD9364 and reconfigures the interface
>>> between the AD9364 and FPGA as Marcus has pointed out. For that reason, it
>>> is recommended to create all streamers before starting any streaming.
>>>
>>> Looking at the images you posted, the gap and first spur correlate to
>>> the creation of the TX streamer, so that should be eliminated if the
>>> streamers are created first. The next significant spur seems to align with
>>> the start of the TX streaming. My suspicion is that it is from garbage
>>> samples left in the DUC from initialization, but some testing is needed to
>>> prove that. Finally, the ramp and elevated power level during the
>>> transmission of the zeros is due to the TX PA being enabled when the stream
>>> starts.
>>>
>>> My suggestions:
>>>
>>> 1) Create the streamers right after creating the multi_usrp object
>>> (before any tuning, setting bandwidth, setting sample rate, etc...).
>>> 2) Pad the end of the TX burst with zeros. The first few samples
>>> transmitted are always the residual samples in the DUC. This means the
>>> last few samples of the burst will not actually make it to the AD9364
>>> unless you pad with zeros to flush them. Zero padding the end of every
>>> burst will make sure all desired samples are transmitted and that the next
>>> burst will start by transmitting the residual zeros. The amount of the
>>> group delay will vary depending on master clock rate and sample rate, but
>>> it is usually on the order of a few to a couple hundred microseconds.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Tue, Apr 11, 2017 at 1:11 AM, Dominik Eyerly via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hello,
>>>>
>>>> A couple of days has gone by so I wanted to follow up on my questions..
>>>>
>>>> *"OK, so, with the zeros, I think I understand what's going on. When
>>>> you create a new streamer, the hardware has to be configured to the new
>>>> state.*
>>>> * In the case of the AD9361, this means the data path between the
>>>> AD9361 and the FPGA, which unavoidably means that the RX samples are
>>>> interrupted*
>>>> * while the interface is reconfigured. I believe this is the reason
>>>> for a lump of zeros when you configure for TX--someone in engineering can
>>>> correct*
>>>> * my understanding if it's wrong."*
>>>>
>>>> So this is confirmed behavior then? It is inherently due to the AD chip
>>>> and not a bug in the code somewhere (host / fpga)?
>>>>
>>>> *"In terms of the rather-long transient time--is this only immediately
>>>> after configuring the TX streamer, or for any TX burst? If it's just
>>>> immediately*
>>>> * after configuring a TX streamer, then this may be expected. If
>>>> it's at the start of every burst, then something is very wrong. Again, I'm
>>>> awaiting*
>>>> * comment from someone in Ettus R&D."*
>>>>
>>>> This is at the start of *every* burst that is initiated when rx is
>>>> running. Even when the tx_streamer is kept alive. Have you had a chance to
>>>> run my example program, or modify the existing loopback example in the way
>>>> I described in my previous email to reproduce the issue? I don't believe I
>>>> am doing something that is incorrect, however, if I am, I would be happy to
>>>> have someone point out my mistake.
>>>>
>>>> Best regards,
>>>> Dominik
>>>>
>>>> On 04/06/2017 05:51 PM, Marcus D. Leech wrote:
>>>>
>>>> On 04/06/2017 05:07 AM, Dominik Eyerly wrote:
>>>>
>>>> I'm using 1M for both rx and tx. I've seen that example but it does not
>>>> have the correct setup to display this behavior. As I mentioned before, the
>>>> acquisition has to be running BEFORE transmit begins. In the example code
>>>> there is no synchronization between rx start and tx start so you don't get
>>>> to see the beginning of the transmit in the capture. I added a simple
>>>> atomic bool to the example to ensure rx is running before tx starts. This
>>>> is sufficient to display the issue. Also, the issue of having zeros in rx
>>>> when creating a streamer will also not be displayed in this example code
>>>> because the tx_streamer is created before the acquisition starts.
>>>>
>>>> Here is a plot of the txrx loopback example with my minor
>>>> synchronization addition.
>>>>
>>>> http://imgur.com/a/0FjeI
>>>>
>>>> Would you be able to run the code that I posted in my previous email to
>>>> see if you have the same issues on your end?
>>>>
>>>>
>>>> cheers,
>>>> dominik
>>>>
>>>> OK, so, with the zeros, I think I understand what's going on. When you
>>>> create a new streamer, the hardware has to be configured to the new state.
>>>> In the case of the AD9361, this means the data path between the
>>>> AD9361 and the FPGA, which unavoidably means that the RX samples are
>>>> interrupted
>>>> while the interface is reconfigured. I believe this is the reason
>>>> for a lump of zeros when you configure for TX--someone in engineering can
>>>> correct
>>>> my understanding if it's wrong.
>>>>
>>>>
>>>> In terms of the rather-long transient time--is this only immediately
>>>> after configuring the TX streamer, or for any TX burst? If it's just
>>>> immediately
>>>> after configuring a TX streamer, then this may be expected. If it's
>>>> at the start of every burst, then something is very wrong. Again, I'm
>>>> awaiting
>>>> comment from someone in Ettus R&D.
>>>>
>>>>
>>>>
>>>> On 04/06/2017 04:10 AM, Marcus D. Leech wrote:
>>>>
>>>> On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>>>>
>>>> Hello,
>>>>
>>>> UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
>>>> UHD_3.11.0.git-release, compiled for ARM
>>>> B205 running on USB3.
>>>>
>>>> Doesn't matter if the port is terminated or if it has a signal, recv
>>>> returns hard 0s, (not 1e-10 or the like) when a tx streamer is created.
>>>> I've uploaded a simple bit of code that illustrates the behavior quite
>>>> clearly.
>>>>
>>>> https://pastebin.com/ZAccunUe
>>>>
>>>> Please note that this code assumes you have 20dB of attenuation between
>>>> rx and tx. However you can adjust the gain values appropriately if you do
>>>> not.
>>>>
>>>> I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
>>>> -lboost_system -luhd
>>>>
>>>> But honestly, this issue is not my primary concern. My primary concern
>>>> is the ramp behavior. Note that the code I posted also illustrates the
>>>> ramping behavior. For this it needs to be in loopback with 20dB attenuation
>>>> (or more). I included a little helper function which performs a quick dump
>>>> to a python file. If you have matplotlib for python you can uncomment the
>>>> "dump_to_py" line in the rx thread and then simply run the generated file
>>>> with python to see a quick plot of the iq data.
>>>>
>>>> What else could I do to further troubleshoot this?
>>>>
>>>> cheers,
>>>> Dominik
>>>>
>>>> There is an example program, called txrx_loopback_to_file that does
>>>> something similar to your test.
>>>>
>>>> I wonder if it would be possible to do your tests with that, and see if
>>>> there is any change in behavior.
>>>>
>>>> Also, what sample rates are you using?
>>>>
>>>>
>>>>
>>>> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>>>>
>>>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>>>
>>>> Hello,
>>>>
>>>> Thanks for the reply. I should add I am doing this test at 3.8G.
>>>>
>>>> Response to (A)
>>>>
>>>> Are you saying that regardless of my tx gain setting, I need 40dB of
>>>> attenuation? I believe at max tx gain the board outputs around 10-15dBm
>>>> @3.8G. I currently have a 6dB pad on tx port, cabled to a splitter which is
>>>> cabled to the rx port with an inline 10dB pad. The other splitter port is
>>>> going directly into my VSA. Also, my tx gain is around 50dB. My
>>>> understanding was that the max input power of the rx port is -15dBm. With
>>>> this configuration I should be well under that, as shown on my VSA capture
>>>> (~-35dBm).
>>>>
>>>> Response to (B)
>>>>
>>>> According to the rough specifications posted here:
>>>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>>>
>>>> The IIP3 is -15dBm. As you can see on my VSA capture, it received
>>>> -35dBm and that doesn't even include the extra 10dB pad on the ettus rx
>>>> port. I should be good on linearity, should I not? The reason the power
>>>> capture looks so wavy is probably because I have the LO's tuned to the same
>>>> spot. When I move tx off by 100kHz the capture looks "nicer" but the ramp
>>>> up behavior is still there. Also, on the link I posted above, the max input
>>>> power is called out as 0 dBm... is that correct?
>>>>
>>>> Could you provide some input on the questions I brought up in my
>>>> previous email? Namely:
>>>>
>>>> (1) recv returning 0s when a tx_streamer is created while receiving
>>>> continuously.
>>>>
>>>> Could you try a simple experiment here? Place a terminator on the
>>>> input to the RX side, and see if you get 0s in the recv buffer. I want to
>>>> distinguish
>>>> between an analog situation and a digital one.
>>>>
>>>> (2) The ramp up behavior that is only present when transmitting during
>>>> an active acquisition.
>>>>
>>>> That's odd. What version of UHD are you using?
>>>>
>>>>
>>>> I also want to mention that the first burst of power in my captures
>>>> coincides with changing the frequency of the tx LO. This triggers an
>>>> internal calibration of the AD chip which in turn outputs this brief burst.
>>>> So at least this mystery is solved. I am curious, however, is it possible
>>>> to allow the chip to perform its cal without actually seeing this signal at
>>>> the tx port?
>>>>
>>>> I'm not certain of exactly how it performs its calibration, but likely
>>>> there will always be some leakage when it is doing so.
>>>>
>>>>
>>>> cheers,
>>>> Dominik
>>>>
>>>> On 04/04/2017 04:54 PM, [email protected] wrote:
>>>>
>>>> How are you doing the physical loop-back? If directly-cabled, you'll
>>>> need about 40dB of attenuation in-line, to keep the receiver from:
>>>>
>>>> (A) Being damaged
>>>>
>>>> (B) Remaining linear
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:
>>>>
>>>> Hello all,
>>>>
>>>>
>>>>
>>>> My questions concern the B205i. I've uploaded some pictures to simplify
>>>> the explaining process.
>>>>
>>>> http://imgur.com/a/XMAv6
>>>>
>>>> Basically, I want to transmit and receive a FSK waveform on one board
>>>> (loopback). This means I've tuned both LOs to the same frequency. I've also
>>>> inserted a splitter to be able to look at the signal on my VSA. This has
>>>> allowed me to identify several problems.
>>>>
>>>>
>>>>
>>>> Let's start on the left:
>>>> (B205i Receive - no zeros)
>>>> Here you see the received power drop from the noise floor to -infinity
>>>> because the rx_streamer was returning 0's. I've tracked this problem to the
>>>> creation of a tx_streamer while an acquisition is running. This seems
>>>> completely unacceptable; that calling a command on a chain (tx) that has
>>>> nothing to do with rx, has an effect on rx. I could understand that the
>>>> sample rate performance of rx is affected because they share a
>>>> communication link, but not to actually alter the data that is returned by
>>>> the recv call. Is this a known bug? Is there a workaround other than "don't
>>>> do that"? Is this bug slated for a fix next release?
>>>>
>>>>
>>>>
>>>> Next:
>>>> Right after all of the 0's, a strong but brief tone is blasted into the
>>>> tx path. The power of this tone is not affected by the tx gain setting.
>>>> This is quite a significant problem because we may use this module to test
>>>> sensitive devices that may not be able to withstand such a transient. Any
>>>> idea what is causing this? Again, any workarounds or fixes known?
>>>>
>>>>
>>>>
>>>> I don't care much for the spur at -83dBm. But it would be interesting
>>>> to understand it.
>>>>
>>>>
>>>>
>>>> Lastly:
>>>> The actual waveform is transmitted. Since this is an FSK waveform, I
>>>> would expect a constant power envelope. Unfortunately, what I capture with
>>>> the B205i is not even close. I performed the test again, but this time
>>>> transmitting 200ms of 0s before my actual FSK waveform. You can still see
>>>> the "warm up" looking behavior, however, by the time the actual waveform
>>>> hits, the output seems settled. Is that what is happening (warm up)?
>>>> Preloading every waveform with 200ms of zeroes is extremely undesirable. Is
>>>> there a way to keep the chip always ready to go from both a Rx and Tx
>>>> perspective?
>>>>
>>>>
>>>>
>>>> Tx only with no zeros:
>>>> I performed the no zeros test again, this time without doing an
>>>> acquisition with the B205i. Now the warm up behavior is completely gone.
>>>> Why is Rx influencing the Tx RF performance?
>>>>
>>>>
>>>>
>>>> Any insight into these issues I am experiencing would be very
>>>> appreciated.
>>>>
>>>> Best regards,
>>>> Dominik
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>> Email: [email protected]
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which may
>>>> contain information that is privileged, confidential, and/or otherwise
>>>> exempt from disclosure under applicable law. If the reader of this message
>>>> is not the intended recipient, any disclosure, dissemination,
>>>> distribution, copying or other use of this communication or its substance
>>>> is prohibited. If you have received this communication in error, please
>>>> contact us immediately. Thank you.
>>>>
>>>> _______________________________________________ USRP-users mailing
>>>> list [email protected] http://lists.ettus.com/mailman
>>>> /listinfo/usrp-users_lists.ettus.com
>>>>
>>>> --
>>>>
>>>> --
>>>>
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>> Email: [email protected]
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which may
>>>> contain information that is privileged, confidential, and/or otherwise
>>>> exempt from disclosure under applicable law. If the reader of this message
>>>> is not the intended recipient, any disclosure, dissemination,
>>>> distribution, copying or other use of this communication or its substance
>>>> is prohibited. If you have received this communication in error, please
>>>> contact us immediately. Thank you.
>>>>
>>>> --
>>>>
>>>> --
>>>>
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>> Email: [email protected]
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which may
>>>> contain information that is privileged, confidential, and/or otherwise
>>>> exempt from disclosure under applicable law. If the reader of this message
>>>> is not the intended recipient, any disclosure, dissemination,
>>>> distribution, copying or other use of this communication or its substance
>>>> is prohibited. If you have received this communication in error, please
>>>> contact us immediately. Thank you.
>>>>
>>>> --
>>>>
>>>> --
>>>>
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>> Email: [email protected]
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which may
>>>> contain information that is privileged, confidential, and/or otherwise
>>>> exempt from disclosure under applicable law. If the reader of this message
>>>> is not the intended recipient, any disclosure, dissemination,
>>>> distribution, copying or other use of this communication or its substance
>>>> is prohibited. If you have received this communication in error, please
>>>> contact us immediately. Thank you.
>>>>
>>>> --
>>>>
>>>> --
>>>>
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>> Email: [email protected]
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which may
>>>> contain information that is privileged, confidential, and/or otherwise
>>>> exempt from disclosure under applicable law. If the reader of this message
>>>> is not the intended recipient, any disclosure, dissemination,
>>>> distribution, copying or other use of this communication or its substance
>>>> is prohibited. If you have received this communication in error, please
>>>> contact us immediately. Thank you.
>>>>
>>>> _______________________________________________ USRP-users mailing
>>>> list [email protected] http://lists.ettus.com/mailman
>>>> /listinfo/usrp-users_lists.ettus.com
>>>
>>> --
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>> Email: [email protected]
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <+49%207732%209815100>*[email protected][image: sig]
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which may
>>> contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>> --
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>>
>
> --
>
>
>
> --
>
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
> Email: [email protected]
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
> *Support Telefon: +49 (0) 7732 9815 100
> <+49%207732%209815100>*[email protected][image: sig]
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
> bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
> contains information from Konrad GmbH, which is intended only for the use of
> the individual or entity to which it is addressed, and which may contain
> information that is privileged, confidential, and/or otherwise exempt from
> disclosure under applicable law. If the reader of this message is not the
> intended recipient, any disclosure, dissemination, distribution, copying or
> other use of this communication or its substance is prohibited. If you have
> received this communication in error, please contact us immediately. Thank
> you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170501/b00e982d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170501/b00e982d/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddojlpbmdhnigbcj.png
Type: image/png
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170501/b00e982d/attachment-0001.png>
------------------------------
Message: 3
Date: Tue, 2 May 2017 11:46:35 +0500
From: Muhammad Munir <[email protected]>
To: [email protected]
Subject: [USRP-users] Does USRP N200 contains Programmable Gain
Amplifier?
Message-ID:
<CACqj-HzBwG5pX_ND9U11vt-X7RPGMKFntDmL+369Tzff3EP7=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I am working on USRP n200. In the datasheet, there is no clue of PGA. I did
studied a few documents about USRP description and found that USRP contains
PGA before the ADC. I am using USRP with Gnuradio and when I set a gain
value in RF options of UHD_Source block, it has no effect on the signal
which shows that there is no PGA. My questions are
1. Does USRP n200 contains PGA before ADC in its motherboard?
2. If yes, How can I get access to it and utilize it from Gnuradio, not
FPGA?
Regards,
Munir
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170502/c6f68a70/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 2 May 2017 04:23:24 -0400
From: Robin Coxe <[email protected]>
To: Muhammad Munir <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Does USRP N200 contains Programmable Gain
Amplifier?
Message-ID:
<CAGVTi8W8uO0PZ=yuvfraag324vg5r1jzzgblqc5mhduqj6m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Munir. The answer to your question can be found by studying the
schematics and the datasheets of the ICs on the board. First take a look
at the p.1 of the schematic of the USRP N200:
http://files.ettus.com/schematics/n200/n2xx.pdf
You are correct, there is no amplifier upstream of the ADC on the N200
motherboard.
But here is the key question-- what daughterboard are you using with your
N200? Check that schematic too.
Let's use the CBX-40 as an example:
http://files.ettus.com/schematics/cbx/CBX.pdf
Looking at the Rx chain on p. 2-- just upstream of the ADC is a ADA4927
driver amplifier, but the gain isn't adjustable. Upstream of the driver
amp is a quadrature demodulator, the ADL5380, which according to the
datasheet, has a non-adjustable ~7 dB conversion gain.
Now look at p 1 of the CBX schematic, U2 and U7 are programmable
attenuators, HMC624LP4E-- there's your programmable gain control stage!
-Robin
On Tue, May 2, 2017 at 2:46 AM, Muhammad Munir via USRP-users <
[email protected]> wrote:
> Hi All,
> I am working on USRP n200. In the datasheet, there is no clue of PGA. I
> did studied a few documents about USRP description and found that USRP
> contains PGA before the ADC. I am using USRP with Gnuradio and when I set a
> gain value in RF options of UHD_Source block, it has no effect on the
> signal which shows that there is no PGA. My questions are
> 1. Does USRP n200 contains PGA before ADC in its motherboard?
> 2. If yes, How can I get access to it and utilize it from Gnuradio, not
> FPGA?
>
> Regards,
> Munir
>
> _______________________________________________
> 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/20170502/48691d6f/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 2 May 2017 10:24:09 +0200
From: Fernando <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Does USRP N200 contains Programmable Gain
Amplifier?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Sure it does. It is very similar to N210 wich has gain 0-31 dB in 1dB
step as trasnmitter and 0-31.5dB in 0.5 step as receiver.
When you use the USRP block in GNU Radio, and set the gain to a value,
you are selecting the PGA gain.
regards
El 02/05/17 a las 08:46, Muhammad Munir via USRP-users escribi?:
> Hi All,
> I am working on USRP n200. In the datasheet, there is no clue of PGA.
> I did studied a few documents about USRP description and found that
> USRP contains PGA before the ADC. I am using USRP with Gnuradio and
> when I set a gain value in RF options of UHD_Source block, it has no
> effect on the signal which shows that there is no PGA. My questions are
> 1. Does USRP n200 contains PGA before ADC in its motherboard?
> 2. If yes, How can I get access to it and utilize it from Gnuradio,
> not FPGA?
>
> Regards,
> Munir
>
>
> _______________________________________________
> 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/20170502/36518629/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 2 May 2017 12:12:02 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Does USRP N200 contains Programmable Gain
Amplifier?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Fernando,
no, as Robin said:
The N210 itself does *not* have any amplifier. Your Daughterboard has
the adjustable amplifers.
Best regards,
Marcus
On 02.05.2017 10:24, Fernando via USRP-users wrote:
> Sure it does. It is very similar to N210 wich has gain 0-31 dB in 1dB
> step as trasnmitter and 0-31.5dB in 0.5 step as receiver.
> When you use the USRP block in GNU Radio, and set the gain to a value,
> you are selecting the PGA gain.
>
> regards
>
>
>
> El 02/05/17 a las 08:46, Muhammad Munir via USRP-users escribi?:
>> Hi All,
>> I am working on USRP n200. In the datasheet, there is no clue of PGA.
>> I did studied a few documents about USRP description and found that
>> USRP contains PGA before the ADC. I am using USRP with Gnuradio and
>> when I set a gain value in RF options of UHD_Source block, it has no
>> effect on the signal which shows that there is no PGA. My questions are
>> 1. Does USRP n200 contains PGA before ADC in its motherboard?
>> 2. If yes, How can I get access to it and utilize it from Gnuradio,
>> not FPGA?
>>
>> Regards,
>> Munir
>>
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170502/0bb2b8f5/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 2 May 2017 12:24:13 +0200
From: Julian Arnold <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] SBX initial saturation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hey,
could you please elaborate on you problem a little bit more?
What is you input signal? How are you recording the data? Why do you
think the device is in saturation?
I could try to replicate your setup but in order to do that I would need
more information.
Cheers,
On 04/29/2017 09:53 AM, Amirhosein naseri via USRP-users wrote:
> Hi
>
> I have n210 with SBX daughterboard . when I start capturing sample
> after a while that usurp was off, after starting SBX is in saturation
> and keep in this state .... after 5 to 10 minutes, SBX start to work
> correctly, why?
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Julian Arnold, M.Sc.
Institute for Networked Systems
RWTH Aachen University
Kackertstrasse 9
52072 Aachen
Germany
------------------------------
Message: 8
Date: Tue, 02 May 2017 13:17:22 +0200
From: "pablo.colodron" <[email protected]>
To: [email protected]
Subject: [USRP-users] Multiple B210 in the same PC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Good morning,
Ettus knowledge base mentions that USB performance varies dramatically
when multiple devices are streaming through the same controller. Are
there some figures available about this performance? We would like to
use 2 B210 USRPs connected to the same PC (and so, probably connected to
the same USB controller). We would need a 10Msps throughput in each
device.
Is this configuration feasible? We prefer to use B210 because of the
AD9361 chip, so N210 (which is more focused in multichannel
applications) would not be an option for us.
Regards,
------------------------------
Message: 9
Date: Tue, 2 May 2017 13:22:52 +0100
From: Derek Kozel <[email protected]>
To: "pablo.colodron" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Multiple B210 in the same PC
Message-ID:
<CAA+K=tubrp+xagozktky+l62-2+uj3jvbj0sxv1xydjvjyh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Pablo,
That is certainly a feasible configuration and 10 MS/s per channel is a
reasonable rate for virtually all controllers. The Intel Series 7, 8, 9,
and 100 USB controllers have a good history of working well. The Asmedia
ones have proven difficult to get reliable performance on.
Regards,
Derek
On Tue, May 2, 2017 at 12:17 PM, pablo.colodron via USRP-users <
[email protected]> wrote:
> Good morning,
>
> Ettus knowledge base mentions that USB performance varies dramatically
> when multiple devices are streaming through the same controller. Are there
> some figures available about this performance? We would like to use 2 B210
> USRPs connected to the same PC (and so, probably connected to the same USB
> controller). We would need a 10Msps throughput in each device.
>
> Is this configuration feasible? We prefer to use B210 because of the
> AD9361 chip, so N210 (which is more focused in multichannel applications)
> would not be an option for us.
>
> Regards,
>
>
>
> _______________________________________________
> 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/20170502/a6d31641/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 2 May 2017 14:27:38 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Multiple B210 in the same PC
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Pablo,
in my experience: with a good USB3 controller, no problem, with a one
that doesn't cooperate as well with your OS and UHD: no chance.
So, this really boils down to: You'll have to try. Modern Intel chipsets
tend to work fine, and 2x 10MS/s isn't *that* much.
10 MS/s can, under certain circumstances, still work over USB2, so I
wouldn't worry all that much, still, there's no guarantee here.
You mention that you need "10 Msps throughput in each device"; does that
mean you're only using one of the two channels of each B210? In that
case, two B200s might be a cheaper alternative.
Best regards,
Marcus
On 05/02/2017 01:17 PM, pablo.colodron via USRP-users wrote:
> Good morning,
>
> Ettus knowledge base mentions that USB performance varies dramatically
> when multiple devices are streaming through the same controller. Are
> there some figures available about this performance? We would like to
> use 2 B210 USRPs connected to the same PC (and so, probably connected
> to the same USB controller). We would need a 10Msps throughput in each
> device.
>
> Is this configuration feasible? We prefer to use B210 because of the
> AD9361 chip, so N210 (which is more focused in multichannel
> applications) would not be an option for us.
>
> Regards,
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 11
Date: Tue, 2 May 2017 20:53:48 +0800 (CST)
From: "Lihua Ren" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] x310 fpga
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
hi,
My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC ---> RFnoc:my
block,
in radio block, sampling rate :200MHz,
in DDC block ?input rate :200MHz,output rate :200kHz,
I think the data rate in the FPGA code should be :200kHz ?but the use of
ChipScope to see the data rate is about 1.67MHz.why?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170502/5fc80b23/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 2 May 2017 09:57:13 -0400
From: Jason Matusiak <[email protected]>
To: Lihua Ren <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] x310 fpga
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
According to a post by Marcus Leech last month
(http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-April/024489.html),
the largest divisor factor for the DUC (I assume the DDC is pretty
similar) is 512.
So I would be surprised if you could go from 200MHz to 200kHz in one
shot, but I am not sure how you ended up with a factor of 119.76 instead.
On 05/02/2017 08:53 AM, Lihua Ren via USRP-users wrote:
> hi,
> My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC --->
> RFnoc:my block,
> in radio block, sampling rate :200MHz,
> in DDC block ?input rate :200MHz,output rate :200kHz,
> I think the data rate in the FPGA code should be :200kHz ?but the use
> of ChipScope to see the data rate is about 1.67MHz.why?
> Thanks.
>
>
>
>
> _______________________________________________
> 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/20170502/297337db/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 2 May 2017 10:53:03 -0400
From: deepa kumar <[email protected]>
To: [email protected]
Subject: [USRP-users] unable to set remote file system path
Message-ID:
<CAOgE1BcOpRg9h1wjdhqagBYvejPi64sfFeST3=sm0si6csm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I created set_env as follows
LOCALPREFIX=~/usr
export PATH=$LOCALPREFIX/bin:$PATH
export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export
GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
after running source ./set_env , when I echo $LD_LIBRARY_PATH it shows
/lib:/root/usr
echo $LOCALPREFIX
/home/root/usr
but when echo $PATH
*bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin*
*so when I do a which uhd_find_devices it keeps pointing to *
/usr/bin/uhd_find_devices
and not to
/home/root/usr
can somebody help me with this.
Thanks and Regards,
Olivani
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170502/ff601ecd/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 2 May 2017 09:55:18 -0500
From: Jonathon Pendlum <[email protected]>
To: Lihua Ren <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] x310 fpga
Message-ID:
<cagdo0uqsqyxgdpup9ka0fzhdxvc7jvw36qwvqrmeflfqom+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
How are you measuring the sample rate in your block? Since RFNoC is
packetized, you will see bursts of data, so you need to find the average
rate over many clock cycles.
What does the console log say? Do you see any warnings about the sample
rate?
Jonathon
On May 2, 2017 7:55 AM, "Lihua Ren via USRP-users" <
[email protected]> wrote:
> hi,
> My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC --->
> RFnoc:my block,
> in radio block, sampling rate :200MHz,
> in DDC block ?input rate :200MHz,output rate :200kHz,
> I think the data rate in the FPGA code should be :200kHz ?but the use of
> ChipScope to see the data rate is about 1.67MHz.why?
> Thanks.
>
>
>
>
> _______________________________________________
> 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/20170502/a12a89d3/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 81, Issue 2
*****************************************
