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: could not find image downloader (Martin Braun)
2. Re: Full-duplex MIMO issues with B210 board (Dario Fertonani)
3. Absolute received power (Dario Fertonani)
4. zpu-elf-gcc not compiling correctly (Aaron Henderson)
5. Re: Absolute received power ([email protected])
6. FW: Firmware Build error (Aaron Henderson)
7. Re: Absolute received power (Dario Fertonani)
8. Re: E110 boost::chrono (Philip Balister)
9. [RFNOC] gr-ettus changes (Martin Braun)
10. Re: Absolute received power (Marcus D. Leech)
11. Re: FW: Firmware Build error (Marcus D. Leech)
12. Re: FW: Firmware Build error (Martin Braun)
13. Re: 4 Channel Synchronization with 2 X-300s (Joel Bratin)
14. Re: 4 Channel Synchronization with 2 X-300s (Michael West)
15. Re: E110 boost::chrono (Simon IJskes)
16. Re: Spikes in b210 received data (Tom Tsou)
17. Re: Spikes in b210 received data (Arjun Nadh)
18. Re: Intermediate Frequency with SBX,WBX... (LEMENAGER Claude)
19. Re: E110 boost::chrono (Marcus M?ller)
20. Re: E110 boost::chrono (Philip Balister)
21. Re: 4 Channel Synchronization with 2 X-300s (Joel Bratin)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Mar 2015 09:07:22 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] could not find image downloader
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Maybe you want to start by installing precompiled binaries? It would
make your entry much easier (apt-get instal ...).
M
On 22.03.2015 20:45, nur qalbi via USRP-users wrote:
> hi. i am use ubuntu 14.04.as <http://14.04.as/> i am installing gnuradio
> from this link:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource
> and choose build from source.
> Gnuradio &uhd
>
> What can i do?i hope you can help me.
> thanks
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Mon, 23 Mar 2015 09:17:33 -0700
From: Dario Fertonani <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Full-duplex MIMO issues with B210 board
Message-ID:
<cajgedajebfptc3yj0gg-9bc-m-+gza184eruveu0cvy_4aw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
*Regarding 2x2 at 30.72 MHz, I understand the discussion above, but I'm
wondering how is this even possible over USB 3? The chart Ettus provides
regarding 2x2 sample rates achievable using various USB 3 controllers shows
19 MS/s as the max rate in 2x2 config. I suppose 8-bit OTW would work
fine, but even 12-bit OTW should only bump it up to about 25 MS/s or so.
Is this correct?*
The thread got confusing over time. What I wasn't able to sustain is a 1.92
MS/s throughput, not a 30.72 MS/s throughput, which as you point out is not
even supported over USB 3 by most controllers. The 30.72e6 value that
creates problems in 2x2 full-duplex MIMO mode is the master clock rate
value.
Best,
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/1cbfd706/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 23 Mar 2015 09:53:03 -0700
From: Dario Fertonani <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Absolute received power
Message-ID:
<CAJGEdAgeXYj0_StSwGkJUON=L5-7vn3D=yowmbjfca-thrx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I found on online archives many (old) threads saying that it's not possible
to know the absolute value of the received power without calibration
procedures involving other devices.
As I understand the problem, the received signal returned by recv() got
pumped up not only by the power gain returned by get_rx_gain(), but also by
some other gain that's unknown and that depends on many things among which
the center frequency. Is this correct? If so, is the order of magnitude of
the unknown gain of a few dBs, or tens of dBs?
Thanks,
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/4fcd472b/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 23 Mar 2015 16:55:26 +0000 (UTC)
From: Aaron Henderson <[email protected]>
To: [email protected]
Subject: [USRP-users] zpu-elf-gcc not compiling correctly
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I am trying to make my usrp2 firmware for an N210 device, and when I run the
cmake command, the terminal replies that i need to add zpu-elf-gcc to my $PATH.
I run the command to add the path and I lose functionality of my ls command.
Has this happened to anyone else?
Aaron
------------------------------
Message: 5
Date: Mon, 23 Mar 2015 13:05:03 -0400
From: [email protected]
To: Dario Fertonani <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Absolute received power
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
There are batch-to-batch variabilities in the entire analog chain, as
well as frequency dependencies, and differences depending on the
hardware involved (WBX? SBX? USRP1? USRP2? N210? B210? etc etc).
This makes it extraordinarily difficult to derive a "power received at
the antenna plane" using a purely-analytical approach.
Each one of these *individually* is a dB or two in either direction. But
there are many places in the chain where there's some uncertainty.
So, you measure against known quantities.
That's one of the reasons that lab equipment is so expensive--this
painstaking process has been undertaken for you.
On 2015-03-23 12:53, Dario Fertonani via USRP-users wrote:
> I found on online archives many (old) threads saying that it's not possible
> to know the absolute value of the received power without calibration
> procedures involving other devices.
>
> As I understand the problem, the received signal returned by recv() got
> pumped up not only by the power gain returned by get_rx_gain(), but also by
> some other gain that's unknown and that depends on many things among which
> the center frequency. Is this correct? If so, is the order of magnitude of
> the unknown gain of a few dBs, or tens of dBs?
>
> Thanks,
> Dario
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150323/1c3a8e78/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 23 Mar 2015 13:11:36 -0500
From: Aaron Henderson <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] FW: Firmware Build error
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
From: [email protected]
To: [email protected]
Subject: Firmware Build error
Date: Mon, 23 Mar 2015 13:01:48 -0500
When running the cmake command for my usrp2 firmware I get,
CMake Error: your C compiler: "zpu-elf-gcc" was not found. Please set
CMAKE_C_COMPILER to a valid compiler path or name.
-- Configuring incomplete, errors occurred!
I have checked and my zpu-elf-gcc is set in $PATH, my zpu-elf-gcc has
executable permisions, and my Cmake_C_Compiler is set to gcc which is
up-to-date.
Does anyone have any ideas that I have not found in my exhaustive search yet?
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/06c2b2b8/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 23 Mar 2015 11:36:47 -0700
From: Dario Fertonani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Absolute received power
Message-ID:
<cajgedahevvzszo7n_7j4j6y8v7wwwfxb0a_vrkgpcngbwxh...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thank you Marcus.
Before that fine calibration, is there any other scaling to consider? In
other words, if I measure the power of the IQ samples returned by recv() in
the default float32 host mode, and from that subtract the value returned by
get_rx_gain(), do I get a dBW value? I'm asking this because the values I
get that way make more sense as dBm values.
Thanks,
Dario
On Mon, Mar 23, 2015 at 10:05 AM, <[email protected]> wrote:
> There are batch-to-batch variabilities in the entire analog chain, as
> well as frequency dependencies, and differences depending on the hardware
> involved (WBX? SBX? USRP1? USRP2? N210? B210? etc etc).
>
> This makes it extraordinarily difficult to derive a "power received at the
> antenna plane" using a purely-analytical approach.
>
> Each one of these *individually* is a dB or two in either direction. But
> there are many places in the chain where there's some uncertainty.
>
> So, you measure against known quantities.
>
> That's one of the reasons that lab equipment is so expensive--this
> painstaking process has been undertaken for you.
>
>
>
>
>
>
> On 2015-03-23 12:53, Dario Fertonani via USRP-users wrote:
>
> I found on online archives many (old) threads saying that it's not
> possible to know the absolute value of the received power without
> calibration procedures involving other devices.
>
> As I understand the problem, the received signal returned by recv() got
> pumped up not only by the power gain returned by get_rx_gain(), but also by
> some other gain that's unknown and that depends on many things among which
> the center frequency. Is this correct? If so, is the order of magnitude of
> the unknown gain of a few dBs, or tens of dBs?
>
> Thanks,
> Dario
>
> _______________________________________________
> USRP-users mailing
> [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/20150323/0c90097d/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 23 Mar 2015 11:55:03 -0700
From: Philip Balister <[email protected]>
To: Simon IJskes <[email protected]>, [email protected]
Subject: Re: [USRP-users] E110 boost::chrono
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 03/21/2015 03:20 PM, Simon IJskes via USRP-users wrote:
> Hoi,
>
> i cannot compile a program on the USRP E110, because there is no
> boost::chrono installed.
>
> fatal error: boost/chrono.hpp: No such file or directory
I need to poke around and look at adding this to the boost packages for
the E110. By any chance have you tried this with the E310 toolchain?
I'll also look at making sure the E310 supports this. I' traveling at
the moment and away from E100 test systems, so I can't update the feeds
until I am home and can verify nothing breaks.
Philip
>
> i've tried:
>
> opkg update
> opkg upgrade
>
>
> root@usrp-e1xx:~# opkg list-installed | grep boost
> boost - 1.45.0-r10.3.9
> boost-dev - 1.45.0-r10.3.9
> libboost-date-time1.45.0 - 1.45.0-r10.3.9
> libboost-filesystem1.45.0 - 1.45.0-r10.3.9
> libboost-iostreams1.45.0 - 1.45.0-r10.3.9
> libboost-prg-exec-monitor1.45.0 - 1.45.0-r10.3.9
> libboost-program-options1.45.0 - 1.45.0-r10.3.9
> libboost-python1.45.0 - 1.45.0-r10.3.9
> libboost-regex1.45.0 - 1.45.0-r10.3.9
> libboost-serialization1.45.0 - 1.45.0-r10.3.9
> libboost-signals1.45.0 - 1.45.0-r10.3.9
> libboost-unit-test-framework1.45.0 - 1.45.0-r10.3.9
> libboost-wserialization1.45.0 - 1.45.0-r10.3.9
>
> is it fixable?
>
> maybe there is no boost.chrono package available? if so, is it possible
> to include it in the next image, or repository update?
>
> thanks.
>
> Gr. Simon
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 9
Date: Mon, 23 Mar 2015 12:22:05 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [RFNOC] gr-ettus changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I just pushed a biggish change to gr-ettus. If you're using custom GNU
Radio C++ code, you might have to updated that.
In brief, all RFNoC blocks are now derived from a dedicated block type
(gr::ettus::rfnoc_block) instead of pulling in RFNoC features. This
couples the GNU Radio and UHD parts closer, allowing to use more
features more easily. It's also a much cleaner solution as what we had
before -- no more magic macros.
If you were just using custom GRC bindings, you don't have to change
anything.
Cheers,
Martin
------------------------------
Message: 10
Date: Mon, 23 Mar 2015 15:46:43 -0400
From: "Marcus D. Leech" <[email protected]>
To: Dario Fertonani <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Absolute received power
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/23/2015 02:36 PM, Dario Fertonani wrote:
> Thank you Marcus.
> Before that fine calibration, is there any other scaling to consider?
> In other words, if I measure the power of the IQ samples returned by
> recv() in the default float32 host mode, and from that subtract the
> value returned by get_rx_gain(), do I get a dBW value? I'm asking this
> because the values I get that way make more sense as dBm values.
>
> Thanks,
> Dario
>
The values you get "out the back" are *linearly-proportional-to* (more
or less) the RF power as seen at the RF connector plane. Also,
get_rx_gain() returns the value of the *settable* parts of the RF-gain
chain. There are parts on most boards that are outside of the bits that
are under variable control.
So, without knowing *in detail*, what the exact *actual* gain is at any
given gain setting (get_rx_gain() only tells part of the story,
typically), you have
only the vaguest notions of what the RF power is as seen at the
connector plane.
So, again, the only way you can get reliable data is to calibrate, with
known sources, over a configuration space that is multiply-dimensioned. You
can limit the size of that space by only doing so for the limited
number of configurations you're actually going to be using.
So, *best case* with a strictly-analytic approach is that you'll be
"off" by several dB. Worst case is that you'll be "off" by 10dB or more.
> On Mon, Mar 23, 2015 at 10:05 AM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> There are batch-to-batch variabilities in the entire analog chain,
> as well as frequency dependencies, and differences depending on
> the hardware involved (WBX? SBX? USRP1? USRP2? N210? B210? etc
> etc).
>
> This makes it extraordinarily difficult to derive a "power
> received at the antenna plane" using a purely-analytical approach.
>
> Each one of these *individually* is a dB or two in either
> direction. But there are many places in the chain where there's
> some uncertainty.
>
> So, you measure against known quantities.
>
> That's one of the reasons that lab equipment is so expensive--this
> painstaking process has been undertaken for you.
>
> On 2015-03-23 12:53, Dario Fertonani via USRP-users wrote:
>
>> I found on online archives many (old) threads saying that it's
>> not possible to know the absolute value of the received power
>> without calibration procedures involving other devices.
>> As I understand the problem, the received signal returned by
>> recv() got pumped up not only by the power gain returned by
>> get_rx_gain(), but also by some other gain that's unknown and
>> that depends on many things among which the center frequency. Is
>> this correct? If so, is the order of magnitude of the unknown
>> gain of a few dBs, or tens of dBs?
>> Thanks,
>> Dario
>>
>> _______________________________________________
>> 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/20150323/6cffb93e/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 23 Mar 2015 15:49:10 -0400
From: "Marcus D. Leech" <[email protected]>
To: Aaron Henderson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] FW: Firmware Build error
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/23/2015 02:11 PM, Aaron Henderson via USRP-users wrote:
>
>
> ------------------------------------------------------------------------
> From: [email protected]
> To: [email protected]
> Subject: Firmware Build error
> Date: Mon, 23 Mar 2015 13:01:48 -0500
>
> When running the cmake command for my usrp2 firmware I get,
>
> CMake Error: your C compiler: "zpu-elf-gcc" was not found. Please set
> CMAKE_C_COMPILER to a valid compiler path or name.
> -- Configuring incomplete, errors occurred!
>
> I have checked and my zpu-elf-gcc is set in $PATH, my zpu-elf-gcc has
> executable permisions, and my Cmake_C_Compiler is set to gcc which is
> up-to-date.
>
> Does anyone have any ideas that I have not found in my exhaustive
> search yet?
>
> Aaron
>
>
Well, I'd say that there's still something wrong with your $PATH, as
seen at the time you invoke CMake.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150323/29e5e9ef/attachment-0001.html>
------------------------------
Message: 12
Date: Mon, 23 Mar 2015 12:55:14 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] FW: Firmware Build error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
From my shell scripts:
# ZPU compiler
ZPUPREFIX=~/.usrlocal-zpu # This is where I dumped all the ZPU stuff
export PATH=$PATH:$ZPUPREFIX/bin
export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:$ZPUPREFIX/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ZPUPREFIX/lib
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$ZPUPREFIX/lib/pkgconfig
M
On 23.03.2015 12:49, Marcus D. Leech via USRP-users wrote:
> On 03/23/2015 02:11 PM, Aaron Henderson via USRP-users wrote:
>>
>>
>> ------------------------------------------------------------------------
>> From: [email protected]
>> To: [email protected]
>> Subject: Firmware Build error
>> Date: Mon, 23 Mar 2015 13:01:48 -0500
>>
>> When running the cmake command for my usrp2 firmware I get,
>>
>> CMake Error: your C compiler: "zpu-elf-gcc" was not found. Please set
>> CMAKE_C_COMPILER to a valid compiler path or name.
>> -- Configuring incomplete, errors occurred!
>>
>> I have checked and my zpu-elf-gcc is set in $PATH, my zpu-elf-gcc has
>> executable permisions, and my Cmake_C_Compiler is set to gcc which is
>> up-to-date.
>>
>> Does anyone have any ideas that I have not found in my exhaustive
>> search yet?
>>
>> Aaron
>>
>>
> Well, I'd say that there's still something wrong with your $PATH, as
> seen at the time you invoke CMake.
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 13
Date: Mon, 23 Mar 2015 20:19:51 +0000
From: Joel Bratin <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 4 Channel Synchronization with 2 X-300s
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
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
------------------------------
Message: 14
Date: Mon, 23 Mar 2015 14:31:57 -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:
<CAM4xKroAYp7tWdYsxXyx9MmzNdR1seg6oW=sakd9tzrenvx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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/20150323/d619c513/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 24 Mar 2015 00:47:19 +0100
From: Simon IJskes <[email protected]>
To: Philip Balister <[email protected]>, [email protected]
Subject: Re: [USRP-users] E110 boost::chrono
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 23-03-15 19:55, Philip Balister wrote:
> On 03/21/2015 03:20 PM, Simon IJskes via USRP-users wrote:
>> Hoi,
>>
>> i cannot compile a program on the USRP E110, because there is no
>> boost::chrono installed.
>>
>> fatal error: boost/chrono.hpp: No such file or directory
>
> I need to poke around and look at adding this to the boost packages for
> the E110. By any chance have you tried this with the E310 toolchain?
> I'll also look at making sure the E310 supports this. I' traveling at
> the moment and away from E100 test systems, so I can't update the feeds
> until I am home and can verify nothing breaks.
I would love to check out the E310 toolchain. I cannot find a link to
the toolchain download from the E310 manual page. Also can i follow the
same recipe as the E310, i.e. the same processor armv7a/neon/softfp
etc.? I will try it in a ubuntu 14.04 vm, as it is a crosscompiler,
right? Instead of -DENABLE_E300=on i will use -DENABLE_E110 or E100 or
similar. Do you expect it will run complete including the bitbake SD
images? export MACHINE="ettus-e100" or so?
Gr. Simon
------------------------------
Message: 16
Date: Mon, 23 Mar 2015 17:26:33 -0700
From: Tom Tsou <[email protected]>
To: Arjun Nadh <[email protected]>
Cc: Usrp-users <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Spikes in b210 received data
Message-ID:
<CAATyM+a8T6e=p+F-sKanGKH-tjmoK=mut9z0-v5-3uad2xe...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Arjun,
On Fri, Mar 20, 2015 at 11:15 PM, Arjun Nadh via USRP-users
<[email protected]> wrote:
> On observing the received samples, there is a periodic " ramp " on the
> received sample. Attaching the plot. I do not observe this effect while
> using N210. Also I do not observe this if I use the internal clock.
Can you reduce the level on the VSG by a few dB and see if that
changes the behavior?
And is the ramp effect consistently tied to the use of the external
reference? or is the relationship intermittent?
-TT
------------------------------
Message: 17
Date: Tue, 24 Mar 2015 10:59:51 +0530
From: Arjun Nadh <[email protected]>
To: Tom Tsou <[email protected]>
Cc: Usrp-users <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Spikes in b210 received data
Message-ID:
<cadat_yibtzjqm-qlhg3yoajqvp6k46kfi7brbe6v5hm53hp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Tom,
I have tried reducing the signal level. The signal level at the input is
now -40dBm. Still there is this ramp behaviour.
I also get this when I use the B210 in loopback mode (with a 30dB
atttenuator in the loop). Also I have observed that
the lower the master clock rate that I set, the less frequent the ramps.
Thank you,
Arjun Nadh
On Tue, Mar 24, 2015 at 5:56 AM, Tom Tsou <[email protected]> wrote:
> Hi Arjun,
>
> On Fri, Mar 20, 2015 at 11:15 PM, Arjun Nadh via USRP-users
> <[email protected]> wrote:
> > On observing the received samples, there is a periodic " ramp " on the
> > received sample. Attaching the plot. I do not observe this effect while
> > using N210. Also I do not observe this if I use the internal clock.
>
> Can you reduce the level on the VSG by a few dB and see if that
> changes the behavior?
>
> And is the ramp effect consistently tied to the use of the external
> reference? or is the relationship intermittent?
>
> -TT
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/080a62c0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b210_ramp_new.png
Type: image/png
Size: 4644 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150324/080a62c0/attachment-0001.png>
------------------------------
Message: 18
Date: Tue, 24 Mar 2015 09:59:18 +0100
From: LEMENAGER Claude <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Intermediate Frequency with SBX,WBX...
Message-ID:
<59957d668d245c4eb38e8f85c054e901077bcc3...@thsonea01cms09p.one.grp>
Content-Type: text/plain; charset="utf-8"
The problem, in my opinion, is that such a way keeps IQ impairments. I will
check and come back with results.
I think it will be better to propose in the interface a way to zeroes the Q
part (or I part) at the input of the DSP (DDC).
[@@ THALES GROUP INTERNAL @@]
De : [email protected] [mailto:[email protected]]
Envoy? : lundi 23 mars 2015 16:29
? : LEMENAGER Claude
Cc : [email protected]
Objet : Re: [USRP-users] Intermediate Frequency with SBX,WBX...
It's handled automatically. You specify the same front-end, and in your tune
request, use an offset.
The data are *always* delivered in complex-baseband format, even if you are
using offset tuning.
On 2015-03-23 11:22, LEMENAGER Claude via USRP-users wrote:
Hello,
I just have a question about the setting of Intermediate Frequency programming
for daughter board with quadrature frontend.
In certain circumstances, we want to avoid IQ impairment and then acquire the
signal using IF techniques which should be possible through UHD.
To program that, we have to put the correct RF and offset frequencies
(tune_request_t) but also, in my opinion, the input of the dsp through
set_subdev.
But the only subdev spec allowed for the SBX in X3x0 are A:0 or B:0, i.e. if I
understand correctly, a quadrature interface (using two ADC in the RX case).
So the question is how to acquire in IF for these boards?
Claude Lem?nager
_______________________________________________
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/20150324/efc33f2e/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 24 Mar 2015 15:16:20 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E110 boost::chrono
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Simon,
you can find the toolchain at
http://files.ettus.com/e3xx_images/beta/dizzy-test/
or, if you want the one used for release 1
http://files.ettus.com/e3xx_images/current/
Greetings,
Marcus
On 03/24/2015 12:47 AM, Simon IJskes via USRP-users wrote:
> On 23-03-15 19:55, Philip Balister wrote:
>> On 03/21/2015 03:20 PM, Simon IJskes via USRP-users wrote:
>>> Hoi,
>>>
>>> i cannot compile a program on the USRP E110, because there is no
>>> boost::chrono installed.
>>>
>>> fatal error: boost/chrono.hpp: No such file or directory
>>
>> I need to poke around and look at adding this to the boost packages for
>> the E110. By any chance have you tried this with the E310 toolchain?
>> I'll also look at making sure the E310 supports this. I' traveling at
>> the moment and away from E100 test systems, so I can't update the feeds
>> until I am home and can verify nothing breaks.
>
> I would love to check out the E310 toolchain. I cannot find a link to
> the toolchain download from the E310 manual page. Also can i follow
> the same recipe as the E310, i.e. the same processor
> armv7a/neon/softfp etc.? I will try it in a ubuntu 14.04 vm, as it is
> a crosscompiler, right? Instead of -DENABLE_E300=on i will use
> -DENABLE_E110 or E100 or similar. Do you expect it will run complete
> including the bitbake SD images? export MACHINE="ettus-e100" or so?
>
> Gr. Simon
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 20
Date: Tue, 24 Mar 2015 07:45:37 -0700
From: Philip Balister <[email protected]>
To: Marcus M?ller <[email protected]>,
[email protected]
Subject: Re: [USRP-users] E110 boost::chrono
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 03/24/2015 07:16 AM, Marcus M?ller via USRP-users wrote:
> Hi Simon,
>
> you can find the toolchain at
> http://files.ettus.com/e3xx_images/beta/dizzy-test/
> or, if you want the one used for release 1
> http://files.ettus.com/e3xx_images/current/
>
> Greetings,
> Marcus
>
> On 03/24/2015 12:47 AM, Simon IJskes via USRP-users wrote:
>> On 23-03-15 19:55, Philip Balister wrote:
>>> On 03/21/2015 03:20 PM, Simon IJskes via USRP-users wrote:
>>>> Hoi,
>>>>
>>>> i cannot compile a program on the USRP E110, because there is no
>>>> boost::chrono installed.
>>>>
>>>> fatal error: boost/chrono.hpp: No such file or directory
>>>
>>> I need to poke around and look at adding this to the boost packages for
>>> the E110. By any chance have you tried this with the E310 toolchain?
>>> I'll also look at making sure the E310 supports this. I' traveling at
>>> the moment and away from E100 test systems, so I can't update the feeds
>>> until I am home and can verify nothing breaks.
>>
>> I would love to check out the E310 toolchain. I cannot find a link to
>> the toolchain download from the E310 manual page. Also can i follow
>> the same recipe as the E310, i.e. the same processor
>> armv7a/neon/softfp etc.? I will try it in a ubuntu 14.04 vm, as it is
>> a crosscompiler, right? Instead of -DENABLE_E300=on i will use
>> -DENABLE_E110 or E100 or similar. Do you expect it will run complete
>> including the bitbake SD images? export MACHINE="ettus-e100" or so?
Setting MACHINE=ettus-e1xx will work. But the kernel will not boot. You
can take the kernel from the FAT partition (after updating the card) and
the modules and copy them on to the new rootfs. Also, taking an E310
card, re-formatting the FAT partition and copying MLO first, then the
rest of the files in the FAT partition and the modules into the rootfs
should also work
There is a tarball of the current E1xx modules here:
https://www.dropbox.com/s/563cvjk0am1utht/modules-3.0-pm-r0h-usrp-e1xx.tgz?dl=0
https://www.dropbox.com/sh/ue8zqnd2pda2guu/AABb6wxEwnWqKxLyjJrrejQEa?dl=0
In this directory there is an sdimage you can dd onto a card (maybe an 8
GB card not sure) also.
Sorry for the info dump, busy day ahead.
Philip
>>
>> Gr. Simon
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
------------------------------
Message: 21
Date: Tue, 24 Mar 2015 14:48:18 +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,
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]<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/20150324/792fed4e/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 23
******************************************
