Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. XML file for multiple output ports (Barker, Douglas W.)
2. USRP Source receiving incorrect number of samples
(Jessica Iwamoto)
3. Re: USRP Source receiving incorrect number of samples
(Marcus M?ller)
4. Re: B205i transient behavior (Michael West)
5. Re: USRP Source receiving incorrect number of samples
(Marcus M?ller)
6. Re: USRP Source receiving incorrect number of samples
(Jessica Iwamoto)
7. Re: ADC of B210 (Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Fri, 14 Apr 2017 17:25:25 +0000
From: "Barker, Douglas W." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] XML file for multiple output ports
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
How does one make the block descriptor XML file when the RFNoC block has
multiple outputs. Specifically, each output port has an associated set of
settings registers. How do you associated a group of settings registers with a
particular output port. There are no examples like this.
Thanks
Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/116704c3/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 14 Apr 2017 20:49:08 +0000
From: Jessica Iwamoto <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP Source receiving incorrect number of
samples
Message-ID:
<sn1pr09mb1008959200a2b2adddffc3d09b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I am using the NUM_SAMPS_AND_DONE mode on a USRP Source on the E310 to receive
a specified number of samples periodically, but when I look at the metadata for
the received samples, the number of samples I've received is not always equal
to the number of samples I've specified to the USRP Source block. By varying
the sampling rate, requested number of samples, and period at which I receive
the bursts, I've observed the following data:
period (s)
sampling rate
# samples requested
max error on # samples received
time spent sampling (s)
1
1000000
500000
1460
0.5
1
1000000
100000
0
0.1
1
500000
100000
584
0.2
1
500000
50000
0
0.1
1
500000
5000
0
0.01
1
500000
100000
584
0.2
0.5
1000000
100000
0
0.1
2
250000
100000
0
0.4
2
1000000
500000
0
0.5
2
1000000
1000000
3212
1
0.5
1000000
200000
1168
0.2
0.5
1000000
100000
0
0.1
It seems like there is some threshold for each period such that if you spend
more time sampling than the threshold, then an incorrect number of samples is
received, regardless of the sampling rate or number of samples requested. For
example, for a period of 1s, if you spend more than 0.1s sampling then an
incorrect number of samples is received.
Any thoughts on why this might be happening?
Thanks,
Jessica
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/238a8bd3/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 14 Apr 2017 23:27:15 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP Source receiving incorrect number of
samples
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Jessica,
expected behaviour is that you might need to call recv() multiple times
to get all samples until the rx_metadata contains the end of burst flag.
This would especially be necessary if the sampling rate dictates that
you get into a timeout if you received more samples.
Now, I'm not sure this is what's happening here. Could you share the
code you use to receive samples?
Best regards,
Marcus
On 14.04.2017 22:49, Jessica Iwamoto via USRP-users wrote:
>
> Hi all,
>
>
>
> I am using the NUM_SAMPS_AND_DONE mode on a USRP Source on the E310 to
> receive a specified number of samples periodically, but when I look at
> the metadata for the received samples, the number of samples I?ve
> received is not always equal to the number of samples I?ve specified
> to the USRP Source block. By varying the sampling rate, requested
> number of samples, and period at which I receive the bursts, I?ve
> observed the following data:
>
>
>
> period (s)
>
>
>
> sampling rate
>
>
>
> # samples requested
>
>
>
> max error on # samples received
>
>
>
> time spent sampling (s)
>
> 1
>
>
>
> 1000000
>
>
>
> 500000
>
>
>
> 1460
>
>
>
> 0.5
>
> 1
>
>
>
> 1000000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.1
>
> 1
>
>
>
> 500000
>
>
>
> 100000
>
>
>
> 584
>
>
>
> 0.2
>
> 1
>
>
>
> 500000
>
>
>
> 50000
>
>
>
> 0
>
>
>
> 0.1
>
> 1
>
>
>
> 500000
>
>
>
> 5000
>
>
>
> 0
>
>
>
> 0.01
>
>
>
>
>
>
>
> 1
>
>
>
> 500000
>
>
>
> 100000
>
>
>
> 584
>
>
>
> 0.2
>
> 0.5
>
>
>
> 1000000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.1
>
> 2
>
>
>
> 250000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.4
>
>
>
>
>
>
>
> 2
>
>
>
> 1000000
>
>
>
> 500000
>
>
>
> 0
>
>
>
> 0.5
>
> 2
>
>
>
> 1000000
>
>
>
> 1000000
>
>
>
> 3212
>
>
>
> 1
>
>
>
>
>
>
>
> 0.5
>
>
>
> 1000000
>
>
>
> 200000
>
>
>
> 1168
>
>
>
> 0.2
>
> 0.5
>
>
>
> 1000000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.1
>
>
>
> It seems like there is some threshold for each period such that if you
> spend more time sampling than the threshold, then an incorrect number
> of samples is received, regardless of the sampling rate or number of
> samples requested. For example, for a period of 1s, if you spend more
> than 0.1s sampling then an incorrect number of samples is received.
>
>
>
> Any thoughts on why this might be happening?
>
>
>
> Thanks,
>
> Jessica
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/770dc04e/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 14 Apr 2017 15:37:55 -0700
From: Michael West <[email protected]>
To: Dominik Eyerly <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<CAM4xKrrROjaVCyw5Bkp=j+3f0bundfszmtebtbn1wvoekob...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dominik,
Creating the streamer connects the blocks in the FPGA, creates the
transports, and does some initialization for the stream. It shouldn't (and
probably doesn't) matter whether you create the streamer or do the other
operations first. I just recommend creating the streamers first as a best
practice to be on the safe side.
As for the PA, 100ms is longer than I would expect for the warm up time. I
suspect the slow rise is partially due to PA warm up, but there may be
other factors involved as well. I recommend trying varying amounts of
leading zeros to see what the minimum amount is to see a clear signal.
Keeping the PA on all the time should be possible, but it will take UHD
code changes and could have side effects like higher noise on the RX side
due to leakage across the RF switch.
Regards,
Michael
On Wed, Apr 12, 2017 at 6:29 AM, Dominik Eyerly <
[email protected]> wrote:
> Hi Michael,
>
> Thank you for your response. Padding the end with zeros clears some of the
> garbage that is played at the beginning of the waveform.
>
> Creating the streams at the beginning should be no problem for me. One
> follow up question, you mentioned explicitly to create the streamer prior
> to tuning, setting bandwidth etc, do these operations have a specific
> effect on the streamer? Or in other words, what adverse effects, if any,
> exist if I perform these operations before creating the streamer?
>
> As per the PA behavior, this is an issue that is extremely undesirable for
> my application. I understand all PAs will have some rise time, however,
> 100ms seems excessive. Is it perhaps possible to power up the PA earlier
> via some modification to the host / fpga code? Simply pre-pending 100ms of
> zeros to my waveform won't work because I need the waveform to play with
> minimal delay. I don't have any low power constraints so it would not be a
> problem to keep the PA permanently enabled, if that is possible.
>
> cheers,
> dominik
> On 04/11/2017 08:40 PM, Michael West wrote:
>
> Hi Dominik,
>
> I can confirm that the creation of the streamers is very intrusive. It
> changes the active chains in the AD9364 and reconfigures the interface
> between the AD9364 and FPGA as Marcus has pointed out. For that reason, it
> is recommended to create all streamers before starting any streaming.
>
> Looking at the images you posted, the gap and first spur correlate to the
> creation of the TX streamer, so that should be eliminated if the streamers
> are created first. The next significant spur seems to align with the start
> of the TX streaming. My suspicion is that it is from garbage samples left
> in the DUC from initialization, but some testing is needed to prove that.
> Finally, the ramp and elevated power level during the transmission of the
> zeros is due to the TX PA being enabled when the stream starts.
>
> My suggestions:
>
> 1) Create the streamers right after creating the multi_usrp object
> (before any tuning, setting bandwidth, setting sample rate, etc...).
> 2) Pad the end of the TX burst with zeros. The first few samples
> transmitted are always the residual samples in the DUC. This means the
> last few samples of the burst will not actually make it to the AD9364
> unless you pad with zeros to flush them. Zero padding the end of every
> burst will make sure all desired samples are transmitted and that the next
> burst will start by transmitting the residual zeros. The amount of the
> group delay will vary depending on master clock rate and sample rate, but
> it is usually on the order of a few to a couple hundred microseconds.
>
> Regards,
> Michael
>
> On Tue, Apr 11, 2017 at 1:11 AM, Dominik Eyerly via USRP-users <
> [email protected]> wrote:
>
>> Hello,
>>
>> A couple of days has gone by so I wanted to follow up on my questions..
>>
>> *"OK, so, with the zeros, I think I understand what's going on. When you
>> create a new streamer, the hardware has to be configured to the new state.*
>> * In the case of the AD9361, this means the data path between the
>> AD9361 and the FPGA, which unavoidably means that the RX samples are
>> interrupted*
>> * while the interface is reconfigured. I believe this is the reason
>> for a lump of zeros when you configure for TX--someone in engineering can
>> correct*
>> * my understanding if it's wrong."*
>>
>> So this is confirmed behavior then? It is inherently due to the AD chip
>> and not a bug in the code somewhere (host / fpga)?
>>
>> *"In terms of the rather-long transient time--is this only immediately
>> after configuring the TX streamer, or for any TX burst? If it's just
>> immediately*
>> * after configuring a TX streamer, then this may be expected. If it's
>> at the start of every burst, then something is very wrong. Again, I'm
>> awaiting*
>> * comment from someone in Ettus R&D."*
>>
>> This is at the start of *every* burst that is initiated when rx is
>> running. Even when the tx_streamer is kept alive. Have you had a chance to
>> run my example program, or modify the existing loopback example in the way
>> I described in my previous email to reproduce the issue? I don't believe I
>> am doing something that is incorrect, however, if I am, I would be happy to
>> have someone point out my mistake.
>>
>> Best regards,
>> Dominik
>>
>> On 04/06/2017 05:51 PM, Marcus D. Leech wrote:
>>
>> On 04/06/2017 05:07 AM, Dominik Eyerly wrote:
>>
>> I'm using 1M for both rx and tx. I've seen that example but it does not
>> have the correct setup to display this behavior. As I mentioned before, the
>> acquisition has to be running BEFORE transmit begins. In the example code
>> there is no synchronization between rx start and tx start so you don't get
>> to see the beginning of the transmit in the capture. I added a simple
>> atomic bool to the example to ensure rx is running before tx starts. This
>> is sufficient to display the issue. Also, the issue of having zeros in rx
>> when creating a streamer will also not be displayed in this example code
>> because the tx_streamer is created before the acquisition starts.
>>
>> Here is a plot of the txrx loopback example with my minor synchronization
>> addition.
>>
>> http://imgur.com/a/0FjeI
>>
>> Would you be able to run the code that I posted in my previous email to
>> see if you have the same issues on your end?
>>
>>
>> cheers,
>> dominik
>>
>> OK, so, with the zeros, I think I understand what's going on. When you
>> create a new streamer, the hardware has to be configured to the new state.
>> In the case of the AD9361, this means the data path between the AD9361
>> and the FPGA, which unavoidably means that the RX samples are interrupted
>> while the interface is reconfigured. I believe this is the reason for
>> a lump of zeros when you configure for TX--someone in engineering can
>> correct
>> my understanding if it's wrong.
>>
>>
>> In terms of the rather-long transient time--is this only immediately
>> after configuring the TX streamer, or for any TX burst? If it's just
>> immediately
>> after configuring a TX streamer, then this may be expected. If it's at
>> the start of every burst, then something is very wrong. Again, I'm awaiting
>> comment from someone in Ettus R&D.
>>
>>
>>
>> On 04/06/2017 04:10 AM, Marcus D. Leech wrote:
>>
>> On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>>
>> Hello,
>>
>> UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
>> UHD_3.11.0.git-release, compiled for ARM
>> B205 running on USB3.
>>
>> Doesn't matter if the port is terminated or if it has a signal, recv
>> returns hard 0s, (not 1e-10 or the like) when a tx streamer is created.
>> I've uploaded a simple bit of code that illustrates the behavior quite
>> clearly.
>>
>> https://pastebin.com/ZAccunUe
>>
>> Please note that this code assumes you have 20dB of attenuation between
>> rx and tx. However you can adjust the gain values appropriately if you do
>> not.
>>
>> I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
>> -lboost_system -luhd
>>
>> But honestly, this issue is not my primary concern. My primary concern is
>> the ramp behavior. Note that the code I posted also illustrates the ramping
>> behavior. For this it needs to be in loopback with 20dB attenuation (or
>> more). I included a little helper function which performs a quick dump to
>> a python file. If you have matplotlib for python you can uncomment the
>> "dump_to_py" line in the rx thread and then simply run the generated file
>> with python to see a quick plot of the iq data.
>>
>> What else could I do to further troubleshoot this?
>>
>> cheers,
>> Dominik
>>
>> There is an example program, called txrx_loopback_to_file that does
>> something similar to your test.
>>
>> I wonder if it would be possible to do your tests with that, and see if
>> there is any change in behavior.
>>
>> Also, what sample rates are you using?
>>
>>
>>
>> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>>
>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>
>> Hello,
>>
>> Thanks for the reply. I should add I am doing this test at 3.8G.
>>
>> Response to (A)
>>
>> Are you saying that regardless of my tx gain setting, I need 40dB of
>> attenuation? I believe at max tx gain the board outputs around 10-15dBm
>> @3.8G. I currently have a 6dB pad on tx port, cabled to a splitter which is
>> cabled to the rx port with an inline 10dB pad. The other splitter port is
>> going directly into my VSA. Also, my tx gain is around 50dB. My
>> understanding was that the max input power of the rx port is -15dBm. With
>> this configuration I should be well under that, as shown on my VSA capture
>> (~-35dBm).
>>
>> Response to (B)
>>
>> According to the rough specifications posted here:
>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>
>> The IIP3 is -15dBm. As you can see on my VSA capture, it received -35dBm
>> and that doesn't even include the extra 10dB pad on the ettus rx port. I
>> should be good on linearity, should I not? The reason the power capture
>> looks so wavy is probably because I have the LO's tuned to the same spot.
>> When I move tx off by 100kHz the capture looks "nicer" but the ramp up
>> behavior is still there. Also, on the link I posted above, the max input
>> power is called out as 0 dBm... is that correct?
>>
>> Could you provide some input on the questions I brought up in my previous
>> email? Namely:
>>
>> (1) recv returning 0s when a tx_streamer is created while receiving
>> continuously.
>>
>> Could you try a simple experiment here? Place a terminator on the input
>> to the RX side, and see if you get 0s in the recv buffer. I want to
>> distinguish
>> between an analog situation and a digital one.
>>
>> (2) The ramp up behavior that is only present when transmitting during an
>> active acquisition.
>>
>> That's odd. What version of UHD are you using?
>>
>>
>> I also want to mention that the first burst of power in my captures
>> coincides with changing the frequency of the tx LO. This triggers an
>> internal calibration of the AD chip which in turn outputs this brief burst.
>> So at least this mystery is solved. I am curious, however, is it possible
>> to allow the chip to perform its cal without actually seeing this signal at
>> the tx port?
>>
>> I'm not certain of exactly how it performs its calibration, but likely
>> there will always be some leakage when it is doing so.
>>
>>
>> cheers,
>> Dominik
>>
>> On 04/04/2017 04:54 PM, [email protected] wrote:
>>
>> How are you doing the physical loop-back? If directly-cabled, you'll
>> need about 40dB of attenuation in-line, to keep the receiver from:
>>
>> (A) Being damaged
>>
>> (B) Remaining linear
>>
>>
>>
>>
>>
>>
>> On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:
>>
>> Hello all,
>>
>>
>>
>> My questions concern the B205i. I've uploaded some pictures to simplify
>> the explaining process.
>>
>> http://imgur.com/a/XMAv6
>>
>> Basically, I want to transmit and receive a FSK waveform on one board
>> (loopback). This means I've tuned both LOs to the same frequency. I've also
>> inserted a splitter to be able to look at the signal on my VSA. This has
>> allowed me to identify several problems.
>>
>>
>>
>> Let's start on the left:
>> (B205i Receive - no zeros)
>> Here you see the received power drop from the noise floor to -infinity
>> because the rx_streamer was returning 0's. I've tracked this problem to the
>> creation of a tx_streamer while an acquisition is running. This seems
>> completely unacceptable; that calling a command on a chain (tx) that has
>> nothing to do with rx, has an effect on rx. I could understand that the
>> sample rate performance of rx is affected because they share a
>> communication link, but not to actually alter the data that is returned by
>> the recv call. Is this a known bug? Is there a workaround other than "don't
>> do that"? Is this bug slated for a fix next release?
>>
>>
>>
>> Next:
>> Right after all of the 0's, a strong but brief tone is blasted into the
>> tx path. The power of this tone is not affected by the tx gain setting.
>> This is quite a significant problem because we may use this module to test
>> sensitive devices that may not be able to withstand such a transient. Any
>> idea what is causing this? Again, any workarounds or fixes known?
>>
>>
>>
>> I don't care much for the spur at -83dBm. But it would be interesting to
>> understand it.
>>
>>
>>
>> Lastly:
>> The actual waveform is transmitted. Since this is an FSK waveform, I
>> would expect a constant power envelope. Unfortunately, what I capture with
>> the B205i is not even close. I performed the test again, but this time
>> transmitting 200ms of 0s before my actual FSK waveform. You can still see
>> the "warm up" looking behavior, however, by the time the actual waveform
>> hits, the output seems settled. Is that what is happening (warm up)?
>> Preloading every waveform with 200ms of zeroes is extremely undesirable. Is
>> there a way to keep the chip always ready to go from both a Rx and Tx
>> perspective?
>>
>>
>>
>> Tx only with no zeros:
>> I performed the no zeros test again, this time without doing an
>> acquisition with the B205i. Now the warm up behavior is completely gone.
>> Why is Rx influencing the Tx RF performance?
>>
>>
>>
>> Any insight into these issues I am experiencing would be very
>> appreciated.
>>
>> Best regards,
>> Dominik
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>> _______________________________________________ USRP-users mailing list
>> [email protected] http://lists.ettus.com/mailman
>> /listinfo/usrp-users_lists.ettus.com
>>
>> --
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>> --
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>> --
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>> --
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>> _______________________________________________ USRP-users mailing list
>> [email protected] http://lists.ettus.com/mailman
>> /listinfo/usrp-users_lists.ettus.com
>
> --
>
> --
>
> i.A. Dominik Eyerly
> Software
>
> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
> Email: [email protected]
> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
> *Support Telefon: +49 (0) 7732 9815 100
> <+49%207732%209815100>*[email protected][image: sig]
> Gesch?ftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
> bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
> contains information from Konrad GmbH, which is intended only for the use of
> the individual or entity to which it is addressed, and which may contain
> information that is privileged, confidential, and/or otherwise exempt from
> disclosure under applicable law. If the reader of this message is not the
> intended recipient, any disclosure, dissemination, distribution, copying or
> other use of this communication or its substance is prohibited. If you have
> received this communication in error, please contact us immediately. Thank
> you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/69f4f8e5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/69f4f8e5/attachment-0006.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/69f4f8e5/attachment-0007.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/69f4f8e5/attachment-0008.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/69f4f8e5/attachment-0009.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/69f4f8e5/attachment-0010.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/69f4f8e5/attachment-0011.jpe>
------------------------------
Message: 5
Date: Sat, 15 Apr 2017 01:23:19 +0200
From: Marcus M?ller <[email protected]>
To: Jessica Iwamoto <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of
samples
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Jessica,
I was specifically hoping for the section where you call recv() and with
what arguments, and how often!
Best regards,
Marcus
On 15.04.2017 01:17, Jessica Iwamoto wrote:
> Thanks,
>
> Jessica
>
>
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Marcus M?ller via USRP-users
> *Sent:* Friday, April 14, 2017 2:27 PM
> *To:* [email protected]
> *Subject:* Re: [USRP-users] USRP Source receiving incorrect number of
> samples
>
>
>
> Dear Jessica,
>
> expected behaviour is that you might need to call recv() multiple
> times to get all samples until the rx_metadata contains the end of
> burst flag.
>
> This would especially be necessary if the sampling rate dictates that
> you get into a timeout if you received more samples.
>
> Now, I'm not sure this is what's happening here. Could you share the
> code you use to receive samples?
>
> Best regards,
>
> Marcus
>
> On 14.04.2017 22:49, Jessica Iwamoto via USRP-users wrote:
>
> Hi all,
>
>
>
> I am using the NUM_SAMPS_AND_DONE mode on a USRP Source on the
> E310 to receive a specified number of samples periodically, but
> when I look at the metadata for the received samples, the number
> of samples I?ve received is not always equal to the number of
> samples I?ve specified to the USRP Source block. By varying the
> sampling rate, requested number of samples, and period at which I
> receive the bursts, I?ve observed the following data:
>
>
>
> period (s)
>
>
>
> sampling rate
>
>
>
> # samples requested
>
>
>
> max error on # samples received
>
>
>
> time spent sampling (s)
>
> 1
>
>
>
> 1000000
>
>
>
> 500000
>
>
>
> 1460
>
>
>
> 0.5
>
> 1
>
>
>
> 1000000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.1
>
> 1
>
>
>
> 500000
>
>
>
> 100000
>
>
>
> 584
>
>
>
> 0.2
>
> 1
>
>
>
> 500000
>
>
>
> 50000
>
>
>
> 0
>
>
>
> 0.1
>
> 1
>
>
>
> 500000
>
>
>
> 5000
>
>
>
> 0
>
>
>
> 0.01
>
>
>
>
>
>
>
> 1
>
>
>
> 500000
>
>
>
> 100000
>
>
>
> 584
>
>
>
> 0.2
>
> 0.5
>
>
>
> 1000000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.1
>
> 2
>
>
>
> 250000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.4
>
>
>
>
>
>
>
> 2
>
>
>
> 1000000
>
>
>
> 500000
>
>
>
> 0
>
>
>
> 0.5
>
> 2
>
>
>
> 1000000
>
>
>
> 1000000
>
>
>
> 3212
>
>
>
> 1
>
>
>
>
>
>
>
> 0.5
>
>
>
> 1000000
>
>
>
> 200000
>
>
>
> 1168
>
>
>
> 0.2
>
> 0.5
>
>
>
> 1000000
>
>
>
> 100000
>
>
>
> 0
>
>
>
> 0.1
>
>
>
> It seems like there is some threshold for each period such that if
> you spend more time sampling than the threshold, then an incorrect
> number of samples is received, regardless of the sampling rate or
> number of samples requested. For example, for a period of 1s, if
> you spend more than 0.1s sampling then an incorrect number of
> samples is received.
>
>
>
> Any thoughts on why this might be happening?
>
>
>
> Thanks,
>
> Jessica
>
>
>
>
> _______________________________________________
>
> USRP-users mailing list
>
> [email protected] <mailto:[email protected]>
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170415/1beb7819/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 14 Apr 2017 23:57:53 +0000
From: Jessica Iwamoto <[email protected]>
To: Marcus M?ller <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of
samples
Message-ID:
<sn1pr09mb1008c8025d14c0471b62526b9b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Marcus,
I have a GNU radio flowgraph in python and in my code I simply start the
flowgraph and then issue stream commands periodically using the code in my
previous email to the USRP Source in my flowgraph. I don't call recv(). Does
that make sense?
Thanks,
Jessica
From: Marcus M?ller [mailto:[email protected]]
Sent: Friday, April 14, 2017 4:23 PM
To: Jessica Iwamoto <[email protected]>; usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of samples
Hi Jessica,
I was specifically hoping for the section where you call recv() and with what
arguments, and how often!
Best regards,
Marcus
On 15.04.2017 01:17, Jessica Iwamoto wrote:
Thanks,
Jessica
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Sent: Friday, April 14, 2017 2:27 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] USRP Source receiving incorrect number of samples
Dear Jessica,
expected behaviour is that you might need to call recv() multiple times to get
all samples until the rx_metadata contains the end of burst flag.
This would especially be necessary if the sampling rate dictates that you get
into a timeout if you received more samples.
Now, I'm not sure this is what's happening here. Could you share the code you
use to receive samples?
Best regards,
Marcus
On 14.04.2017 22:49, Jessica Iwamoto via USRP-users wrote:
Hi all,
I am using the NUM_SAMPS_AND_DONE mode on a USRP Source on the E310 to receive
a specified number of samples periodically, but when I look at the metadata for
the received samples, the number of samples I've received is not always equal
to the number of samples I've specified to the USRP Source block. By varying
the sampling rate, requested number of samples, and period at which I receive
the bursts, I've observed the following data:
period (s)
sampling rate
# samples requested
max error on # samples received
time spent sampling (s)
1
1000000
500000
1460
0.5
1
1000000
100000
0
0.1
1
500000
100000
584
0.2
1
500000
50000
0
0.1
1
500000
5000
0
0.01
1
500000
100000
584
0.2
0.5
1000000
100000
0
0.1
2
250000
100000
0
0.4
2
1000000
500000
0
0.5
2
1000000
1000000
3212
1
0.5
1000000
200000
1168
0.2
0.5
1000000
100000
0
0.1
It seems like there is some threshold for each period such that if you spend
more time sampling than the threshold, then an incorrect number of samples is
received, regardless of the sampling rate or number of samples requested. For
example, for a period of 1s, if you spend more than 0.1s sampling then an
incorrect number of samples is received.
Any thoughts on why this might be happening?
Thanks,
Jessica
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170414/80b53603/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 14 Apr 2017 18:07:04 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] ADC of B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
We do *not* stream control in-band with samples on B210; we have
separate packets for that.
Like Marcus said, samples coming from the radio are zero-padded to
16-bits. When they leave the DDC, they might have more than 12
significant bits.
See also:
https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/b200/b200.v#L183-L211
Cheers,
Martin
On 04/14/2017 07:10 AM, Dan CaJacob via USRP-users wrote:
> Marcus,
>
> I am deferring to you as the expert on this, but I am surprised as
> well. I thought (at least on older Ettus products) that similar 12-bit
> ADCs truly did return 12 bits of data and that the extra 4 bits to pad
> out to 16 could/were used for streaming control of things like GPIO, etc.
>
> - Dan
>
> On Fri, Apr 14, 2017 at 7:05 AM Marcus M?ller via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi John,
>
>
>> So it is not a simply add zero after the data?Maybe add some
>> "0101" at some where.
>
> No! It's more complicated than that.
>
> Imagine the samples coming from the ADC entering a FIR filter.
>
> In that FIR filter, they get multiplied with fixed-point filter
> coefficients, so the resulting products have more "valid" bits than
> the ADC samples have.
>
> These filter states get added up to the FIR output ? which thus has
> more bits than the products.
>
> There's multiple digital filters in the B210's DSP chain.
>
> The output of the filters is rounded to the most significant 16 bit.
>
> So, there's no "padding" in the sense of "adding some constant bits
> to the end" anywhere, here, unless you chose the case of
> MCR=sampling rate.
>
> Best regards,
>
> Marcus
>
>
> On 14.04.2017 11:37, liu Jong wrote:
>> HI,Marcus,
>> thank you for your reply.
>> So it is not a simply add zero after the data?Maybe add some
>> "0101" at some where.
>>
>>
>> 2017-04-14 17:02 GMT+08:00 Marcus M?ller via USRP-users
>> <[email protected] <mailto:[email protected]>>:
>>
>> Hi John,
>>
>> there's digital downconversion happening between the ADC's
>> sample rate (which coincides with the rate we call Master
>> Clock Rate) and your sampling rate, which inherently is a
>> bit-widening operation.
>>
>> Thus, under sufficient oversampling due to above process, all
>> your 16 bits might be significant.
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 14.04.2017 09:53, john liu via USRP-users wrote:
>>> Hi,all,
>>> From the datasheet of B210,we know the ADC is 12bit,But the
>>> OTW is 16bit(or 12bit),so?there is a conversion process.Is
>>> it directly add zero after the data?
>>> Thank you.
>>>
>>> best regards
>>> John
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> _______________________________________________ USRP-users
>> mailing list [email protected]
>> <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Very Respectfully,
>
> Dan CaJacob
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 80, Issue 15
******************************************
