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. Error codes from uhd::tx_streamer::send (Daryl Lee)
2. Re: Error codes from uhd::tx_streamer::send ([email protected])
3. Re: Error codes from uhd::tx_streamer::send (Martin Braun)
4. Re: Error codes from uhd::tx_streamer::send (Daryl Lee)
5. Range of allowable transmit sample rates, x310 (Daryl Lee)
6. Re: Range of allowable transmit sample rates, x310
(Marcus D. Leech)
7. Re: about FPGA x310 (Sugandha Gupta)
8. Re: USRP device connection issue (Jalal Shams)
9. Re: USRP device connection issue (Marcus D. Leech)
10. Re: USRP device connection issue (Jalal Shams)
11. Re: USRP device connection issue (Jalal Shams)
12. Re: USRP device connection issue (Marcus D. Leech)
13. Re: B205i transient behavior (Dominik Eyerly)
14. 1PPS specs for the X310 (Jason Matusiak)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Apr 2017 10:15:12 -0600
From: Daryl Lee <[email protected]>
To: [email protected]
Subject: [USRP-users] Error codes from uhd::tx_streamer::send
Message-ID:
<CAEu-DVKHeRrafhh=vv+4gl7vln5wbr-lucb_l4t1kix22hu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to stream some data samples stored in a file. I slurp the file
into a holding buffer, from which I initialize small buffers to hand off to
uhd::tx_streamer::send(). In the console, I get a string of L followed by
a string of U. I found the U as "underflow", but I can't find L. I've
seen once or twice a D and an S.
Is there somewhere an explanation of all these "error codes", what they
signify, and what I should look for to eliminate them? I have relied
heavily on the examples tx_samples_from_file (for reading and buffering
files) and tx_waveforms (for the correct calling sequence to the send()
function.
--
*Daryl O. Lee*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/95c3d74a/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 10 Apr 2017 13:37:20 -0400
From: [email protected]
To: Daryl Lee <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Error codes from uhd::tx_streamer::send
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
L is late packet--the packet is marked for timed delivery, but that time
has already expired.
On 2017-04-10 12:15, Daryl Lee via USRP-users wrote:
> I am trying to stream some data samples stored in a file. I slurp the file
> into a holding buffer, from which I initialize small buffers to hand off to
> uhd::tx_streamer::send(). In the console, I get a string of L followed by a
> string of U. I found the U as "underflow", but I can't find L. I've seen
> once or twice a D and an S.
>
> Is there somewhere an explanation of all these "error codes", what they
> signify, and what I should look for to eliminate them? I have relied heavily
> on the examples tx_samples_from_file (for reading and buffering files) and
> tx_waveforms (for the correct calling sequence to the send() function.
>
> --
>
> DARYL O. LEE
> _______________________________________________
> 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/20170410/4ab9814d/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 10 Apr 2017 12:16:17 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Error codes from uhd::tx_streamer::send
Message-ID: <20170410191617.GA27064@glad0s>
Content-Type: text/plain; charset="us-ascii"
See these pages:
http://files.ettus.com/manual/structuhd_1_1async__metadata__t.html
http://files.ettus.com/manual/structuhd_1_1rx__metadata__t.html
http://files.ettus.com/manual/page_usrp_x3x0_config.html#x3x0cfg_hosthw_troubleshooting
Cheers,
Martin
On Mon, Apr 10, 2017 at 10:15:12AM -0600, Daryl Lee via USRP-users wrote:
> I am trying to stream some data samples stored in a file. I slurp the file
> into a holding buffer, from which I initialize small buffers to hand off to
> uhd::tx_streamer::send(). In the console, I get a string of L followed by
> a string of U. I found the U as "underflow", but I can't find L. I've
> seen once or twice a D and an S.
>
> Is there somewhere an explanation of all these "error codes", what they
> signify, and what I should look for to eliminate them? I have relied
> heavily on the examples tx_samples_from_file (for reading and buffering
> files) and tx_waveforms (for the correct calling sequence to the send()
> function.
>
> --
> *Daryl O. Lee*
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/ef392d3f/attachment-0001.asc>
------------------------------
Message: 4
Date: Mon, 10 Apr 2017 14:51:31 -0600
From: Daryl Lee <[email protected]>
To: Martin Braun <[email protected]>, [email protected]
Subject: Re: [USRP-users] Error codes from uhd::tx_streamer::send
Message-ID:
<CAEu-DVJR1EA3G9XXpkB=alkh5mrb9cwb4bvigc8zzopsco1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank You! That's exactly what I needed.
On Mon, Apr 10, 2017 at 1:16 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> See these pages:
>
> http://files.ettus.com/manual/structuhd_1_1async__metadata__t.html
> http://files.ettus.com/manual/structuhd_1_1rx__metadata__t.html
> http://files.ettus.com/manual/page_usrp_x3x0_config.html#
> x3x0cfg_hosthw_troubleshooting
>
> Cheers,
> Martin
>
>
> On Mon, Apr 10, 2017 at 10:15:12AM -0600, Daryl Lee via USRP-users wrote:
> > I am trying to stream some data samples stored in a file. I slurp the
> file
> > into a holding buffer, from which I initialize small buffers to hand off
> to
> > uhd::tx_streamer::send(). In the console, I get a string of L followed
> by
> > a string of U. I found the U as "underflow", but I can't find L. I've
> > seen once or twice a D and an S.
> >
> > Is there somewhere an explanation of all these "error codes", what they
> > signify, and what I should look for to eliminate them? I have relied
> > heavily on the examples tx_samples_from_file (for reading and buffering
> > files) and tx_waveforms (for the correct calling sequence to the send()
> > function.
> >
> > --
> > *Daryl O. Lee*
>
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
*Daryl O. Lee*
Principal Software Engineer
Bluecom Systems and Consulting LLC
505-977-1686
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/bf60bfbd/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 10 Apr 2017 15:36:48 -0600
From: Daryl Lee <[email protected]>
To: [email protected]
Subject: [USRP-users] Range of allowable transmit sample rates, x310
Message-ID:
<CAEu-DVJyFz+T0jH8n4SKAEwPUk=zg-Y+eZuECqFyRanLA=s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
My earlier problem with the string of U output to the console seems to be
directly related to my lack of care as to transmit sample rate; in brief, I
was setting that too high. The next step was to go too low:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 0.050000 MSps
Actual sample rate: 0.390625 MSps
I looked in the x310 documentation and couldn't find specification on the
range of allowed transmit sampling rates. Is that documented somewhere?
(Google doesn't seem to know, either.)
--
*Daryl O. Lee*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/1eb19260/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 10 Apr 2017 17:43:00 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Range of allowable transmit sample rates,
x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 04/10/2017 05:36 PM, Daryl Lee via USRP-users wrote:
> My earlier problem with the string of U output to the console seems to
> be directly related to my lack of care as to transmit sample rate; in
> brief, I was setting that too high. The next step was to go too low:
>
> UHD Warning:
> The hardware does not support the requested TX sample rate:
> Target sample rate: 0.050000 MSps
> Actual sample rate: 0.390625 MSps
>
> I looked in the x310 documentation and couldn't find specification on
> the range of allowed transmit sampling rates. Is that documented
> somewhere? (Google doesn't seem to know, either.)
>
> --
> *Daryl O. Lee*
>
>
Sample-rates on most USRP devices have to be an integer fraction of the
master clock rate, which on the X310 is 200Msps.
Factors that are multiples of 4 work best, due to the interpolation
functions in the DUC, with the highest factor allowed being 512--which
is what produced
the sample-rate shown in your example.
This document in the knowledge base might help:
https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/29bda271/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 10 Apr 2017 15:42:28 -0700
From: Sugandha Gupta <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] about FPGA x310
Message-ID:
<CAG_kd166_dANwUvWnyRRFfCHBV1+gMYB=xi7qqhxb8xejib...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi John
Refer to the Knowledge Base [1] article on FPGA Debugging.
Thanks
Sugandha
[1] https://kb.ettus.com/Debugging_FPGA_images
On Thu, Apr 6, 2017 at 9:28 AM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi John,
>
> well, you will need to build up some familarity with Vivado, in any case,
> since you'll need to build and simulate the X310 code with it in the end.
>
> So, this is a very open-ended question. I just normally connect the
> waveform display probes in Vivado to the ports I'm interested in, which is
> a relatively nice thing to observe while running the normal test benches.
>
> Hope this helps a bit!
>
> Marcus
> On 06.04.2017 11:27, john liu via USRP-users wrote:
>
> Dear all,
> We found that the noc_shell.v file debug [31:0] signal in USRP X310 FPGA
> code, how they are used? What tools to debug you are use?
> We used Chipscope online debugging FPGA code now ,because we are not
> familiar with vivado software.
>
> thank you.
>
> best regards
> John
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Sugandha Gupta
Staff Software Engineer
Ettus Research
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/ed6123e2/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 11 Apr 2017 04:50:29 +0500
From: Jalal Shams <[email protected]>
To: Muhammad Munir <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP device connection issue
Message-ID:
<CAMnwUyTxBgRXTOP5kCjc_18XEHgiw1LjtbJFCvVJYa=bqam...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
Well I have worked on few of the issues I was facing but it is still not
connecting and I am all at loss at the moment. Please look into the
attached screen-shots .
Thanks
Jalal
On Sun, Apr 9, 2017 at 10:07 PM, Muhammad Munir via USRP-users <
[email protected]> wrote:
> Hi Jalal SHams,
> Looking at the screenshots, It looks like you are facing problems with the
> Ethernet connection. First, you have to make sure your PC IP address and
> USRP IP addresses are using same gateway. I mean the IP address of USRP is
> "192.168.10.2", so using gateway of 192.168.*10*.1. You need to verify
> your PC address and It must be of "192.168.10.xx" and gateway
> "192.168.10.1". If you are using Ethernet switch, Its gateway should also
> be of same configuration.
>
> On Sun, Apr 9, 2017 at 8:21 PM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
>> On 04/09/2017 10:45 AM, Jalal Shams via USRP-users wrote:
>>
>>> Hi all,
>>>
>>> I have installed the UHD driver and GNU radio from the following link
>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-S
>>> ource_Toolchain_(UHD_and_GNU_Radio)_on_Linux <
>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-
>>> Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>
>>>
>>> Both were installed and I am sharing the screen shots below ( I think I
>>> might be facing ethernet issue when it comes to its speed 10/100 MBs).
>>> Please help me out.
>>>
>>>
>>> Thanks in advance.
>>> Jalal
>>>
>>>
>>> You absolutely, positively, NEED a 1Gbit-capable port or this isn't
>> going to work. The N2xx series require 1GBit, and the X3xx series required
>> 1Gbit or
>> 10Gbit ethernet ports.
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> 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/20170411/545d4cb3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-04-11 04-42-15.png
Type: image/png
Size: 166082 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170411/545d4cb3/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-04-11 04-43-29.png
Type: image/png
Size: 190926 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170411/545d4cb3/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2017-04-11 04-44-01.png
Type: image/png
Size: 185074 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170411/545d4cb3/attachment-0005.png>
------------------------------
Message: 9
Date: Mon, 10 Apr 2017 20:10:45 -0400
From: "Marcus D. Leech" <[email protected]>
To: Jalal Shams <[email protected]>, Muhammad Munir
<[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] USRP device connection issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/10/2017 07:50 PM, Jalal Shams wrote:
> Hi all,
>
> Well I have worked on few of the issues I was facing but it is still
> not connecting and I am all at loss at the moment. Please look into
> the attached screen-shots .
>
> Thanks
> Jalal
Reminds us all, please of what type of device this is? Is this an N2xx,
or an X3xx?
What is the history of the device, was it brand-new when you got it? Is
it a lab instrument that someone else may have used, and changed the
address of?
>
> On Sun, Apr 9, 2017 at 10:07 PM, Muhammad Munir via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Jalal SHams,
> Looking at the screenshots, It looks like you are facing problems
> with the Ethernet connection. First, you have to make sure your PC
> IP address and USRP IP addresses are using same gateway. I mean
> the IP address of USRP is "192.168.10.2", so using gateway of
> 192.168.*10*.1. You need to verify your PC address and It must be
> of "192.168.10.xx" and gateway "192.168.10.1". If you are using
> Ethernet switch, Its gateway should also be of same configuration.
>
> On Sun, Apr 9, 2017 at 8:21 PM, Marcus D. Leech via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> On 04/09/2017 10:45 AM, Jalal Shams via USRP-users wrote:
>
> Hi all,
>
> I have installed the UHD driver and GNU radio from the
> following link
>
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>
>
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux
>
> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>>
>
> Both were installed and I am sharing the screen shots
> below ( I think I might be facing ethernet issue when it
> comes to its speed 10/100 MBs).
> Please help me out.
>
>
> Thanks in advance.
> Jalal
>
>
> You absolutely, positively, NEED a 1Gbit-capable port or this
> isn't going to work. The N2xx series require 1GBit, and the
> X3xx series required 1Gbit or
> 10Gbit ethernet ports.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/69873a2d/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 11 Apr 2017 05:19:43 +0500
From: Jalal Shams <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Muhammad Munir <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP device connection issue
Message-ID:
<camnwuyrsqy7h7xgopa5wwp-e03wmlba_nkvam1mfnzriqkh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It is a lab instrument
On Tue, Apr 11, 2017 at 5:10 AM, Marcus D. Leech <[email protected]> wrote:
> On 04/10/2017 07:50 PM, Jalal Shams wrote:
>
> Hi all,
>
> Well I have worked on few of the issues I was facing but it is still not
> connecting and I am all at loss at the moment. Please look into the
> attached screen-shots .
>
> Thanks
> Jalal
>
> Reminds us all, please of what type of device this is? Is this an N2xx,
> or an X3xx?
>
> What is the history of the device, was it brand-new when you got it? Is
> it a lab instrument that someone else may have used, and changed the
> address of?
>
>
>
> On Sun, Apr 9, 2017 at 10:07 PM, Muhammad Munir via USRP-users <
> [email protected]> wrote:
>
>> Hi Jalal SHams,
>> Looking at the screenshots, It looks like you are facing problems with
>> the Ethernet connection. First, you have to make sure your PC IP address
>> and USRP IP addresses are using same gateway. I mean the IP address of USRP
>> is "192.168.10.2", so using gateway of 192.168.*10*.1. You need to
>> verify your PC address and It must be of "192.168.10.xx" and gateway
>> "192.168.10.1". If you are using Ethernet switch, Its gateway should also
>> be of same configuration.
>>
>> On Sun, Apr 9, 2017 at 8:21 PM, Marcus D. Leech via USRP-users <
>> [email protected]> wrote:
>>
>>> On 04/09/2017 10:45 AM, Jalal Shams via USRP-users wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have installed the UHD driver and GNU radio from the following link
>>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-S
>>>> ource_Toolchain_(UHD_and_GNU_Radio)_on_Linux <
>>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-
>>>> Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>
>>>>
>>>> Both were installed and I am sharing the screen shots below ( I think I
>>>> might be facing ethernet issue when it comes to its speed 10/100 MBs).
>>>> Please help me out.
>>>>
>>>>
>>>> Thanks in advance.
>>>> Jalal
>>>>
>>>>
>>>> You absolutely, positively, NEED a 1Gbit-capable port or this isn't
>>> going to work. The N2xx series require 1GBit, and the X3xx series required
>>> 1Gbit or
>>> 10Gbit ethernet ports.
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>> _______________________________________________
>> 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/20170411/b638f1d0/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 11 Apr 2017 05:21:06 +0500
From: Jalal Shams <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: Muhammad Munir <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP device connection issue
Message-ID:
<CAMnwUyTfVWvP_YSEn3E60Hbo+hhXrUaG_US40cLpZRNg=b=j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
USRP 2 N210 , can I somehow find its IP if its changed ?
On Tue, Apr 11, 2017 at 5:19 AM, Jalal Shams <[email protected]> wrote:
> It is a lab instrument
>
> On Tue, Apr 11, 2017 at 5:10 AM, Marcus D. Leech <[email protected]>
> wrote:
>
>> On 04/10/2017 07:50 PM, Jalal Shams wrote:
>>
>> Hi all,
>>
>> Well I have worked on few of the issues I was facing but it is still not
>> connecting and I am all at loss at the moment. Please look into the
>> attached screen-shots .
>>
>> Thanks
>> Jalal
>>
>> Reminds us all, please of what type of device this is? Is this an N2xx,
>> or an X3xx?
>>
>> What is the history of the device, was it brand-new when you got it? Is
>> it a lab instrument that someone else may have used, and changed the
>> address of?
>>
>>
>>
>> On Sun, Apr 9, 2017 at 10:07 PM, Muhammad Munir via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi Jalal SHams,
>>> Looking at the screenshots, It looks like you are facing problems with
>>> the Ethernet connection. First, you have to make sure your PC IP address
>>> and USRP IP addresses are using same gateway. I mean the IP address of USRP
>>> is "192.168.10.2", so using gateway of 192.168.*10*.1. You need to
>>> verify your PC address and It must be of "192.168.10.xx" and gateway
>>> "192.168.10.1". If you are using Ethernet switch, Its gateway should also
>>> be of same configuration.
>>>
>>> On Sun, Apr 9, 2017 at 8:21 PM, Marcus D. Leech via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> On 04/09/2017 10:45 AM, Jalal Shams via USRP-users wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have installed the UHD driver and GNU radio from the following link
>>>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-S
>>>>> ource_Toolchain_(UHD_and_GNU_Radio)_on_Linux <
>>>>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-
>>>>> Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>
>>>>>
>>>>> Both were installed and I am sharing the screen shots below ( I think
>>>>> I might be facing ethernet issue when it comes to its speed 10/100 MBs).
>>>>> Please help me out.
>>>>>
>>>>>
>>>>> Thanks in advance.
>>>>> Jalal
>>>>>
>>>>>
>>>>> You absolutely, positively, NEED a 1Gbit-capable port or this isn't
>>>> going to work. The N2xx series require 1GBit, and the X3xx series required
>>>> 1Gbit or
>>>> 10Gbit ethernet ports.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20170411/c31dde27/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 10 Apr 2017 20:27:54 -0400
From: "Marcus D. Leech" <[email protected]>
To: Jalal Shams <[email protected]>
Cc: Muhammad Munir <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] USRP device connection issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 04/10/2017 08:21 PM, Jalal Shams wrote:
> USRP 2 N210 , can I somehow find its IP if its changed ?
My recollection is that it sends out unsolicited ARP replies when it
powers up. You could stick WireShark on that port and look for that
traffic--I assume that
the N210 is the only thing on that port on your PC?
Failing that, you could use nmap in ICMP mode to discover what address
it's using--but that's assuming that it's at least on the correct subnet.
You could also follow the instructions here:
https://files.ettus.com/manual/page_usrp2.html#usrp2_network_changeip
>
>
> On Tue, Apr 11, 2017 at 5:19 AM, Jalal Shams <[email protected]
> <mailto:[email protected]>> wrote:
>
> It is a lab instrument
>
> On Tue, Apr 11, 2017 at 5:10 AM, Marcus D. Leech
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 04/10/2017 07:50 PM, Jalal Shams wrote:
>> Hi all,
>>
>> Well I have worked on few of the issues I was facing but it
>> is still not connecting and I am all at loss at the moment.
>> Please look into the attached screen-shots .
>>
>> Thanks
>> Jalal
> Reminds us all, please of what type of device this is? Is
> this an N2xx, or an X3xx?
>
> What is the history of the device, was it brand-new when you
> got it? Is it a lab instrument that someone else may have
> used, and changed the
> address of?
>
>
>>
>> On Sun, Apr 9, 2017 at 10:07 PM, Muhammad Munir via
>> USRP-users <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Jalal SHams,
>> Looking at the screenshots, It looks like you are facing
>> problems with the Ethernet connection. First, you have to
>> make sure your PC IP address and USRP IP addresses are
>> using same gateway. I mean the IP address of USRP is
>> "192.168.10.2", so using gateway of 192.168.*10*.1. You
>> need to verify your PC address and It must be of
>> "192.168.10.xx" and gateway "192.168.10.1". If you are
>> using Ethernet switch, Its gateway should also be of same
>> configuration.
>>
>> On Sun, Apr 9, 2017 at 8:21 PM, Marcus D. Leech via
>> USRP-users <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On 04/09/2017 10:45 AM, Jalal Shams via USRP-users wrote:
>>
>> Hi all,
>>
>> I have installed the UHD driver and GNU radio
>> from the following link
>>
>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>>
>> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>
>>
>> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux
>>
>> <https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>>
>>
>> Both were installed and I am sharing the screen
>> shots below ( I think I might be facing ethernet
>> issue when it comes to its speed 10/100 MBs).
>> Please help me out.
>>
>>
>> Thanks in advance.
>> Jalal
>>
>>
>> You absolutely, positively, NEED a 1Gbit-capable port
>> or this isn't going to work. The N2xx series require
>> 1GBit, and the X3xx series required 1Gbit or
>> 10Gbit ethernet ports.
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170410/e36fbee2/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 11 Apr 2017 10:11:04 +0200
From: Dominik Eyerly <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
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
>>>>>>>> Fax: +49 (0) 351 7958019 232
>>>>>>>> Email: [email protected]
>>>>>>>> <mailto:[email protected]>
>>>>>>>>
>>>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>>>
>>>>>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>>>>>> [email protected]
>>>>>>>> <mailto:[email protected]>
>>>>>>>> sig
>>>>>>>> Gesch?ftsleitung: Michael Konrad
>>>>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>>>>> Ust-Id-Nr. DE 206693267
>>>>>>>>
>>>>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r
>>>>>>>> die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe
>>>>>>>> an nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen
>>>>>>>> k?nnen Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>>>>
>>>>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may
>>>>>>>> accompany it, contains information from Konrad GmbH, which is intended
>>>>>>>> only for the use of the individual or entity to which it is addressed,
>>>>>>>> and which may contain information that is privileged, confidential,
>>>>>>>> and/or otherwise exempt from disclosure under applicable law. If the
>>>>>>>> reader of this message is not the intended recipient, any disclosure,
>>>>>>>> dissemination, distribution, copying or other use of this
>>>>>>>> communication or its substance is prohibited. If you have received
>>>>>>>> this communication in error, please contact us immediately. Thank you.
>>>>>>>> _______________________________________________ USRP-users
>>>>>>>> mailing list [email protected]
>>>>>>>> <mailto:[email protected]>
>>>>>>>> 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: [email protected]
>>>>>> <mailto:[email protected]>
>>>>>>
>>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>>>
>>>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>>>> [email protected]
>>>>>> <mailto:[email protected]>
>>>>>> sig
>>>>>> Gesch?ftsleitung: Michael Konrad
>>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>>> Ust-Id-Nr. DE 206693267
>>>>>>
>>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen
>>>>>> Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>>
>>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may
>>>>>> accompany it, contains information from Konrad GmbH, which is intended
>>>>>> only for the use of the individual or entity to which it is addressed,
>>>>>> and which may contain information that is privileged, confidential,
>>>>>> and/or otherwise exempt from disclosure under applicable law. If the
>>>>>> reader of this message is not the intended recipient, any disclosure,
>>>>>> dissemination, distribution, copying or other use of this communication
>>>>>> or its substance is prohibited. If you have received this communication
>>>>>> in error, please contact us immediately. Thank you.
>>>> --
>>>>
>>>> --
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233
>>>> Fax: +49 (0) 351 7958019 232
>>>> Email: [email protected]
>>>> <mailto:[email protected]>
>>>>
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>>>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>>>> www.abexstandard.org <http://www.abexstandard.org>
>>>>
>>>> *Support Telefon: +49 (0) 7732 9815 100*
>>>> [email protected] <mailto:[email protected]>
>>>> sig
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which may
>>>> contain information that is privileged, confidential, and/or otherwise
>>>> exempt from disclosure under applicable law. If the reader of this message
>>>> is not the intended recipient, any disclosure, dissemination,
>>>> distribution, copying or other use of this communication or its substance
>>>> is prohibited. If you have received this communication in error, please
>>>> contact us immediately. Thank you.
>> --
>>
>> --
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233
>> Fax: +49 (0) 351 7958019 232
>> Email: [email protected]
>> <mailto:[email protected]>
>>
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
>> www.konrad-technologies.de <http://www.konrad-technologies.de>
>> www.abexstandard.org <http://www.abexstandard.org>
>>
>> *Support Telefon: +49 (0) 7732 9815 100*
>> [email protected] <mailto:[email protected]>
>> sig
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
--
--
i.A. Dominik Eyerly
Software
Tel: +49 (0) 351 7958019 233
Fax: +49 (0) 351 7958019 232
Email: [email protected]
<mailto:[email protected]>
*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
www.konrad-technologies.de <http://www.konrad-technologies.de>
www.abexstandard.org <http://www.abexstandard.org>
*Support Telefon: +49 (0) 7732 9815 100*
[email protected] <mailto:[email protected]>
sig
Gesch?ftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267
VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person
bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen
sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind
verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie
nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke
CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it,
contains information from Konrad GmbH, which is intended only for the use of
the individual or entity to which it is addressed, and which may contain
information that is privileged, confidential, and/or otherwise exempt from
disclosure under applicable law. If the reader of this message is not the
intended recipient, any disclosure, dissemination, distribution, copying or
other use of this communication or its substance is prohibited. If you have
received this communication in error, please contact us immediately. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170411/b40ad86f/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/20170411/b40ad86f/attachment-0004.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/20170411/b40ad86f/attachment-0005.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/20170411/b40ad86f/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/20170411/b40ad86f/attachment-0007.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170411/b40ad86f/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170411/b40ad86f/attachment-0001.asc>
------------------------------
Message: 14
Date: Tue, 11 Apr 2017 07:49:02 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] 1PPS specs for the X310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Is there a minimum requirement for the 1PPS input for the X310? We have
an OctoClock that seems to work fine with its 25% duty cycle, but I have
a Rubidium clock source whose 1PPS is only high for 10us, but that
doesn't seem to be working for the X310. At a running 200Mhz master
clock rate on the X310, 10us is 2000 clock ticks, I would have assumed
that that was more than long enough to trigger the internal 1PPS logic.
Is there a spec written up somewhere for the minimum duty cycle for the
1PPS input?
------------------------------
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 11
******************************************
