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 Fax: +49 (0) 351 7958019 232 Email: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

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 > Fax: +49 (0) 351 7958019 232 > Email: dominik.eyerly@konrad-technologies.de > > KONRAD GMBH — FRITZ-REICHLE-RING 12 — D-78315 RADOLFZELL > www.konrad-technologies.de [1] > www.abexstandard.org [2] > > SUPPORT TELEFON: +49 (0) 7732 9815 100 > support@konrad-technologies.de > > 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@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com Links: ------ [1] http://www.konrad-technologies.de [2] http://www.abexstandard.org

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. (2) The ramp up behavior that is only present when transmitting during an active acquisition. 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? cheers, Dominik On 04/04/2017 04:54 PM, mleech@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 >> Fax: +49 (0) 351 7958019 232 >> Email: dominik.eyerly@konrad-technologies.de >> <mailto:dominik.eyerly@konrad-technologies.de> >> >> *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* >> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >> 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@lists.ettus.com <mailto: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 Fax: +49 (0) 351 7958019 232 Email: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

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@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 >>> Fax: +49 (0) 351 7958019 232 >>> Email:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> >>> >>> *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* >>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>> 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@lists.ettus.com <mailto: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 > Fax: +49 (0) 351 7958019 232 > Email:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> > > *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* > support@konrad-technologies.de <mailto:support@konrad-technologies.de> > 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.

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 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@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 >>>> Fax: +49 (0) 351 7958019 232 >>>> Email: dominik.eyerly@konrad-technologies.de >>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>> >>>> *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* >>>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>>> 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@lists.ettus.com <mailto: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 >> Fax: +49 (0) 351 7958019 232 >> Email: dominik.eyerly@konrad-technologies.de >> <mailto:dominik.eyerly@konrad-technologies.de> >> >> *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* >> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >> 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: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

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@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 >>>>> Fax: +49 (0) 351 7958019 232 >>>>> Email:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> >>>>> >>>>> *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* >>>>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>>>> 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@lists.ettus.com >>>>> <mailto: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 >>> Fax: +49 (0) 351 7958019 232 >>> Email:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> >>> >>> *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* >>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>> 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:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> > > *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* > support@konrad-technologies.de <mailto:support@konrad-technologies.de> > 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'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 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@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 >>>>>> Fax: +49 (0) 351 7958019 232 >>>>>> Email: dominik.eyerly@konrad-technologies.de >>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>> >>>>>> *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* >>>>>> support@konrad-technologies.de >>>>>> <mailto:support@konrad-technologies.de> >>>>>> 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@lists.ettus.com >>>>>> <mailto: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 >>>> Fax: +49 (0) 351 7958019 232 >>>> Email: dominik.eyerly@konrad-technologies.de >>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>> >>>> *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* >>>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>>> 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: dominik.eyerly@konrad-technologies.de >> <mailto:dominik.eyerly@konrad-technologies.de> >> >> *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* >> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >> 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: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

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@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 >>>>>>> Fax: +49 (0) 351 7958019 232 >>>>>>> Email:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>> >>>>>>> *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* >>>>>>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>>>>>> 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@lists.ettus.com >>>>>>> <mailto: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 >>>>> Fax: +49 (0) 351 7958019 232 >>>>> Email:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> >>>>> >>>>> *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* >>>>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>>>> 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:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> >>> >>> *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* >>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>> 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:dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> > > *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* > support@konrad-technologies.de <mailto:support@konrad-technologies.de> > 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.

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@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 >>>>>>>> Fax: +49 (0) 351 7958019 232 >>>>>>>> Email: dominik.eyerly@konrad-technologies.de >>>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>>> >>>>>>>> *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* >>>>>>>> support@konrad-technologies.de >>>>>>>> <mailto:support@konrad-technologies.de> >>>>>>>> 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@lists.ettus.com >>>>>>>> <mailto: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 >>>>>> Fax: +49 (0) 351 7958019 232 >>>>>> Email: dominik.eyerly@konrad-technologies.de >>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>> >>>>>> *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* >>>>>> support@konrad-technologies.de >>>>>> <mailto:support@konrad-technologies.de> >>>>>> 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: dominik.eyerly@konrad-technologies.de >>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>> >>>> *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* >>>> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >>>> 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: dominik.eyerly@konrad-technologies.de >> <mailto:dominik.eyerly@konrad-technologies.de> >> >> *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* >> support@konrad-technologies.de <mailto:support@konrad-technologies.de> >> 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: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

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@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@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@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@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@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@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@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@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@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@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@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 > Email: dominik.eyerly@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@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@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >

 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, mleech@ripnet.com
 <mailto:mleech@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 <tel:+49%20351%207958019233>
 Fax:     +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
 Email:   dominik.eyerly@konrad-technologies.de
 <mailto:dominik.eyerly@konrad-technologies.de>

 *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>*
 support@konrad-technologies.de
 <mailto:support@konrad-technologies.de>
 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@lists.ettus.com
 <mailto:USRP-users@lists.ettus.com>
 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:   dominik.eyerly@konrad-technologies.de
 <mailto:dominik.eyerly@konrad-technologies.de>

 *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>*
 support@konrad-technologies.de
 <mailto:support@konrad-technologies.de>
 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:   dominik.eyerly@konrad-technologies.de
 <mailto:dominik.eyerly@konrad-technologies.de>

 *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>*
 support@konrad-technologies.de
 <mailto:support@konrad-technologies.de>
 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:   dominik.eyerly@konrad-technologies.de
 <mailto:dominik.eyerly@konrad-technologies.de>

 *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>*
 support@konrad-technologies.de
 <mailto:support@konrad-technologies.de>
 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
 Email:   dominik.eyerly@konrad-technologies.de
 <mailto:dominik.eyerly@konrad-technologies.de>

 *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>*
 support@konrad-technologies.de <mailto:support@konrad-technologies.de>
 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@lists.ettus.com
 <mailto:USRP-users@lists.ettus.com>
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> 

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@lists.ettus.com <mailto:usrp-users@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 >>>>>>> <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@ripnet.com >>>>>>> <mailto:mleech@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 <tel:+49%20351%207958019233> >>>>>>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232> >>>>>>>>> Email: dominik.eyerly@konrad-technologies.de >>>>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>>>> >>>>>>>>> *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>* >>>>>>>>> support@konrad-technologies.de >>>>>>>>> <mailto:support@konrad-technologies.de> >>>>>>>>> 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@lists.ettus.com >>>>>>>>> <mailto:USRP-users@lists.ettus.com> >>>>>>>>> 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: dominik.eyerly@konrad-technologies.de >>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>> >>>>>>> *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>* >>>>>>> support@konrad-technologies.de >>>>>>> <mailto:support@konrad-technologies.de> >>>>>>> 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: dominik.eyerly@konrad-technologies.de >>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>> >>>>> *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>* >>>>> support@konrad-technologies.de >>>>> <mailto:support@konrad-technologies.de> >>>>> 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: dominik.eyerly@konrad-technologies.de >>> <mailto:dominik.eyerly@konrad-technologies.de> >>> >>> *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>* >>> support@konrad-technologies.de >>> <mailto:support@konrad-technologies.de> >>> 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 > Email: dominik.eyerly@konrad-technologies.de > <mailto:dominik.eyerly@konrad-technologies.de> > > *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>* > support@konrad-technologies.de <mailto:support@konrad-technologies.de> > 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@lists.ettus.com > <mailto:USRP-users@lists.ettus.com> > 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 Fax: +49 (0) 351 7958019 232 Email: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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. > >

 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@lists.ettus.com <mailto:usrp-users@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
     <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@ripnet.com
     <mailto:mleech@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 <tel:+49%20351%207958019233>
     Fax:     +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
     Email:   dominik.eyerly@konrad-technologies.de
     <mailto:dominik.eyerly@konrad-technologies.de>

     *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>*
     support@konrad-technologies.de
     <mailto:support@konrad-technologies.de>
     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@lists.ettus.com
     <mailto:USRP-users@lists.ettus.com>
     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:   dominik.eyerly@konrad-technologies.de
     <mailto:dominik.eyerly@konrad-technologies.de>

     *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>*
     support@konrad-technologies.de
     <mailto:support@konrad-technologies.de>
     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:   dominik.eyerly@konrad-technologies.de
     <mailto:dominik.eyerly@konrad-technologies.de>

     *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>*
     support@konrad-technologies.de
     <mailto:support@konrad-technologies.de>
     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:   dominik.eyerly@konrad-technologies.de
     <mailto:dominik.eyerly@konrad-technologies.de>

     *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>*
     support@konrad-technologies.de
     <mailto:support@konrad-technologies.de>
     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:   dominik.eyerly@konrad-technologies.de
     <mailto:dominik.eyerly@konrad-technologies.de>

     *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>*
     support@konrad-technologies.de
     <mailto:support@konrad-technologies.de>
     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@lists.ettus.com
     <mailto:USRP-users@lists.ettus.com>
     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:   dominik.eyerly@konrad-technologies.de
 <mailto:dominik.eyerly@konrad-technologies.de>

 *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>*
 support@konrad-technologies.de <mailto:support@konrad-technologies.de>
 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.

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@konrad-technologies.de > <mailto:d.eyerly@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@lists.ettus.com <mailto:usrp-users@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 >>>>>>>> <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@ripnet.com >>>>>>>> <mailto:mleech@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 <tel:+49%20351%207958019233> >>>>>>>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232> >>>>>>>>>> Email: dominik.eyerly@konrad-technologies.de >>>>>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>>>>> >>>>>>>>>> *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>* >>>>>>>>>> support@konrad-technologies.de >>>>>>>>>> <mailto:support@konrad-technologies.de> >>>>>>>>>> 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@lists.ettus.com >>>>>>>>>> <mailto:USRP-users@lists.ettus.com> >>>>>>>>>> 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: dominik.eyerly@konrad-technologies.de >>>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>>> >>>>>>>> *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>* >>>>>>>> support@konrad-technologies.de >>>>>>>> <mailto:support@konrad-technologies.de> >>>>>>>> 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: dominik.eyerly@konrad-technologies.de >>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>> >>>>>> *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>* >>>>>> support@konrad-technologies.de >>>>>> <mailto:support@konrad-technologies.de> >>>>>> 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: dominik.eyerly@konrad-technologies.de >>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>> >>>> *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>* >>>> support@konrad-technologies.de >>>> <mailto:support@konrad-technologies.de> >>>> 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: dominik.eyerly@konrad-technologies.de >> <mailto:dominik.eyerly@konrad-technologies.de> >> >> *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>* >> support@konrad-technologies.de >> <mailto:support@konrad-technologies.de> >> 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@lists.ettus.com >> <mailto:USRP-users@lists.ettus.com> >> 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: dominik.eyerly@konrad-technologies.de > <mailto:dominik.eyerly@konrad-technologies.de> > > *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>* > support@konrad-technologies.de <mailto:support@konrad-technologies.de> > 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: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

