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. multiuser device using x300 and n210 (Nikita Airee)
2. RFNoC support device (???)
3. Re: RFNoC support device (Marcus M?ller)
4. FW: Re: RFNoC support device (???)
5. Re: B205i transient behavior (Dominik Eyerly)
6. Receiving power issue (Jahnavendra Mattipa)
7. Re: Receiving power issue (Marcus M?ller)
8. Re: multiuser device using x300 and n210 (Nicolas Cuervo)
9. Re: multiuser device using x300 and n210 (Nikita Airee)
10. Re: multiuser device using x300 and n210 (Nicolas Cuervo)
11. Re: multiuser device using x300 and n210 (Nikita Airee)
12. Re: multiuser device using x300 and n210 (Nicolas Cuervo)
13. Dynamic range of DAC (Anders Charly Rasmussen)
14. Re: multiuser device using x300 and n210 (Marcus D. Leech)
15. Re: multiuser device using x300 and n210 (Nikita Airee)
16. Re: multiuser device using x300 and n210 ([email protected])
17. Announcing NEWSDR at Tufts University on Thr/Fri June 1/2
(Neel Pandeya)
----------------------------------------------------------------------
Message: 1
Date: Mon, 24 Apr 2017 11:48:41 +0530
From: Nikita Airee <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] multiuser device using x300 and n210
Message-ID:
<CAOT=STnk2nD5ktacC8PJ9=ezj43-6a6rrab1zmsnp3obvtm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone!
I have an x300 and an n210 that I would like to use in MIMO configuration.
Before, I had been working with 2 x300 which I daisy chained into a
multiusrp device.
However, doing the same for these 2 different usrps throws up the following
error:
Device discovery error: ValueError: Could not resolve device hint
"addr=192.168.10.3" to a single device.
Could you please tell me if this is expected behaviour and if not what
steps should I take to correct it?
Bests,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/1053f042/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 24 Apr 2017 15:31:31 +0900
From: ??? <[email protected]>
To: [email protected] <[email protected]>
Subject: [USRP-users] RFNoC support device
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi all
Is there any reason RFNoC support only E and X series?
Or future plan for the other device?
Regards
Kim taeyeong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/8eaa1a82/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 24 Apr 2017 09:02:52 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNoC support device
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Kim,
RFNoC requires features that are simply not present on the other
devices' FPGAs.
So, you currently can't use RFNoC on anything but E and X series.
What is your use case? Can we help you with that, maybe? Maybe RFNoC
isn't your only option to achieve what you need.
Best regards,
Marcus
On 24.04.2017 08:31, ??? via USRP-users wrote:
>
> Hi all
>
>
>
> Is there any reason RFNoC support only E and X series?
>
> Or future plan for the other device?
>
>
>
> Regards
>
> Kim taeyeong
>
>
>
> _______________________________________________
> 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/20170424/5cf9877a/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 24 Apr 2017 16:41:28 +0900
From: ??? <[email protected]>
To: [email protected] <[email protected]>
Cc: ??? <[email protected]>
Subject: [USRP-users] FW: Re: RFNoC support device
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Marcus
This question in very advance
Now I'm start to building FMCW radar with E310 and GRC
Only success WBFM receiver compiled on Windows 10 and tftp to E310,
Get recorded testwav file to computer
I'm not sure what I have to do or not clearly yet
Regards
Kim taeyeong
------------Original Message------------
Subject : Re: [USRP-users] RFNoC support device
Date : 2017-04-24 16:04:08
>From : Marcus Müller via USRP-users <usrp-users@listsettuscom>
To : usrp-users@listsettuscom
Cc : Marcus Müller <marcusmueller@ettuscom>
Hi Kim,
RFNoC requires features that are simply not present on the other
devices' FPGAs
So, you currently can't use RFNoC on anything but E and X series
What is your use case? Can we help you with that, maybe? Maybe RFNoC
isn't your only option to achieve what you need
Best regards,
Marcus
On 24042017 08:31, ??? via USRP-users wrote:
Hi all
Is there any reason RFNoC support only E and X series?
Or future plan for the other device?
Regards
Kim taeyeong
_______________________________________________
USRP-users mailing list
USRP-users@listsettuscom
http://listsettuscom/mailman/listinfo/usrp-users_listsettuscom
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/91cc70b1/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: no_file_name_0.ext
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/91cc70b1/attachment-0001.ext>
------------------------------
Message: 5
Date: Mon, 24 Apr 2017 09:44:48 +0200
From: Dominik Eyerly <[email protected]>
To: Michael West <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
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]
> <mailto:[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] <mailto:[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
>>>>>>>>
>>>>>>>> <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]
>>>>>>>> <mailto:[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
>>>>>>>>>> <tel:+49%20351%207958019233>
>>>>>>>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>>>>>>>>>> Email: [email protected]
>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>
>>>>>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>>>>>>> www.konrad-technologies.de
>>>>>>>>>> <http://www.konrad-technologies.de>
>>>>>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>>>>>
>>>>>>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>>>>>>> <tel:+49%207732%209815100>*
>>>>>>>>>> [email protected]
>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>> 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]
>>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>>
>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>>>>>> --
>>>>>>>>
>>>>>>>> --
>>>>>>>> i.A. Dominik Eyerly
>>>>>>>> Software
>>>>>>>>
>>>>>>>> Tel: +49 (0) 351 7958019 233 <tel:+49%20351%207958019233>
>>>>>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>>>>>>>> Email: [email protected]
>>>>>>>> <mailto:[email protected]>
>>>>>>>>
>>>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>>>>> www.konrad-technologies.de
>>>>>>>> <http://www.konrad-technologies.de>
>>>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>>>
>>>>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>>>>> <tel:+49%207732%209815100>*
>>>>>>>> [email protected]
>>>>>>>> <mailto:[email protected]>
>>>>>>>> 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 <tel:+49%20351%207958019233>
>>>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>>>>>> Email: [email protected]
>>>>>> <mailto:[email protected]>
>>>>>>
>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>>> www.konrad-technologies.de
>>>>>> <http://www.konrad-technologies.de>
>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>
>>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>>> <tel:+49%207732%209815100>*
>>>>>> [email protected]
>>>>>> <mailto:[email protected]>
>>>>>> 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 <tel:+49%20351%207958019233>
>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>>>> Email: [email protected]
>>>> <mailto:[email protected]>
>>>>
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>
>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>> <tel:+49%207732%209815100>*
>>>> [email protected]
>>>> <mailto:[email protected]>
>>>> 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 <tel:+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
>> Email: [email protected]
>> <mailto:[email protected]>
>>
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>> www.abexstandard.org <http://www.abexstandard.org>
>>
>> *Support Telefon: +49 (0) 7732 9815 100
>> <tel:+49%207732%209815100>*
>> [email protected]
>> <mailto:[email protected]>
>> 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]
>> <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
> --
>
> --
>
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233 <tel:+49%20351%207958019233>
> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
> Email: [email protected]
> <mailto:[email protected]>
>
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
> www.konrad-technologies.de <http://www.konrad-technologies.de>
> www.abexstandard.org <http://www.abexstandard.org>
>
> *Support Telefon: +49 (0) 7732 9815 100 <tel:+49%207732%209815100>*
> [email protected] <mailto:[email protected]>
> 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
Fax: +49 (0) 351 7958019 232
Email: [email protected]
<mailto:[email protected]>
*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
www.konrad-technologies.de <http://www.konrad-technologies.de>
www.abexstandard.org <http://www.abexstandard.org>
*Support Telefon: +49 (0) 7732 9815 100*
[email protected] <mailto:[email protected]>
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/20170424/bb850218/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/bb850218/attachment-0006.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/bb850218/attachment-0007.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/bb850218/attachment-0008.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/bb850218/attachment-0009.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/bb850218/attachment-0010.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/bb850218/attachment-0011.jpe>
-------------- 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/20170424/bb850218/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/bb850218/attachment-0001.asc>
------------------------------
Message: 6
Date: Mon, 24 Apr 2017 14:58:16 +0530
From: Jahnavendra Mattipa <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] Receiving power issue
Message-ID:
<CAH5NE-Z2=y+A3guoVFVqASYVmHnGFf5ez=6vstttknyr-b+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I am using the sampling rate for my experiment is 5M s/s. When i tried
to change the sampling rate from 5M s/s to 10M s/s, the receiving power
also changing. Can anybody familiar about this please explain me "why the
power is changing for changing the sampling rate?". If anyone has advices
and comments, they would be greatly appreciated.
Best Regards,
M.Jahnavendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/27558740/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 24 Apr 2017 11:43:30 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Receiving power issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
You change the observed bandwidth. So, the observed power might change,
too.
Also, don't forget that the Ettus USRPs are not calibrated measurement
equipment. You have to do a power calibration at each
frequency/gain/filter/sampling rate/master clock rate combination you
want to use, if you want to use the USRP as power measurement
Best regards,
Marcus
On 04/24/2017 11:28 AM, Jahnavendra Mattipa via USRP-users wrote:
> Hello all,
> I am using the sampling rate for my experiment is 5M s/s. When i
> tried to change the sampling rate from 5M s/s to 10M s/s, the
> receiving power also changing. Can anybody familiar about this please
> explain me "why the power is changing for changing the sampling
> rate?". If anyone has advices and comments, they would be greatly
> appreciated.
>
> Best Regards,
> M.Jahnavendra
>
>
> _______________________________________________
> 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/20170424/70cadf7f/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 24 Apr 2017 14:11:21 +0200
From: Nicolas Cuervo <[email protected]>
To: Nikita Airee <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID:
<caoupcvjpeutiojpo3otrnshjvbvr-wtz9r_vmhrmjww9+gx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Nikita,
This means that the x300 device and the n210 device have both the same IP
address. You can verify this by running the uhd_usrp_probe for both of them
specifying the device type:
$ uhd_usrp_probe --args="type=x300"
and the same for the n210 device. This is not unexpected, as the 192.168.10.3
is the default address that is burned into this devices. You can either
change the IP address of one of them [1][2] or refer to each device by its
type, its serial number or a name of your choice (that you can give to the
device).
Regards,
-Nicolas
[1] https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
// N210
[2]
https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network_multidevs
// X310
On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users <
[email protected]> wrote:
> Hello everyone!
>
> I have an x300 and an n210 that I would like to use in MIMO configuration.
> Before, I had been working with 2 x300 which I daisy chained into a
> multiusrp device.
> However, doing the same for these 2 different usrps throws up the
> following error:
>
> Device discovery error: ValueError: Could not resolve device hint
> "addr=192.168.10.3" to a single device.
>
> Could you please tell me if this is expected behaviour and if not what
> steps should I take to correct it?
>
> Bests,
> Nikita
>
> _______________________________________________
> 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/20170424/b47f0249/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 24 Apr 2017 17:47:49 +0530
From: Nikita Airee <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID:
<CAOT=stnewst74mfjjqz22k_asszv5hoemntf-lq9vmf7ylk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nicholas, thanks for your suggestions.
I did check the addresses of the two usrps but they are not the same. I am
also able to separately ping them.
So I think that that is not really the problem.
On Apr 24, 2017 5:41 PM, "Nicolas Cuervo" <[email protected]> wrote:
> Hello Nikita,
>
> This means that the x300 device and the n210 device have both the same IP
> address. You can verify this by running the uhd_usrp_probe for both of them
> specifying the device type:
>
> $ uhd_usrp_probe --args="type=x300"
>
> and the same for the n210 device. This is not unexpected, as the 192.168.10.3
> is the default address that is burned into this devices. You can either
> change the IP address of one of them [1][2] or refer to each device by its
> type, its serial number or a name of your choice (that you can give to the
> device).
>
> Regards,
> -Nicolas
>
> [1] https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
> // N210
> [2] https://files.ettus.com/manual/page_usrp_x3x0.html#
> x3x0_setup_network_multidevs // X310
>
> On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users <
> [email protected]> wrote:
>
>> Hello everyone!
>>
>> I have an x300 and an n210 that I would like to use in MIMO
>> configuration. Before, I had been working with 2 x300 which I daisy chained
>> into a multiusrp device.
>> However, doing the same for these 2 different usrps throws up the
>> following error:
>>
>> Device discovery error: ValueError: Could not resolve device hint
>> "addr=192.168.10.3" to a single device.
>>
>> Could you please tell me if this is expected behaviour and if not what
>> steps should I take to correct it?
>>
>> Bests,
>> Nikita
>>
>> _______________________________________________
>> 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/20170424/88850693/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 24 Apr 2017 14:23:17 +0200
From: Nicolas Cuervo <[email protected]>
To: Nikita Airee <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID:
<CAOuPCvgNyFuzXAC+V5RxsuM-Gh-hxXMgtaJf==xvz0qqh8v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Nikita,
Before I check a way to reproduce your issue, a couple of questions as
sanity check:
1. Are you using GNURadio to set up your application?
2. If the answer to (1) is 'yes', how are you setting the multiple access
to the devices? By setting up only one UHD source/sink block and then
setting multiple motherboards in its settings? or with two different UHD:
usrp source/sink's? If the latter is the true one, are you setting
different arguments to refer to each device? (being in this case the device
addr)
Regards,
-N
On Mon, Apr 24, 2017 at 2:17 PM, Nikita Airee <[email protected]> wrote:
> Hi Nicholas, thanks for your suggestions.
>
> I did check the addresses of the two usrps but they are not the same. I am
> also able to separately ping them.
> So I think that that is not really the problem.
>
> On Apr 24, 2017 5:41 PM, "Nicolas Cuervo" <[email protected]>
> wrote:
>
>> Hello Nikita,
>>
>> This means that the x300 device and the n210 device have both the same IP
>> address. You can verify this by running the uhd_usrp_probe for both of them
>> specifying the device type:
>>
>> $ uhd_usrp_probe --args="type=x300"
>>
>> and the same for the n210 device. This is not unexpected, as the 192.168.10.3
>> is the default address that is burned into this devices. You can either
>> change the IP address of one of them [1][2] or refer to each device by its
>> type, its serial number or a name of your choice (that you can give to the
>> device).
>>
>> Regards,
>> -Nicolas
>>
>> [1] https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
>> // N210
>> [2] https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_
>> setup_network_multidevs // X310
>>
>> On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello everyone!
>>>
>>> I have an x300 and an n210 that I would like to use in MIMO
>>> configuration. Before, I had been working with 2 x300 which I daisy chained
>>> into a multiusrp device.
>>> However, doing the same for these 2 different usrps throws up the
>>> following error:
>>>
>>> Device discovery error: ValueError: Could not resolve device hint
>>> "addr=192.168.10.3" to a single device.
>>>
>>> Could you please tell me if this is expected behaviour and if not what
>>> steps should I take to correct it?
>>>
>>> Bests,
>>> Nikita
>>>
>>> _______________________________________________
>>> 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/20170424/c8c06941/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 24 Apr 2017 18:04:33 +0530
From: Nikita Airee <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID:
<CAOT=ST=OEoObNnpp5F2-=gX-fs3yKA+aw4cN6x3TC0bC=7=2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Apr 24, 2017 5:53 PM, "Nicolas Cuervo" <[email protected]> wrote:
Hello Nikita,
Before I check a way to reproduce your issue, a couple of questions as
sanity check:
1. Are you using GNURadio to set up your application?
No, I setup the blocks in gnuradio and then modify the python file so that
the n210 takes pps and ref from the x300. I also set a common time/freq for
the 2 usrps using timed commands. Btw, this works without glitches when
both are x300s.
2. If the answer to (1) is 'yes', how are you setting the multiple access
to the devices? By setting up only one UHD source/sink block and then
setting multiple motherboards in its settings? or with two different UHD:
usrp source/sink's? If the latter is the true one, are you setting
different arguments to refer to each device? (being in this case the device
addr
I do have one usrp sink with 2 motherboards and 2 channels in grc file I
initially use. The device address is addr0=<x300addr>,addr1=<n210addr>.
Regards,
-N
On Mon, Apr 24, 2017 at 2:17 PM, Nikita Airee <[email protected]> wrote:
> Hi Nicholas, thanks for your suggestions.
>
> I did check the addresses of the two usrps but they are not the same. I am
> also able to separately ping them.
> So I think that that is not really the problem.
>
> On Apr 24, 2017 5:41 PM, "Nicolas Cuervo" <[email protected]>
> wrote:
>
>> Hello Nikita,
>>
>> This means that the x300 device and the n210 device have both the same IP
>> address. You can verify this by running the uhd_usrp_probe for both of them
>> specifying the device type:
>>
>> $ uhd_usrp_probe --args="type=x300"
>>
>> and the same for the n210 device. This is not unexpected, as the 192.168.10.3
>> is the default address that is burned into this devices. You can either
>> change the IP address of one of them [1][2] or refer to each device by its
>> type, its serial number or a name of your choice (that you can give to the
>> device).
>>
>> Regards,
>> -Nicolas
>>
>> [1] https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
>> // N210
>> [2] https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setu
>> p_network_multidevs // X310
>>
>> On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users <
>> [email protected]> wrote:
>>
>>> Hello everyone!
>>>
>>> I have an x300 and an n210 that I would like to use in MIMO
>>> configuration. Before, I had been working with 2 x300 which I daisy chained
>>> into a multiusrp device.
>>> However, doing the same for these 2 different usrps throws up the
>>> following error:
>>>
>>> Device discovery error: ValueError: Could not resolve device hint
>>> "addr=192.168.10.3" to a single device.
>>>
>>> Could you please tell me if this is expected behaviour and if not what
>>> steps should I take to correct it?
>>>
>>> Bests,
>>> Nikita
>>>
>>> _______________________________________________
>>> 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/20170424/b1c9f61c/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 24 Apr 2017 14:53:01 +0200
From: Nicolas Cuervo <[email protected]>
To: Nikita Airee <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID:
<CAOuPCvg==wc2p1bghg03mjrpue4notf93j8rms+riff4o9b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Nikita,
Thanks for your answer. I think it contains the root of your problem. By
referencing the multi_usrp manual [1]:
"""
Some USRP devices are capable of being grouped to form a single, virtual
device. A single uhd::usrp::multi_usrp
<https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html>
instantiation
can control such a compound of devices.
Currently, the following devices support this capability:
- USRP2 / N2x0 Series
- X3x0 Series
*Note that only USRPs of the same type can be combined.*
"""
As you are setting only one sink block with 2 motherboards, you are forcing
it to be a mult_usrp object, and that is not set to work when the devices
involved have different types. This would also explain why your setup was
working without any problems when only usrps type X310 were involved.
[1] https://files.ettus.com/manual/page_multiple.html
On Mon, Apr 24, 2017 at 2:34 PM, Nikita Airee <[email protected]> wrote:
>
>
> On Apr 24, 2017 5:53 PM, "Nicolas Cuervo" <[email protected]>
> wrote:
>
> Hello Nikita,
>
> Before I check a way to reproduce your issue, a couple of questions as
> sanity check:
>
> 1. Are you using GNURadio to set up your application?
>
> No, I setup the blocks in gnuradio and then modify the python file so that
> the n210 takes pps and ref from the x300. I also set a common time/freq for
> the 2 usrps using timed commands. Btw, this works without glitches when
> both are x300s.
>
> 2. If the answer to (1) is 'yes', how are you setting the multiple access
> to the devices? By setting up only one UHD source/sink block and then
> setting multiple motherboards in its settings? or with two different UHD:
> usrp source/sink's? If the latter is the true one, are you setting
> different arguments to refer to each device? (being in this case the device
> addr
>
> I do have one usrp sink with 2 motherboards and 2 channels in grc file I
> initially use. The device address is addr0=<x300addr>,addr1=<n210addr>.
>
>
> Regards,
> -N
>
> On Mon, Apr 24, 2017 at 2:17 PM, Nikita Airee <[email protected]>
> wrote:
>
>> Hi Nicholas, thanks for your suggestions.
>>
>> I did check the addresses of the two usrps but they are not the same. I
>> am also able to separately ping them.
>> So I think that that is not really the problem.
>>
>> On Apr 24, 2017 5:41 PM, "Nicolas Cuervo" <[email protected]>
>> wrote:
>>
>>> Hello Nikita,
>>>
>>> This means that the x300 device and the n210 device have both the same
>>> IP address. You can verify this by running the uhd_usrp_probe for both of
>>> them specifying the device type:
>>>
>>> $ uhd_usrp_probe --args="type=x300"
>>>
>>> and the same for the n210 device. This is not unexpected, as the
>>> 192.168.10.3
>>> is the default address that is burned into this devices. You can either
>>> change the IP address of one of them [1][2] or refer to each device by its
>>> type, its serial number or a name of your choice (that you can give to the
>>> device).
>>>
>>> Regards,
>>> -Nicolas
>>>
>>> [1] https://files.ettus.com/manual/page_usrp2.html#usrp2_net
>>> work_multidev // N210
>>> [2] https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setu
>>> p_network_multidevs // X310
>>>
>>> On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hello everyone!
>>>>
>>>> I have an x300 and an n210 that I would like to use in MIMO
>>>> configuration. Before, I had been working with 2 x300 which I daisy chained
>>>> into a multiusrp device.
>>>> However, doing the same for these 2 different usrps throws up the
>>>> following error:
>>>>
>>>> Device discovery error: ValueError: Could not resolve device hint
>>>> "addr=192.168.10.3" to a single device.
>>>>
>>>> Could you please tell me if this is expected behaviour and if not what
>>>> steps should I take to correct it?
>>>>
>>>> Bests,
>>>> Nikita
>>>>
>>>> _______________________________________________
>>>> 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/20170424/8ed82c09/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 24 Apr 2017 11:48:07 +0000
From: Anders Charly Rasmussen <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Mathias R?nholt Kielgast <[email protected]>
Subject: [USRP-users] Dynamic range of DAC
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello USRP mailing list
We are trying to add baseband signals with varying signal power on a PC and
then transmitting the combined signal using a B210 board.
We would like to know what the dynamic range of the DAC is, so that we can
determine a maximum difference in power between several different signals.
We have so far been unable to find any information about this, so any help as
to what it is or where we can find more info is greatly appreciated!
BR Anders
------------------------------
Message: 14
Date: Mon, 24 Apr 2017 09:16:22 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 04/24/2017 08:11 AM, Nicolas Cuervo via USRP-users wrote:
> Hello Nikita,
>
> This means that the x300 device and the n210 device have both the same
> IP address. You can verify this by running the uhd_usrp_probe for both
> of them specifying the device type:
>
> $ uhd_usrp_probe --args="type=x300"
>
> and the same for the n210 device. This is not unexpected, as the
> 192.168.10.3 is the default address that is burned into this devices.
> You can either change the IP address of one of them [1][2] or refer to
> each device by its type, its serial number or a name of your choice
> (that you can give to the device).
>
> Regards,
> -Nicolas
> [1]
> https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
> // N210
> [2]
> https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network_multidevs
>
> // X310
>
> On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hello everyone!
>
> I have an x300 and an n210 that I would like to use in MIMO
> configuration. Before, I had been working with 2 x300 which I
> daisy chained into a multiusrp device.
> However, doing the same for these 2 different usrps throws up the
> following error:
>
> Device discovery error: ValueError: Could not resolve device
> hint "addr=192.168.10.3" to a single device.
>
> Could you please tell me if this is expected behaviour and if not
> what steps should I take to correct it?
>
> Bests,
> Nikita
>
The TCP/IP stack *requires* that devices have unique addresses, so
you'll have to change the address of one of those devices.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/9508d12e/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 24 Apr 2017 19:28:47 +0530
From: Nikita Airee <[email protected]>
To: "Marcus D. Leech" <[email protected]>, Nicolas Cuervo
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID:
<CAOT=STm+sCrGRGS+VNN0_S0u4Q7Fyb+w3HXA_F=qp_nvb-n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus my initial mail might not have been very clear but both the devices
have different addresses.
As Nicolas so helpfully pointed out the little detail, it is not possible
to create a multiusrp device out of dissimilar usrps, I would like to know
if using different usrp sinks could help me in this situation if I want to
create a mimo system?
On Apr 24, 2017 6:47 PM, "Marcus D. Leech via USRP-users" <
[email protected]> wrote:
On 04/24/2017 08:11 AM, Nicolas Cuervo via USRP-users wrote:
Hello Nikita,
This means that the x300 device and the n210 device have both the same IP
address. You can verify this by running the uhd_usrp_probe for both of them
specifying the device type:
$ uhd_usrp_probe --args="type=x300"
and the same for the n210 device. This is not unexpected, as the 192.168.10.3
is the default address that is burned into this devices. You can either
change the IP address of one of them [1][2] or refer to each device by its
type, its serial number or a name of your choice (that you can give to the
device).
Regards,
-Nicolas
[1] https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
// N210
[2] https://files.ettus.com/manual/page_usrp_x3x0.html#
x3x0_setup_network_multidevs // X310
On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users <
[email protected]> wrote:
> Hello everyone!
>
> I have an x300 and an n210 that I would like to use in MIMO configuration.
> Before, I had been working with 2 x300 which I daisy chained into a
> multiusrp device.
> However, doing the same for these 2 different usrps throws up the
> following error:
>
> Device discovery error: ValueError: Could not resolve device hint
> "addr=192.168.10.3" to a single device.
>
> Could you please tell me if this is expected behaviour and if not what
> steps should I take to correct it?
>
> Bests,
> Nikita
>
> The TCP/IP stack *requires* that devices have unique addresses, so you'll
have to change the address of one of those devices.
_______________________________________________
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/20170424/1eb5e07b/attachment-0001.html>
------------------------------
Message: 16
Date: Mon, 24 Apr 2017 10:07:24 -0400
From: [email protected]
To: Nikita Airee <[email protected]>
Cc: Nicolas Cuervo <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] multiuser device using x300 and n210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
You would need to do synchronization setup yourself, by editing the code
generated by GRC, as you have already done.
You'd need to arrange for both devices to agree on a time-of-day,
probably via set_time_next_pps() on both, and then commence streaming at
the same time on both.
The ideal situation is to have a shared synchronization source, rather
than daisy-chaining out of the REF and PPS ports on the X310, since
there isn't full support for that in the FPGA on the X310.
On 2017-04-24 09:58, Nikita Airee wrote:
> Marcus my initial mail might not have been very clear but both the devices
> have different addresses.
> As Nicolas so helpfully pointed out the little detail, it is not possible to
> create a multiusrp device out of dissimilar usrps, I would like to know if
> using different usrp sinks could help me in this situation if I want to
> create a mimo system?
>
> On Apr 24, 2017 6:47 PM, "Marcus D. Leech via USRP-users"
> <[email protected]> wrote:
>
> On 04/24/2017 08:11 AM, Nicolas Cuervo via USRP-users wrote:
> Hello Nikita,
>
> This means that the x300 device and the n210 device have both the same IP
> address. You can verify this by running the uhd_usrp_probe for both of them
> specifying the device type:
>
> $ uhd_usrp_probe --args="type=x300"
>
> and the same for the n210 device. This is not unexpected, as the 192.168.10.3
> is the default address that is burned into this devices. You can either
> change the IP address of one of them [1][2] or refer to each device by its
> type, its serial number or a name of your choice (that you can give to the
> device).
>
> Regards,
> -Nicolas
>
> [1] https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev [1]
> // N210
> [2]
> https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network_multidevs
> [2] // X310
>
> On Mon, Apr 24, 2017 at 8:18 AM, Nikita Airee via USRP-users
> <[email protected]> wrote:
>
> Hello everyone!
>
> I have an x300 and an n210 that I would like to use in MIMO configuration.
> Before, I had been working with 2 x300 which I daisy chained into a multiusrp
> device.
> However, doing the same for these 2 different usrps throws up the following
> error:
>
> Device discovery error: ValueError: Could not resolve device hint
> "addr=192.168.10.3" to a single device.
>
> Could you please tell me if this is expected behaviour and if not what steps
> should I take to correct it?
>
> Bests,
> Nikita
The TCP/IP stack *requires* that devices have unique addresses, so
you'll have to change the address of one of those devices.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [3]
Links:
------
[1]
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
[2]
https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network_multidevs
[3] 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/20170424/6f388a5c/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 24 Apr 2017 07:35:01 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Announcing NEWSDR at Tufts University on Thr/Fri
June 1/2
Message-ID:
<cacaxmv93texe_sddahprasaqo0uowmjs8q-re+qym2zjyjj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*********************************************************************
CALL-FOR-PARTICIPATION
*********************************************************************
NEWSDR 2017
New England Workshop on Software Defined Radio
Seventh-Annual
Evening Workshops
Thursday June 1
17:30 to 21:00
Day-Long Symposium
Friday June 2
08:00 to 16:00
Tufts University
Medford, MA, USA
http://www.sdr-boston.org/
Free Pre-Registration
Poster Submissions and Pre-Registrations
Accepted Until Friday May 12
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2017 New England Workshop on
Software Defined Radio (NEWSDR 2017), which is the seventh installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).
This year, NEWSDR will be held at Tufts University, and consists of
a day-long symposium on Friday, as well as several hands-on technical
workshops the evening before on Thursday. You are welcome to attend
either or both events, which are entirely free when pre-registering.
Attendance is typically about 100 people, and attendees are evenly
split between academia and industry.
*********************************************************************
EVENING WORKSHOPS
THURSDAY JUNE 1
17:00 to 21:00
Tufts University
Medford, Massachusetts
AGENDA
16:00 ? 17:30 Setup session for the Workshop Events (optional)
17:30 ? 21:00 Workshop Events
Two hands-on technical workshops are being offered in parallel:
* "SDR Using USRP E310 and Simulink"
by MathWorks
* "FPGA Programming on the USRP with the RFNoC Framework"
by Ettus Research
MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops is listed below. Attendance is free, but
pre-registration is required. Free pizza and soda will be provided.
*********************************************************************
DAY-LONG SYMPOSIUM
FRIDAY JUNE 2
08:00 to 16:00
Breed Memorial Hall
Tufts University
51 Winthrop Street
Medford, Massachusetts
AGENDA
07:30 to 08:00 Coffee and Light Refreshments
08:00 to 08:15 Welcome and Introduction
08:15 to 09:40 Sponsor Overview Presentations (20 minutes each)
09:40 to 10:15 Elevator-Pitch Oral Presentations
of Poster Presenters (2 minutes each)
10:15 to 10:45 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos
10:45 to 11:45 Industry Tutorial Presentation by MediaTek:
"Prototyping Next Generation Wireless Devices"
11:45 to 13:00 Lunch and Attendee Networking
13:00 to 14:00 Keynote Presentation by Professor Dennis Roberson
14:00 to 14:30 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos
14:30 to 15:30 Industry Tutorial Presentation by Analog Devices:
"ADALM-PLUTO SDR Prototyping with Matlab"
15:30 to 16:00 Closing Remarks, Best Poster Award, Announcements
Keynote Speaker:
* Professor Dennis Roberson, Illinois Institute of Technology
Technical Poster Presentations:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
Corporate Sponsors:
* Analog Devices
* Ettus Research
* MathWorks
* MediaTek Wireless
The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.
The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.
*********************************************************************
WORKSHOP DESCRIPTION
SDR with E310 using Simulink
MathWorks
This tutorial focuses on demonstrating modeling SDR-based designs in
MATLAB and Simulink, and configuring and deploying on the USRP E310.
Topics presented will include modeling communication systems using
Simulink, implementing radio I/O with E310 and Simulink, and
prototyping deployment with real-time data via HW/SW co-design.
Prior knowledge of programming Xilinx Zynq SoCs with MATLAB and
Simulink, and knowledge of communications systems and hardware design
are prerequisites.
Outline:
Model Communication system using Simulink:
* Model and simulate RF signal chain and communication algorithms.
* Overview of Software Defined Radio concepts and workflows.
* Simulate a communication system that includes a transmitter,
AD9361 transceiver, channel, and receiver (RF test environment).
Implement Radio I/O with E310 SDR and Simulink:
* Verify the operation of baseband transceiver algorithm using real
data streamed from the AD9361 into MATLAB and Simulink.
* Overview of System objects and hardware platforms.
* Perform baseband processing in MATLAB and Simulink on received
signal.
* Verify algorithm performance for real data versus simulated data.
Hardware-Software Co-Design for Software:
* Split and deploy Tx/Rx algorithms to PL and PS.
* Overview of Zynq HW/SW co-design workflow.
* Implement transmitter and receiver on PL/PS using HW/SW co-design
workflow.
* Download generated code to the ARM & FPGA, and tune system
parameters in real-time operation via Simulink.
*********************************************************************
WORKSHOP DESCRIPTION
FPGA Programming on the USRP with the RFNoC Framework
Ettus Research
Ettus Research's RFNoC (RF Network-on-Chip) software is meant
to decrease the development time for experienced FPGA engineers
seeking to integrate IP into the USRP signal processing chain.
RFNoC is the architecture for USRP devices that use Xilinx 7-series
FPGAs (E310, E312, X300, X310). RFNoC is built around a packetized
network infrastructure in the FPGA that handles the transport of
control and sample data between the host CPU and the radio. Users
target their custom algorithms to the FPGA in the form of
Computation Engines (CE), which are processing blocks that attach to
this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU). Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, including a
discussion on its design and capabilities, demonstrations of several
existing examples, and a walk-through on implementing a user-defined
CE and integrating the CE into GNU Radio.
Prerequisites:
* Attendees are expected to bring their own laptops to the workshop.
The laptop should have a minimum of 4 GB memory, 60 GB of free disk
space, one Ethernet port available, and one USB 3.0 port available.
* Attendees are expected to install VirtualBox 5.1.18 or newer.
All necessary USRP hardware will be provided in the workshop.
Attendees do not need to bring any USRP hardware.
*********************************************************************
REGISTRATION
* Pre-register for the Symposium, or for the Workshop, or both
* Pre-registration is required, but is completely free
* Pre-registration takes less than 5 minutes
* Pre-registration includes free meals at the event
* Parking available
* You must pre-register online
* Attendance, meals, parking are all limited, so please
pre-register online as soon as possible to secure your spot
* Pre-registration deadline is Friday May 12
* See link at the bottom of this announcement to pre-register online
*********************************************************************
LINKS
Attendee Pre-registration:
https://goo.gl/Oy99HU
Poster Abstract Submission:
https://goo.gl/pJohKn
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170424/f7d44245/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 80, Issue 24
******************************************
