Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. B-200 front end damaged (John M Petrich)
2. Re: B-200 front end damaged (Marcus D. Leech)
3. Re: Non-integer number of dropped samples during overflow
(Jacob Gilbert)
4. Re: Non-integer number of dropped samples during overflow
(Marcus M?ller)
5. Re: Non-integer number of dropped samples during overflow
(Jacob Gilbert)
6. Re: Non-integer number of dropped samples during overflow
(Nick Foster)
7. B200 Gain Control (Trevor Yensen)
8. Re: Non-integer number of dropped samples during overflow
(Jacob Gilbert)
9. Re: B200 Gain Control (Michael West)
10. Re: Non-integer number of dropped samples during overflow
(Martin Braun)
11. Re: Non-integer number of dropped samples during overflow
(Jacob Gilbert)
12. Re: RFNOC on E312 (Martin Braun)
13. Re: Weird behaviour with set_master_clock_rate in X300
(Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Fri, 14 Oct 2016 09:28:32 -0700
From: John M Petrich <petr...@uw.edu>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] B-200 front end damaged
Message-ID: <f053a428a7ee4c7a52100b6667840...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The RX front end of my B-200 suddenly went out. I suspect too much
microwave energy from an external power amplifier leaking around the
external TX/RX relay. Is there someone or someplace where I can send my
B200 for a front end repair?
All suggestions welcome,
John Petrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/6c74fe98/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 14 Oct 2016 12:37:56 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B-200 front end damaged
Message-ID: <580109e4.6050...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 10/14/2016 12:28 PM, John M Petrich via USRP-users wrote:
>
> The RX front end of my B-200 suddenly went out.I suspect too much
> microwave energy from an external power amplifier leaking around the
> external TX/RX relay.Is there someone or someplace where I can send my
> B200 for a front end repair?
>
> All suggestions welcome,
>
> John Petrich
>
>
Sadly, the "front end" in these units is a high-integration "does
everything" chip--the AD9364. There are some RF switches in front of it,
and balun transformers and the like. If you're *lucky* it's one of
the switches, if not, it's the AD9364.
The warranty doesn't cover that type of damage, unfortunately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/e4271131/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 14 Oct 2016 11:20:42 -0600
From: Jacob Gilbert <mrjacobagilb...@gmail.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID:
<cac52akbtprocaw8ugkih2a374qvz410spy4-ebki67qvnum...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I probably should have done this when I first posted, but I uploaded the
block and an example FG here:
https://github.com/mrjacobagilbert/gr-misc_debug_utils
Also worth mentioning: the X series USRP appears to drop non-integer
numbers of samples much less frequently than the B series, but it does on
occasion. I have not tested with the E/N series yet.
Thanks,
Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/c789bb7a/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 14 Oct 2016 19:23:52 +0200
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID: <847d0b4e-5a5d-8cbc-02fa-06f1d69b1...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Hi Jacob,
I'm a bit confused; "samples" are an integer thing; you can't use "half
a sample"; can you elaborate on what you mean with non-integer numbers?
Best regards,
Marcus
On 10/14/2016 07:20 PM, Jacob Gilbert via USRP-users wrote:
> I probably should have done this when I first posted, but I uploaded
> the block and an example FG
> here: https://github.com/mrjacobagilbert/gr-misc_debug_utils
>
> Also worth mentioning: the X series USRP appears to drop non-integer
> numbers of samples much less frequently than the B series, but it does
> on occasion. I have not tested with the E/N series yet.
>
> Thanks,
> Jacob
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161014/37cc1ec6/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 14 Oct 2016 11:31:20 -0600
From: Jacob Gilbert <mrjacobagilb...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID:
<CAC52AkAoFq=kp8omdzdle9rf990k_5pklndzogplylaqvff...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
They are indeed, and the language is a bit confusing.
That block seeks to determine how many samples have been lost during an
underflow and does so using the rx_time tags emitted by the
uhd_source_block. When run, it will often produce non-integer numbers like
43814.375 (this number might occur when the USRP decimation is 8*n). Thus
it appears that the 'decimation phase' in the USRP can change during
overflows, which is something I did not expect.
If that still doesn't make sense, let me know.
Jacob
On Fri, Oct 14, 2016 at 11:23 AM, Marcus M?ller via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Jacob,
>
> I'm a bit confused; "samples" are an integer thing; you can't use "half a
> sample"; can you elaborate on what you mean with non-integer numbers?
>
> Best regards,
> Marcus
>
> On 10/14/2016 07:20 PM, Jacob Gilbert via USRP-users wrote:
>
> I probably should have done this when I first posted, but I uploaded the
> block and an example FG here: https://github.com/
> mrjacobagilbert/gr-misc_debug_utils
>
> Also worth mentioning: the X series USRP appears to drop non-integer
> numbers of samples much less frequently than the B series, but it does on
> occasion. I have not tested with the E/N series yet.
>
> Thanks,
> Jacob
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161014/77d84d30/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 14 Oct 2016 17:37:24 +0000
From: Nick Foster <bistrom...@gmail.com>
To: Jacob Gilbert <mrjacobagilb...@gmail.com>, Marcus M?ller
<marcus.muel...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID:
<CA+JMMq8S=9iiYXvR5_=gupa41um+5eg_hc0fi9czzasstfn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It sounds kind of like the Radio block is dropping samples pre-DDC, if
you're using a very recent X310 build (after the separation of the Radio
and DUC/DDC blocks). What UHD version are you running?
I would definitely not expect the B series devices to do this.
--n
On Fri, Oct 14, 2016 at 10:33 AM Jacob Gilbert via USRP-users <
usrp-users@lists.ettus.com> wrote:
> They are indeed, and the language is a bit confusing.
>
> That block seeks to determine how many samples have been lost during an
> underflow and does so using the rx_time tags emitted by the
> uhd_source_block. When run, it will often produce non-integer numbers like
> 43814.375 (this number might occur when the USRP decimation is 8*n). Thus
> it appears that the 'decimation phase' in the USRP can change during
> overflows, which is something I did not expect.
>
> If that still doesn't make sense, let me know.
>
> Jacob
>
> On Fri, Oct 14, 2016 at 11:23 AM, Marcus M?ller via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Jacob,
>
> I'm a bit confused; "samples" are an integer thing; you can't use "half a
> sample"; can you elaborate on what you mean with non-integer numbers?
>
> Best regards,
> Marcus
>
> On 10/14/2016 07:20 PM, Jacob Gilbert via USRP-users wrote:
>
> I probably should have done this when I first posted, but I uploaded the
> block and an example FG here:
> https://github.com/mrjacobagilbert/gr-misc_debug_utils
>
> Also worth mentioning: the X series USRP appears to drop non-integer
> numbers of samples much less frequently than the B series, but it does on
> occasion. I have not tested with the E/N series yet.
>
> Thanks,
> Jacob
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161014/b37fb0d6/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 14 Oct 2016 17:41:15 +0000
From: Trevor Yensen <trevor.yen...@allenvanguard.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] B200 Gain Control
Message-ID: <1476466875.3361.120.ca...@allenvanguard.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have a B200mini USRP and I'm trying to perform a capture at a specific offset
to GPS 1PPS (in my example 1s after the occurrence of a 1PPS event). I have
disabled the AGC and locked the gain to 30dB. I'm sampling at 31.25MHz. I
have set my capture frequency to 145MHz and set my signal generator to 150MHz
with an input signal level of -30dBm. I have tried both the RX2 and TX/RX
antenna ports and the results are very similar.
I observe a gain variation in the first 10,000 samples roughly or 320us after
which time my signal capture appears to be steady-state. This correlates to a
gain change of around 1.5dB from my sample 0 to sample 10000.
I was expecting no envelope variation over the 50,000 sample capture,
best-case, and perhaps a very short transient, worst-case, at the start. 320us
seems like a long time for a "transient". My best guess is that there is some
sort of internal calibration event occurring in the ADI Catalina? However, the
signal is present for a long time prior to the capture, so I would have thought
this would be resolved before the capture event initiated.
I've embedded a capture in the email - but if unable to view this please email
me.
Please let me know if you have some ideas to resolve this envelope issue for a
discrete capture.
Thanks,
Trevor Yensen
[cid:1476466875.3361.121.camel@allenvanguard.com]
IMPORTANT LEGAL NOTICE
This message is intended only for the use of the named addressee. It may
contain information that is copywritten, privileged, confidential and exempt
from disclosure under applicable law. If you are not the intended recipient,
you are notified that any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this in error,
please notify the sender immediately and delete it from your system.
Communications using this system are monitored and recorded for lawful business
purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/1965f965/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown-THTIPY
Type: image/png
Size: 15367 bytes
Desc: unknown-THTIPY
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/1965f965/attachment-0001.png>
------------------------------
Message: 8
Date: Fri, 14 Oct 2016 12:53:17 -0600
From: Jacob Gilbert <mrjacobagilb...@gmail.com>
To: Nick Foster <bistrom...@gmail.com>
Cc: Marcus M?ller <marcus.muel...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID:
<CAC52AkCL=A+eE-h3m7=Dk2o3=p3feqetbam16gwgbk7ghwp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
That is exactly what it seems like to me. Tested with UHD 3.9.2 and 3.9.4.
On Fri, Oct 14, 2016 at 11:37 AM, Nick Foster <bistrom...@gmail.com> wrote:
> It sounds kind of like the Radio block is dropping samples pre-DDC, if
> you're using a very recent X310 build (after the separation of the Radio
> and DUC/DDC blocks). What UHD version are you running?
>
> I would definitely not expect the B series devices to do this.
>
> --n
>
> On Fri, Oct 14, 2016 at 10:33 AM Jacob Gilbert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> They are indeed, and the language is a bit confusing.
>>
>> That block seeks to determine how many samples have been lost during an
>> underflow and does so using the rx_time tags emitted by the
>> uhd_source_block. When run, it will often produce non-integer numbers like
>> 43814.375 (this number might occur when the USRP decimation is 8*n). Thus
>> it appears that the 'decimation phase' in the USRP can change during
>> overflows, which is something I did not expect.
>>
>> If that still doesn't make sense, let me know.
>>
>> Jacob
>>
>> On Fri, Oct 14, 2016 at 11:23 AM, Marcus M?ller via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hi Jacob,
>>
>> I'm a bit confused; "samples" are an integer thing; you can't use "half a
>> sample"; can you elaborate on what you mean with non-integer numbers?
>>
>> Best regards,
>> Marcus
>>
>> On 10/14/2016 07:20 PM, Jacob Gilbert via USRP-users wrote:
>>
>> I probably should have done this when I first posted, but I uploaded the
>> block and an example FG here: https://github.com/mrjac
>> obagilbert/gr-misc_debug_utils
>>
>> Also worth mentioning: the X series USRP appears to drop non-integer
>> numbers of samples much less frequently than the B series, but it does on
>> occasion. I have not tested with the E/N series yet.
>>
>> Thanks,
>> Jacob
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> 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/20161014/13f3fe78/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 14 Oct 2016 12:08:46 -0700
From: Michael West <michael.w...@ettus.com>
To: Trevor Yensen <trevor.yen...@allenvanguard.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] B200 Gain Control
Message-ID:
<CAM4xKrqMADCfc+Vs=ypgkzfeajvse2xwo8dieuykdz7frsf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Trevor,
It looks like group delay either from the AD9364 or the DDC chain in the
FPGA. Since the signal is present long before the burst, I would more
likely suspect the DDC chain in the FPGA. In any case, it is common to
need to calibrate out group delay. To do that, either start the burst
early and discard the undesired samples or continuously receive and discard
any unnecessary samples.
Regards,
Michael
On Fri, Oct 14, 2016 at 10:41 AM, Trevor Yensen via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> I have a B200mini USRP and I'm trying to perform a capture at a specific
> offset to GPS 1PPS (in my example 1s after the occurrence of a 1PPS
> event). I have disabled the AGC and locked the gain to 30dB. I'm sampling
> at 31.25MHz. I have set my capture frequency to 145MHz and set my signal
> generator to 150MHz with an input signal level of -30dBm. I have tried
> both the RX2 and TX/RX antenna ports and the results are very similar.
> I observe a gain variation in the first 10,000 samples roughly or 320us
> after which time my signal capture appears to be steady-state. This
> correlates to a gain change of around 1.5dB from my sample 0 to sample
> 10000.
> I was expecting no envelope variation over the 50,000 sample capture,
> best-case, and perhaps a very short transient, worst-case, at the start.
> 320us seems like a long time for a "transient". My best guess is that
> there is some sort of internal calibration event occurring in the ADI
> Catalina? However, the signal is present for a long time prior to the
> capture, so I would have thought this would be resolved before the capture
> event initiated.
> I've embedded a capture in the email - but if unable to view this please
> email me.
> Please let me know if you have some ideas to resolve this envelope issue
> for a discrete capture.
>
> Thanks,
> Trevor Yensen
>
>
>
>
>
>
> *IMPORTANT LEGAL NOTICE *
>
> This message is intended only for the use of the named addressee. It may
> contain information that is copywritten, privileged, confidential and
> exempt from disclosure under applicable law. If you are not the intended
> recipient, you are notified that any dissemination, distribution or copying
> of this communication is strictly prohibited. If you have received this in
> error, please notify the sender immediately and delete it from your system.
> Communications using this system are monitored and recorded for lawful
> business purposes.
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20161014/443342cd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown-THTIPY
Type: image/png
Size: 15367 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/443342cd/attachment-0001.png>
------------------------------
Message: 10
Date: Fri, 14 Oct 2016 14:43:28 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID: <c0b15710-ea22-be9f-0b7f-6f04fa5c7...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Overruns are similar to bursts (in fact, the DDC treats them the same
way). When you're doing infinite streaming, you're fine. When you're
receiving bursts, the DDC will output one burst, with a timestamp at the
beginning and an EOB at the end, for every burst that is input.
Now, the DDC decimates with an integer factor. Any burst length that is
not an integer multiple of the decimation rate will have to lose some
samples. If you're decimating by a factor of 10, and you input 1003
samples, it will output 100 samples.
In the overrun case, the last sample of the "intact" sample stream is
tagged with an EOB. It's unlikely that the EOB occurs at an integer
multiple of the decimation rate, so it'll lose samples.
Is this in line with what you're seeing?
Prior to 3.10, the DDC was prior to packetization. So for every sample
you dropped due to an overrun, you would drop an integer number of input
samples. The net result is pretty much the same, though, because on the
slow side of the DDC, you will only see samples that have passed the DDC
stage.
Cheers,
M
On 10/14/2016 11:53 AM, Jacob Gilbert via USRP-users wrote:
> That is exactly what it seems like to me. Tested with UHD 3.9.2 and 3.9.4.
>
>
> On Fri, Oct 14, 2016 at 11:37 AM, Nick Foster <bistrom...@gmail.com
> <mailto:bistrom...@gmail.com>> wrote:
>
> It sounds kind of like the Radio block is dropping samples pre-DDC,
> if you're using a very recent X310 build (after the separation of
> the Radio and DUC/DDC blocks). What UHD version are you running?
>
> I would definitely not expect the B series devices to do this.
>
> --n
>
> On Fri, Oct 14, 2016 at 10:33 AM Jacob Gilbert via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> They are indeed, and the language is a bit confusing.
>
> That block seeks to determine how many samples have been lost
> during an underflow and does so using the rx_time tags emitted
> by the uhd_source_block. When run, it will often produce
> non-integer numbers like 43814.375 (this number might occur when
> the USRP decimation is 8*n). Thus it appears that the
> 'decimation phase' in the USRP can change during overflows,
> which is something I did not expect.
>
> If that still doesn't make sense, let me know.
>
> Jacob
>
> On Fri, Oct 14, 2016 at 11:23 AM, Marcus M?ller via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
> wrote:
>
> Hi Jacob,
>
> I'm a bit confused; "samples" are an integer thing; you
> can't use "half a sample"; can you elaborate on what you
> mean with non-integer numbers?
>
> Best regards,
> Marcus
>
>
> On 10/14/2016 07:20 PM, Jacob Gilbert via USRP-users wrote:
>> I probably should have done this when I first posted, but
>> I uploaded the block and an example FG
>> here: https://github.com/mrjacobagilbert/gr-misc_debug_utils
>> <https://github.com/mrjacobagilbert/gr-misc_debug_utils>
>>
>> Also worth mentioning: the X series USRP appears to drop
>> non-integer numbers of samples much less frequently than
>> the B series, but it does on occasion. I have not tested
>> with the E/N series yet.
>>
>> Thanks,
>> Jacob
>>
>>
>> _______________________________________________
>> 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>
>
>
> _______________________________________________
> 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>
>
>
> _______________________________________________
> 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>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Fri, 14 Oct 2016 16:14:05 -0600
From: Jacob Gilbert <mrjacobagilb...@gmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Non-integer number of dropped samples during
overflow
Message-ID:
<CAC52AkDfz3B8rr-dPog9xfQ3eFtdg49hek99kxjKfHaOzX=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Martin,
On Fri, Oct 14, 2016 at 3:43 PM, Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Overruns are similar to bursts (in fact, the DDC treats them the same
> way). When you're doing infinite streaming, you're fine. When you're
> receiving bursts, the DDC will output one burst, with a timestamp at the
> beginning and an EOB at the end, for every burst that is input.
>
> Now, the DDC decimates with an integer factor. Any burst length that is
> not an integer multiple of the decimation rate will have to lose some
> samples. If you're decimating by a factor of 10, and you input 1003
> samples, it will output 100 samples.
>
> In the overrun case, the last sample of the "intact" sample stream is
> tagged with an EOB. It's unlikely that the EOB occurs at an integer
> multiple of the decimation rate, so it'll lose samples.
>
> Is this in line with what you're seeing?
>
>
I just tested with master, and I did not see any non-integer-sample
duration losses during dropped data on the X series USRP, but I definitely
still do on the B series. I need to test a little more though. I am not
quite clear on what you are suggesting. If I have a DDC decimation of 8,
and end up with a "D", should this not always occur when data is produced
by the DDC and at a constant point in the input stream relative to the
output stream? Or are you saying that the DDC stops and when it starts back
up, there are some data samples in flight that are first processed by the
DDC (for your example above, the 3 samples that did not get processed
yet?).
> Prior to 3.10, the DDC was prior to packetization. So for every sample
> you dropped due to an overrun, you would drop an integer number of input
> samples. The net result is pretty much the same, though, because on the
> slow side of the DDC, you will only see samples that have passed the DDC
> stage.
>
>
I suppose part of my confusion comes from not understanding what exactly
happens during an overflow. I had assumed the digitizer/DDC keeps running
and some amount of data in the buffer after the DDC is dropped (either a
packet in the case of the X series, or some amount of the USB 'send'
buffer. It sounds like this is not the case, and that the behavior between
the B and X series may likely be different?
Cheers,
> M
>
As always I appreciate the help.
Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161014/48e0186c/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 14 Oct 2016 16:34:35 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNOC on E312
Message-ID: <96c0556c-428b-c653-7ca7-74bd639cc...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 10/14/2016 06:10 AM, Long, Jeffrey P. via USRP-users wrote:
> A little googling seemed to say that my pybombs problem is maybe a
> version issue. I am doing this work from a Ubuntu 12 machine which is
> starting to get more and more out of date for many things. : )
Jeff,
Ubuntu 12.04 is no longer supported for RFNoC, unless you jump through
hoops to update dependencies manually.
Cheers,
Martin
>
>
>
> Jeff
>
>
>
> *From:*Nicolas Cuervo [mailto:nicolas.cue...@ettus.com]
> *Sent:* Tuesday, October 11, 2016 3:17 PM
> *To:* Long, Jeffrey P.
> *Cc:* USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] RFNOC on E312
>
>
>
> Hello Jeffrey,
>
> We have a page in our knowledge base that approaches the procedure to
> set up your development environment. You can find it here:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312. You can
> use the PyBOMBS recipe "e3xx-rfnoc" to set it up for RFNoC development.
> (This step is included in the tutorial provided within the given link).
>
> After you have all that set up, you can continue with RFNoC development
> in your machine following this guide:
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development. After you
> have your FPGA design ready, you just have to locate the image in the
> usual location so that the device picks it up at initialization.
>
> Let us know if this is the info that you need, or if you have more
> questions.
>
> Cheers,
>
> -Nicolas
>
>
>
> On Tue, Oct 11, 2016 at 11:58 AM, Long, Jeffrey P. via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> What is the best approach to use the latest RFNOC on a E312/E310? Are
> there any pre-built SD images to get you started or do you need to build
> everything from scratch(FPGA image, filesystem, uhd etc..)?
>
> From what I can see the only RFNOC image is a fido based one that is now
> considered obsolete. If I am yocto challenged maybe start with a release
> 4 image and update uhd(switch to rfnoc-devel) and get updated fpga
> images or build them?
>
>
>
> Thanks
>
> Jeff
>
>
> _______________________________________________
> 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
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Fri, 14 Oct 2016 18:01:33 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Weird behaviour with set_master_clock_rate
in X300
Message-ID: <93f394df-158f-2ecf-1b2c-b9eb53f31...@ettus.com>
Content-Type: text/plain; charset=windows-1252
The behaviour is actually as expected, with a small hitch.
`set_master_clock_rate()` is only for devices that support changing the
clock at run time, which the X300 does not. However, we have a known
issue that the reported clock rate may be wrong.
To confirm, master_clock_rate=foo is *not* a workaround. It's the right
way to configure this.
Cheers,
Martin
On 10/14/2016 02:13 AM, Pol Henarejos via USRP-users wrote:
> Dear Claudio,
>
> Thank you! Your snippet works like a charm. This is a temporary
> workaround but I guess the behvaiour should not be the described one.
>
> Thank you again.
>
>
> Pol Henarejos
> Researcher, MSc
> pol.henare...@cttc.es
>
> Centre Tecnol?gic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00 Ext: 2177
> Fax. +34 93 645 29 01
> www.cttc.es
>
> El 14/10/2016 a les 10:09, Claudio Cicconetti ha escrit:
>> Dear Pol,
>> I experienced the same issue with X300, while the same code with
>> set_master_clock() works fine with B210.
>>
>> I worked around the issue by adding "master_clock_rate=184.32e6" to the
>> argument of multi_usrp::make(), which works with both X300 and B210.
>>
>> Best regards,
>> Claudio
>>
>> On 10/14/2016 09:25 AM, Pol Henarejos via USRP-users wrote:
>>> Dear all,
>>>
>>> I am experimenting some weird issues when I try to change the master
>>> clock. I wish to set the TX rate of my X300 to 15.36 Msps. So,
>>> previously I set the master clock to 184.32 MHz in order to obtain an
>>> integer decimation (184.32/15.36 = 12) but it seems that is not set
>>> properly. What I get from USRP X300 is the following warning:
>>>
>>> UHD Warning:
>>> The requested interpolation is odd; the user should expect passband
>>> CIC rolloff.
>>> Select an even interpolation to ensure that a halfband filter is
>>> enabled.
>>> interpolation = dsp_rate/samp_rate -> 13 = (200.000000
>>> MHz)/(15.360000 MHz)
>>>
>>> UHD Warning:
>>> The hardware does not support the requested TX sample rate:
>>> Target sample rate: 15.360000 MSps
>>> Actual sample rate: 15.384615 MSps
>>>
>>> I guess that the master clock is set to the default 200 MHz and not
>>> changed to 184.32e6.
>>>
>>> Any clue?
>>>
>>> The code is:
>>>
>>> usrp->set_master_clock(184.32e6);
>>> usrp->set_tx_rate(15.36e6); //Warnings are displayed here
>>>
>>> I am using the UHD version Win32; Microsoft Visual C++ version 14.0;
>>> Boost_106000; UHD_003.010.000.000-92-ON
>>>
>>> Thanks.
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 74, Issue 15
******************************************