Hi Dominik, To keep the PA on all the time on the B205mini, change STATE_OFF to TX_ENABLE1 on this line: https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L1178 I am still not convinced that is the main source of long ramp up in power. Some transient due to PA warm up is expected, but it is usually on the order of microseconds and not milliseconds. Regards, Michael On Mon, Apr 24, 2017 at 12:44 AM, Dominik Eyerly < d.eyerly@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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. > >

 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@konrad-technologies.de
 <mailto:d.eyerly@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@lists.ettus.com
     <mailto:usrp-users@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
         <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@ripnet.com
         <mailto:mleech@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 <tel:+49%20351%207958019233>
         Fax:     +49 (0) 351 7958019 232 <tel:+49%20351%207958019232>
         Email:   dominik.eyerly@konrad-technologies.de
         <mailto:dominik.eyerly@konrad-technologies.de>

         *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>*
         support@konrad-technologies.de
         <mailto:support@konrad-technologies.de>
         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@lists.ettus.com
         <mailto:USRP-users@lists.ettus.com>
         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:   dominik.eyerly@konrad-technologies.de
         <mailto:dominik.eyerly@konrad-technologies.de>

         *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>*
         support@konrad-technologies.de
         <mailto:support@konrad-technologies.de>
         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:   dominik.eyerly@konrad-technologies.de
         <mailto:dominik.eyerly@konrad-technologies.de>

         *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>*
         support@konrad-technologies.de
         <mailto:support@konrad-technologies.de>
         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:   dominik.eyerly@konrad-technologies.de
         <mailto:dominik.eyerly@konrad-technologies.de>

         *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>*
         support@konrad-technologies.de
         <mailto:support@konrad-technologies.de>
         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:   dominik.eyerly@konrad-technologies.de
         <mailto:dominik.eyerly@konrad-technologies.de>

         *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>*
         support@konrad-technologies.de
         <mailto:support@konrad-technologies.de>
         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@lists.ettus.com
         <mailto:USRP-users@lists.ettus.com>
         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:   dominik.eyerly@konrad-technologies.de
     <mailto:dominik.eyerly@konrad-technologies.de>

     *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>*
     support@konrad-technologies.de
     <mailto:support@konrad-technologies.de>
     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:   dominik.eyerly@konrad-technologies.de
 <mailto:dominik.eyerly@konrad-technologies.de>

 *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>*
 support@konrad-technologies.de <mailto:support@konrad-technologies.de>
 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.

