[USRP-users] B205i transient behavior

Michael West michael.west at ettus.com
Mon Oct 9 16:57:48 EDT 2017


As a further follow up, the final capacitor changes have been made and the
new rev C boards are being built.  The necessary capacitor changes on the
rev B boards are as follows:

C15, C23, C25, C26:  470 pF
C14, C17:  220 pF

Regards,
Michael


On Wed, May 24, 2017 at 11:07 AM, Michael West <michael.west at ettus.com>
wrote:

> To update anyone following this thread, the issue of the slow ramp on the
> TX has been root caused to a simple hardware issue.  The capacitors around
> the RF switches (C15, C17, C23, C25, and C26) were too large.  Reducing
> them from 100 uF to 470 pF resolved the issue.  To be clear, the issues is
> only seen when operating in full duplex on a B200mini/B205mini/B205mini-I.
> For anyone affected by the issue, please contact support at ettus.com to
> arrange an RMA for the rework.
>
> Many thanks to Dominik for staying on top of this issue!
>
> Regards,
> Michael
>
> On Mon, May 1, 2017 at 4:41 PM, Michael West <michael.west at ettus.com>
> wrote:
>
>> 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 support at ettus.com 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 <
>> d.eyerly at konrad-technologies.de> 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/EttusResear
>>> ch/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 <
>>> d.eyerly at konrad-technologies.de> 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 <
>>>> d.eyerly at konrad-technologies.de> 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 <
>>>>> usrp-users at lists.ettus.com> 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, mleech at ripnet.com 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:   dominik.eyerly at konrad-technologies.de
>>>>>> *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>*support at konrad-technologies.de[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 USRP-users at 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 <+49%20351%207958019233>
>>>>>> Fax:     +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>>>> Email:   dominik.eyerly at konrad-technologies.de
>>>>>> *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>*support at konrad-technologies.de[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:   dominik.eyerly at konrad-technologies.de
>>>>>> *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>*support at konrad-technologies.de[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:   dominik.eyerly at konrad-technologies.de
>>>>>> *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>*support at konrad-technologies.de[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:   dominik.eyerly at konrad-technologies.de
>>>>>> *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>*support at konrad-technologies.de[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 USRP-users at 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 <+49%20351%207958019233>
>>>>> Fax:     +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>>> Email:   dominik.eyerly at konrad-technologies.de
>>>>> *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>*support at konrad-technologies.de[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:   dominik.eyerly at konrad-technologies.de
>>>> *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>*support at konrad-technologies.de[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:   dominik.eyerly at konrad-technologies.de
>>> *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>*support at konrad-technologies.de[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/20171009/3a054875/attachment-0002.html>
-------------- 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/20171009/3a054875/attachment.png>
-------------- 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/20171009/3a054875/attachment.jpg>


More information about the USRP-users mailing list