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. Windows UHD C++ API (Krzysztof Cwalina)
2. Configuring the USRP X310 for Labview (Kalen Williams)
3. Re: Use of external reference clock to sync the internal
clock of X310 USRPs (Isen I-Chun Chao)
4. Re: Zeros are not zero? (Jim Hunziker)
5. Re: Use of external reference clock to sync the internal
clock of X310 USRPs (Ian Buckley)
6. Re: USRP B210 GPS Time w/Master Clock Rate (Ben Hilburn)
7. Re: Windows UHD C++ API (Ben Hilburn)
8. Re: UHD 003.008.000 N210R4: SPI CLOCK not changeable anymore
(Ben Hilburn)
9. Re: x300 on Windows 7 and 10GbE: getting ?S? and ?U? from UHD
(Ben Hilburn)
10. Re: Use of external reference clock to sync the internal
clock of X310 USRPs (Isen I-Chun Chao)
11. Re: Use of external reference clock to sync the internal
clock of X310 USRPs (Ian Buckley)
12. X310 vs N210 with LFRX digital gain problems (Louis Brown)
13. Re: B200 UHD 3.8.0: UHD Error: recv packet demuxer unexpected
sid... (Ralph A. Schmid, dk5ras)
14. Re: Windows UHD C++ API (Krzysztof Cwalina)
15. Re: Windows UHD C++ API (Nir Eden)
16. Re: Windows UHD C++ API (Krzysztof Cwalina)
17. Re: B200 UHD 3.8.0: UHD Error: recv packet demuxer unexpected
sid... (Andy Walls)
----------------------------------------------------------------------
Message: 1
Date: Fri, 07 Nov 2014 14:49:50 +0100
From: Krzysztof Cwalina <kkcwal...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Windows UHD C++ API
Message-ID: <545ccdfe.3040...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
in my project I just write the C++ DLL Library and import it into C#
project. The problem is - there are some problems with the UHD. My platform:
Windows 7 x64,
Visual Studio 2013 Pro
when I run project sometimes on the line: uhd::usrp::multi_usrp::sptr
usrp = uhd::usrp::multi_usrp::make(args); there is exception like:
A first chance exception of type
'System.Runtime.InteropServices.SEHException' occurred in USRPTest.exe
Additional information: External component has thrown an exception.
Sometimes it is - sometimes is not (depends on how many times I compile
the same code. Next problem is when I want to use two methods:
usrp->set_clock_source("internal"); or uhd::stream_args_t
stream_args("fc32");
Same error show up. I tried everything, I've searched almost all topics
about this subject - but I didn't found the solution. Can anyone help me?
Thanks.
------------------------------
Message: 2
Date: Fri, 7 Nov 2014 14:37:28 -0600
From: Kalen Williams <wenlak93.m...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Configuring the USRP X310 for Labview
Message-ID:
<CAPTvN3k0Ly=bExFfBiCOawnB-WOi_+S_A04YeKPH3Zc4m+y=s...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm a know nothing undergraduate student trying to set up this board to run
simple signal generation and capture in Labview. I can't get the image to
agree with the Labview driver. When I try to run labview code using the
NI-USRP library it gives me:
Error-1074118627 occurred at niUSRP Open Tx Session.vi
Possible reason(s):
A runtime or configuration error occurred.
Code: 1440
Details: RuntimeError: Expected FPGA compatibility number 0x6, but got
0x7.0:
The FPGA build is not compatible with the host code build.
As an Administrator, please run:
"C:\Program Files (x86)\UHD\lib\uhd\utils\uhd_images_downloader.py" I'm
using the usrp_x310_fpga_HGS.lvbitx image.
What do I need to do?
C:\Program Files (x86)\UHD\bin>uhd_usrp_probe.exe
Win32; Microsoft Visual C++ version 10.0; Boost_105400;
UHD_003.007.002-90-unsta
ble
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- Initialize Radio control...
UHD Warning:
The MTU (1472) is larger than the FastSendDatagramThreshold (1024)!
This will negatively affect the transmit performance.
See the transport application notes for more detail.
-- Creating WSA UDP transport for 192.168.10.2:49153
-- Performing register loopback test... pass
-- Sync DAC's.
-- Creating WSA UDP transport for 192.168.10.2:49153
-- Performing register loopback test... pass
-- Sync DAC's.
-- Initializing clock and PPS references...
-- References initialized to internal sources
_____________________________________________________
/
| Device: X-Series Device
| _____________________________________________________
| /
| | Mboard: X310
| | revision: 6
| | product: 30410
| | mac-addr0: 00:80:2f:0a:f9:8b
| | mac-addr1: 00:80:2f:0a:f9:8c
| | gateway: 192.168.10.1
| | ip-addr0: 192.168.10.2
| | subnet0: 255.255.255.0
| | ip-addr1: 192.168.20.2
| | subnet1: 255.255.255.0
| | ip-addr2: 192.168.30.2
| | subnet2: 255.255.255.0
| | ip-addr3: 192.168.40.2
| | subnet3: 255.255.255.0
| | serial: F589F2
| | FW Version: 3.0
| | FPGA Version: 7.0
| |
| | Time sources: internal, external, gpsdo
| | Clock sources: internal, external, gpsdo
| | Sensors: ref_locked
| | _____________________________________________________
| | /
| | | RX DSP: 0
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | RX DSP: 1
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | RX Dboard: A
| | | ID: SBX-120 (0x0083)
| | | Serial: F5633A
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: SBX-120 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: A
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | RX Dboard: B
| | | ID: SBX-120 (0x0083)
| | | Serial: F56338
| | | _____________________________________________________
| | | /
| | | | RX Frontend: 0
| | | | Name: SBX-120 RX
| | | | Antennas: TX/RX, RX2, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: IQ
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: B
| | | | Name: ads62p48
| | | | Gain range digital: 0.0 to 6.0 step 0.5 dB
| | _____________________________________________________
| | /
| | | TX DSP: 0
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | TX DSP: 1
| | | Freq range: -100.000 to 100.000 Mhz
| | _____________________________________________________
| | /
| | | TX Dboard: A
| | | ID: SBX-120 (0x0082)
| | | Serial: F5633A
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: SBX-120 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: A
| | | | Name: ad9146
| | | | Gain Elements: None
| | _____________________________________________________
| | /
| | | TX Dboard: B
| | | ID: SBX-120 (0x0082)
| | | Serial: F56338
| | | _____________________________________________________
| | | /
| | | | TX Frontend: 0
| | | | Name: SBX-120 TX
| | | | Antennas: TX/RX, CAL
| | | | Sensors: lo_locked
| | | | Freq range: 400.000 to 4400.000 Mhz
| | | | Gain range PGA0: 0.0 to 31.5 step 0.5 dB
| | | | Connection Type: QI
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: B
| | | | Name: ad9146
| | | | Gain Elements: None
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141107/c7602f6d/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 7 Nov 2014 16:51:27 -0500
From: Isen I-Chun Chao <chao...@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] Use of external reference clock to sync the
internal clock of X310 USRPs
Message-ID:
<caeg73krzioip_sg4fycapt5thoqo_jzhhou0k6h+q3u7iut...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Marcus,
I took a look at the the X3x0 schematic (
http://files.ettus.com/schematics/x300/x3xx.pdf).
1a) According to the page 1 and page 11 of X3x0 schematic, it looks like
that there is a 96MHz main oscillator as a master clock and it will
redistributed to DAC/ADC. Then what is the "200MHz default master clock"
you mentioned previously?
1b). In the page 1 and pgae 12 of the X3x0 schematic, there is three are
internal 10MHz TCXO, external 10MHz interface and the GPSDO interface so I
can understand how set_clock_source() works for selecting one of them.
However, I don't understand the role that the 96MHz main oscillator and the
internal 10MHz TCXO play, respectively. What are they responsible for,
respectively, in X310 architecture?
2). Just to make sure we are in the same page, by talking about "there
are multiple
clock domains in X310" in your previously email, did you mean the output of
"clock gen" block in the X3x0 schematic?
3) According to your answer for the question about set_time_source(): "Setting
the time source -- ie. saying that the internal time of the X310 should
come from the GPSDO or somewhere else." and the page one of the X3x0
schematic, there must be time registers design in the FPGA and the content
of the time registers are something like second and nanosecond, counting
based on one of the output of "Clock Gen" connecting to FPGA. Do I
understand it correctly? If so, what is the time source this clock signal
based on? the internal 10MHz TCXO or the 96MHz main oscillator?
4) Regarding the previous question of using set_clock_source() and
set_time_source(), I was asking if these two method is one-time use. Like
people write a Linux drivers to access a hardware device attached on
computer and set up a register to enable some feature of the hardware
device as a configuration process. This only needs to be done in the
initialization phase of loading a driver program or running a driver
program. So If I turn the X310 on and plug the reference clock, I only need
to call set_clock_source("external")/set_time_source("external") one time
and the X3x0 will be configured as working on external reference until I
turned the X310 off.
I am using uhd 3.7.3. I will install the newest one and give it a try to
see if I still have lo_locked failed warning. And for your interest
question, I don't have the measure result regarding to the clock stability
using T-connector with me. But based on our previous related experimental
work, one-stage of our T-connector will be just fine. And the precision we
do care is not the frequency output, which is used for verifying if the
internal clock follows external clock. We actually care about the precision
of a generated time-stamp in the FPGA.
*Best Regards,Isen I-Chun Chao*
On Fri, Nov 7, 2014 at 5:39 AM, Marcus M?ller <marcus.muel...@ettus.com>
wrote:
> Hello Isen,
> On 06.11.2014 23:08, Isen I-Chun Chao wrote:
> > Hi Marcus,
> > In our application, the quality of clock is extremely affect our
> interest.
> > So clearly understanding of what clock source is related to our
> application
> > is important. That is why we are using atomic clock as the external
> > reference.
> As this is interesting to me: What are your accuracy needs?
> Have you measured phase noise with a highspeed oscilloscope when using
> your t-connector with 50Ohm termination on the measurement end, and a
> running X310 plugged in to the other end of the t-piece? You really have
> to make sure the signal quality is excellent if you want to be better
> than the internal oscillator, and thus should ensure your external
> cabling doesn't eliminate the gain in clock stability you get by using
> an atomic clock by introducing phase noise.
>
> > Besides, the USRP Tx and Rx will be respectively coordinating with other
> > devices. It is expected to be separated.
> Ah, so you need two USRPs to simulate your comm system.
> > That is why two USRPs are used. I
> > agree with you. I don't think Daisy-chain is appropriate in the our use
> > case.
> >
> > Following are extended questions:
> > 1a). By talking about internal clock, does it mean the 200MHz clock?
> Um, there are dozens of internal clocks in the X310; I don't know which
> statement you are referring to. Most probably, when we're talking about
> "internal clock source", we mean the 10MHz reference clock.
> >
> > 1b). According to the manual there are "set_clock_source()",
> > "set_clock_source_out()", "set_time_source()", "set_time_source_out()".
> And
> > I wonder if I set_clock_source_out() and set_time_source_out() are only
> > used for enabling/disabling Ref and PPS output respectively.
>
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a60445c1a52e4763b6ebbbfce2db96569
> yes.
> > If so, what is
> > the Ref output based on? The 200MHz clock?
> I'm assuming you're referring to the 200MHz default master clock rate,
> which it cannot be based on, as that clock is adjustable and the Ref Out
> must be 10MHz.
>
> Compare page 11 of the X300 schematic:
> http://files.ettus.com/schematics/x300/x3xx.pdf
> The ref clock output gets generated directly by the central clock
> generation, stabilization and distribution IC, the LMK04816, which means
> it's derived inside that chip from the reference clock with the help of
> stabilization and further oscillators. I must admit that I still haven't
> gotten around to understanding the workings of the LMK in fullness; it's
> a complex piece of hardware, and for you, as a user, it basically "does
> what it should".
> >
> > 1c). Is the PPS output based on a register maintaining count ticks from
> > 200MHz clock, or based on what mechanism?
> Depends on whether you use an actual PPS as input (in which case that
> one is used) or not (in which case ticks are counted in the FPGA).
> > 1d). What is the concrete use case of set_time_source() in USRP X310?
> Setting the time source -- ie. saying that the internal time of the X310
> should come from the GPSDO or somewhere else.
> > If I
> > have an external PPS reference connected to X310 and I use this method,
> > does that mean the PPS signal (including the PPS output) throughout whole
> > X310 will BE the external PPS reference?
> yes.
> >
> > 2). Is the method, set_clock_source() (so are et_clock_source_out(),
> > set_time_source(), set_time_source_out()), needed to use only one time
> > (call it for configuring USRP, and USRP will stay using external clock
> > until it is powered off)?
> I don't understand, sorry. Every USRP can only have one device time.
> >
> > 3). If I run applications in GRC on USRP without connecting an external
> > clock (and I did not use set_clock_source() either), I always got warning
> > message "WARN: Sensor 'lo_locked' failed to lock within timeout on
> channel 0";
> > however, if I connect the atomic clock as an external clock, there is no
> > such warning message. Looks like there is something activated after
> > plugging eternal clock. If so, what is that? something like the PLL
> locking
> > mechanism?
> Yes, that is the information that the USRP couldn't gain a stabilized
> clock, which is a bad thing as is.
> However, there is no way to detect whether a cable is connected to the
> ref in port, which means that either the external clock source is
> selected in the UHD source/sinks options, or you have a problem with the
> clock locking mechanism.
> Are you using a recent version of UHD?
>
> Greetings,
> Marcus
>
> >
> >
> >
> >
> >
> >
> > *Best Regards,Isen I-Chun Chao*
> >
> > On Tue, Nov 4, 2014 at 4:22 PM, Marcus M?ller <marcus.muel...@ettus.com>
> > wrote:
> >
> >> Hi Isen,
> >> On 04.11.2014 21:37, Isen I-Chun Chao wrote:
> >>> Hi Marcus Leech and Marcus Muller,
> >>> Thanks for the answers. But I am a little bit confused.
> >>>
> >>> Once I connect the atomic and X310, hardware (X310 USRPs) should
> operate
> >>> based on external clock (atomic clock)
> >> no, you must explicitely select the external clock source.
> >>> due to the daisy-chain(?).
> >> Daisy-chaining is the option to connect the reference output of one USRP
> >> to the reference input of the next; inherently, it doesn't relate to
> >> your use case.
> >>> This is
> >>> regardless of application use.
> >> Depends on what your application wants to do. Most application will not
> >> care where the reference comes from -- but you'll still need to set the
> >> reference source.
> >>> And I should have synchronized signal from
> >>> REF outputs of two USRPs, right?
> >>>
> >>> If applications did not set up the use of external clock by using
> >>> set_clock_source(), the application is going to use the default clock
> on
> >>> X310 USRPs. (?)
> >> yes.
> >>> What clock the FPGA is based on? because the FPGA code will be modified
> >>> working on our application.
> >> The FPGA design has multiple clock domains. The most important clock
> >> domain is driven at the master clock rate, which is 200MHz by default,
> >> but can take more values (see UHD manual).
> >>> BTW, the two X310 USRPs are Tx and Rx.
> >> Each X310 has two completely independent TX and RX chains. Unless you
> >> need to have them in two different places, I'm afraid I don't understand
> >> why you need two X310.
> >>> I am not using them as MIMO. The
> >>> reason I want to make sure their clock can synchronized to an atomic
> >> clock
> >>> is that I would like to draw timestamps on both Tx and Rx based on the
> >>> clock on USRPs. I use T-connectors to distribute atomic signals to two
> >> X310
> >>> USRP.
> >> T-Connectors might or might not work -- distributing a 10MHz clock is a
> >> bit of a tricky task, since reflections might mess up your phase
> >> quality. Also, you split energy (let's say by half) between the two
> >> USRPs! Make sure you're still able to reliably drive the clock inputs.
> >> Usually, this is a case where you would need a proper clock distributor,
> >> or a forwarding solution (such as daisy-chaining). For PPS synchronity,
> >> you really should make sure you know what you're doing on the signal
> >> distribution. I can see that daisy chaining will not be a good solution
> >> here, unless you calibrate (which you could easily do).
> >>
> >> Best regards,
> >> Marcus
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *Best Regards,Isen I-Chun Chao*
> >>>
> >>> On Tue, Nov 4, 2014 at 3:11 PM, Marcus M?ller <
> >> usrp-users@lists.ettus.com>
> >>> wrote:
> >>>
> >>>> Hi Isen,
> >>>>
> >>>> yes, you're understanding correctly, but you'll have to select the
> >>>> external reference explicitely using the set_clock_source method.
> >>>> Also, your atomic clock has to have the possibility to drive two
> >>>> receivers; distributing clock signals correctly isn't inherently
> >> trivial.
> >>>> For this reason, the X3x0s have the ability to "daisy-chain" the
> >> reference
> >>>> and PPS signals.
> >>>>
> >>>> Greetings,
> >>>> Marcus
> >>>>
> >>>>
> >>>> On 04.11.2014 20:48, Isen I-Chun Chao via USRP-users wrote:
> >>>>
> >>>> Hi,
> >>>> If I have a atomic clock with me and would like to two X310 USRP
> >>>> synchronize to this atomic clock.
> >>>> I just connect the PPS output and the 10MHz Ref output on atomic clock
> >> to
> >>>> the input of two USRP. As long as the 'REF' leds on the front panel of
> >> X310
> >>>> USRPs are turned on, the internal clock of X310 USRPs are locked. No
> >>>> further settings are required.
> >>>>
> >>>> Am I understanding it right?
> >>>> Thanks.
> >>>>
> >>>>
> >>>>
> >>>> *Best Regards,Isen I-Chun Chao*
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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/20141107/c881ec52/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 7 Nov 2014 17:31:27 -0500
From: Jim Hunziker <jhunzi...@bcisensors.com>
To: Ian Buckley <i...@ionconcepts.com>
Cc: usrp-users <usrp-users@lists.ettus.com>, Timothy Maese
<tma...@bcisensors.com>
Subject: Re: [USRP-users] Zeros are not zero?
Message-ID:
<cagh06jvprqyr5pjsgspf7l4opstxgebq+_wpprtd_wm5eee...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'm only reading this for the first time today, and I'm still thinking
through some of what you said. One thing you misinterpreted, though, was
the number of samples I'm sending. I'm not sending sixteen samples of
zeros. I'm sending a pulse of 4000 samples of zeros sixteen times. The
groups of sixteen are what you see as groups of sixteen spikes in the
zoomed out plot. Each pulse of 4000 zeros starts 2 ms after the previous
one. (The sampling rate is 25 MHz.) The zoomed out plot I sent may have
been misleading because the X axis has units of hundreds of samples.
In my actual application, I'm trying to send 2000 signal samples with 1000
zero samples before it and 1000 zero samples after it. I was hoping that
would be enough to clear the transient effects.
So my application is trying to toggle TX every 2 milliseconds or so.
I'm starting to think that my problem is the same as the DC calibration
problem that my colleague is working with Michael West on. I believe he's
working on an FPGA load that will help with the application of calibration
files.
Thank you for your help.
--
Jim Hunziker
BCI Systems and Software Engineering
jhunzi...@bcisensors.com
On Tue, Nov 4, 2014 at 2:12 PM, Ian Buckley <i...@ionconcepts.com> wrote:
> Jim,
> I just wanted to add a little more to perhaps give you a better visual
> about how this is working as a system.
>
> If I understand you correctly you are generating a transmit burst of 16
> samples each with complex value 0 and attaching a time spec to the start of
> that burst?you create six of these bursts in short (time) proximity.
>
> When that time spec matches the clock inside the X300 a state machine
> inside X300 will shift to an active transmit state and start pushing those
> samples into the input of the transmit DSP?depending how the DSP is
> configured (interpolation rate) there will then be a delay on the order of
> tens (possibly low hundreds) of clock cycles (@200MHz - 5nS per tick)
> before that data hits the DAC. Meanwhile that transition in the state
> machine also causes control signals to propagate to the daughter card radio
> to change the configuration for TX?applying gain settings and enabling the
> power amp, possibly also turning on a power supply regulator (all daughter
> board design dependant). As you can imagine it takes some time, a handful
> of digital clock cycles then some analog time for those control signals to
> take effect and for those components to come into a new stable state. 16
> sample times (interpolation rate sets this time) later that state machine
> goes idle and those control signals transition again turning off the power
> amp etc. It's quite conceivable that none of your zero's have even hit the
> DAC by then (though the starting state of the DSP pipeline would be
> initialized to zero samples).
>
> I think it would be interesting for you to create a much longer
> transmission pulse on the order of thousands of samples (of zero) to
> establish a baseline of what the TX looks like in a steady state once all
> this transient behavior is discarded, what you should see is the residual
> DC offset in your system plus whatever noise sources exist in the analog
> circuits.
>
> I guess what I'm driving at is that if you need to build an application
> that toggles the TX on and off every tens or hundreds of nS then your going
> to have to think in detail about the underlying implementation of the H/W
> more closely. If I was building some type of pulsed application (UWB/RADAR
> etc) then I'd likely stream continuously and just return to the digital
> silence state between pulses.
>
> Things that might help you:
>
> Calibrate your daughter card to minimize DC offset (See app notes if you
> need to know how)
> Interpolation rate 1x will have the minimal system latency for samples as
> all FIR filters are bypassed?(still 10's of cycles delay) ?.but you'll have
> to deal with the serious challenge of feeding a 200MSps stream from the
> host.
>
> -Ian
>
> p.s. I'm curious to see a plot zoomed into to one 16 sample burst?to my
> eye's it doesn't look like I expected from my understanding of the various
> factors.
>
> On Nov 4, 2014, at 7:49 AM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> You might try ramping the TX gain down as you're ramping-down your
> baseband signal.
>
> At the end of the day, you're dealing with analog electronics and "zero"
> is only really notional zero. There'll be a tiny bit of voltage coming out
> of the DAC even at a binary setting of 0. There'll be a tiny amount of
> bias on the mixer, even when there's only effectively "ground" going into
> the IF port.
>
>
>
>
> On 2014-11-04 10:21, Jim Hunziker via USRP-users wrote:
>
> I have a program that sends pulses out at 5.6 GHz. It does this by
> using the time_spec in the metadata to schedule these pulses.
>
> When I make these pulses have nothing but zeros in them, the transmitter
> is still emitting at a higher power than when nothing is scheduled. How can
> I get my zeros to be as low as the quiet state? I want this because, when
> zero-padding the sides of my desired pulse, I keep getting a big jump above
> the noise floor where the zeros are sent.
>
> Attached are zoomed out and zoomed in plots of the magnitude of the
> received signal when sending pulsed zeros. (The pulses are sent in groups
> of 16, and the plot shows 6 of these groups.)
>
> Thanks.
>
> --
> Jim Hunziker
> BCI Systems and Software Engineering
> jhunzi...@bcisensors.com
>
> _______________________________________________
> 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/20141107/69192280/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 7 Nov 2014 14:34:36 -0800
From: Ian Buckley <i...@ionconcepts.com>
To: Isen I-Chun Chao <chao...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Use of external reference clock to sync the
internal clock of X310 USRPs
Message-ID: <3fd94ab5-5dcf-462b-88c0-5efe4725a...@ionconcepts.com>
Content-Type: text/plain; charset="iso-8859-1"
Isen,
On Nov 7, 2014, at 1:51 PM, Isen I-Chun Chao via USRP-users
<usrp-users@lists.ettus.com> wrote:
> Hi Marcus,
> I took a look at the the X3x0 schematic
> (http://files.ettus.com/schematics/x300/x3xx.pdf).
> 1a) According to the page 1 and page 11 of X3x0 schematic, it looks like that
> there is a 96MHz main oscillator as a master clock and it will redistributed
> to DAC/ADC. Then what is the "200MHz default master clock" you mentioned
> previously?
>
The 96MHz oscillator drives the TI PLL chip(LMK04816) which is used to
synthesis a variety of clocks, including the so called "master_clock". The
default frequency of the master_clock is 200MHz but we also provide support for
a tested configurations of 120MHz and 184.32MHz. The TI chip actually contains
two PLL's and is very powerful, but complicated to program. The master clock is
provided directly to ADC's and DAC's as well as the FPGA. Other reference
clocks to synthesize RF LO's are provided to the Radio daughter cards.
> 1b). In the page 1 and pgae 12 of the X3x0 schematic, there is three are
> internal 10MHz TCXO, external 10MHz interface and the GPSDO interface so I
> can understand how set_clock_source() works for selecting one of them.
> However, I don't understand the role that the 96MHz main oscillator and the
> internal 10MHz TCXO play, respectively. What are they responsible for,
> respectively, in X310 architecture?
The 96MHz oscillator is a VCXO, it is disciplined using a 10MHz reference
clock. When there is no external source of a 10MHz ref clock then the on board
10MHz TCXO is used instead.
>
> 2). Just to make sure we are in the same page, by talking about "there are
> multiple clock domains in X310" in your previously email, did you mean the
> output of "clock gen" block in the X3x0 schematic?
There a great number of discrete clocks of different frequency and phase used
within the FPGA..
>
> 3) According to your answer for the question about set_time_source():
> "Setting the time source -- ie. saying that the internal time of the X310
> should come from the GPSDO or somewhere else." and the page one of the X3x0
> schematic, there must be time registers design in the FPGA and the content of
> the time registers are something like second and nanosecond, counting based
> on one of the output of "Clock Gen" connecting to FPGA. Do I understand it
> correctly? If so, what is the time source this clock signal based on? the
> internal 10MHz TCXO or the 96MHz main oscillator?
The internal reference clock maintained in the FPGA is in quanta of the
master_clock. By default therefore it's incrementing every 5nS.
>
> 4) Regarding the previous question of using set_clock_source() and
> set_time_source(), I was asking if these two method is one-time use. Like
> people write a Linux drivers to access a hardware device attached on computer
> and set up a register to enable some feature of the hardware device as a
> configuration process. This only needs to be done in the initialization phase
> of loading a driver program or running a driver program. So If I turn the
> X310 on and plug the reference clock, I only need to call
> set_clock_source("external")/set_time_source("external") one time and the
> X3x0 will be configured as working on external reference until I turned the
> X310 off.
>
> I am using uhd 3.7.3. I will install the newest one and give it a try to see
> if I still have lo_locked failed warning. And for your interest question, I
> don't have the measure result regarding to the clock stability using
> T-connector with me. But based on our previous related experimental work,
> one-stage of our T-connector will be just fine. And the precision we do care
> is not the frequency output, which is used for verifying if the internal
> clock follows external clock. We actually care about the precision of a
> generated time-stamp in the FPGA.
>
>
> Best Regards,
> Isen I-Chun Chao
>
> On Fri, Nov 7, 2014 at 5:39 AM, Marcus M?ller <marcus.muel...@ettus.com>
> wrote:
> Hello Isen,
> On 06.11.2014 23:08, Isen I-Chun Chao wrote:
> > Hi Marcus,
> > In our application, the quality of clock is extremely affect our interest.
> > So clearly understanding of what clock source is related to our application
> > is important. That is why we are using atomic clock as the external
> > reference.
> As this is interesting to me: What are your accuracy needs?
> Have you measured phase noise with a highspeed oscilloscope when using
> your t-connector with 50Ohm termination on the measurement end, and a
> running X310 plugged in to the other end of the t-piece? You really have
> to make sure the signal quality is excellent if you want to be better
> than the internal oscillator, and thus should ensure your external
> cabling doesn't eliminate the gain in clock stability you get by using
> an atomic clock by introducing phase noise.
>
> > Besides, the USRP Tx and Rx will be respectively coordinating with other
> > devices. It is expected to be separated.
> Ah, so you need two USRPs to simulate your comm system.
> > That is why two USRPs are used. I
> > agree with you. I don't think Daisy-chain is appropriate in the our use
> > case.
> >
> > Following are extended questions:
> > 1a). By talking about internal clock, does it mean the 200MHz clock?
> Um, there are dozens of internal clocks in the X310; I don't know which
> statement you are referring to. Most probably, when we're talking about
> "internal clock source", we mean the 10MHz reference clock.
> >
> > 1b). According to the manual there are "set_clock_source()",
> > "set_clock_source_out()", "set_time_source()", "set_time_source_out()". And
> > I wonder if I set_clock_source_out() and set_time_source_out() are only
> > used for enabling/disabling Ref and PPS output respectively.
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a60445c1a52e4763b6ebbbfce2db96569
> yes.
> > If so, what is
> > the Ref output based on? The 200MHz clock?
> I'm assuming you're referring to the 200MHz default master clock rate,
> which it cannot be based on, as that clock is adjustable and the Ref Out
> must be 10MHz.
>
> Compare page 11 of the X300 schematic:
> http://files.ettus.com/schematics/x300/x3xx.pdf
> The ref clock output gets generated directly by the central clock
> generation, stabilization and distribution IC, the LMK04816, which means
> it's derived inside that chip from the reference clock with the help of
> stabilization and further oscillators. I must admit that I still haven't
> gotten around to understanding the workings of the LMK in fullness; it's
> a complex piece of hardware, and for you, as a user, it basically "does
> what it should".
> >
> > 1c). Is the PPS output based on a register maintaining count ticks from
> > 200MHz clock, or based on what mechanism?
> Depends on whether you use an actual PPS as input (in which case that
> one is used) or not (in which case ticks are counted in the FPGA).
> > 1d). What is the concrete use case of set_time_source() in USRP X310?
> Setting the time source -- ie. saying that the internal time of the X310
> should come from the GPSDO or somewhere else.
> > If I
> > have an external PPS reference connected to X310 and I use this method,
> > does that mean the PPS signal (including the PPS output) throughout whole
> > X310 will BE the external PPS reference?
> yes.
> >
> > 2). Is the method, set_clock_source() (so are et_clock_source_out(),
> > set_time_source(), set_time_source_out()), needed to use only one time
> > (call it for configuring USRP, and USRP will stay using external clock
> > until it is powered off)?
> I don't understand, sorry. Every USRP can only have one device time.
> >
> > 3). If I run applications in GRC on USRP without connecting an external
> > clock (and I did not use set_clock_source() either), I always got warning
> > message "WARN: Sensor 'lo_locked' failed to lock within timeout on channel
> > 0";
> > however, if I connect the atomic clock as an external clock, there is no
> > such warning message. Looks like there is something activated after
> > plugging eternal clock. If so, what is that? something like the PLL locking
> > mechanism?
> Yes, that is the information that the USRP couldn't gain a stabilized
> clock, which is a bad thing as is.
> However, there is no way to detect whether a cable is connected to the
> ref in port, which means that either the external clock source is
> selected in the UHD source/sinks options, or you have a problem with the
> clock locking mechanism.
> Are you using a recent version of UHD?
>
> Greetings,
> Marcus
>
> >
> >
> >
> >
> >
> >
> > *Best Regards,Isen I-Chun Chao*
> >
> > On Tue, Nov 4, 2014 at 4:22 PM, Marcus M?ller <marcus.muel...@ettus.com>
> > wrote:
> >
> >> Hi Isen,
> >> On 04.11.2014 21:37, Isen I-Chun Chao wrote:
> >>> Hi Marcus Leech and Marcus Muller,
> >>> Thanks for the answers. But I am a little bit confused.
> >>>
> >>> Once I connect the atomic and X310, hardware (X310 USRPs) should operate
> >>> based on external clock (atomic clock)
> >> no, you must explicitely select the external clock source.
> >>> due to the daisy-chain(?).
> >> Daisy-chaining is the option to connect the reference output of one USRP
> >> to the reference input of the next; inherently, it doesn't relate to
> >> your use case.
> >>> This is
> >>> regardless of application use.
> >> Depends on what your application wants to do. Most application will not
> >> care where the reference comes from -- but you'll still need to set the
> >> reference source.
> >>> And I should have synchronized signal from
> >>> REF outputs of two USRPs, right?
> >>>
> >>> If applications did not set up the use of external clock by using
> >>> set_clock_source(), the application is going to use the default clock on
> >>> X310 USRPs. (?)
> >> yes.
> >>> What clock the FPGA is based on? because the FPGA code will be modified
> >>> working on our application.
> >> The FPGA design has multiple clock domains. The most important clock
> >> domain is driven at the master clock rate, which is 200MHz by default,
> >> but can take more values (see UHD manual).
> >>> BTW, the two X310 USRPs are Tx and Rx.
> >> Each X310 has two completely independent TX and RX chains. Unless you
> >> need to have them in two different places, I'm afraid I don't understand
> >> why you need two X310.
> >>> I am not using them as MIMO. The
> >>> reason I want to make sure their clock can synchronized to an atomic
> >> clock
> >>> is that I would like to draw timestamps on both Tx and Rx based on the
> >>> clock on USRPs. I use T-connectors to distribute atomic signals to two
> >> X310
> >>> USRP.
> >> T-Connectors might or might not work -- distributing a 10MHz clock is a
> >> bit of a tricky task, since reflections might mess up your phase
> >> quality. Also, you split energy (let's say by half) between the two
> >> USRPs! Make sure you're still able to reliably drive the clock inputs.
> >> Usually, this is a case where you would need a proper clock distributor,
> >> or a forwarding solution (such as daisy-chaining). For PPS synchronity,
> >> you really should make sure you know what you're doing on the signal
> >> distribution. I can see that daisy chaining will not be a good solution
> >> here, unless you calibrate (which you could easily do).
> >>
> >> Best regards,
> >> Marcus
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *Best Regards,Isen I-Chun Chao*
> >>>
> >>> On Tue, Nov 4, 2014 at 3:11 PM, Marcus M?ller <
> >> usrp-users@lists.ettus.com>
> >>> wrote:
> >>>
> >>>> Hi Isen,
> >>>>
> >>>> yes, you're understanding correctly, but you'll have to select the
> >>>> external reference explicitely using the set_clock_source method.
> >>>> Also, your atomic clock has to have the possibility to drive two
> >>>> receivers; distributing clock signals correctly isn't inherently
> >> trivial.
> >>>> For this reason, the X3x0s have the ability to "daisy-chain" the
> >> reference
> >>>> and PPS signals.
> >>>>
> >>>> Greetings,
> >>>> Marcus
> >>>>
> >>>>
> >>>> On 04.11.2014 20:48, Isen I-Chun Chao via USRP-users wrote:
> >>>>
> >>>> Hi,
> >>>> If I have a atomic clock with me and would like to two X310 USRP
> >>>> synchronize to this atomic clock.
> >>>> I just connect the PPS output and the 10MHz Ref output on atomic clock
> >> to
> >>>> the input of two USRP. As long as the 'REF' leds on the front panel of
> >> X310
> >>>> USRPs are turned on, the internal clock of X310 USRPs are locked. No
> >>>> further settings are required.
> >>>>
> >>>> Am I understanding it right?
> >>>> Thanks.
> >>>>
> >>>>
> >>>>
> >>>> *Best Regards,Isen I-Chun Chao*
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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/20141107/840f3a76/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 7 Nov 2014 17:00:43 -0800
From: Ben Hilburn <ben.hilb...@ettus.com>
To: "Knee, Peter A" <pak...@sandia.gov>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP B210 GPS Time w/Master Clock Rate
Message-ID:
<CAOEVZkJ0QLfn4=Axuf7J510gTjzS5gN=_mpqafbp6h7w0cz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Peter -
Can you elaborate a bit on this:
> However, as soon as I change the master clock rate, the USRP time
> changes, with the amount of change inversely proportional to the amount of
> change in the master clock rate.
>
How are you changing the master clock rate, and what state is your
application in when this occurs?
Thanks!
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141107/57d30d2f/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 7 Nov 2014 17:02:39 -0800
From: Ben Hilburn <ben.hilb...@ettus.com>
To: Krzysztof Cwalina <kkcwal...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Windows UHD C++ API
Message-ID:
<CAOEVZkLov8AEpjJc8_1Z=oK=3tksec3elpkivwsevzybtwm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Krzysztof -
I'm a bit confused, I think. Can you explain what you mean by importing the
UHD DLL into a C# project? I'm not familiar with C#, but is that expected
to work?
We certainly haven't tested anything like that, here. Or am I
misunderstanding your question?
Cheers,
Ben
On Fri, Nov 7, 2014 at 5:49 AM, Krzysztof Cwalina via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello,
>
> in my project I just write the C++ DLL Library and import it into C#
> project. The problem is - there are some problems with the UHD. My platform:
>
> Windows 7 x64,
> Visual Studio 2013 Pro
>
> when I run project sometimes on the line: uhd::usrp::multi_usrp::sptr usrp
> = uhd::usrp::multi_usrp::make(args); there is exception like:
>
> A first chance exception of type 'System.Runtime.InteropServices.SEHException'
> occurred in USRPTest.exe
> Additional information: External component has thrown an exception.
>
> Sometimes it is - sometimes is not (depends on how many times I compile
> the same code. Next problem is when I want to use two methods:
>
> usrp->set_clock_source("internal"); or uhd::stream_args_t
> stream_args("fc32");
>
> Same error show up. I tried everything, I've searched almost all topics
> about this subject - but I didn't found the solution. Can anyone help me?
>
> Thanks.
>
> _______________________________________________
> 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/20141107/c3040bd5/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 7 Nov 2014 17:03:56 -0800
From: Ben Hilburn <ben.hilb...@ettus.com>
To: etter.c...@bluewin.ch
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UHD 003.008.000 N210R4: SPI CLOCK not
changeable anymore
Message-ID:
<caoevzklj9me0jmwqtuglcmroakemt5e0qdpv0ymxtsod12c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Peter -
Moving from UHD-3.4.3 to UHD-3.8.0 is pretty big change, but honestly there
hasn't been much in the way of N-Series development since the UHD-3.5
series.
Can you give UHD-3.5.5 a shot and let us know how it goes?
Cheers,
Ben
On Wed, Nov 5, 2014 at 12:48 PM, etter.crel--- via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello
> We are using the N210R4 to communicate with external hardware via the rx
> and tx daughterboard spi interface.
> With UHD 003.004.003 we can change the spi clock when modifying the
> firmware file "spi.c" .
> We change the default value from spi_regs->div=1 to 249, which results in
> the desired spi clock frequency of
> 100kHz.
> When migrating to UHD 003.008.000 changing the spi clock seems not to be
> possible anymore. Modifying the
> value spi_core->divider=10 to any other value will not change the spi
> clock frequency, it remains at 10MHz.
>
> Changing the baud rate of the rs232 interface after migrating is still
> possible, indicating that the tool chain is OK.
>
> Thanks for any help.
>
> Hans-Peter
>
> _______________________________________________
> 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/20141107/0e98b859/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 7 Nov 2014 17:07:20 -0800
From: Ben Hilburn <ben.hilb...@ettus.com>
To: Serge Malo <serge.m...@averna.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] x300 on Windows 7 and 10GbE: getting ?S? and
?U? from UHD
Message-ID:
<CAOEVZkJYQzZYoxeQB=seq_60s5munyhrcydk+mwy5csb0z9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Serge -
Hm, very strange. A few things:
- Are you able to run Linux on that box (perhaps with the Ettus LiveUSB
image?) and try talking to your X300 on that hardware under the Linux OS?
- Have you tried UHD-3.8.0?
- What 10GigE card are you using?
Cheers,
Ben
On Thu, Oct 30, 2014 at 3:38 AM, Serge Malo via USRP-users <
usrp-users@lists.ettus.com> wrote:
>
> * Hi all, We are trying to use the x300 with the 10GbE port 1. We use it
> with a Dell Workstation Rack 7910 which hosts an intel X520-DA2 10GbE card,
> running Windows 7 x64 from a SSD. We are using UHD 3.7.2 and UHD 3.7.3.
> We have been able to read 100Msps from the x300 without problem
> (benchmark_rate test) However, we can?t send 1Msps to the x300 without
> getting errors from UHD. We get both ?S? and ?U? errors: Sequence error on
> Tx and buffer under-runs. Has anyone been successful sending samples to
> the x300 on Windows 7 with 10GbE? If so, did you have to change any
> parameters/registry key? Which UHD version are you using? We have set the
> registry key ?FastSendDatagramThreshold? to 9000. We also have issues
> with the x300 fpga image in UHD 3.7.3. With this image, the ethernet
> connection is unstable, we can?t really connect to the x300. So, we had to
> perform our tests with the image from UHD 3.7.2. We tried both uhd.dll from
> UHD 3.7.2 and 3.7.3, both shown the ?S? problem. Best regards, Serge Malo
> *
>
>
> _______________________________________________
> 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/20141107/c587ea97/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 7 Nov 2014 22:31:06 -0500
From: Isen I-Chun Chao <chao...@gmail.com>
To: Ian Buckley <i...@ionconcepts.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Use of external reference clock to sync the
internal clock of X310 USRPs
Message-ID:
<caeg73kqzeodg7tzsss0cvdz32s-rjmpxfvuegtez6xsvsma...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ian,
Thanks for the explanation. It is much more clear to me about the clock
arch in X310 now.
So I think the arch maybe based on Fig. 2 (0-delay dual PLL) of the
LMK04816 manual (http://www.ti.com/lit/ds/symlink/lmk04816.pdf) and this
chip takes CLKin1 as a reference clock. The CLKin1 in this case is
connected to a multiplexer (SY89547LMGTR), which is responsible for
selecting external ref, internal ref or GPSDO. And that is why user have to
use set_clock_source() to set up/select the one of them as the source.
And I tried to find out the signal master_clock in verilog code (X300
series). But I did no find it. Is is actually called 'master_clock' in
verilog code?
Has a time register based on master_clock (5ns resolution) been implemented
in fpga-src of current version (3.8.0) UHD?
Or people have to implement it by themselves? I was told that the time
maintained so far in the FPGA in X3x0 is not as precise as 5ns?
*Best Regards,Isen I-Chun Chao*
On Fri, Nov 7, 2014 at 5:34 PM, Ian Buckley <i...@ionconcepts.com> wrote:
> Isen,
>
> On Nov 7, 2014, at 1:51 PM, Isen I-Chun Chao via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Marcus,
> I took a look at the the X3x0 schematic (
> http://files.ettus.com/schematics/x300/x3xx.pdf).
> 1a) According to the page 1 and page 11 of X3x0 schematic, it looks like
> that there is a 96MHz main oscillator as a master clock and it will
> redistributed to DAC/ADC. Then what is the "200MHz default master clock"
> you mentioned previously?
>
> The 96MHz oscillator drives the TI PLL chip(LMK04816) which is used to
> synthesis a variety of clocks, including the so called "master_clock". The
> default frequency of the master_clock is 200MHz but we also provide support
> for a tested configurations of 120MHz and 184.32MHz. The TI chip actually
> contains two PLL's and is very powerful, but complicated to program. The
> master clock is provided directly to ADC's and DAC's as well as the FPGA.
> Other reference clocks to synthesize RF LO's are provided to the Radio
> daughter cards.
>
> 1b). In the page 1 and pgae 12 of the X3x0 schematic, there is three are
> internal 10MHz TCXO, external 10MHz interface and the GPSDO interface so I
> can understand how set_clock_source() works for selecting one of them.
> However, I don't understand the role that the 96MHz main oscillator and the
> internal 10MHz TCXO play, respectively. What are they responsible for,
> respectively, in X310 architecture?
>
>
> The 96MHz oscillator is a VCXO, it is disciplined using a 10MHz reference
> clock. When there is no external source of a 10MHz ref clock then the on
> board 10MHz TCXO is used instead.
>
>
> 2). Just to make sure we are in the same page, by talking about "there are
> multiple
> clock domains in X310" in your previously email, did you mean the output
> of "clock gen" block in the X3x0 schematic?
>
>
> There a great number of discrete clocks of different frequency and phase
> used within the FPGA..
>
>
> 3) According to your answer for the question about set_time_source(): "Setting
> the time source -- ie. saying that the internal time of the X310 should
> come from the GPSDO or somewhere else." and the page one of the X3x0
> schematic, there must be time registers design in the FPGA and the content
> of the time registers are something like second and nanosecond, counting
> based on one of the output of "Clock Gen" connecting to FPGA. Do I
> understand it correctly? If so, what is the time source this clock signal
> based on? the internal 10MHz TCXO or the 96MHz main oscillator?
>
>
> The internal reference clock maintained in the FPGA is in quanta of the
> master_clock. By default therefore it's incrementing every 5nS.
>
>
> 4) Regarding the previous question of using set_clock_source() and
> set_time_source(), I was asking if these two method is one-time use. Like
> people write a Linux drivers to access a hardware device attached on
> computer and set up a register to enable some feature of the hardware
> device as a configuration process. This only needs to be done in the
> initialization phase of loading a driver program or running a driver
> program. So If I turn the X310 on and plug the reference clock, I only need
> to call set_clock_source("external")/set_time_source("external") one time
> and the X3x0 will be configured as working on external reference until I
> turned the X310 off.
>
> I am using uhd 3.7.3. I will install the newest one and give it a try to
> see if I still have lo_locked failed warning. And for your interest
> question, I don't have the measure result regarding to the clock stability
> using T-connector with me. But based on our previous related experimental
> work, one-stage of our T-connector will be just fine. And the precision we
> do care is not the frequency output, which is used for verifying if the
> internal clock follows external clock. We actually care about the precision
> of a generated time-stamp in the FPGA.
>
>
>
> *Best Regards,Isen I-Chun Chao*
>
> On Fri, Nov 7, 2014 at 5:39 AM, Marcus M?ller <marcus.muel...@ettus.com>
> wrote:
>
>> Hello Isen,
>> On 06.11.2014 23:08, Isen I-Chun Chao wrote:
>> > Hi Marcus,
>> > In our application, the quality of clock is extremely affect our
>> interest.
>> > So clearly understanding of what clock source is related to our
>> application
>> > is important. That is why we are using atomic clock as the external
>> > reference.
>> As this is interesting to me: What are your accuracy needs?
>> Have you measured phase noise with a highspeed oscilloscope when using
>> your t-connector with 50Ohm termination on the measurement end, and a
>> running X310 plugged in to the other end of the t-piece? You really have
>> to make sure the signal quality is excellent if you want to be better
>> than the internal oscillator, and thus should ensure your external
>> cabling doesn't eliminate the gain in clock stability you get by using
>> an atomic clock by introducing phase noise.
>>
>> > Besides, the USRP Tx and Rx will be respectively coordinating with other
>> > devices. It is expected to be separated.
>> Ah, so you need two USRPs to simulate your comm system.
>> > That is why two USRPs are used. I
>> > agree with you. I don't think Daisy-chain is appropriate in the our use
>> > case.
>> >
>> > Following are extended questions:
>> > 1a). By talking about internal clock, does it mean the 200MHz clock?
>> Um, there are dozens of internal clocks in the X310; I don't know which
>> statement you are referring to. Most probably, when we're talking about
>> "internal clock source", we mean the 10MHz reference clock.
>> >
>> > 1b). According to the manual there are "set_clock_source()",
>> > "set_clock_source_out()", "set_time_source()", "set_time_source_out()".
>> And
>> > I wonder if I set_clock_source_out() and set_time_source_out() are only
>> > used for enabling/disabling Ref and PPS output respectively.
>>
>> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a60445c1a52e4763b6ebbbfce2db96569
>> yes.
>> > If so, what is
>> > the Ref output based on? The 200MHz clock?
>> I'm assuming you're referring to the 200MHz default master clock rate,
>> which it cannot be based on, as that clock is adjustable and the Ref Out
>> must be 10MHz.
>>
>> Compare page 11 of the X300 schematic:
>> http://files.ettus.com/schematics/x300/x3xx.pdf
>> The ref clock output gets generated directly by the central clock
>> generation, stabilization and distribution IC, the LMK04816, which means
>> it's derived inside that chip from the reference clock with the help of
>> stabilization and further oscillators. I must admit that I still haven't
>> gotten around to understanding the workings of the LMK in fullness; it's
>> a complex piece of hardware, and for you, as a user, it basically "does
>> what it should".
>> >
>> > 1c). Is the PPS output based on a register maintaining count ticks from
>> > 200MHz clock, or based on what mechanism?
>> Depends on whether you use an actual PPS as input (in which case that
>> one is used) or not (in which case ticks are counted in the FPGA).
>> > 1d). What is the concrete use case of set_time_source() in USRP X310?
>> Setting the time source -- ie. saying that the internal time of the X310
>> should come from the GPSDO or somewhere else.
>> > If I
>> > have an external PPS reference connected to X310 and I use this method,
>> > does that mean the PPS signal (including the PPS output) throughout
>> whole
>> > X310 will BE the external PPS reference?
>> yes.
>> >
>> > 2). Is the method, set_clock_source() (so are et_clock_source_out(),
>> > set_time_source(), set_time_source_out()), needed to use only one time
>> > (call it for configuring USRP, and USRP will stay using external clock
>> > until it is powered off)?
>> I don't understand, sorry. Every USRP can only have one device time.
>> >
>> > 3). If I run applications in GRC on USRP without connecting an external
>> > clock (and I did not use set_clock_source() either), I always got
>> warning
>> > message "WARN: Sensor 'lo_locked' failed to lock within timeout on
>> channel 0";
>> > however, if I connect the atomic clock as an external clock, there is no
>> > such warning message. Looks like there is something activated after
>> > plugging eternal clock. If so, what is that? something like the PLL
>> locking
>> > mechanism?
>> Yes, that is the information that the USRP couldn't gain a stabilized
>> clock, which is a bad thing as is.
>> However, there is no way to detect whether a cable is connected to the
>> ref in port, which means that either the external clock source is
>> selected in the UHD source/sinks options, or you have a problem with the
>> clock locking mechanism.
>> Are you using a recent version of UHD?
>>
>> Greetings,
>> Marcus
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > *Best Regards,Isen I-Chun Chao*
>> >
>> > On Tue, Nov 4, 2014 at 4:22 PM, Marcus M?ller <marcus.muel...@ettus.com
>> >
>> > wrote:
>> >
>> >> Hi Isen,
>> >> On 04.11.2014 21:37, Isen I-Chun Chao wrote:
>> >>> Hi Marcus Leech and Marcus Muller,
>> >>> Thanks for the answers. But I am a little bit confused.
>> >>>
>> >>> Once I connect the atomic and X310, hardware (X310 USRPs) should
>> operate
>> >>> based on external clock (atomic clock)
>> >> no, you must explicitely select the external clock source.
>> >>> due to the daisy-chain(?).
>> >> Daisy-chaining is the option to connect the reference output of one
>> USRP
>> >> to the reference input of the next; inherently, it doesn't relate to
>> >> your use case.
>> >>> This is
>> >>> regardless of application use.
>> >> Depends on what your application wants to do. Most application will not
>> >> care where the reference comes from -- but you'll still need to set the
>> >> reference source.
>> >>> And I should have synchronized signal from
>> >>> REF outputs of two USRPs, right?
>> >>>
>> >>> If applications did not set up the use of external clock by using
>> >>> set_clock_source(), the application is going to use the default clock
>> on
>> >>> X310 USRPs. (?)
>> >> yes.
>> >>> What clock the FPGA is based on? because the FPGA code will be
>> modified
>> >>> working on our application.
>> >> The FPGA design has multiple clock domains. The most important clock
>> >> domain is driven at the master clock rate, which is 200MHz by default,
>> >> but can take more values (see UHD manual).
>> >>> BTW, the two X310 USRPs are Tx and Rx.
>> >> Each X310 has two completely independent TX and RX chains. Unless you
>> >> need to have them in two different places, I'm afraid I don't
>> understand
>> >> why you need two X310.
>> >>> I am not using them as MIMO. The
>> >>> reason I want to make sure their clock can synchronized to an atomic
>> >> clock
>> >>> is that I would like to draw timestamps on both Tx and Rx based on the
>> >>> clock on USRPs. I use T-connectors to distribute atomic signals to two
>> >> X310
>> >>> USRP.
>> >> T-Connectors might or might not work -- distributing a 10MHz clock is a
>> >> bit of a tricky task, since reflections might mess up your phase
>> >> quality. Also, you split energy (let's say by half) between the two
>> >> USRPs! Make sure you're still able to reliably drive the clock inputs.
>> >> Usually, this is a case where you would need a proper clock
>> distributor,
>> >> or a forwarding solution (such as daisy-chaining). For PPS synchronity,
>> >> you really should make sure you know what you're doing on the signal
>> >> distribution. I can see that daisy chaining will not be a good solution
>> >> here, unless you calibrate (which you could easily do).
>> >>
>> >> Best regards,
>> >> Marcus
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> *Best Regards,Isen I-Chun Chao*
>> >>>
>> >>> On Tue, Nov 4, 2014 at 3:11 PM, Marcus M?ller <
>> >> usrp-users@lists.ettus.com>
>> >>> wrote:
>> >>>
>> >>>> Hi Isen,
>> >>>>
>> >>>> yes, you're understanding correctly, but you'll have to select the
>> >>>> external reference explicitely using the set_clock_source method.
>> >>>> Also, your atomic clock has to have the possibility to drive two
>> >>>> receivers; distributing clock signals correctly isn't inherently
>> >> trivial.
>> >>>> For this reason, the X3x0s have the ability to "daisy-chain" the
>> >> reference
>> >>>> and PPS signals.
>> >>>>
>> >>>> Greetings,
>> >>>> Marcus
>> >>>>
>> >>>>
>> >>>> On 04.11.2014 20:48, Isen I-Chun Chao via USRP-users wrote:
>> >>>>
>> >>>> Hi,
>> >>>> If I have a atomic clock with me and would like to two X310 USRP
>> >>>> synchronize to this atomic clock.
>> >>>> I just connect the PPS output and the 10MHz Ref output on atomic
>> clock
>> >> to
>> >>>> the input of two USRP. As long as the 'REF' leds on the front panel
>> of
>> >> X310
>> >>>> USRPs are turned on, the internal clock of X310 USRPs are locked. No
>> >>>> further settings are required.
>> >>>>
>> >>>> Am I understanding it right?
>> >>>> Thanks.
>> >>>>
>> >>>>
>> >>>>
>> >>>> *Best Regards,Isen I-Chun Chao*
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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/20141107/8b747f1f/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 7 Nov 2014 20:24:07 -0800
From: Ian Buckley <i...@ionconcepts.com>
To: Isen I-Chun Chao <chao...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Use of external reference clock to sync the
internal clock of X310 USRPs
Message-ID: <8b3b25f2-0a46-4511-a14d-f72287fe6...@ionconcepts.com>
Content-Type: text/plain; charset="windows-1252"
Isen,
On Nov 7, 2014, at 7:31 PM, Isen I-Chun Chao <chao...@gmail.com> wrote:
> Hi Ian,
> Thanks for the explanation. It is much more clear to me about the clock arch
> in X310 now.
>
> So I think the arch maybe based on Fig. 2 (0-delay dual PLL) of the LMK04816
> manual (http://www.ti.com/lit/ds/symlink/lmk04816.pdf) and this chip takes
> CLKin1 as a reference clock. The CLKin1 in this case is connected to a
> multiplexer (SY89547LMGTR), which is responsible for selecting external ref,
> internal ref or GPSDO. And that is why user have to use set_clock_source() to
> set up/select the one of them as the source.
Yes, though it should default to the internal 10MHz TCXO if no arguments are
supplied and no GPSDO is installed.
>
> And I tried to find out the signal master_clock in verilog code (X300
> series). But I did no find it. Is is actually called 'master_clock' in
> verilog code?
master_clk_rate is the keyword used in UHD command invocation for all the new
USRP models and it corresponds to the sample rate of the ADC/DAC. We have
standardized on this term, since most users only write S/W and have no
visibility into the FPGA design.
In the X310 Verilog follow the signal "radio_clk" from X300.v down through the
hierarchy?the name will change to just "clk" in some sub-modules?.this is the
200MHz clock.
>
> Has a time register based on master_clock (5ns resolution) been implemented
> in fpga-src of current version (3.8.0) UHD?
> Or people have to implement it by themselves? I was told that the time
> maintained so far in the FPGA in X3x0 is not as precise as ins?
Yes, there is a 64bit 200MHz counter in each instance of the radio in X300. All
time specs for X310 are accurate in the H/W to 5nS when using a 200MHz
master_clock_rate. We use the term vita_time also to refer to the same clocks
sometimes.
>
>
>
-Ian
> Best Regards,
> Isen I-Chun Chao
>
> On Fri, Nov 7, 2014 at 5:34 PM, Ian Buckley <i...@ionconcepts.com> wrote:
> Isen,
>
> On Nov 7, 2014, at 1:51 PM, Isen I-Chun Chao via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
>> Hi Marcus,
>> I took a look at the the X3x0 schematic
>> (http://files.ettus.com/schematics/x300/x3xx.pdf).
>> 1a) According to the page 1 and page 11 of X3x0 schematic, it looks like
>> that there is a 96MHz main oscillator as a master clock and it will
>> redistributed to DAC/ADC. Then what is the "200MHz default master clock" you
>> mentioned previously?
>>
>
> The 96MHz oscillator drives the TI PLL chip(LMK04816) which is used to
> synthesis a variety of clocks, including the so called "master_clock". The
> default frequency of the master_clock is 200MHz but we also provide support
> for a tested configurations of 120MHz and 184.32MHz. The TI chip actually
> contains two PLL's and is very powerful, but complicated to program. The
> master clock is provided directly to ADC's and DAC's as well as the FPGA.
> Other reference clocks to synthesize RF LO's are provided to the Radio
> daughter cards.
>
>> 1b). In the page 1 and pgae 12 of the X3x0 schematic, there is three are
>> internal 10MHz TCXO, external 10MHz interface and the GPSDO interface so I
>> can understand how set_clock_source() works for selecting one of them.
>> However, I don't understand the role that the 96MHz main oscillator and the
>> internal 10MHz TCXO play, respectively. What are they responsible for,
>> respectively, in X310 architecture?
>
> The 96MHz oscillator is a VCXO, it is disciplined using a 10MHz reference
> clock. When there is no external source of a 10MHz ref clock then the on
> board 10MHz TCXO is used instead.
>>
>> 2). Just to make sure we are in the same page, by talking about "there are
>> multiple clock domains in X310" in your previously email, did you mean the
>> output of "clock gen" block in the X3x0 schematic?
>
> There a great number of discrete clocks of different frequency and phase used
> within the FPGA..
>>
>> 3) According to your answer for the question about set_time_source():
>> "Setting the time source -- ie. saying that the internal time of the X310
>> should come from the GPSDO or somewhere else." and the page one of the X3x0
>> schematic, there must be time registers design in the FPGA and the content
>> of the time registers are something like second and nanosecond, counting
>> based on one of the output of "Clock Gen" connecting to FPGA. Do I
>> understand it correctly? If so, what is the time source this clock signal
>> based on? the internal 10MHz TCXO or the 96MHz main oscillator?
>
> The internal reference clock maintained in the FPGA is in quanta of the
> master_clock. By default therefore it's incrementing every 5nS.
>
>>
>> 4) Regarding the previous question of using set_clock_source() and
>> set_time_source(), I was asking if these two method is one-time use. Like
>> people write a Linux drivers to access a hardware device attached on
>> computer and set up a register to enable some feature of the hardware device
>> as a configuration process. This only needs to be done in the initialization
>> phase of loading a driver program or running a driver program. So If I turn
>> the X310 on and plug the reference clock, I only need to call
>> set_clock_source("external")/set_time_source("external") one time and the
>> X3x0 will be configured as working on external reference until I turned the
>> X310 off.
>>
>> I am using uhd 3.7.3. I will install the newest one and give it a try to see
>> if I still have lo_locked failed warning. And for your interest question, I
>> don't have the measure result regarding to the clock stability using
>> T-connector with me. But based on our previous related experimental work,
>> one-stage of our T-connector will be just fine. And the precision we do care
>> is not the frequency output, which is used for verifying if the internal
>> clock follows external clock. We actually care about the precision of a
>> generated time-stamp in the FPGA.
>>
>>
>> Best Regards,
>> Isen I-Chun Chao
>>
>> On Fri, Nov 7, 2014 at 5:39 AM, Marcus M?ller <marcus.muel...@ettus.com>
>> wrote:
>> Hello Isen,
>> On 06.11.2014 23:08, Isen I-Chun Chao wrote:
>> > Hi Marcus,
>> > In our application, the quality of clock is extremely affect our interest.
>> > So clearly understanding of what clock source is related to our application
>> > is important. That is why we are using atomic clock as the external
>> > reference.
>> As this is interesting to me: What are your accuracy needs?
>> Have you measured phase noise with a highspeed oscilloscope when using
>> your t-connector with 50Ohm termination on the measurement end, and a
>> running X310 plugged in to the other end of the t-piece? You really have
>> to make sure the signal quality is excellent if you want to be better
>> than the internal oscillator, and thus should ensure your external
>> cabling doesn't eliminate the gain in clock stability you get by using
>> an atomic clock by introducing phase noise.
>>
>> > Besides, the USRP Tx and Rx will be respectively coordinating with other
>> > devices. It is expected to be separated.
>> Ah, so you need two USRPs to simulate your comm system.
>> > That is why two USRPs are used. I
>> > agree with you. I don't think Daisy-chain is appropriate in the our use
>> > case.
>> >
>> > Following are extended questions:
>> > 1a). By talking about internal clock, does it mean the 200MHz clock?
>> Um, there are dozens of internal clocks in the X310; I don't know which
>> statement you are referring to. Most probably, when we're talking about
>> "internal clock source", we mean the 10MHz reference clock.
>> >
>> > 1b). According to the manual there are "set_clock_source()",
>> > "set_clock_source_out()", "set_time_source()", "set_time_source_out()". And
>> > I wonder if I set_clock_source_out() and set_time_source_out() are only
>> > used for enabling/disabling Ref and PPS output respectively.
>> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a60445c1a52e4763b6ebbbfce2db96569
>> yes.
>> > If so, what is
>> > the Ref output based on? The 200MHz clock?
>> I'm assuming you're referring to the 200MHz default master clock rate,
>> which it cannot be based on, as that clock is adjustable and the Ref Out
>> must be 10MHz.
>>
>> Compare page 11 of the X300 schematic:
>> http://files.ettus.com/schematics/x300/x3xx.pdf
>> The ref clock output gets generated directly by the central clock
>> generation, stabilization and distribution IC, the LMK04816, which means
>> it's derived inside that chip from the reference clock with the help of
>> stabilization and further oscillators. I must admit that I still haven't
>> gotten around to understanding the workings of the LMK in fullness; it's
>> a complex piece of hardware, and for you, as a user, it basically "does
>> what it should".
>> >
>> > 1c). Is the PPS output based on a register maintaining count ticks from
>> > 200MHz clock, or based on what mechanism?
>> Depends on whether you use an actual PPS as input (in which case that
>> one is used) or not (in which case ticks are counted in the FPGA).
>> > 1d). What is the concrete use case of set_time_source() in USRP X310?
>> Setting the time source -- ie. saying that the internal time of the X310
>> should come from the GPSDO or somewhere else.
>> > If I
>> > have an external PPS reference connected to X310 and I use this method,
>> > does that mean the PPS signal (including the PPS output) throughout whole
>> > X310 will BE the external PPS reference?
>> yes.
>> >
>> > 2). Is the method, set_clock_source() (so are et_clock_source_out(),
>> > set_time_source(), set_time_source_out()), needed to use only one time
>> > (call it for configuring USRP, and USRP will stay using external clock
>> > until it is powered off)?
>> I don't understand, sorry. Every USRP can only have one device time.
>> >
>> > 3). If I run applications in GRC on USRP without connecting an external
>> > clock (and I did not use set_clock_source() either), I always got warning
>> > message "WARN: Sensor 'lo_locked' failed to lock within timeout on channel
>> > 0";
>> > however, if I connect the atomic clock as an external clock, there is no
>> > such warning message. Looks like there is something activated after
>> > plugging eternal clock. If so, what is that? something like the PLL locking
>> > mechanism?
>> Yes, that is the information that the USRP couldn't gain a stabilized
>> clock, which is a bad thing as is.
>> However, there is no way to detect whether a cable is connected to the
>> ref in port, which means that either the external clock source is
>> selected in the UHD source/sinks options, or you have a problem with the
>> clock locking mechanism.
>> Are you using a recent version of UHD?
>>
>> Greetings,
>> Marcus
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > *Best Regards,Isen I-Chun Chao*
>> >
>> > On Tue, Nov 4, 2014 at 4:22 PM, Marcus M?ller <marcus.muel...@ettus.com>
>> > wrote:
>> >
>> >> Hi Isen,
>> >> On 04.11.2014 21:37, Isen I-Chun Chao wrote:
>> >>> Hi Marcus Leech and Marcus Muller,
>> >>> Thanks for the answers. But I am a little bit confused.
>> >>>
>> >>> Once I connect the atomic and X310, hardware (X310 USRPs) should operate
>> >>> based on external clock (atomic clock)
>> >> no, you must explicitely select the external clock source.
>> >>> due to the daisy-chain(?).
>> >> Daisy-chaining is the option to connect the reference output of one USRP
>> >> to the reference input of the next; inherently, it doesn't relate to
>> >> your use case.
>> >>> This is
>> >>> regardless of application use.
>> >> Depends on what your application wants to do. Most application will not
>> >> care where the reference comes from -- but you'll still need to set the
>> >> reference source.
>> >>> And I should have synchronized signal from
>> >>> REF outputs of two USRPs, right?
>> >>>
>> >>> If applications did not set up the use of external clock by using
>> >>> set_clock_source(), the application is going to use the default clock on
>> >>> X310 USRPs. (?)
>> >> yes.
>> >>> What clock the FPGA is based on? because the FPGA code will be modified
>> >>> working on our application.
>> >> The FPGA design has multiple clock domains. The most important clock
>> >> domain is driven at the master clock rate, which is 200MHz by default,
>> >> but can take more values (see UHD manual).
>> >>> BTW, the two X310 USRPs are Tx and Rx.
>> >> Each X310 has two completely independent TX and RX chains. Unless you
>> >> need to have them in two different places, I'm afraid I don't understand
>> >> why you need two X310.
>> >>> I am not using them as MIMO. The
>> >>> reason I want to make sure their clock can synchronized to an atomic
>> >> clock
>> >>> is that I would like to draw timestamps on both Tx and Rx based on the
>> >>> clock on USRPs. I use T-connectors to distribute atomic signals to two
>> >> X310
>> >>> USRP.
>> >> T-Connectors might or might not work -- distributing a 10MHz clock is a
>> >> bit of a tricky task, since reflections might mess up your phase
>> >> quality. Also, you split energy (let's say by half) between the two
>> >> USRPs! Make sure you're still able to reliably drive the clock inputs.
>> >> Usually, this is a case where you would need a proper clock distributor,
>> >> or a forwarding solution (such as daisy-chaining). For PPS synchronity,
>> >> you really should make sure you know what you're doing on the signal
>> >> distribution. I can see that daisy chaining will not be a good solution
>> >> here, unless you calibrate (which you could easily do).
>> >>
>> >> Best regards,
>> >> Marcus
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> *Best Regards,Isen I-Chun Chao*
>> >>>
>> >>> On Tue, Nov 4, 2014 at 3:11 PM, Marcus M?ller <
>> >> usrp-users@lists.ettus.com>
>> >>> wrote:
>> >>>
>> >>>> Hi Isen,
>> >>>>
>> >>>> yes, you're understanding correctly, but you'll have to select the
>> >>>> external reference explicitely using the set_clock_source method.
>> >>>> Also, your atomic clock has to have the possibility to drive two
>> >>>> receivers; distributing clock signals correctly isn't inherently
>> >> trivial.
>> >>>> For this reason, the X3x0s have the ability to "daisy-chain" the
>> >> reference
>> >>>> and PPS signals.
>> >>>>
>> >>>> Greetings,
>> >>>> Marcus
>> >>>>
>> >>>>
>> >>>> On 04.11.2014 20:48, Isen I-Chun Chao via USRP-users wrote:
>> >>>>
>> >>>> Hi,
>> >>>> If I have a atomic clock with me and would like to two X310 USRP
>> >>>> synchronize to this atomic clock.
>> >>>> I just connect the PPS output and the 10MHz Ref output on atomic clock
>> >> to
>> >>>> the input of two USRP. As long as the 'REF' leds on the front panel of
>> >> X310
>> >>>> USRPs are turned on, the internal clock of X310 USRPs are locked. No
>> >>>> further settings are required.
>> >>>>
>> >>>> Am I understanding it right?
>> >>>> Thanks.
>> >>>>
>> >>>>
>> >>>>
>> >>>> *Best Regards,Isen I-Chun Chao*
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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/20141107/d9dc8835/attachment-0001.html>
------------------------------
Message: 12
Date: Sat, 08 Nov 2014 05:22:08 +0000 (GMT)
From: Louis Brown <rfeng...@me.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] X310 vs N210 with LFRX digital gain problems
Message-ID: <d3b1cb10-fe62-4f13-94b1-41eb69ed2...@me.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I have both an X310 and N210, each with an LFRX, being fed via a splitter with
the same 1.60 MHz and 1.61 MHz tones at -60 dBm each. Each 250 ksps UHD source
is then fed to a frequency sink; X310 (blue) vs N210 (red). Each source shares
the same tune and gain settings. UHD_003.008.000-9-g426ad0be
At 0.0 dB gain things look fine:
https://dl.dropboxusercontent.com/u/49570443/x310_vs_n210_LFRX_0dB.png
At 1.0 dB gain the X310 (blue) has severe distortion:
https://dl.dropboxusercontent.com/u/49570443/x310_vs_n210_LFRX_1dB.png
It returns to normal at 1.5 dB gain, but then goes haywire again as the gain
varies to 6 dB.
As a side note, at low frequencies there is a strange "thumping" in the X310
spectrum, sort as if there were some kind of AGC action happening at 1 Hz rate.
A picture really can't capture it, but the X310 spectrum (blue) moves up and
down several dB (note this is connected to an active loop antenna):
https://dl.dropboxusercontent.com/u/49570443/x310_vs_n210_LFRX_thumping.png
All goes away when terminated with 50 Ohms. I assume there is no sort of
digital AGC happening in the X310? I need to swap these LFRX cards, and the
spur environment is totally different inside the X310 vs the N210, but this all
came about since the X310 seems to have poorer intermods for my HF reception,
given the same active loop antenna, even with sharp AM band-stop filtering.
Anyway, something wrong in the digital gain though.?
Thanks,
Lou
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141108/c7311f75/attachment-0001.html>
------------------------------
Message: 13
Date: Sat, 8 Nov 2014 10:03:36 +0100
From: "Ralph A. Schmid, dk5ras" <ra...@schmid.xxx>
To: "'Andy Walls'" <a...@silverblocksystems.net>,
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] B200 UHD 3.8.0: UHD Error: recv packet
demuxer unexpected sid...
Message-ID: <004201cffb32$e1aad6c0$a5008440$@schmid.xxx>
Content-Type: text/plain; charset="utf-8"
Hi,
When using Debian wheezy the system was as unstable as with Kubuntu, but an
upgrade with wheezy backports also updated the libusb stuff, and this may have
improved things, at least now gqrx can receive at 32MS for minutes until it
crashes with such a message:
thread[thread-per-block[0]: <block gr uhd usrp source (48)>]: EnvironmentError:
IOError: Radio ctrl (0) packet parse error - AssertionError:
packet_info.packet_count == (seq_to_ack & 0xfff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /home/openbts/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:258
So maybe really some libusb weirdness?!
Ralph.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141108/30e34806/attachment-0001.sig>
------------------------------
Message: 14
Date: Sat, 08 Nov 2014 10:55:31 +0100
From: Krzysztof Cwalina <kkcwal...@gmail.com>
To: Ben Hilburn <ben.hilb...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Windows UHD C++ API
Message-ID: <545de893.2030...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello Ben,
Thank You for reply. Yes I do not explain my problem enough. Dont focus
on C# - C++ connection and DLL. I just want to write a little library
which uses UHD driver to connect with the device (N2920 and N2921).
I just copy my code from DLL and build a simple C++ project which uses
the UHD driver. The problem is that in Linux this code works very
welland anything is ok. But suddenly on Windows I've got an error in the
places where I need to pass parameters as a string like methods:
usrp->set_clock_source("internal");
uhd::stream_args_t stream_args("fc32");
The other like:
usrp->set_rx_rate(rate);
usrp->get_rx_rate();
Works well under the Windows. I'm a bit confused why is it happening and
why I get error there. Only the methods where string is a parameter
seems to not working for me. I tried almost everything.
W dniu 2014-11-08 o 02:02, Ben Hilburn pisze:
> Hi Krzysztof -
>
> I'm a bit confused, I think. Can you explain what you mean by
> importing the UHD DLL into a C# project? I'm not familiar with C#, but
> is that expected to work?
>
> We certainly haven't tested anything like that, here. Or am I
> misunderstanding your question?
>
> Cheers,
> Ben
>
> On Fri, Nov 7, 2014 at 5:49 AM, Krzysztof Cwalina via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hello,
>
> in my project I just write the C++ DLL Library and import it into
> C# project. The problem is - there are some problems with the UHD.
> My platform:
>
> Windows 7 x64,
> Visual Studio 2013 Pro
>
> when I run project sometimes on the line:
> uhd::usrp::multi_usrp::sptr usrp =
> uhd::usrp::multi_usrp::make(args); there is exception like:
>
> A first chance exception of type
> 'System.Runtime.InteropServices.SEHException' occurred in USRPTest.exe
> Additional information: External component has thrown an exception.
>
> Sometimes it is - sometimes is not (depends on how many times I
> compile the same code. Next problem is when I want to use two methods:
>
> usrp->set_clock_source("internal"); or uhd::stream_args_t
> stream_args("fc32");
>
> Same error show up. I tried everything, I've searched almost all
> topics about this subject - but I didn't found the solution. Can
> anyone help me?
>
> Thanks.
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141108/0febb596/attachment-0001.html>
------------------------------
Message: 15
Date: Sat, 8 Nov 2014 12:50:27 +0200
From: Nir Eden <nir.e...@gmail.com>
To: Krzysztof Cwalina <kkcwal...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Windows UHD C++ API
Message-ID:
<CAP4_4=f7tfrsinqybdt2b+modsfnqbapxnr_pxjobgmdkcm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm not sure that I'm fully understand your setup. You are trying to call
UHD in windows from c++/cli program? if so you need to marshal string. Try
this:
std::string MarshalString(String ^ s)
{
using namespace Runtime::InteropServices;
const char* chars = (const
char*)(Marshal::StringToHGlobalAnsi(s)).ToPointer();
std::string os = chars;
Marshal::FreeHGlobal(IntPtr((void*)chars));
return os;
}
and than:
usrp->set_clock_source(MarshalString("internal");
-- Nir, 4Z7DEF
On Sat, Nov 8, 2014 at 11:55 AM, Krzysztof Cwalina via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hello Ben,
>
> Thank You for reply. Yes I do not explain my problem enough. Dont focus on
> C# - C++ connection and DLL. I just want to write a little library which
> uses UHD driver to connect with the device (N2920 and N2921).
>
> I just copy my code from DLL and build a simple C++ project which uses the
> UHD driver. The problem is that in Linux this code works very welland
> anything is ok. But suddenly on Windows I've got an error in the places
> where I need to pass parameters as a string like methods:
> usrp->set_clock_source("internal");
> uhd::stream_args_t stream_args("fc32");
>
> The other like:
> usrp->set_rx_rate(rate);
> usrp->get_rx_rate();
>
> Works well under the Windows. I'm a bit confused why is it happening and
> why I get error there. Only the methods where string is a parameter seems
> to not working for me. I tried almost everything.
>
> W dniu 2014-11-08 o 02:02, Ben Hilburn pisze:
>
> Hi Krzysztof -
>
> I'm a bit confused, I think. Can you explain what you mean by importing
> the UHD DLL into a C# project? I'm not familiar with C#, but is that
> expected to work?
>
> We certainly haven't tested anything like that, here. Or am I
> misunderstanding your question?
>
> Cheers,
> Ben
>
> On Fri, Nov 7, 2014 at 5:49 AM, Krzysztof Cwalina via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello,
>>
>> in my project I just write the C++ DLL Library and import it into C#
>> project. The problem is - there are some problems with the UHD. My platform:
>>
>> Windows 7 x64,
>> Visual Studio 2013 Pro
>>
>> when I run project sometimes on the line: uhd::usrp::multi_usrp::sptr
>> usrp = uhd::usrp::multi_usrp::make(args); there is exception like:
>>
>> A first chance exception of type
>> 'System.Runtime.InteropServices.SEHException' occurred in USRPTest.exe
>> Additional information: External component has thrown an exception.
>>
>> Sometimes it is - sometimes is not (depends on how many times I compile
>> the same code. Next problem is when I want to use two methods:
>>
>> usrp->set_clock_source("internal"); or uhd::stream_args_t
>> stream_args("fc32");
>>
>> Same error show up. I tried everything, I've searched almost all topics
>> about this subject - but I didn't found the solution. Can anyone help me?
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141108/95f1b5a0/attachment-0001.html>
------------------------------
Message: 16
Date: Sat, 08 Nov 2014 11:52:23 +0100
From: Krzysztof Cwalina <kkcwal...@gmail.com>
To: Nir Eden <nir.e...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Windows UHD C++ API
Message-ID: <545df5e7.7080...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello,
thank You very much for Your reply - I try this tommorow when I got
access to device. I will reply if it helps.
Best regards,
Krzysztof Cwalina
W dniu 2014-11-08 o 11:50, Nir Eden pisze:
> Hi,
>
> I'm not sure that I'm fully understand your setup. You are trying to
> call UHD in windows from c++/cli program? if so you need to marshal
> string. Try this:
>
> std::string MarshalString(String ^ s)
> {
> using namespace Runtime::InteropServices;
> const char* chars = (const
> char*)(Marshal::StringToHGlobalAnsi(s)).ToPointer();
> std::string os = chars;
> Marshal::FreeHGlobal(IntPtr((void*)chars));
> return os;
> }
>
> and than:
> usrp->set_clock_source(MarshalString("internal");
>
> -- Nir, 4Z7DEF
>
> On Sat, Nov 8, 2014 at 11:55 AM, Krzysztof Cwalina via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hello Ben,
>
> Thank You for reply. Yes I do not explain my problem enough. Dont
> focus on C# - C++ connection and DLL. I just want to write a
> little library which uses UHD driver to connect with the device
> (N2920 and N2921).
>
> I just copy my code from DLL and build a simple C++ project which
> uses the UHD driver. The problem is that in Linux this code works
> very welland anything is ok. But suddenly on Windows I've got an
> error in the places where I need to pass parameters as a string
> like methods:
> usrp->set_clock_source("internal");
> uhd::stream_args_t stream_args("fc32");
>
> The other like:
> usrp->set_rx_rate(rate);
> usrp->get_rx_rate();
>
> Works well under the Windows. I'm a bit confused why is it
> happening and why I get error there. Only the methods where string
> is a parameter seems to not working for me. I tried almost everything.
>
> W dniu 2014-11-08 o 02:02, Ben Hilburn pisze:
>> Hi Krzysztof -
>>
>> I'm a bit confused, I think. Can you explain what you mean by
>> importing the UHD DLL into a C# project? I'm not familiar with
>> C#, but is that expected to work?
>>
>> We certainly haven't tested anything like that, here. Or am I
>> misunderstanding your question?
>>
>> Cheers,
>> Ben
>>
>> On Fri, Nov 7, 2014 at 5:49 AM, Krzysztof Cwalina via USRP-users
>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
>> wrote:
>>
>> Hello,
>>
>> in my project I just write the C++ DLL Library and import it
>> into C# project. The problem is - there are some problems
>> with the UHD. My platform:
>>
>> Windows 7 x64,
>> Visual Studio 2013 Pro
>>
>> when I run project sometimes on the line:
>> uhd::usrp::multi_usrp::sptr usrp =
>> uhd::usrp::multi_usrp::make(args); there is exception like:
>>
>> A first chance exception of type
>> 'System.Runtime.InteropServices.SEHException' occurred in
>> USRPTest.exe
>> Additional information: External component has thrown an
>> exception.
>>
>> Sometimes it is - sometimes is not (depends on how many times
>> I compile the same code. Next problem is when I want to use
>> two methods:
>>
>> usrp->set_clock_source("internal"); or uhd::stream_args_t
>> stream_args("fc32");
>>
>> Same error show up. I tried everything, I've searched almost
>> all topics about this subject - but I didn't found the
>> solution. Can anyone help me?
>>
>> Thanks.
>>
>> _______________________________________________
>> 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 <mailto: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/20141108/6042b2be/attachment-0001.html>
------------------------------
Message: 17
Date: Sat, 08 Nov 2014 11:09:31 -0500
From: Andy Walls <a...@silverblocksystems.net>
To: Martin Braun <martin.br...@ettus.com>
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B200 UHD 3.8.0: UHD Error: recv packet
demuxer unexpected sid...
Message-ID: <1415462971.2819.12.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2014-11-06 at 10:12 +0100, Martin Braun via USRP-users wrote:
> On 11/01/2014 09:49 PM, Andy Walls via USRP-users wrote:
> > I've got a shiny new USRP B200 with the AC power adapter, factory
> > provided USB 3 cable, and no GPSDO install. I just used PyBOMBS to
> > build UHD 003.008.000 from git using the release tag.
>
> A bit late here, but since 3.8.0 we have a debug image for the B200 in
> the images package. If you write that to the device (--args fw=<path to
> images>/usrp_b200_fw_debug.hex and run tools/b200/b2x0_side_channel.py,
> you will get bunch of diagnostics.
>
> Note you need PyUSB 1.0 for this to work.
>
> Cheers,
> M
Thanks. I just ran through a test with this.
$ uhd_usrp_probe --args="fw=<prefix>/share/uhd/images/usrp_b200_fw_debug.hex" >
c1.output 2>&1
(In another terminal: )
$ <src_prefix>/src/uhd/tools/b200/b2x0_side_channel.py > c2sc.output 2>&1
(In original terminal: )
$ uhd_fft -A TX/RX -s 2000000 -f 315000000 > c2.output 2>&1
The debug output looks good; until things fall apart, upon which it
essentially informs one that communications are broken badly. The
counters are all trash at that point (bad magic), and when they do get
good magic back, they have obviously been cleared.
For the curious, below is the edited output of the side channel utility,
showing the highlights. Note that the growth of
"usb_error_count_update" by 49-52 counts every cycle appears to me to be
normal from my reading of the firmware source.
Regards,
Andy
Finding 2500:0020...
Opened 2500:0020
Operating at USB 3
Max buffer size: 4096
[00001 00001] 00000001 0001 USB_EVENT_VBUS_VALID
[00002 00001] 00000006 0002 CyU3PUsbSetTxSwing 45
[00003 00001] 00000006 0003 Compat: 7.0
[00004 00001] 00000006 0004 FX3 SDK: 1.2.3 (build 125)
[00005 00001] 00000007 0005 USB_EVENT_CONNECT
[00006 00001] 00000075 0006 USB_EVENT_RESET
[00007 00001] 000000EF 0007 USB_EVENT_SETCONF (#1)
[00008 00001] 000000EF 0008 b200_fw_start
[00009 00001] 000000EF 0009 LPMDisable OK
[00010 00001] 000000EF 0010 [DMA] to host: 64512, from host: 64512, depth: 1,
burst size: 16
[00011 00001] 000004CF 0011 b200_spi_init
[00012 00001] 000004CF 0012 Begin FPGA
[00013 00001] 00000501 0013 Wait FPGA
[00014 00001] 00000501 0014 Configuring FPGA
[00015 00001] 00002A8B 0015 FPGA done
[00016 00001] 00002A8B 0016 b200_gpif_init
[00017 00001] 00002A8D 0017 Running
[00018 00002] 00004E27 0018 Keep-alive
[00001]
magic: 268582913
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
log_overrun_count: 00000 usb_error_update_count: 00237
phy_error_count: 01658 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000
RX_ERROR_CRC16_EV: 00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV:
00000 PHY_ERROR_EB_UND_EV: 00001 PHY_ERROR_EB_OVR_EV: 00000
PHY_ERROR_DECODE_EV: 00001
usb_ep_underrun_count: 00000 heap_size: 00000 resume_count: 00000
[***lots of messages hand edited out]
[00028 00012] 00035B67 0028 Keep-alive
[00039]
magic: 268582913
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
log_overrun_count: 00000 usb_error_update_count: 02200
phy_error_count: 01658 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000
RX_ERROR_CRC16_EV: 00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV:
00000 PHY_ERROR_EB_UND_EV: 00001 PHY_ERROR_EB_OVR_EV: 00000
PHY_ERROR_DECODE_EV: 00001
usb_ep_underrun_count: 00000 heap_size: 00000 resume_count: 00000
[00040]
magic: 268582913
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
log_overrun_count: 00000 usb_error_update_count: 02252
phy_error_count: 01658 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000
RX_ERROR_CRC16_EV: 00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV:
00000 PHY_ERROR_EB_UND_EV: 00001 PHY_ERROR_EB_OVR_EV: 00000
PHY_ERROR_DECODE_EV: 00001
usb_ep_underrun_count: 00000 heap_size: 00000 resume_count: 00000
[00041]
magic: 268582913
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
log_overrun_count: 00000 usb_error_update_count: 02304
phy_error_count: 01658 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000
RX_ERROR_CRC16_EV: 00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV:
00000 PHY_ERROR_EB_UND_EV: 00001 PHY_ERROR_EB_OVR_EV: 00000
PHY_ERROR_DECODE_EV: 00001
usb_ep_underrun_count: 00000 heap_size: 00000 resume_count: 00000
0x23 (B200_VREQ_GET_LOG): [Errno 5] Input/output error
0x26 (B200_VREQ_GET_USB_EVENT_LOG): [Errno 5] Input/output error
0x23 (B200_VREQ_GET_LOG): [Errno 5] Input/output error
0x26 (B200_VREQ_GET_USB_EVENT_LOG): [Errno 5] Input/output error
0x23 (B200_VREQ_GET_LOG): [Errno 5] Input/output error
0x26 (B200_VREQ_GET_USB_EVENT_LOG): [Errno 5] Input/output error
0x23 (B200_VREQ_GET_LOG): [Errno 5] Input/output error
0x26 (B200_VREQ_GET_USB_EVENT_LOG): [Errno 5] Input/output error
0x23 (B200_VREQ_GET_LOG): [Errno 5] Input/output error
0x26 (B200_VREQ_GET_USB_EVENT_LOG): [Errno 5] Input/output error
0x23 (B200_VREQ_GET_LOG): [Errno 5] Input/output error
[00823] CYU3P_USB_LOG_USBSS_DISCONNECT: Indicates that the USB 3.0 link has
been disabled.
[00824] CYU3P_USB_LOG_LTSSM_CHG+34: LTSSM: (unknown)
[00042]
magic: 370414870
XFER_CPLT: 353768724 SEND_CPLT: 00001 RECV_CPLT: 1443422375
PROD_EVENT: 00001 CONS_EVENT: 1443422376 ABORTED: 852012 ERROR: 720865
PROD_SUSP: -1245164 CONS_SUSP: 4259860 BUFFER_MARKER: -393222
BUFFER_EOP: 4522001 BUFFER_ERROR: -917439 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 2490348 ABORTED: -5373966 ERROR:
-1572816 PROD_SUSP: 1638444 CONS_SUSP: 4849658 BUFFER_MARKER: 4849704
BUFFER_EOP: 196588 BUFFER_ERROR: 721042 BUFFER_OCCUPIED: 2948680
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
log_overrun_count: 00000 usb_error_update_count: 02357
phy_error_count: 01658 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000
RX_ERROR_CRC16_EV: 00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV:
00000 PHY_ERROR_EB_UND_EV: 00001 PHY_ERROR_EB_OVR_EV: 31720126
PHY_ERROR_DECODE_EV: 00001
usb_ep_underrun_count: 00000 heap_size: 00000 resume_count: 00000
[00826] CYU3P_USB_LOG_VBUS_OFF: Indicates VBus turned off.
[00826] CYU3P_USB_LOG_USB2_SUSP: Indicates that a USB 2.0 suspend
condition has been detected.
[00826] CYU3P_USB_LOG_VBUS_ON: Indicates VBus turned on.
[00826] CYU3P_USB_LOG_USBSS_DISCONNECT: Indicates that the USB 3.0 link has
been disabled.
[00029 00013] [***unprintable control codes hand edited out]
[00836] CYU3P_USB_LOG_USB2_RESET: Indicates that a USB 2.0 bus reset has
been detected.
[00043]
magic: 353768724
XFER_CPLT: 370414870 SEND_CPLT: 1699422265 RECV_CPLT: 842018848
PROD_EVENT: 1702259052 CONS_EVENT: 1630367845 ABORTED: 1279350367 ERROR:
1398079488 PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER:
00000 BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 2162786 CONS_SUSP: 6553642 BUFFER_MARKER: 2031674
BUFFER_EOP: -5505019 BUFFER_ERROR: 14090272 BUFFER_OCCUPIED: -49414082
last_count: -21102609 last_size: 9109647 last_sid: -2293731
bad_sid_count: 6029275
log_overrun_count: -6422525 usb_error_update_count: 8585214
phy_error_count: 4653068 link_error_count: 3539039
PHY_LOCK_EV: -2752462 TRAINING_ERROR_EV: 2359335 RX_ERROR_CRC32_EV:
3997619 RX_ERROR_CRC16_EV: -982958 RX_ERROR_CRC5_EV: -4128729
PHY_ERROR_DISPARITY_EV: -3801130 PHY_ERROR_EB_UND_EV: 6029384
PHY_ERROR_EB_OVR_EV: 6422570 PHY_ERROR_DECODE_EV: -1966163
usb_ep_underrun_count: -262098 heap_size: -983015 resume_count: 52428494
[00839] CYU3P_USB_LOG_VBUS_OFF: Indicates VBus turned off.
[00839] CYU3P_USB_LOG_USB2_SUSP: Indicates that a USB 2.0 suspend
condition has been detected.
[00839] CYU3P_USB_LOG_VBUS_ON: Indicates VBus turned on.
[00839] CYU3P_USB_LOG_USBSS_DISCONNECT: Indicates that the USB 3.0 link has
been disabled.
[***8 repeats of the above 4 lines hand edited out]
[00848] CYU3P_USB_LOG_VBUS_OFF: Indicates VBus turned off.
[00848] CYU3P_USB_LOG_USB2_SUSP: Indicates that a USB 2.0 suspend
condition has been detected.
[00848] CYU3P_USB_LOG_VBUS_ON: Indicates VBus turned on.
[00848] CYU3P_USB_LOG_USBSS_DISCONNECT: Indicates that the USB 3.0 link has
been disabled.
[00044]
magic: 268582913
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
XFER_CPLT: 00000 SEND_CPLT: 00000 RECV_CPLT: 00000
PROD_EVENT: 00000 CONS_EVENT: 00000 ABORTED: 00000 ERROR: 00000
PROD_SUSP: 00000 CONS_SUSP: 00000 BUFFER_MARKER: 00000
BUFFER_EOP: 00000 BUFFER_ERROR: 00000 BUFFER_OCCUPIED: 00000
last_count: 00000 last_size: 00000 last_sid: 00000 bad_sid_count:
00000
log_overrun_count: 00000 usb_error_update_count: 00000
phy_error_count: 00000 link_error_count: 00000 PHY_LOCK_EV: 00000
TRAINING_ERROR_EV: 00000 RX_ERROR_CRC32_EV: 00000
RX_ERROR_CRC16_EV: 00000 RX_ERROR_CRC5_EV: 00000 PHY_ERROR_DISPARITY_EV:
00000 PHY_ERROR_EB_UND_EV: 00000 PHY_ERROR_EB_OVR_EV: 00000
PHY_ERROR_DECODE_EV: 00000
usb_ep_underrun_count: 00000 heap_size: 00000 resume_count: 00000
[***remainder hand edited out]
------------------------------
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 51, Issue 8
*****************************************