Hi Michael, Unfortunately, this did not resolve the issue. It seemed to have no effect on the waveform. What else could be causing this behavior? Would you be able to test this on a board you have available to rule out the possibility that I have a bad batch? cheers, Dominik On 04/25/2017 08:25 PM, Michael West wrote: > Hi Dominik, > > To keep the PA on all the time on the B205mini, change STATE_OFF to > TX_ENABLE1 on this line: > https://github.com/EttusResearch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L1178 > > I am still not convinced that is the main source of long ramp up in > power. Some transient due to PA warm up is expected, but it is > usually on the order of microseconds and not milliseconds. > > Regards, > Michael > > On Mon, Apr 24, 2017 at 12:44 AM, Dominik Eyerly > <d.eyerly@konrad-technologies.de > <mailto:d.eyerly@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@konrad-technologies.de >> <mailto:d.eyerly@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@lists.ettus.com >>> <mailto:usrp-users@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 >>>>>>>>> <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@ripnet.com >>>>>>>>> <mailto:mleech@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 <tel:+49%20351%207958019233> >>>>>>>>>>> Fax: +49 (0) 351 7958019 232 <tel:+49%20351%207958019232> >>>>>>>>>>> Email: dominik.eyerly@konrad-technologies.de >>>>>>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>>>>>> >>>>>>>>>>> *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>* >>>>>>>>>>> support@konrad-technologies.de >>>>>>>>>>> <mailto:support@konrad-technologies.de> >>>>>>>>>>> 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@lists.ettus.com >>>>>>>>>>> <mailto:USRP-users@lists.ettus.com> >>>>>>>>>>> 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: dominik.eyerly@konrad-technologies.de >>>>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>>>> >>>>>>>>> *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>* >>>>>>>>> support@konrad-technologies.de >>>>>>>>> <mailto:support@konrad-technologies.de> >>>>>>>>> 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: dominik.eyerly@konrad-technologies.de >>>>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>>>> >>>>>>> *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>* >>>>>>> support@konrad-technologies.de >>>>>>> <mailto:support@konrad-technologies.de> >>>>>>> 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: dominik.eyerly@konrad-technologies.de >>>>> <mailto:dominik.eyerly@konrad-technologies.de> >>>>> >>>>> *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>* >>>>> support@konrad-technologies.de >>>>> <mailto:support@konrad-technologies.de> >>>>> 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: dominik.eyerly@konrad-technologies.de >>> <mailto:dominik.eyerly@konrad-technologies.de> >>> >>> *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>* >>> support@konrad-technologies.de >>> <mailto:support@konrad-technologies.de> >>> 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@lists.ettus.com >>> <mailto:USRP-users@lists.ettus.com> >>> 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: dominik.eyerly@konrad-technologies.de >> <mailto:dominik.eyerly@konrad-technologies.de> >> >> *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>* >> support@konrad-technologies.de >> <mailto:support@konrad-technologies.de> >> 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: dominik.eyerly@konrad-technologies.de > <mailto:dominik.eyerly@konrad-technologies.de> > > *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>* > support@konrad-technologies.de <mailto:support@konrad-technologies.de> > 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: dominik.eyerly@konrad-technologies.de <mailto:dominik.eyerly@konrad-technologies.de> *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* support@konrad-technologies.de <mailto:support@konrad-technologies.de> 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.

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@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@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/EttusResearch/uhd/blob/maint/ > host/lib/usrp/b200/b200_impl.cpp#L1178 > > I am still not convinced that is the main source of long ramp up in > power. Some transient due to PA warm up is expected, but it is usually on > the order of microseconds and not milliseconds. > > Regards, > Michael > > On Mon, Apr 24, 2017 at 12:44 AM, Dominik Eyerly < > d.eyerly@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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. > >

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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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. >> >> >

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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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. >>> >>> >> >