Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: X300 w/ GPSDO PPS Drift (Peter Witkowski)
2. Re: PC performance optimization (Rob Kossler)
3. Compile Boost and UHD with QT Creator Project (Patrick DaSilva)
4. Re: Compile Boost and UHD with QT Creator Project (Martin Braun)
5. Re: X300 w/ GPSDO PPS Drift (Neel Pandeya)
6. Re: Compile Boost and UHD with QT Creator Project (Ian Buckley)
7. Re: PC performance optimization (Michael West)
8. Re: PC performance optimization (Rob Kossler)
9. Re: X310 FPGA : Lowering bus_clk ? (Matt Ettus)
10. Re: 4 Channel Synchronization with 2 X-300s (Joel Bratin)
11. Re: 4 Channel Synchronization with 2 X-300s (Michael West)
12. Re: X310 50MHz two channel transmit problem (Neel Pandeya)
13. Ubuntu: install conflict between gnuradio uhd-host package
and Ettus uhd package (Patrick Sathyanathan)
14. Re: Ubuntu: install conflict between gnuradio uhd-host
package and Ettus uhd package (Marcus M?ller)
15. Unexpected FIFO depth (Rob Kossler)
16. Re: 4 Channel Synchronization with 2 X-300s (Joel Bratin)
17. (no subject) (Anil Gaddam)
18. Re: X310 over PCIe Instability ([email protected])
19. Re: X310 over PCIe Instability (Peter Witkowski)
----------------------------------------------------------------------
Message: 1
Date: Thu, 26 Mar 2015 13:38:41 -0400
From: Peter Witkowski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300 w/ GPSDO PPS Drift
Message-ID:
<can1qg3meq_cs9igskfo-nzy+27ukufpwqorw1nidqk+u5nt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Update:
I am able to reproduce the issue really easily. By just calling
multi_usrp::make(), the PPS will disappear, and then come back and drift.
I wrote a very simple program that just calls multi_usrp::make() and then
sits in an infinite loop waiting for CTRL+C. Even hitting CTRL+C right
afterwards (and therefore closing the connection to the USRP) causes the
issue. Note that this assumes that I don't need to change any clock
parameters, because the system will default to using the GPSDO (which is
what the documentation leads me to believe).
So to reiterate my point: there appears to be a bug that prevents multiple
X300s from synchronizing using the GPSDO, because when the connection to
the device gets opened, you lose PPS and reference lock, and then the PPS
drifts wildly. This affects anyone who has an X300 and is trying to
synchronize it using the GPSDO. I know of colleagues who have been able to
accomplish GPS synchronization on the N210, so this problem appears to be
X300 specific.
If anyone can recommend a fix (that doesn't involve throwing the $980 OCXO
modules in the trash and using an external clock source that actually
works), please let me know. I have already lost a week or so tracking down
this issue, so I'd prefer to not have to dive into the driver code myself
looking for the problem.
On Wed, Mar 25, 2015 at 2:49 PM, Peter Witkowski <[email protected]>
wrote:
> Hello,
>
> I am currently experiencing a rather puzzling issue trying to get a few
> X300s to synchronize together. Each X300 has a GPSDO installed (the OCXO
> model).
>
> When I first boot up each X300, I see no reference, PPS, or GPS lights on
> (I'm assuming this is normal). I then run uhd_usrp_probe and the reference
> and PPS lights start working. After some time (about ten to twenty minutes
> or so) the GPS light comes on. Note that even before the GPS light comes
> on, I can query the GPS and it shows 12 satellites and a good GPS position
> and lock.
>
> During this time, I am monitoring the PPS Out (via an oscilloscope) of
> each USRP to note whether or not the PPS signals are within spec. After
> about an hour or so, all the PPS signals are very tightly coupled (well
> within the spec of +/- 50ns. In fact, many of the signals are within +/-10
> ns or even better.
>
> However, when I go to start a program that receives signal data (either my
> own custom UHD application or uhd_fft), bad things happen. Here's what I'm
> seeing (note that I did a bit of debugging to note exactly where this is
> all happening).
>
> 1. When the UHD driver prints "Detecting Internal GPSDO" the PPS totally
> drops off of my scope. Hitting Ctrl+C during this time puts the X300 in a
> weird state where I can't see the PPS Out signal at all and the PPS light
> is noticeably different than the lights on the other units.
> 2. When the UHD driver prints "Initializing clock and time using GPSDO"
> the PPS comes back in the same spot that it was prior to starting the
> program.
> 3. The PPS will now drift wildly over time (+/- 200ns) leading me to
> believe it is no longer properly locked. It takes anywhere from one hour
> to several hours for the PPS to now steady itself.
>
> As a result, it would appear that when running any UHD program, the GPSDO
> is re-initialized, and drops its previously well established
> synchronization and lock. The UHD driver appears to be agnostic of whether
> or not the GPS is well synchronized or if it has just been powered on for
> the first time.
>
> I've also noted that this problem seems to occur regardless of
> daughtercard selection (tried both a WBX-120 and a CBX-120). Also, the
> problem is independent of which channel the daughtercard is plugged into as
> well.
>
> A final note is that this problem doesn't seem to occur when doing a
> uhd_usrp_probe, which uses the "device" interface (instead of multi_usrp)
> in terms of the UHD API. The PPS still drops out, but when it comes back,
> there is no drift.
>
> As a result, I'm wondering if there's a way to tell UHD to skip any GPSDO
> re-initialization when running a program. Also, is there a way to
> automatically get the GPSDO to come up and lock after power up (i.e., so I
> don't have to run a uhd_usrp_probe)? My ideal use case would be to power
> up my USRPs, allow them to get a good GPS synch, and then start my data
> collection without disturbing the previously established synch.
>
> Thanks for the assistance.
>
> --
> Peter Witkowski
> [email protected]
>
--
Peter Witkowski
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/3a18d7aa/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 26 Mar 2015 13:54:46 -0400
From: Rob Kossler <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<CAB__hTT84RNVFP9A9v0gZOY9kK=fcdajopy2nq_t3unreyn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Michael / Neel,
I renamed the "/etc/rc*.d/S99ondemand" files (and I also renamed
"/etc/init.d/ondemand") and now the CPU governor behaves as expected.
However, the very next Ubuntu Software Update that came along re-instated
these files. I renamed them again, but perhaps this is not the ideal
solution. Let me know if you think of a better way to accomplish this.
Any thoughts on the "PCIe Performance Mode" setting in the BIOS which is
described as "Configures power and performance options to maximize pcie
bandwidth". Does anyone know what this setting does and if it should be
enabled for use with the X310 (it is disabled by default)?
So, with the CPU always running at 3.5GHz (rather than dropping down to
1.2GHz), I am seeing much better performance results as measured by
benchmark_rate. However, I'm still seeing some underruns which I am not
used to. My other PC is an HP Z230 SFF Workstation with an Intel i7-4770
CPU. When I bought the new PC (HP Z440 Workstation with Intel Xeon E5-1620
v3 CPU), it looked like the performance benchmarks of these CPUs were
similar. So, I'm now wondering if my issue with occasional underruns is
CPU related (i.e., the Xeon is just worse than the i7 for this type of data
processing) of if it is a function of the motherboard architecture, BIOS
settings, and/or Ubuntu configuration. If you have any ideas on this, I
would love to hear them.
Thanks.
Rob
On Wed, Mar 25, 2015 at 5:44 PM, Michael West <[email protected]>
wrote:
> It looks like /etc/init.d/ondemand will set the governor to ondemand and
> is called whenever it is booted into multi-user mode. There are 2 options
> as I see it:
>
> 1) Disable the script by changing S99ondemand to s99ondemand in the
> /etc/rc*.d directories.
> 2) Edit /etc/init.d/ondemand to set the governor to "performance".
>
> (Looks like we need to update our documentation either way.)
>
> Regards,
> Michael
>
> On Wed, Mar 25, 2015 at 1:49 PM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> By the way, the popup help for the PCIe Performance Mode settings says
>> "Configures power and performance options to maximize pcie bandwidth".
>> This sounds pretty good to me.
>>
>> Rob
>>
>> On Wed, Mar 25, 2015 at 4:45 PM, Rob Kossler <[email protected]> wrote:
>>
>>> I don't know specifically about "ACPI power control/power management".
>>> My BIOS has the following:
>>>
>>> OS Power Options (items with ** described below. First option is the
>>> current setting)
>>> - ** Runtime Power Management: Enable/Disable
>>> - ** Idle Power Savings: Extended/Normal
>>> - Unique Blink States: Disable/Enable
>>>
>>> Additionally, the BIOS contains Performance settings.
>>>
>>> Performance Options
>>> - Intel HyperThreading Technology: Enable/Disable
>>> - Active CPU Cores For Processor: All cores per processor
>>> - PCIe Performance Mode: Enable/Disable
>>> - ** Turbo Mode: Enable/Disable
>>>
>>> Note: All items noted with ** indicate items that are unavailable for
>>> setting or even viewing if the option "PCIe Performance Mode" is Enabled.
>>> If it is Disabled (which is the default), then I can set all of the **
>>> items. However, I presently have PCIe Performance Mode Enabled because
>>> that "seems" to work better.
>>>
>>> So,
>>> 1) Let me know if you have any thoughts on the Power settings. I'm not
>>> sure if these map to "ACPI power control" or not.
>>> 2) Let me know if you have any thoughts on the PCIe Performance Mode
>>> Enable/Disable setting. I would think that we would want this enabled even
>>> though it is by default disabled. And the fact that the Power options are
>>> unavailable when this is Enabled makes me think that it effectively
>>> disables power control / management. But, I don't know that for certain.
>>>
>>> Rob
>>>
>>> On Wed, Mar 25, 2015 at 4:26 PM, Neel Pandeya <[email protected]>
>>> wrote:
>>>
>>>> Michael's post reminded me, you may also want/need to disable ACPI
>>>> power control/power management in your BIOS.
>>>>
>>>> --Neel
>>>>
>>>>
>>>> On 25 March 2015 at 13:03, Michael West <[email protected]> wrote:
>>>>
>>>>> Hi Rob,
>>>>>
>>>>> Check for power management utilities and either disable them or make
>>>>> sure their settings match what you want. What OS are you using?
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to support
>>>>>> EIST. But, I can't find anything in the HP M60 BIOS (v 1.21) related to
>>>>>> such a setting. BTW, there is a newer bios (1.25A) that I plan to install
>>>>>> later today....
>>>>>>
>>>>>> Regarding the speed settings, I am indeed able to change the MIN
>>>>>> speed to 3.5GHz. When I reboot now, the CPU setting always reports as
>>>>>> 3.5GHz, but the governor changes as before. That is, it starts out as
>>>>>> "performance" and then unexpectedly changes to "ondemand" after 30 secs
>>>>>> or
>>>>>> so. I'm wondering if this is worth worrying about or not. Perhaps as
>>>>>> long
>>>>>> as the CPU stays at 3.5GHz, that is all that matters. Or, perhaps some
>>>>>> other settings are affected by the "ondemand" governor or whatever is
>>>>>> triggering the governor setting to change. Not really sure on this???
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <[email protected]
>>>>>> > wrote:
>>>>>>
>>>>>>> Hello Rob:
>>>>>>>
>>>>>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you may
>>>>>>> need to disable it in the BIOS?? This is the only reason that I can
>>>>>>> think
>>>>>>> of at the moment as to why you'd see the behavior that you're seeing.
>>>>>>> Indeed, the "performance" governor is the governor setting that you
>>>>>>> want,
>>>>>>> but I don't understand why it's dynamically changing. I think it's due
>>>>>>> to
>>>>>>> Intel SpeedStep.
>>>>>>>
>>>>>>> Also, you may need to specify the CPU frequency separately from the
>>>>>>> governor setting. Set the governor, and then set the CPU frequency to
>>>>>>> the
>>>>>>> maximum possible.
>>>>>>>
>>>>>>> Please let us know if any of this works/helps.
>>>>>>>
>>>>>>> --Neel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> I just bought a new PC for use with an X310 and attempted to
>>>>>>>> configure it according to the instructions here (
>>>>>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>>>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2
>>>>>>>> chan,
>>>>>>>> full duplex, 100 MS/s). After getting lots of underruns and after
>>>>>>>> doing
>>>>>>>> some investigation, I noticed something strange. My CPU speed as
>>>>>>>> reported
>>>>>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>>>>>
>>>>>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>>>>>> configured for the "performance" governor setting. Then, I noticed
>>>>>>>> that
>>>>>>>> immediately after bootup, the freq was set to 3.5GHz and the governor
>>>>>>>> was
>>>>>>>> set to "performance" as expected. However, without running anything
>>>>>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>>>>>> governor setting unexpectedly changed to "ondemand" and the freq
>>>>>>>> setting
>>>>>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using "sudo
>>>>>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>>>>>> "performance" setting forever.
>>>>>>>>
>>>>>>>> Does anyone know why this setting would change (and/or how I can
>>>>>>>> stop it from doing so)? Looking online, I noticed that there can
>>>>>>>> sometimes
>>>>>>>> be a conflict with "laptop-mode-tools", but this PC is not a laptop
>>>>>>>> and I
>>>>>>>> don't have this package installed.
>>>>>>>>
>>>>>>>> Rob Kossler
>>>>>>>>
>>>>>>>> PC Info
>>>>>>>> Model: HP Z440 Workstation
>>>>>>>> CPU: Xeon E5-1620 v3
>>>>>>>> RAM: 32GB DDR4
>>>>>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>>>>>
>>>>>>>> UHD Info
>>>>>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/83fb37ce/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 26 Mar 2015 11:15:26 -0700
From: Patrick DaSilva <[email protected]>
To: USRP Mailing List <[email protected]>
Subject: [USRP-users] Compile Boost and UHD with QT Creator Project
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=us-ascii
I'm sorry for what may sound like a beginner question.
1. I'm looking to create a plotting GUI to also control an Ettus N210 inside QT
Creator. I'm thinking of using QTCustomPlot with a shared library. Is it doable
to also use a shared library with Boost and UHD? I found an example for
QTCustomPlot in QT Creator, but how would I link the UHD and Boost shared
libraries using QT Creator compiler?
2. Is it possible to just get the binary data of the 32-bit value output by the
N210 through the UHD API, split it in half into 2x16-bit values and then format
them appropriately? One half would an integer and the other half would be a
float.
Thank You
Patrick
------------------------------
Message: 4
Date: Thu, 26 Mar 2015 11:44:02 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Compile Boost and UHD with QT Creator
Project
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 26.03.2015 11:15, Patrick DaSilva via USRP-users wrote:
> I'm sorry for what may sound like a beginner question.
>
> 1. I'm looking to create a plotting GUI to also control an Ettus N210
> inside QT Creator. I'm thinking of using QTCustomPlot with a shared
> library. Is it doable to also use a shared library with Boost and
> UHD? I found an example for QTCustomPlot in QT Creator, but how would
> I link the UHD and Boost shared libraries using QT Creator compiler?
It must be possible. Now, I'm no QT Creator Expert (hopefully there's
someone here) but maybe CMake can actually gen such a project for you?
Also, check out how GNU Radio's QT stuff works, as a pointer. It might
get you there faster.
> 2. Is it possible to just get the binary data of the 32-bit value
> output by the N210 through the UHD API, split it in half into
> 2x16-bit values and then format them appropriately? One half would an
> integer and the other half would be a float.
Not sure which 32-bit value you're asking about. Are you asking about
complex ints (2x 16 bit)? Of course, you can do whatever you like with
the data once you have it in your app. But I'm not sure why you would
want to convert the Q part to float, and not I. Probably
misunderstanding your question anyway, maybe you can elaborate?
M
------------------------------
Message: 5
Date: Thu, 26 Mar 2015 11:51:46 -0700
From: Neel Pandeya <[email protected]>
To: Peter Witkowski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300 w/ GPSDO PPS Drift
Message-ID:
<CACaXmv95vbjJ+ch8kehdBeei6xpARaa3=s2xp3yoi5zbjuz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Peter:
Please contact me directly off-list, and let's work on this together. If
you don't mind, please send me your code example, and I'll try to reproduce
what you're seeing here. I'll post the results and solution back onto the
list afterwards.
--Neel
On 26 March 2015 at 10:38, Peter Witkowski via USRP-users <
[email protected]> wrote:
> Update:
>
> I am able to reproduce the issue really easily. By just calling
> multi_usrp::make(), the PPS will disappear, and then come back and drift.
> I wrote a very simple program that just calls multi_usrp::make() and then
> sits in an infinite loop waiting for CTRL+C. Even hitting CTRL+C right
> afterwards (and therefore closing the connection to the USRP) causes the
> issue. Note that this assumes that I don't need to change any clock
> parameters, because the system will default to using the GPSDO (which is
> what the documentation leads me to believe).
>
> So to reiterate my point: there appears to be a bug that prevents multiple
> X300s from synchronizing using the GPSDO, because when the connection to
> the device gets opened, you lose PPS and reference lock, and then the PPS
> drifts wildly. This affects anyone who has an X300 and is trying to
> synchronize it using the GPSDO. I know of colleagues who have been able to
> accomplish GPS synchronization on the N210, so this problem appears to be
> X300 specific.
>
> If anyone can recommend a fix (that doesn't involve throwing the $980 OCXO
> modules in the trash and using an external clock source that actually
> works), please let me know. I have already lost a week or so tracking down
> this issue, so I'd prefer to not have to dive into the driver code myself
> looking for the problem.
>
> On Wed, Mar 25, 2015 at 2:49 PM, Peter Witkowski <[email protected]>
> wrote:
>
>> Hello,
>>
>> I am currently experiencing a rather puzzling issue trying to get a few
>> X300s to synchronize together. Each X300 has a GPSDO installed (the OCXO
>> model).
>>
>> When I first boot up each X300, I see no reference, PPS, or GPS lights on
>> (I'm assuming this is normal). I then run uhd_usrp_probe and the reference
>> and PPS lights start working. After some time (about ten to twenty minutes
>> or so) the GPS light comes on. Note that even before the GPS light comes
>> on, I can query the GPS and it shows 12 satellites and a good GPS position
>> and lock.
>>
>> During this time, I am monitoring the PPS Out (via an oscilloscope) of
>> each USRP to note whether or not the PPS signals are within spec. After
>> about an hour or so, all the PPS signals are very tightly coupled (well
>> within the spec of +/- 50ns. In fact, many of the signals are within +/-10
>> ns or even better.
>>
>> However, when I go to start a program that receives signal data (either
>> my own custom UHD application or uhd_fft), bad things happen. Here's what
>> I'm seeing (note that I did a bit of debugging to note exactly where this
>> is all happening).
>>
>> 1. When the UHD driver prints "Detecting Internal GPSDO" the PPS totally
>> drops off of my scope. Hitting Ctrl+C during this time puts the X300 in a
>> weird state where I can't see the PPS Out signal at all and the PPS light
>> is noticeably different than the lights on the other units.
>> 2. When the UHD driver prints "Initializing clock and time using GPSDO"
>> the PPS comes back in the same spot that it was prior to starting the
>> program.
>> 3. The PPS will now drift wildly over time (+/- 200ns) leading me to
>> believe it is no longer properly locked. It takes anywhere from one hour
>> to several hours for the PPS to now steady itself.
>>
>> As a result, it would appear that when running any UHD program, the GPSDO
>> is re-initialized, and drops its previously well established
>> synchronization and lock. The UHD driver appears to be agnostic of whether
>> or not the GPS is well synchronized or if it has just been powered on for
>> the first time.
>>
>> I've also noted that this problem seems to occur regardless of
>> daughtercard selection (tried both a WBX-120 and a CBX-120). Also, the
>> problem is independent of which channel the daughtercard is plugged into as
>> well.
>>
>> A final note is that this problem doesn't seem to occur when doing a
>> uhd_usrp_probe, which uses the "device" interface (instead of multi_usrp)
>> in terms of the UHD API. The PPS still drops out, but when it comes back,
>> there is no drift.
>>
>> As a result, I'm wondering if there's a way to tell UHD to skip any GPSDO
>> re-initialization when running a program. Also, is there a way to
>> automatically get the GPSDO to come up and lock after power up (i.e., so I
>> don't have to run a uhd_usrp_probe)? My ideal use case would be to power
>> up my USRPs, allow them to get a good GPS synch, and then start my data
>> collection without disturbing the previously established synch.
>>
>> Thanks for the assistance.
>>
>> --
>> Peter Witkowski
>> [email protected]
>>
>
>
>
> --
> Peter Witkowski
> [email protected]
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/34318b7a/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 26 Mar 2015 11:54:09 -0700
From: Ian Buckley <[email protected]>
To: Martin Braun <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Compile Boost and UHD with QT Creator
Project
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Perhaps study GQRX (http://gqrx.dk) since that uses GR and UHD and is built
under QT?
-Ian
On Mar 26, 2015, at 11:44 AM, Martin Braun via USRP-users
<[email protected]> wrote:
> On 26.03.2015 11:15, Patrick DaSilva via USRP-users wrote:
>> I'm sorry for what may sound like a beginner question.
>>
>> 1. I'm looking to create a plotting GUI to also control an Ettus N210
>> inside QT Creator. I'm thinking of using QTCustomPlot with a shared
>> library. Is it doable to also use a shared library with Boost and
>> UHD? I found an example for QTCustomPlot in QT Creator, but how would
>> I link the UHD and Boost shared libraries using QT Creator compiler?
>
> It must be possible. Now, I'm no QT Creator Expert (hopefully there's someone
> here) but maybe CMake can actually gen such a project for you?
>
> Also, check out how GNU Radio's QT stuff works, as a pointer. It might get
> you there faster.
>
------------------------------
Message: 7
Date: Thu, 26 Mar 2015 12:51:17 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cam4xkrphay867ec5xtaxmeo0og5uug4q9rzgtj3v48-5u-b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
Renaming /etc/init.d/ondemand may have caused the problem with the updater
restoring all the files. If you just rename the /etc/rc*.d/S99ondemand
files, that is sufficient to prevent the init script from running at
startup. Otherwise, you can try modifying /etc/init.d/ondemand to do
nothing.
Not sure what the "PCIe Performance Mode" BIOS setting is. You can try it
to see if it makes a difference. A simple Google search turned up the
following document that gives some tips on how to get the best I/O
performance for the HP Z440:
http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA5-4043ENW
Are you seeing underruns at all sample rates or just the higher ones? At
200 MSPS, there will be occasional underruns. This is because the buffer
space for incoming TX data is very limited on the X300 and can drain faster
than the host can get the flow control signal to send more data and respond
to it. We are working on a solution for that.
Regards,
Michael
On Thu, Mar 26, 2015 at 10:54 AM, Rob Kossler <[email protected]> wrote:
> Thanks Michael / Neel,
> I renamed the "/etc/rc*.d/S99ondemand" files (and I also renamed
> "/etc/init.d/ondemand") and now the CPU governor behaves as expected.
> However, the very next Ubuntu Software Update that came along re-instated
> these files. I renamed them again, but perhaps this is not the ideal
> solution. Let me know if you think of a better way to accomplish this.
>
> Any thoughts on the "PCIe Performance Mode" setting in the BIOS which is
> described as "Configures power and performance options to maximize pcie
> bandwidth". Does anyone know what this setting does and if it should be
> enabled for use with the X310 (it is disabled by default)?
>
> So, with the CPU always running at 3.5GHz (rather than dropping down to
> 1.2GHz), I am seeing much better performance results as measured by
> benchmark_rate. However, I'm still seeing some underruns which I am not
> used to. My other PC is an HP Z230 SFF Workstation with an Intel i7-4770
> CPU. When I bought the new PC (HP Z440 Workstation with Intel Xeon E5-1620
> v3 CPU), it looked like the performance benchmarks of these CPUs were
> similar. So, I'm now wondering if my issue with occasional underruns is
> CPU related (i.e., the Xeon is just worse than the i7 for this type of data
> processing) of if it is a function of the motherboard architecture, BIOS
> settings, and/or Ubuntu configuration. If you have any ideas on this, I
> would love to hear them.
>
> Thanks.
>
> Rob
>
>
>
> On Wed, Mar 25, 2015 at 5:44 PM, Michael West <[email protected]>
> wrote:
>
>> It looks like /etc/init.d/ondemand will set the governor to ondemand and
>> is called whenever it is booted into multi-user mode. There are 2 options
>> as I see it:
>>
>> 1) Disable the script by changing S99ondemand to s99ondemand in the
>> /etc/rc*.d directories.
>> 2) Edit /etc/init.d/ondemand to set the governor to "performance".
>>
>> (Looks like we need to update our documentation either way.)
>>
>> Regards,
>> Michael
>>
>> On Wed, Mar 25, 2015 at 1:49 PM, Rob Kossler via USRP-users <
>> [email protected]> wrote:
>>
>>> By the way, the popup help for the PCIe Performance Mode settings says
>>> "Configures power and performance options to maximize pcie bandwidth".
>>> This sounds pretty good to me.
>>>
>>> Rob
>>>
>>> On Wed, Mar 25, 2015 at 4:45 PM, Rob Kossler <[email protected]> wrote:
>>>
>>>> I don't know specifically about "ACPI power control/power management".
>>>> My BIOS has the following:
>>>>
>>>> OS Power Options (items with ** described below. First option is the
>>>> current setting)
>>>> - ** Runtime Power Management: Enable/Disable
>>>> - ** Idle Power Savings: Extended/Normal
>>>> - Unique Blink States: Disable/Enable
>>>>
>>>> Additionally, the BIOS contains Performance settings.
>>>>
>>>> Performance Options
>>>> - Intel HyperThreading Technology: Enable/Disable
>>>> - Active CPU Cores For Processor: All cores per processor
>>>> - PCIe Performance Mode: Enable/Disable
>>>> - ** Turbo Mode: Enable/Disable
>>>>
>>>> Note: All items noted with ** indicate items that are unavailable for
>>>> setting or even viewing if the option "PCIe Performance Mode" is Enabled.
>>>> If it is Disabled (which is the default), then I can set all of the **
>>>> items. However, I presently have PCIe Performance Mode Enabled because
>>>> that "seems" to work better.
>>>>
>>>> So,
>>>> 1) Let me know if you have any thoughts on the Power settings. I'm not
>>>> sure if these map to "ACPI power control" or not.
>>>> 2) Let me know if you have any thoughts on the PCIe Performance Mode
>>>> Enable/Disable setting. I would think that we would want this enabled even
>>>> though it is by default disabled. And the fact that the Power options are
>>>> unavailable when this is Enabled makes me think that it effectively
>>>> disables power control / management. But, I don't know that for certain.
>>>>
>>>> Rob
>>>>
>>>> On Wed, Mar 25, 2015 at 4:26 PM, Neel Pandeya <[email protected]>
>>>> wrote:
>>>>
>>>>> Michael's post reminded me, you may also want/need to disable ACPI
>>>>> power control/power management in your BIOS.
>>>>>
>>>>> --Neel
>>>>>
>>>>>
>>>>> On 25 March 2015 at 13:03, Michael West <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Rob,
>>>>>>
>>>>>> Check for power management utilities and either disable them or make
>>>>>> sure their settings match what you want. What OS are you using?
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to
>>>>>>> support EIST. But, I can't find anything in the HP M60 BIOS (v 1.21)
>>>>>>> related to such a setting. BTW, there is a newer bios (1.25A) that I
>>>>>>> plan
>>>>>>> to install later today....
>>>>>>>
>>>>>>> Regarding the speed settings, I am indeed able to change the MIN
>>>>>>> speed to 3.5GHz. When I reboot now, the CPU setting always reports as
>>>>>>> 3.5GHz, but the governor changes as before. That is, it starts out as
>>>>>>> "performance" and then unexpectedly changes to "ondemand" after 30 secs
>>>>>>> or
>>>>>>> so. I'm wondering if this is worth worrying about or not. Perhaps as
>>>>>>> long
>>>>>>> as the CPU stays at 3.5GHz, that is all that matters. Or, perhaps some
>>>>>>> other settings are affected by the "ondemand" governor or whatever is
>>>>>>> triggering the governor setting to change. Not really sure on this???
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hello Rob:
>>>>>>>>
>>>>>>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you
>>>>>>>> may need to disable it in the BIOS?? This is the only reason that I can
>>>>>>>> think of at the moment as to why you'd see the behavior that you're
>>>>>>>> seeing.
>>>>>>>> Indeed, the "performance" governor is the governor setting that you
>>>>>>>> want,
>>>>>>>> but I don't understand why it's dynamically changing. I think it's due
>>>>>>>> to
>>>>>>>> Intel SpeedStep.
>>>>>>>>
>>>>>>>> Also, you may need to specify the CPU frequency separately from the
>>>>>>>> governor setting. Set the governor, and then set the CPU frequency to
>>>>>>>> the
>>>>>>>> maximum possible.
>>>>>>>>
>>>>>>>> Please let us know if any of this works/helps.
>>>>>>>>
>>>>>>>> --Neel
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> I just bought a new PC for use with an X310 and attempted to
>>>>>>>>> configure it according to the instructions here (
>>>>>>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>>>>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2
>>>>>>>>> chan,
>>>>>>>>> full duplex, 100 MS/s). After getting lots of underruns and after
>>>>>>>>> doing
>>>>>>>>> some investigation, I noticed something strange. My CPU speed as
>>>>>>>>> reported
>>>>>>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>>>>>>
>>>>>>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>>>>>>> configured for the "performance" governor setting. Then, I noticed
>>>>>>>>> that
>>>>>>>>> immediately after bootup, the freq was set to 3.5GHz and the governor
>>>>>>>>> was
>>>>>>>>> set to "performance" as expected. However, without running anything
>>>>>>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>>>>>>> governor setting unexpectedly changed to "ondemand" and the freq
>>>>>>>>> setting
>>>>>>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using
>>>>>>>>> "sudo
>>>>>>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>>>>>>> "performance" setting forever.
>>>>>>>>>
>>>>>>>>> Does anyone know why this setting would change (and/or how I can
>>>>>>>>> stop it from doing so)? Looking online, I noticed that there can
>>>>>>>>> sometimes
>>>>>>>>> be a conflict with "laptop-mode-tools", but this PC is not a laptop
>>>>>>>>> and I
>>>>>>>>> don't have this package installed.
>>>>>>>>>
>>>>>>>>> Rob Kossler
>>>>>>>>>
>>>>>>>>> PC Info
>>>>>>>>> Model: HP Z440 Workstation
>>>>>>>>> CPU: Xeon E5-1620 v3
>>>>>>>>> RAM: 32GB DDR4
>>>>>>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>>>>>>
>>>>>>>>> UHD Info
>>>>>>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> USRP-users mailing list
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/20f693e6/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 26 Mar 2015 17:36:38 -0400
From: Rob Kossler <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] PC performance optimization
Message-ID:
<cab__httuwhh843+ukvy+xn4o7clem9znpjwt9v8hyx3dbkz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Michael,
Ok. I will restore /etc/init.d/ondemand. I'll let you know if any
subsequent update causes any issue.
Thanks for the doc link. I had seen this and attempted to configure the
system optimally according to this doc.
Regarding the underruns, yes, it is only happening at 200 MS/s (actually
100 MS/s on two channels). But, it seems to be occurring more frequently
than with my old PC (at same rate). I understand your comment about the
limited buffer on the X300, but there also seems to be a PC-related
component that is causing different performance on different PCs. No
matter, this is not a big issue for me presently, so we can drop this for
now.
Rob
On Thu, Mar 26, 2015 at 3:51 PM, Michael West <[email protected]>
wrote:
> Hi Rob,
>
> Renaming /etc/init.d/ondemand may have caused the problem with the updater
> restoring all the files. If you just rename the /etc/rc*.d/S99ondemand
> files, that is sufficient to prevent the init script from running at
> startup. Otherwise, you can try modifying /etc/init.d/ondemand to do
> nothing.
>
> Not sure what the "PCIe Performance Mode" BIOS setting is. You can try it
> to see if it makes a difference. A simple Google search turned up the
> following document that gives some tips on how to get the best I/O
> performance for the HP Z440:
> http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA5-4043ENW
>
> Are you seeing underruns at all sample rates or just the higher ones? At
> 200 MSPS, there will be occasional underruns. This is because the buffer
> space for incoming TX data is very limited on the X300 and can drain faster
> than the host can get the flow control signal to send more data and respond
> to it. We are working on a solution for that.
>
> Regards,
> Michael
>
>
> On Thu, Mar 26, 2015 at 10:54 AM, Rob Kossler <[email protected]> wrote:
>
>> Thanks Michael / Neel,
>> I renamed the "/etc/rc*.d/S99ondemand" files (and I also renamed
>> "/etc/init.d/ondemand") and now the CPU governor behaves as expected.
>> However, the very next Ubuntu Software Update that came along re-instated
>> these files. I renamed them again, but perhaps this is not the ideal
>> solution. Let me know if you think of a better way to accomplish this.
>>
>> Any thoughts on the "PCIe Performance Mode" setting in the BIOS which is
>> described as "Configures power and performance options to maximize pcie
>> bandwidth". Does anyone know what this setting does and if it should be
>> enabled for use with the X310 (it is disabled by default)?
>>
>> So, with the CPU always running at 3.5GHz (rather than dropping down to
>> 1.2GHz), I am seeing much better performance results as measured by
>> benchmark_rate. However, I'm still seeing some underruns which I am not
>> used to. My other PC is an HP Z230 SFF Workstation with an Intel i7-4770
>> CPU. When I bought the new PC (HP Z440 Workstation with Intel Xeon E5-1620
>> v3 CPU), it looked like the performance benchmarks of these CPUs were
>> similar. So, I'm now wondering if my issue with occasional underruns is
>> CPU related (i.e., the Xeon is just worse than the i7 for this type of data
>> processing) of if it is a function of the motherboard architecture, BIOS
>> settings, and/or Ubuntu configuration. If you have any ideas on this, I
>> would love to hear them.
>>
>> Thanks.
>>
>> Rob
>>
>>
>>
>> On Wed, Mar 25, 2015 at 5:44 PM, Michael West <[email protected]>
>> wrote:
>>
>>> It looks like /etc/init.d/ondemand will set the governor to ondemand and
>>> is called whenever it is booted into multi-user mode. There are 2 options
>>> as I see it:
>>>
>>> 1) Disable the script by changing S99ondemand to s99ondemand in the
>>> /etc/rc*.d directories.
>>> 2) Edit /etc/init.d/ondemand to set the governor to "performance".
>>>
>>> (Looks like we need to update our documentation either way.)
>>>
>>> Regards,
>>> Michael
>>>
>>> On Wed, Mar 25, 2015 at 1:49 PM, Rob Kossler via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> By the way, the popup help for the PCIe Performance Mode settings says
>>>> "Configures power and performance options to maximize pcie bandwidth".
>>>> This sounds pretty good to me.
>>>>
>>>> Rob
>>>>
>>>> On Wed, Mar 25, 2015 at 4:45 PM, Rob Kossler <[email protected]> wrote:
>>>>
>>>>> I don't know specifically about "ACPI power control/power
>>>>> management". My BIOS has the following:
>>>>>
>>>>> OS Power Options (items with ** described below. First option is the
>>>>> current setting)
>>>>> - ** Runtime Power Management: Enable/Disable
>>>>> - ** Idle Power Savings: Extended/Normal
>>>>> - Unique Blink States: Disable/Enable
>>>>>
>>>>> Additionally, the BIOS contains Performance settings.
>>>>>
>>>>> Performance Options
>>>>> - Intel HyperThreading Technology: Enable/Disable
>>>>> - Active CPU Cores For Processor: All cores per processor
>>>>> - PCIe Performance Mode: Enable/Disable
>>>>> - ** Turbo Mode: Enable/Disable
>>>>>
>>>>> Note: All items noted with ** indicate items that are unavailable for
>>>>> setting or even viewing if the option "PCIe Performance Mode" is Enabled.
>>>>> If it is Disabled (which is the default), then I can set all of the **
>>>>> items. However, I presently have PCIe Performance Mode Enabled because
>>>>> that "seems" to work better.
>>>>>
>>>>> So,
>>>>> 1) Let me know if you have any thoughts on the Power settings. I'm
>>>>> not sure if these map to "ACPI power control" or not.
>>>>> 2) Let me know if you have any thoughts on the PCIe Performance Mode
>>>>> Enable/Disable setting. I would think that we would want this enabled
>>>>> even
>>>>> though it is by default disabled. And the fact that the Power options are
>>>>> unavailable when this is Enabled makes me think that it effectively
>>>>> disables power control / management. But, I don't know that for certain.
>>>>>
>>>>> Rob
>>>>>
>>>>> On Wed, Mar 25, 2015 at 4:26 PM, Neel Pandeya <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Michael's post reminded me, you may also want/need to disable ACPI
>>>>>> power control/power management in your BIOS.
>>>>>>
>>>>>> --Neel
>>>>>>
>>>>>>
>>>>>> On 25 March 2015 at 13:03, Michael West <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> Check for power management utilities and either disable them or make
>>>>>>> sure their settings match what you want. What OS are you using?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michael
>>>>>>>
>>>>>>> On Wed, Mar 25, 2015 at 12:32 PM, Rob Kossler via USRP-users <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Looking at the CPU specs (Xeon E5-1620 v3), it does appear to
>>>>>>>> support EIST. But, I can't find anything in the HP M60 BIOS (v 1.21)
>>>>>>>> related to such a setting. BTW, there is a newer bios (1.25A) that I
>>>>>>>> plan
>>>>>>>> to install later today....
>>>>>>>>
>>>>>>>> Regarding the speed settings, I am indeed able to change the MIN
>>>>>>>> speed to 3.5GHz. When I reboot now, the CPU setting always reports as
>>>>>>>> 3.5GHz, but the governor changes as before. That is, it starts out as
>>>>>>>> "performance" and then unexpectedly changes to "ondemand" after 30
>>>>>>>> secs or
>>>>>>>> so. I'm wondering if this is worth worrying about or not. Perhaps as
>>>>>>>> long
>>>>>>>> as the CPU stays at 3.5GHz, that is all that matters. Or, perhaps some
>>>>>>>> other settings are affected by the "ondemand" governor or whatever is
>>>>>>>> triggering the governor setting to change. Not really sure on this???
>>>>>>>>
>>>>>>>> Rob
>>>>>>>>
>>>>>>>> On Wed, Mar 25, 2015 at 2:22 PM, Neel Pandeya <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hello Rob:
>>>>>>>>>
>>>>>>>>> Perhaps your CPU has Intel SpeedStep (aka EIST) enabled, and you
>>>>>>>>> may need to disable it in the BIOS?? This is the only reason that I
>>>>>>>>> can
>>>>>>>>> think of at the moment as to why you'd see the behavior that you're
>>>>>>>>> seeing.
>>>>>>>>> Indeed, the "performance" governor is the governor setting that you
>>>>>>>>> want,
>>>>>>>>> but I don't understand why it's dynamically changing. I think it's
>>>>>>>>> due to
>>>>>>>>> Intel SpeedStep.
>>>>>>>>>
>>>>>>>>> Also, you may need to specify the CPU frequency separately from
>>>>>>>>> the governor setting. Set the governor, and then set the CPU
>>>>>>>>> frequency to
>>>>>>>>> the maximum possible.
>>>>>>>>>
>>>>>>>>> Please let us know if any of this works/helps.
>>>>>>>>>
>>>>>>>>> --Neel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 25 March 2015 at 10:48, Rob Kossler via USRP-users <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>> I just bought a new PC for use with an X310 and attempted to
>>>>>>>>>> configure it according to the instructions here (
>>>>>>>>>> http://files.ettus.com/manual/page_usrp_x3x0_config.html).
>>>>>>>>>> Subsequently, I tested the configured PC using "benchmark_rate" (2
>>>>>>>>>> chan,
>>>>>>>>>> full duplex, 100 MS/s). After getting lots of underruns and after
>>>>>>>>>> doing
>>>>>>>>>> some investigation, I noticed something strange. My CPU speed as
>>>>>>>>>> reported
>>>>>>>>>> by "cpufreq-info" was at 1.2 GHz rather than 3.5 GHz.
>>>>>>>>>>
>>>>>>>>>> I double-checked that the file "/etc/init.d/cpufrequtils" was
>>>>>>>>>> configured for the "performance" governor setting. Then, I noticed
>>>>>>>>>> that
>>>>>>>>>> immediately after bootup, the freq was set to 3.5GHz and the
>>>>>>>>>> governor was
>>>>>>>>>> set to "performance" as expected. However, without running anything
>>>>>>>>>> besides "cpufreq-info", I noticed that after about 30 secs or so, the
>>>>>>>>>> governor setting unexpectedly changed to "ondemand" and the freq
>>>>>>>>>> setting
>>>>>>>>>> dropped to 1.2 GHz. If I subsequently restart cpufrequtils using
>>>>>>>>>> "sudo
>>>>>>>>>> /etc/init.d/cpufrequtils restart", it then seems to stay in the
>>>>>>>>>> "performance" setting forever.
>>>>>>>>>>
>>>>>>>>>> Does anyone know why this setting would change (and/or how I can
>>>>>>>>>> stop it from doing so)? Looking online, I noticed that there can
>>>>>>>>>> sometimes
>>>>>>>>>> be a conflict with "laptop-mode-tools", but this PC is not a laptop
>>>>>>>>>> and I
>>>>>>>>>> don't have this package installed.
>>>>>>>>>>
>>>>>>>>>> Rob Kossler
>>>>>>>>>>
>>>>>>>>>> PC Info
>>>>>>>>>> Model: HP Z440 Workstation
>>>>>>>>>> CPU: Xeon E5-1620 v3
>>>>>>>>>> RAM: 32GB DDR4
>>>>>>>>>> 10Gb: Intel X520-DA2 (previously used successfully in another PC)
>>>>>>>>>>
>>>>>>>>>> UHD Info
>>>>>>>>>> - 3.8.2 compiled from source, installed via PyBOMBS
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> USRP-users mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/df9da150/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 26 Mar 2015 14:47:55 -0700
From: Matt Ettus <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 FPGA : Lowering bus_clk ?
Message-ID:
<CAN=1kn_FeUETQXBdqgYULLy-PcBAP=1hu1uf_gqk7dvtxp1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Mar 22, 2015 at 3:18 PM, Sylvain Munaut <[email protected]> wrote:
> Hi Matt,
>
>
> > bus_clk needs to be at least 156.25 MHz to keep up with 10GE. The ZPU
> > doesn't need to be that fast, but it would take some work to get it off
> of
> > bus_clk.
>
> Ok, so lowering it in general wouldn't be good.
>
> But since I don't use 10GE, I could still modify it locally to 150M
> just to speed up my test builds and this should work ?
>
Yes
>
> Then when things are finalized, I can move it back to 166M and if it
> takes a couple of run to produce a production bitstream, that's not
> too much of an issue.
>
>
Good.
>
> > One thing to keep in mind, though, is that the problem is not
> necessarily in
> > bus_clk. If you put in some logic elsewhere which has a lot of trouble
> > meeting timing, the tool works very hard on that clock domain, and you
> can
> > see timing errors show up in unrelated clock domains. So optimizing your
> > logic might help.
>
> Yes I know, but I'm fairly confident that particular path is the
> problem. Out of 10 failed timing build this weekend (some not even
> including my custom logic but just a full set of standard NoC blocks),
> this path (starting from zpu bram and ending somewhere with zpu stack)
> has been present in all the failures, and it's always very long (9-10
> levels of logic including a BRAM out).
>
> Some time others will also show up, like the radio_clk_2x db phase
> thing that's running at 400 MHz, but those only show up randomly and
> are probably just because it tried meeting the bus_clk so hard.
>
Sounds like you understand the issues involved. When we switch to Vivado,
hopefully this will get better.
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/24a1905b/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 26 Mar 2015 21:49:40 +0000
From: Joel Bratin <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Thanks for clarifying that.
We are still trying to find a solution to synchronize multiple boxes with an
?internal? PPS.
We took the PPS-Out from a GPSDO (without a GPS lock) on an NI USRP-2930 and
split it to the PPS-In on both of our X300s and successfully synchronized them
to within 1ns.
We were wondering if we added a GPSDO to one of the X300s would there be any
way to use the PPS-out from that GPSDO to synchronize the time sources of both
X300s? This would really help us so we don?t have to include another piece of
hardware outside the X300.
Should we expect any negative impact on our synchronization if we never have a
GPS lock on the GPSDO?
Thanks,
Joel Bratin
From: Michael West [mailto:[email protected]]
Sent: Wednesday, March 25, 2015 7:27 PM
To: Joel Bratin
Cc: [email protected]
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Hi Joel,
So, here is what is going on. When using multiple X300s, they need to have the
same time set on both. If not, there will be all kinds of timing issues.
Supplying a common external reference and PPS and using set_time_unknown_pps()
is the best way to synchronize the times on the devices.
The benchmark_rate example does not do this, so the default reference and PPS
are used and the times on the X300s are different. The RX rate test results in
a timeout when specifying channels on the second device because it sets the
start time for the streaming based on the time retrieved from the first device.
You can modify the example to add lines to set the clock and time sources to
external and call set_time_unknown_pps() and it should work fine.
Hope this helps clear things up.
Regards,
Michael
On Tue, Mar 24, 2015 at 2:08 PM, Joel Bratin
<[email protected]<mailto:[email protected]>> wrote:
Hi Michael,
We are using UHD 3.8.2. We tried it on Windows, Mac OS and Linux (Fedora) and
received the same problem.
Steps to reproduce the problem:
1. X300 #1 with IP address 192.168.40.2
2. X300 #2 with IP Address 192.168.140.2
3. Connect each X300 to its own interface on our Intel X520-DA2
4. Reboot each X300
5. Run benchmark_rate.exe --args ?addr0=192.168.140.2,
addr1=192.168.40.2? ?rx_rate 625000 ?channels ?2,3
When running we receive ERROR_CODE_TIMEOUT
We managed to find a workaround but we?re not entirely sure why it works.
In our own application we used set_time_source(?external?) and
set_clock_source(?external?). We connected an external clock and PPS to both
X300s.
We called set_time_unknown_pps(uhd::time_spec_t(0.0))
We stopped seeing the ERROR_CODE_TIMEOUT while streaming.
Furthermore, when we returned back to benchmark_rate.exe we found that we
stopped getting the ERROR_CODE_TIMEOUT. The ERROR_CODE_TIMEOUT disappeared
until we shut off one of the X300s and turned it back on.
It seems like our application kicked the X300s into a working state but we?re
not sure why. Do you have any idea what could?ve fixed our problem?
Benchmark_rate doesn?t set the time_source or ?clock_source so we assume it
automatically uses an ?internal? clock_source and ?internal? time_source.
Should we expect to see ERROR_CODE_TIMEOUT if we?re not using an external
clock/PPS? Is there a command that we called that might be missing in
benchmark_rate?
Thanks,
Joel Bratin
From: Michael West
[mailto:[email protected]<mailto:[email protected]>]
Sent: Tuesday, March 24, 2015 4:09 PM
To: Joel Bratin
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Hi Joel,
It should work the way you are using it. Can you tell me what version of UHD
you are using so I can try to reproduce it and look into it further for you?
Thanks,
Michael
On Tue, Mar 24, 2015 at 7:48 AM, Joel Bratin
<[email protected]<mailto:[email protected]>> wrote:
Hi Michael,
The two network interfaces are on different subnets and both have 255.255.255.0
subnet masks.
I am able to stream from each channel independently so I know that I can
connect to both X300s.
I don?t understand why benchmark_rate.exe --args "addr0=192.168.140.2,
addr1=192.168.40.2" --rx_rate 625000 --channels"0,1" works perfectly but
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"2,3" gives me the ERROR_CODE_TIMEOUT error.
For some reason changing the values of addr0 and addr1 causes an issue.
Does something happen in uhd that it treats the devices on addr0 and addr1
differently? Does it matter which one I declare as addr0 and which one I
declare as addr1?
Thanks,
Joel Bratin
From: Michael West
[mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, March 23, 2015 5:32 PM
To: Joel Bratin
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Hi Joel,
This looks like it could be a network interface configuration issue. Check to
make sure the two network interfaces on the host computer are on different
subnets and the subnet masks are set correctly (should be 255.255.255.0).
Regards,
Michael
On Mon, Mar 23, 2015 at 1:19 PM, Joel Bratin via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
My setup from last week keeps running into the same problem.
When receiving from the rx_streamer I get the ERROR_CODE_TIMEOUT error.
I tried debugging my setup with benchmark_rate and noticed that I get this
error when trying to stream from channels "2" and "3" regardless of which X300
was designated as the addr1.
For example, the following commands lead to ERROR_CODE_TIMEOUTs.
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,3"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1,2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1,3"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1,2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"2,3"
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"2,3" <-- notice the addr0/addr1 swap doesn't help
The following commands are successful:
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"3"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,1"
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"0,1" <-- addr0/addr1 swap still works
I got the same error last week and it seemed to disappear on its own but now
it's happening again.
It doesn't look like a hardware issue because the following 2 commands do the
same thing (stream both channels on 192.168.140.2) but give the opposite results
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,1" --> works
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"2,3" --> FAILS
Any insight into this problem would be greatly appreciated.
Thanks,
Joel Bratin
-----Original Message-----
From: USRP-users
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Daniele Nicolodi via USRP-users
Sent: Friday, March 20, 2015 1:14 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
On 20/03/15 17:57, Marcus D. Leech via USRP-users wrote:
> On 03/20/2015 12:51 PM, Daniele Nicolodi via USRP-users wrote:
>> A completely different matter is the PPS generation. If you need a
>> PPS to synchronize multiple instruments you can use a PPS generated
>> from a whatever oscillator (and much probably you don't even need
>> this, but simply a trigger signal).
>>
>> If what you need is to align a local time scale to a well known time
>> scale, well, you need to connect to that time scale somehow. How you
>> do that, depends on what are your synchronization requirements. A GPS
>> receiver gives you good synchronization to the GPS time, which can be
>> related to the UTC time (or assumed equal to the UTC time, for most
>> applications).
>
> Thanks, Daniele.
>
> I was mostly idly curious about the existence of less-expensive
> devices based on a 10MHz OCXO that also produce a 1PPS signal. I have a
> bunch of
> 10MHz OCXOs myself, and while *I* could easily whip up something
> that produces a 1PPS pulse in parallel to the 10MHz output, I was curious
> about
> commercial "off the shelf" devices that did this, and that weren't
> necessarily GPSDOs.
I still don't understand why you need a PPS. Is it to synchronize multiple
devices to a common time scale? If that is the case, simply generating an
unreferenced PPS (as the one you could derive from different oscillators) is
definitely not a solution. In this case what you need is a PPS generator and
distributor (a device with multiple phase aligned PPS outputs). Such a device
may or may not include an oscillator (you may need to plug an external one). No
idea of the price range for such a device, but it is going to depend a lot on
your accuracy and stability requirements.
Cheers,
Daniele
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/085947ce/attachment-0001.html>
------------------------------
Message: 11
Date: Thu, 26 Mar 2015 15:30:52 -0700
From: Michael West <[email protected]>
To: Joel Bratin <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Message-ID:
<CAM4xKrqUdtDO1Fkc3iztjmqiAnrMHoUjddO7j=mbyar4dpv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Joel,
The only way to guarantee synchronization across multiple X300s is to
provide a common PPS and clock reference to all of them. The PPS out is
significantly delayed and we do not guarantee it will be within the same 10
MHz reference clock cycle. You can try it, but we do not guarantee it will
work. If you do want to try it, be sure to use both the PPS and clock
references and set the clock source and time source to "internal" on the
master and "external" on the slave.
Regards,
Michael
On Thu, Mar 26, 2015 at 2:49 PM, Joel Bratin <[email protected]> wrote:
> Hi Michael,
>
>
>
> Thanks for clarifying that.
>
>
>
> We are still trying to find a solution to synchronize multiple boxes with
> an ?internal? PPS.
>
> We took the PPS-Out from a GPSDO (without a GPS lock) on an NI USRP-2930
> and split it to the PPS-In on both of our X300s and successfully
> synchronized them to within 1ns.
>
>
>
> We were wondering if we added a GPSDO to one of the X300s would there be
> any way to use the PPS-out from that GPSDO to synchronize the time sources
> of both X300s? This would really help us so we don?t have to include
> another piece of hardware outside the X300.
>
> Should we expect any negative impact on our synchronization if we never
> have a GPS lock on the GPSDO?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Wednesday, March 25, 2015 7:27 PM
>
> *To:* Joel Bratin
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
> So, here is what is going on. When using multiple X300s, they need to
> have the same time set on both. If not, there will be all kinds of timing
> issues. Supplying a common external reference and PPS and using
> set_time_unknown_pps() is the best way to synchronize the times on the
> devices.
>
> The benchmark_rate example does not do this, so the default reference and
> PPS are used and the times on the X300s are different. The RX rate test
> results in a timeout when specifying channels on the second device because
> it sets the start time for the streaming based on the time retrieved from
> the first device. You can modify the example to add lines to set the clock
> and time sources to external and call set_time_unknown_pps() and it should
> work fine.
>
> Hope this helps clear things up.
>
> Regards,
>
> Michael
>
>
>
> On Tue, Mar 24, 2015 at 2:08 PM, Joel Bratin <[email protected]>
> wrote:
>
> Hi Michael,
>
>
>
> We are using UHD 3.8.2. We tried it on Windows, Mac OS and Linux (Fedora)
> and received the same problem.
>
>
> Steps to reproduce the problem:
>
> 1. X300 #1 with IP address 192.168.40.2
>
> 2. X300 #2 with IP Address 192.168.140.2
>
> 3. Connect each X300 to its own interface on our Intel X520-DA2
>
> 4. Reboot each X300
>
> 5. Run benchmark_rate.exe --args ?addr0=192.168.140.2,
> addr1=192.168.40.2? ?rx_rate 625000 ?channels ?2,3
>
>
>
> When running we receive ERROR_CODE_TIMEOUT
>
>
>
> We managed to find a workaround but we?re not entirely sure why it works.
>
> In our own application we used *set_time_source(?external?)* and
> *set_clock_source(?external?)*. We connected an external clock and PPS to
> both X300s.
>
> We called *set_time_unknown_pps(uhd::time_spec_t(0.0))*
>
>
>
> We stopped seeing the ERROR_CODE_TIMEOUT while streaming.
>
> Furthermore, when we returned back to benchmark_rate.exe we found that we
> stopped getting the ERROR_CODE_TIMEOUT. The ERROR_CODE_TIMEOUT disappeared
> until we shut off one of the X300s and turned it back on.
>
>
>
> It seems like our application kicked the X300s into a working state but
> we?re not sure why. Do you have any idea what could?ve fixed our problem?
>
>
>
> Benchmark_rate doesn?t set the *time_*source or *?clock_*source so we
> assume it automatically uses an ?internal? *clock_source* and ?internal?
> *time_source*. Should we expect to see ERROR_CODE_TIMEOUT if we?re not
> using an external clock/PPS? Is there a command that we called that might
> be missing in benchmark_rate?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Tuesday, March 24, 2015 4:09 PM
>
>
> *To:* Joel Bratin
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
>
>
> It should work the way you are using it. Can you tell me what version of
> UHD you are using so I can try to reproduce it and look into it further for
> you?
>
>
>
> Thanks,
>
> Michael
>
>
>
> On Tue, Mar 24, 2015 at 7:48 AM, Joel Bratin <[email protected]>
> wrote:
>
> Hi Michael,
>
>
>
> The two network interfaces are on different subnets and both have
> 255.255.255.0 subnet masks.
>
>
>
> I am able to stream from each channel independently so I know that I can
> connect to both X300s.
>
>
>
> I don?t understand why benchmark_rate.exe --args "addr0=192.168.140.2,
> addr1=192.168.40.2" --rx_rate 625000 --channels"0,1" works perfectly but
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" gives me the ERROR_CODE_TIMEOUT error.
>
> For some reason changing the values of addr0 and addr1 causes an issue.
>
>
>
> Does something happen in uhd that it treats the devices on addr0 and addr1
> differently? Does it matter which one I declare as addr0 and which one I
> declare as addr1?
>
>
>
> Thanks,
>
> Joel Bratin
>
>
>
> *From:* Michael West [mailto:[email protected]]
> *Sent:* Monday, March 23, 2015 5:32 PM
> *To:* Joel Bratin
> *Cc:* [email protected]
>
>
> *Subject:* Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
>
>
> Hi Joel,
>
> This looks like it could be a network interface configuration issue.
> Check to make sure the two network interfaces on the host computer are on
> different subnets and the subnet masks are set correctly (should be
> 255.255.255.0).
>
> Regards,
>
> Michael
>
>
>
> On Mon, Mar 23, 2015 at 1:19 PM, Joel Bratin via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
> My setup from last week keeps running into the same problem.
>
> When receiving from the rx_streamer I get the ERROR_CODE_TIMEOUT error.
>
> I tried debugging my setup with benchmark_rate and noticed that I get this
> error when trying to stream from channels "2" and "3" regardless of which
> X300 was designated as the addr1.
>
> For example, the following commands lead to ERROR_CODE_TIMEOUTs.
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1,2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"2,3"
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" <-- notice the addr0/addr1 swap doesn't
> help
>
> The following commands are successful:
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"1"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"2"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"3"
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,1"
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"0,1" <-- addr0/addr1 swap still works
>
> I got the same error last week and it seemed to disappear on its own but
> now it's happening again.
>
> It doesn't look like a hardware issue because the following 2 commands do
> the same thing (stream both channels on 192.168.140.2) but give the
> opposite results
> benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2"
> --rx_rate 625000 --channels"0,1" --> works
> benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2"
> --rx_rate 625000 --channels"2,3" --> FAILS
>
> Any insight into this problem would be greatly appreciated.
>
> Thanks,
> Joel Bratin
>
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Daniele Nicolodi via USRP-users
> Sent: Friday, March 20, 2015 1:14 PM
> To: [email protected]
> Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
>
> On 20/03/15 17:57, Marcus D. Leech via USRP-users wrote:
> > On 03/20/2015 12:51 PM, Daniele Nicolodi via USRP-users wrote:
> >> A completely different matter is the PPS generation. If you need a
> >> PPS to synchronize multiple instruments you can use a PPS generated
> >> from a whatever oscillator (and much probably you don't even need
> >> this, but simply a trigger signal).
> >>
> >> If what you need is to align a local time scale to a well known time
> >> scale, well, you need to connect to that time scale somehow. How you
> >> do that, depends on what are your synchronization requirements. A GPS
> >> receiver gives you good synchronization to the GPS time, which can be
> >> related to the UTC time (or assumed equal to the UTC time, for most
> >> applications).
> >
> > Thanks, Daniele.
> >
> > I was mostly idly curious about the existence of less-expensive
> > devices based on a 10MHz OCXO that also produce a 1PPS signal. I have a
> bunch of
> > 10MHz OCXOs myself, and while *I* could easily whip up something
> > that produces a 1PPS pulse in parallel to the 10MHz output, I was
> curious about
> > commercial "off the shelf" devices that did this, and that weren't
> > necessarily GPSDOs.
>
> I still don't understand why you need a PPS. Is it to synchronize multiple
> devices to a common time scale? If that is the case, simply generating an
> unreferenced PPS (as the one you could derive from different oscillators)
> is definitely not a solution. In this case what you need is a PPS generator
> and distributor (a device with multiple phase aligned PPS outputs). Such a
> device may or may not include an oscillator (you may need to plug an
> external one). No idea of the price range for such a device, but it is
> going to depend a lot on your accuracy and stability requirements.
>
> Cheers,
> Daniele
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/f4fbedc1/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 26 Mar 2015 19:27:55 -0700
From: Neel Pandeya <[email protected]>
To: Trek <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] X310 50MHz two channel transmit problem
Message-ID:
<CACaXmv9oOLbALDqhBeMOq3kMCo22tfkn-tNWLtGv7mCNXdD=5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Trek:
Is your CPU being heavily loaded during transmit? What does your flowgraph
do for transmit and receive? Does it simply read/write to/from a file, or
is there also some additional processing going on too? If possible, could
you post the transmit flowgraph that gives you this problem?
Just to see if there is a disk I/O limitation for transmit, could you
modify your transmit flowgraph to read from "/dev/zero" instead of the
actual file, and let me know whether or not the "U" and "L" persist.
Could you tell me more about your system and your setup? Are you running
Linux? Which distribution and which version? How are you connecting to the
X310, via 1 GbE, 10 GbE, or PCIe? What kind of disk are you using, a
machanical disk, or an SSD?
Could you run "sudo lshw -html > system_specs.html", and post the HTML file
as an attachment?
--Neel
On 25 March 2015 at 02:58, Trek via USRP-users <[email protected]>
wrote:
> I have one unit of Ettus X310 radio and I am using UHD 3.8.2 driver with
> Gnuradio Companion (GRC) for some record/playback experiments.
>
> I am doing a receive with 50Msps on both channels A:0 and B:0 and save the
> data to files, there is no issue, it works fine.
>
> However when I transmit the received data file back to the X310 device
> with 50Msps, frequent U (under run) and L (link issue) pop on the screen.
>
> however based on the disk drive benchmark, the disk read performance is
> around 1GB/s, much better than the disk write performance (500MB/s), this
> is a bit strange, I would expect otherwise. If receive is fine, transmit
> should have been easier.
>
> pl. let me know if there is anything I could do to get the transmit
> working with 50Msps.
>
> Thanks,
>
> Trek
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150326/c947954d/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 27 Mar 2015 02:42:27 -0700
From: Patrick Sathyanathan <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Ubuntu: install conflict between gnuradio
uhd-host package and Ettus uhd package
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
It's been two weeks of frustration trying to install and build UHD/gnuradio on
mingw after the purchase of my B210. After much effort I have a successful
build and have finally got a simple "Hello, world" FM radio example working in
GRC on that platform. But I still get app crash when I try to use the "WX GUI
FFT sink" block. And no doubt there are many more runtime failures to debug. I
would eventually like to update the gnuradio mingw install page to reflect
current reality.
For now, since the Linux install instructions sounded so simple, I decided to
try it on my bootable USB drive installation of Ubuntu 14.04.
I first installed the uhd package following the instructions on Ettus webpage
"Basic Installation Instructions: Linux (Binary Installation)". I verified that
uhd_find_devices and uhd_usrp_probe discovered my B210 and printed out the
correct output. Then I tried to install gnuradio using "sudo apt-get install
gnuradio" but the install complained about files in the package uhd-host that
were overwriting files required by the previously installed "uhd" package.
After the aborted install uhd_find_devices no longer runs correctly. It prints
an errors about a dynamic load symbol not being found.
So I tried the reverse after uninstalling both the packages. First install
gnuradio. After this uhd_find_devices (from uhd-host package) runs but does not
find my device. Uninstall uhd-host package only. Install uhd package. After
this uhd_find_devices again complains about not finding a symbol.
I would appreciate any help on resolving this issue. Could this be a conflict
introduced by recent changes ?
Thanks,
--Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/6f677738/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 27 Mar 2015 11:06:31 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Ubuntu: install conflict between gnuradio
uhd-host package and Ettus uhd package
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Patrick,
>
> I first installed the uhd package following the instructions on Ettus
> webpage "Basic Installation Instructions: Linux (Binary Installation)
> <http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux>". I
> verified that uhd_find_devices and uhd_usrp_probe discovered my B210
> and printed out the correct output.
That's good.
> Then I tried to install gnuradio using "sudo apt-get install gnuradio"
> but the install complained about files in the package uhd-host that
> were overwriting files required by the previously installed "uhd"
> package. After the aborted install uhd_find_devices no longer runs
> correctly. It prints an errors about a dynamic load symbol not being
> found.
The Ubuntu gnuradio-package relies on the Ubuntu uhd-host package, which
is a horribly outdated UHD; that's why we supply our own UHD repository.
Ubuntu's GNU Radio build is linked against Ubuntu's UHD, though, so
there's no way to use Ubuntu's GNU Radio, because libraries must have
the same ABI (basically: must be the same version) during build and
runtime. Therefore, you simply can't apt-get install gnuradio on Ubuntu.
So what probably happened is that parts of Ettus' UHD were overwritten.
Make sure all uhd packages, both from Ubuntu and from Ettus, are
uninstalled, and then install the Ettus packages again. You should again
be getting working uhd_* tools.
After that, you should go ahead and build GNU Radio from source. There's
a lot of tools that help, for example there's pybombs[1], which you can
tell that you want to install gnuradio; you must tell it that you
already have "uhd" installed during the initial run, or it will try to
install it again.
Best regards,
Marcus
[1] http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart
On 03/27/2015 10:42 AM, Patrick Sathyanathan via USRP-users wrote:
> Hi All,
>
> It's been two weeks of frustration trying to install and build
> UHD/gnuradio on mingw after the purchase of my B210. After much effort
> I have a successful build and have finally got a simple "Hello,
> world" FM radio example working in GRC on that platform. But I still
> get app crash when I try to use the "WX GUI FFT sink" block. And no
> doubt there are many more runtime failures to debug. I would
> eventually like to update the gnuradio mingw install page to reflect
> current reality.
>
> For now, since the Linux install instructions sounded so simple, I
> decided to try it on my bootable USB drive installation of Ubuntu 14.04.
>
> I first installed the uhd package following the instructions on Ettus
> webpage "Basic Installation Instructions: Linux (Binary Installation)
> <http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Linux>". I
> verified that uhd_find_devices and uhd_usrp_probe discovered my B210
> and printed out the correct output. Then I tried to install gnuradio
> using "sudo apt-get install gnuradio" but the install complained about
> files in the package uhd-host that were overwriting files required by
> the previously installed "uhd" package. After the aborted install
> uhd_find_devices no longer runs correctly. It prints an errors about a
> dynamic load symbol not being found.
>
> So I tried the reverse after uninstalling both the packages. First
> install gnuradio. After this uhd_find_devices (from uhd-host package)
> runs but does not find my device. Uninstall uhd-host package only.
> Install uhd package. After this uhd_find_devices again complains
> about not finding a symbol.
>
> I would appreciate any help on resolving this issue. Could this be a
> conflict introduced by recent changes ?
>
> Thanks,
>
> --Patrick
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/c9abe19a/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 27 Mar 2015 09:43:12 -0400
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Unexpected FIFO depth
Message-ID:
<cab__httrnlw0eonyzc7elky1xjwqoqvczkipgp1mhbct1k-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have seen the following error several times over this past week. It is
intermittent such that if I rerun the example program immediately following
this error it will likely run fine.
Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected FIFO
depth [0x7]
I am running Ubuntu 14.04 LTS and using the benchmark_rate example program
along with an X310 (SBX-40 daughterboards). The full command output is
shown below.
Any ideas?
Rob
crosshair@crosshair-HP-Z440:~$ benchmark_rate --tx_rate=100e6
--rx_rate=100e6 --channels="0,1"
linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-131-gb850dfb5
Creating the usrp device with: ...
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Initializing clock and time using internal sources... done
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: SBX/CBX RX
RX Channel: 1
RX DSP: 1
RX Dboard: B
RX Subdev: SBX/CBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: SBX/CBX TX
TX Channel: 1
TX DSP: 1
TX Dboard: B
TX Subdev: SBX/CBX TX
Testing receive rate 100.000000 Msps on 2 channels
UHD Warning:
x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected FIFO
depth [0x7]
crosshair@crosshair-HP-Z440:~$
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/cf7eb410/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 27 Mar 2015 14:44:20 +0000
From: Joel Bratin <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
We didn?t realize there were two different GPSDO Kits for the N210 and the X300
series.
We were able to synchronize multiple boxes using the GPSDO Kit for the N210 as
an external PPS.
We thought we could just stick that kit into our X300 but we realize that it
wouldn?t work.
Do you think the GPSDO Kit for the USRP N210 would be reliable as an external
PPS? Would the PPS be suitable even if we didn?t have a GPS lock?
Thanks,
Joel Bratin
From: Michael West [mailto:[email protected]]
Sent: Thursday, March 26, 2015 6:31 PM
To: Joel Bratin
Cc: [email protected]
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Hi Joel,
The only way to guarantee synchronization across multiple X300s is to provide a
common PPS and clock reference to all of them. The PPS out is significantly
delayed and we do not guarantee it will be within the same 10 MHz reference
clock cycle. You can try it, but we do not guarantee it will work. If you do
want to try it, be sure to use both the PPS and clock references and set the
clock source and time source to "internal" on the master and "external" on the
slave.
Regards,
Michael
On Thu, Mar 26, 2015 at 2:49 PM, Joel Bratin
<[email protected]<mailto:[email protected]>> wrote:
Hi Michael,
Thanks for clarifying that.
We are still trying to find a solution to synchronize multiple boxes with an
?internal? PPS.
We took the PPS-Out from a GPSDO (without a GPS lock) on an NI USRP-2930 and
split it to the PPS-In on both of our X300s and successfully synchronized them
to within 1ns.
We were wondering if we added a GPSDO to one of the X300s would there be any
way to use the PPS-out from that GPSDO to synchronize the time sources of both
X300s? This would really help us so we don?t have to include another piece of
hardware outside the X300.
Should we expect any negative impact on our synchronization if we never have a
GPS lock on the GPSDO?
Thanks,
Joel Bratin
From: Michael West
[mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, March 25, 2015 7:27 PM
To: Joel Bratin
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Hi Joel,
So, here is what is going on. When using multiple X300s, they need to have the
same time set on both. If not, there will be all kinds of timing issues.
Supplying a common external reference and PPS and using set_time_unknown_pps()
is the best way to synchronize the times on the devices.
The benchmark_rate example does not do this, so the default reference and PPS
are used and the times on the X300s are different. The RX rate test results in
a timeout when specifying channels on the second device because it sets the
start time for the streaming based on the time retrieved from the first device.
You can modify the example to add lines to set the clock and time sources to
external and call set_time_unknown_pps() and it should work fine.
Hope this helps clear things up.
Regards,
Michael
On Tue, Mar 24, 2015 at 2:08 PM, Joel Bratin
<[email protected]<mailto:[email protected]>> wrote:
Hi Michael,
We are using UHD 3.8.2. We tried it on Windows, Mac OS and Linux (Fedora) and
received the same problem.
Steps to reproduce the problem:
1. X300 #1 with IP address 192.168.40.2
2. X300 #2 with IP Address 192.168.140.2
3. Connect each X300 to its own interface on our Intel X520-DA2
4. Reboot each X300
5. Run benchmark_rate.exe --args ?addr0=192.168.140.2,
addr1=192.168.40.2? ?rx_rate 625000 ?channels ?2,3
When running we receive ERROR_CODE_TIMEOUT
We managed to find a workaround but we?re not entirely sure why it works.
In our own application we used set_time_source(?external?) and
set_clock_source(?external?). We connected an external clock and PPS to both
X300s.
We called set_time_unknown_pps(uhd::time_spec_t(0.0))
We stopped seeing the ERROR_CODE_TIMEOUT while streaming.
Furthermore, when we returned back to benchmark_rate.exe we found that we
stopped getting the ERROR_CODE_TIMEOUT. The ERROR_CODE_TIMEOUT disappeared
until we shut off one of the X300s and turned it back on.
It seems like our application kicked the X300s into a working state but we?re
not sure why. Do you have any idea what could?ve fixed our problem?
Benchmark_rate doesn?t set the time_source or ?clock_source so we assume it
automatically uses an ?internal? clock_source and ?internal? time_source.
Should we expect to see ERROR_CODE_TIMEOUT if we?re not using an external
clock/PPS? Is there a command that we called that might be missing in
benchmark_rate?
Thanks,
Joel Bratin
From: Michael West
[mailto:[email protected]<mailto:[email protected]>]
Sent: Tuesday, March 24, 2015 4:09 PM
To: Joel Bratin
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Hi Joel,
It should work the way you are using it. Can you tell me what version of UHD
you are using so I can try to reproduce it and look into it further for you?
Thanks,
Michael
On Tue, Mar 24, 2015 at 7:48 AM, Joel Bratin
<[email protected]<mailto:[email protected]>> wrote:
Hi Michael,
The two network interfaces are on different subnets and both have 255.255.255.0
subnet masks.
I am able to stream from each channel independently so I know that I can
connect to both X300s.
I don?t understand why benchmark_rate.exe --args "addr0=192.168.140.2,
addr1=192.168.40.2" --rx_rate 625000 --channels"0,1" works perfectly but
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"2,3" gives me the ERROR_CODE_TIMEOUT error.
For some reason changing the values of addr0 and addr1 causes an issue.
Does something happen in uhd that it treats the devices on addr0 and addr1
differently? Does it matter which one I declare as addr0 and which one I
declare as addr1?
Thanks,
Joel Bratin
From: Michael West
[mailto:[email protected]<mailto:[email protected]>]
Sent: Monday, March 23, 2015 5:32 PM
To: Joel Bratin
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Hi Joel,
This looks like it could be a network interface configuration issue. Check to
make sure the two network interfaces on the host computer are on different
subnets and the subnet masks are set correctly (should be 255.255.255.0).
Regards,
Michael
On Mon, Mar 23, 2015 at 1:19 PM, Joel Bratin via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
My setup from last week keeps running into the same problem.
When receiving from the rx_streamer I get the ERROR_CODE_TIMEOUT error.
I tried debugging my setup with benchmark_rate and noticed that I get this
error when trying to stream from channels "2" and "3" regardless of which X300
was designated as the addr1.
For example, the following commands lead to ERROR_CODE_TIMEOUTs.
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,3"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1,2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1,3"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1,2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"2,3"
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"2,3" <-- notice the addr0/addr1 swap doesn't help
The following commands are successful:
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"1"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"2"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"3"
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,1"
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"0,1" <-- addr0/addr1 swap still works
I got the same error last week and it seemed to disappear on its own but now
it's happening again.
It doesn't look like a hardware issue because the following 2 commands do the
same thing (stream both channels on 192.168.140.2) but give the opposite results
benchmark_rate.exe --args "addr0=192.168.140.2, addr1=192.168.40.2" --rx_rate
625000 --channels"0,1" --> works
benchmark_rate.exe --args "addr0=192.168.40.2, addr1=192.168.140.2" --rx_rate
625000 --channels"2,3" --> FAILS
Any insight into this problem would be greatly appreciated.
Thanks,
Joel Bratin
-----Original Message-----
From: USRP-users
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Daniele Nicolodi via USRP-users
Sent: Friday, March 20, 2015 1:14 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
On 20/03/15 17:57, Marcus D. Leech via USRP-users wrote:
> On 03/20/2015 12:51 PM, Daniele Nicolodi via USRP-users wrote:
>> A completely different matter is the PPS generation. If you need a
>> PPS to synchronize multiple instruments you can use a PPS generated
>> from a whatever oscillator (and much probably you don't even need
>> this, but simply a trigger signal).
>>
>> If what you need is to align a local time scale to a well known time
>> scale, well, you need to connect to that time scale somehow. How you
>> do that, depends on what are your synchronization requirements. A GPS
>> receiver gives you good synchronization to the GPS time, which can be
>> related to the UTC time (or assumed equal to the UTC time, for most
>> applications).
>
> Thanks, Daniele.
>
> I was mostly idly curious about the existence of less-expensive
> devices based on a 10MHz OCXO that also produce a 1PPS signal. I have a
> bunch of
> 10MHz OCXOs myself, and while *I* could easily whip up something
> that produces a 1PPS pulse in parallel to the 10MHz output, I was curious
> about
> commercial "off the shelf" devices that did this, and that weren't
> necessarily GPSDOs.
I still don't understand why you need a PPS. Is it to synchronize multiple
devices to a common time scale? If that is the case, simply generating an
unreferenced PPS (as the one you could derive from different oscillators) is
definitely not a solution. In this case what you need is a PPS generator and
distributor (a device with multiple phase aligned PPS outputs). Such a device
may or may not include an oscillator (you may need to plug an external one). No
idea of the price range for such a device, but it is going to depend a lot on
your accuracy and stability requirements.
Cheers,
Daniele
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/8ceb6107/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 27 Mar 2015 20:17:05 +0530
From: Anil Gaddam <[email protected]>
To: GNURadio Discussion List <[email protected]>,
[email protected]
Subject: [USRP-users] (no subject)
Message-ID:
<cag4jthcsbqbwdpdrzb9tlsjr5vmqgxdz5c-lqwzy-dlpdvt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I want to simulate a analog transmission system in GNURadio Companion
(GRC).
My system configuration is as follows:
TRANSMITTER :signal source --> encryption --> modulator --> RF
RECEIVER : sink <-- decryption <-- demodulator <-- RF
I have simulated the above configuration in Ubuntu 12.10 machine but
without
encryption/decryption blocks.
If you can point me to an existing OoTM of digital encryption, it would be
nice.
Is it possible to encrypt digitally in some way and decrypt using existing
blocks in gnu radio companion 3.7.6
Thanks and Regards,
Anil Gaddam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/6558266a/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 27 Mar 2015 15:20:29 +0000 (UTC)
From: [email protected]
To: [email protected]
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] X310 over PCIe Instability
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Neel,
?
I can not change this system to Ubuntu or do any of the things you outline.
?
My simple test program pseudocode that illustrates the problem is something
like this:
?
for( int I=0 ; I < 100 ; I++ )
{
?? usrp = uhd::multi_usrp::make( "resource=RIO0" );
?
?? Sleep( 5000 );
?? usrp->reset();
??? Sleep (5000);
}
?
On 3.8.1, the loop above would never get past 10 before failing.? On 3.8.2, it
was better, but still encountered errors consistently.
?
I am trying to get a system setup on a more available platform to help
facilitate easier debugging, but that has been quite challenging.
?
Also, removing one of the WBX cards (so there is now only a single card) did
not fix the issue (something I figured I would try to see if there was some
sort of race condition initializing both boards)...
?
Any other suggestions to help debug this would be much appreciated.
?
I have purchased 10 devices at 8K per device makes 80K of hardware that I
cannot make use of... :(
?
Thanks.
?
----- Original Message -----
From: "tilla--- via USRP-users" <[email protected]>
To: "usrp-users" <[email protected]>
Sent: Monday, March 16, 2015 7:12:19 PM
Subject: Re: [USRP-users] X310 over PCIe Instability
I have verified our chipset is C600/X79...
?
Some more info:
?
I upgraded to 3.8.2 and it did offer some improvements.
?
Instead of getting 1 out of 3 failures for the 4 reasons listed previously, I
got about 2 out of 10 failures with the radio cntrl message timeout failure.
?
So there is some improvement, but still some gremlins in the mix.
?
My X310 has 2 WBX-120 daughter cards within.
?
Is there something else that I can do help trace this down?? Only speculation
that comes to mind is some sort of race condition initializing the multiple
cards.
?
My system is win7, so no chance for an lshw results...
?
Let me know if you have any further thoughts...
----- Original Message -----
? From: USRP-users [mailto:[email protected]] On Behalf Of
Neel Pandeya via USRP-users
Sent: Friday, February 27, 2015 3:55 PM
To: tilla
Cc: usrp-users
Subject: Re: [USRP-users] X310 over PCIe Instability
?
I looked at the specs for the HP Z820 at [1], and it looks like the Intel C602
system chipset is being used. I'd like to confirm the PCIe chipset. When you
get back in the office, please run "sudo lshw -html > system_config.html", and
post the HTML file to the mailing list.
[1] http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=c04111177
[1] http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=c04111177
?
On 27 February 2015 at 12:41, tilla < [email protected] > wrote:
I am out of the office for the next week, not sure of the chipset but these are
brand new high end HP Z820 machines.
?
I will check as soon as I get back.
?
Sent from my Verizon Wireless 4G LTE smartphone
?
-------- Original message --------
From: Neel Pandeya
Date:02/27/2015 14:15 (GMT-05:00)
To: [email protected]
Cc: usrp-users ,Ashish Chaudhari
Subject: Re: [USRP-users] X310 over PCIe Instability
?
Some PCI-Express chipsets do not work as well as others. Results can vary
between chipsets. What motherboard and PCIe chipset are you using?? Could you
run "sudo lshw -html > system_config.html", and send the HTML file as an
attachment to the mailing list?
Here in the office, we have a system that works well with X310 over PCIe, with
the specifications below.
Dell Precision T3600
Intel Xeon CPU E5-1650 0 @ 3.20GHz
C600/X79 series chipset PCI Express Virtual Root Port
Dell Precision T3600
Intel Xeon CPU E5-1650 0 @ 3.20GHz
C600/X79 series chipset PCI Express Virtual Root Port
?
--Neel
?
On 25 February 2015 at 11:08, tilla--- via USRP-users <
[email protected] > wrote:
Peeps,
?
SW Platform:
??? UHD 3.8.1 64 bit
??? Windows 7 64 bit
??? VS 2013
?
Have a gaggle of N210s and X310s.? All work flawlessly over Ethernet.
?
I have assessed going to PCIe on the X310s to?lower latency of sample rx/tx.
?
We never have any problems over Ethernet initializing the devices.
?
Over PCI, the devices fail about 2 times out of 10 purely in the initialization
phase.
?
The equivalent code is something so simple like:
?
uhd::usrp::multi_usrp::make( "resource=RIO0" );
?
This fails for the following list of reasons:
?
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
?
?
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/67990a62/attachment-0001.html>
------------------------------
Message: 19
Date: Fri, 27 Mar 2015 11:35:37 -0400
From: Peter Witkowski <[email protected]>
To: [email protected], usrp-users <[email protected]>
Subject: Re: [USRP-users] X310 over PCIe Instability
Message-ID:
<CAN1Qg3OsNcXwQzD2Dv=hpajazf1h8c+req8qhhgaqdkj_f2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I too experienced issues with the PCIe driver last fall. The only solution
was to move everything over to 10GigE (and eat the cost of cables and NICs).
Here's a link to what I was seeing:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-September/010584.html.
Note that as far as I know, only the issue where an Ethernet cable had to
be plugged in was resolved.
On Fri, Mar 27, 2015 at 11:20 AM, tilla--- via USRP-users <
[email protected]> wrote:
> Hi Neel,
>
> I can not change this system to Ubuntu or do any of the things you outline.
>
> My simple test program pseudocode that illustrates the problem is
> something like this:
>
> for( int I=0 ; I < 100 ; I++ )
> {
> usrp = uhd::multi_usrp::make( "resource=RIO0" );
>
> Sleep( 5000 );
> usrp->reset();
> Sleep (5000);
> }
>
> On 3.8.1, the loop above would never get past 10 before failing. On
> 3.8.2, it was better, but still encountered errors consistently.
>
> I am trying to get a system setup on a more available platform to help
> facilitate easier debugging, but that has been quite challenging.
>
> Also, removing one of the WBX cards (so there is now only a single card)
> did not fix the issue (something I figured I would try to see if there was
> some sort of race condition initializing both boards)...
>
> Any other suggestions to help debug this would be much appreciated.
>
> I have purchased 10 devices at 8K per device makes 80K of hardware that I
> cannot make use of... :(
>
> Thanks.
>
>
> ------------------------------
> *From: *"tilla--- via USRP-users" <[email protected]>
> *To: *"usrp-users" <[email protected]>
> *Sent: *Monday, March 16, 2015 7:12:19 PM
>
> *Subject: *Re: [USRP-users] X310 over PCIe Instability
>
> I have verified our chipset is C600/X79...
>
> Some more info:
>
> I upgraded to 3.8.2 and it did offer some improvements.
>
> Instead of getting 1 out of 3 failures for the 4 reasons listed
> previously, I got about 2 out of 10 failures with the radio cntrl message
> timeout failure.
>
> So there is some improvement, but still some gremlins in the mix.
>
> My X310 has 2 WBX-120 daughter cards within.
>
> Is there something else that I can do help trace this down? Only
> speculation that comes to mind is some sort of race condition initializing
> the multiple cards.
>
> My system is win7, so no chance for an lshw results...
>
> Let me know if you have any further thoughts...
> ------------------------------
> *From:* USRP-users [mailto:[email protected]] *On
> Behalf Of *Neel Pandeya via USRP-users
> *Sent:* Friday, February 27, 2015 3:55 PM
> *To:* tilla
> *Cc:* usrp-users
> *Subject:* Re: [USRP-users] X310 over PCIe Instability
>
>
>
> I looked at the specs for the HP Z820 at [1], and it looks like the Intel
> C602 system chipset is being used. I'd like to confirm the PCIe chipset.
> When you get back in the office, please run "sudo lshw -html >
> system_config.html", and post the HTML file to the mailing list.
>
> [1] http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=c04111177
>
>
>
> On 27 February 2015 at 12:41, tilla <[email protected]> wrote:
>
> I am out of the office for the next week, not sure of the chipset but
> these are brand new high end HP Z820 machines.
>
>
>
> I will check as soon as I get back.
>
>
>
> Sent from my Verizon Wireless 4G LTE smartphone
>
>
>
> -------- Original message --------
>
> From: Neel Pandeya
>
> Date:02/27/2015 14:15 (GMT-05:00)
>
> To: [email protected]
>
> Cc: usrp-users ,Ashish Chaudhari
>
> Subject: Re: [USRP-users] X310 over PCIe Instability
>
>
>
> Some PCI-Express chipsets do not work as well as others. Results can vary
> between chipsets. What motherboard and PCIe chipset are you using?? Could
> you run "sudo lshw -html > system_config.html", and send the HTML file as
> an attachment to the mailing list?
>
> Here in the office, we have a system that works well with X310 over PCIe,
> with the specifications below.
>
> Dell Precision T3600
> Intel Xeon CPU E5-1650 0 @ 3.20GHz
> C600/X79 series chipset PCI Express Virtual Root Port
>
>
>
> --Neel
>
>
>
> On 25 February 2015 at 11:08, tilla--- via USRP-users <
> [email protected]> wrote:
>
> Peeps,
>
>
>
> SW Platform:
>
> UHD 3.8.1 64 bit
>
> Windows 7 64 bit
>
> VS 2013
>
>
>
> Have a gaggle of N210s and X310s. All work flawlessly over Ethernet.
>
>
>
> I have assessed going to PCIe on the X310s to lower latency of sample
> rx/tx.
>
>
>
> We never have any problems over Ethernet initializing the devices.
>
>
>
> Over PCI, the devices fail about 2 times out of 10 purely in the
> initialization phase.
>
>
>
> The equivalent code is something so simple like:
>
>
>
> uhd::usrp::multi_usrp::make( "resource=RIO0" );
>
>
>
> This fails for the following list of reasons:
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Peter Witkowski
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150327/f07d2d97/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 55, Issue 27
******************************************
