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: unstable LO of USRP-N200 and WBX (Christophe ALEXANDRE)
2. Re: Two-stage tuning process (Christophe ALEXANDRE)
3. Re: Two-stage tuning process (Josh Blum)
4. Re: unstable LO of USRP-N200 and WBX (Nick Foster)
5. Re: Two-stage tuning process (ALEXANDRE Christophe)
6. Simple example built for UHD crashes when run. (Ed Jubenville)
7. Re: Simple example built for UHD crashes when run. (Josh Blum)
8. Re: Simple example built for UHD crashes when run. (Simon HB9DRV)
9. Re: Two-stage tuning process (Josh Blum)
10. Re: Simple example built for UHD crashes when run. (Ed Jubenville)
11. Re: Simple example built for UHD crashes when run. (Josh Blum)
12. Re: Problems building E110 FPGA images (John Buetefuer)
13. Re: unstable LO of USRP-N200 and WBX (Christophe ALEXANDRE)
14. Re: Two-stage tuning process (Christophe ALEXANDRE)
15. Re: unstable LO of USRP-N200 and WBX (Nick Foster)
16. Re: External and internal clock sources (Nowlan, Sean)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Jul 2012 18:17:32 +0200
From: "Christophe ALEXANDRE" <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
Message-ID: <B84D87607DD54A088035C47249FF5CB9@fletan>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
Hi Josh,
could you tell us the model number of the VCTCXOs ?
i see U27 and U8 on the N2xx schematics, but no model number.
Regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 11B niveau -1, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
----- Original Message -----
From: "Josh Blum" <[email protected]>
To: <[email protected]>
Sent: Thursday, July 12, 2012 10:39 AM
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
>
>
> On 05/24/2012 04:59 PM, Francois Quitin wrote:
>> Hi all,
>>
>>
>>
>> I'm currently using a USRP N200 with a WBX daughterboard. We are using a
>> gnuradio design (with some custom blocks) to synchronize the LOs of
>> several
>> USRPs to the LO of a master USRP using over-the air-signals.
>>
>>
>>
>> While the setup was working perfectly with our old USRP-2, I have some
>> problems for it to work with the USRP-N200. The LOs of the latter seems
>> to
>> sometimes randomly "jump" by several tens of Hz.
>>
>>
>
> You may be seeing the result of the onboard TCXO performing adjustments.
> Unfortunately, the adjustments are digital and not analog, so it can be
> seen a small jump.
>
> You might try set_clock_source("external"). I believe that you can
> either apply an external 10 MHz reference, or allow the clock
> synthesizer to free-run.
>
> Nick can confirm this tomorrow.
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 2
Date: Thu, 12 Jul 2012 18:41:21 +0200
From: "Christophe ALEXANDRE" <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <55804F1D563D49DFBBD39C0B15E3E0E7@fletan>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
hi josh,
1) i have some difficulties to understand how the
tuning is done. I know that the frequency tuning is very precise
(locked on an external reference, i see 600 010 001 Hz
instead of 600,01 MHz in my test). So i wonder how this precision
is obtained.
do you know the exact frequency of the analog LO, even if this frequency
is not very precise ? and as you know this difference, you can compensate
with the DDS ?
2) i understand the lo_offset (i think) and i can modify directly the .py
file
(i have more tests to do including timed commands so i think i will have
to give up GRC).
GRC gives me the following .py code for my sink :
self.uhd_usrp_sink_0 = uhd.usrp_sink(
device_addr="addr=163.173.96.128",
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.uhd_usrp_sink_0.set_clock_source("external", 0)
self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
self.uhd_usrp_sink_0.set_center_freq(freq, 0)
self.uhd_usrp_sink_0.set_gain(-20, 0)
self.uhd_usrp_sink_0.set_antenna("TX/RX", 0)
where should i insert your code in the flowgraph ?
uhd.tune_request(desired_freq, lo_offset)
regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 11B niveau -1, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
----- Original Message -----
From: "Josh Blum" <[email protected]>
To: <[email protected]>
Sent: Thursday, July 12, 2012 10:33 AM
Subject: Re: [USRP-users] Two-stage tuning process
>
>
> On 07/12/2012 12:24 AM, Christophe ALEXANDRE wrote:
>> hi all,
>>
>> i'm reading the tuning notes about the two-stage tuning process :
>>
>> A USRP device has two stages of tuning: a.. RF front-end: translates
>> bewteen RF and IF b.. DSP: translates between IF and baseband In a
>> typical use-case, the user specifies an overall center frequency for
>> the signal chain. The RF front-end will be tuned as close as possible
>> to the center frequency, and the DSP will account for the error in
>> tuning between target frequency and actual frequency. The user may
>> also explicitly control both stages of tuning through through the
>> tune_request_t object, which allows for more advanced tuning.
>>
>> In general, Using UHD's advanced tuning is highly recommended as it
>> makes it easy to move the DC component out of your band-of-interest.
>> This can be done by passing your desired LO offset to the
>> tune_request_t object, and letting UHD handle the rest.
>>
>>
>> i have some questions about this :
>>
>> 1) when the note says : The RF front-end will be tuned as close as
>> possible to the center frequency what is the precision of the RF
>> tuning ? i'm using an SBX + N210.
>>
>
> SBX used a fraction N synthesizer. Offhand, I would on the order of
> kilohertz.
>
>> i mean : i want to tune first the RF (VCO) at a desired freq, then
>> adjust the lo_offset to tune the FPGA/DDS. but i need to know
>> precisely the VCO frequency (the DDS freq is supposed to be precise
>> enough).
>>
>
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
>
> Also, the result of a tune actually returns a tune_request_t object
> which describes the exact RF and DSP frequency. This may be hard to
> access from GRC though.
>
>> 2) how can i use this 2 step process using gnuradio (i'm using GRC)
>> ?
>>
>
> There are some notes actually in the grc block. Basically the same
> tune_request_t object is available in python as uhd.tune_request. Put
> this in the frequency parameter
>
> uhd.tune_request(desired_freq, lo_offset)
>
> The actual LO will be desired_freq + lo_offset + epsilon
>
> The DSP will compensate for lo_offset + epsilon
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Thu, 12 Jul 2012 10:22:29 -0700
From: Josh Blum <[email protected]>
To: Christophe ALEXANDRE <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/12/2012 09:41 AM, Christophe ALEXANDRE wrote:
> hi josh,
>
> 1) i have some difficulties to understand how the
> tuning is done. I know that the frequency tuning is very precise
> (locked on an external reference, i see 600 010 001 Hz
> instead of 600,01 MHz in my test). So i wonder how this precision
> is obtained.
>
> do you know the exact frequency of the analog LO, even if this frequency
> is not very precise ? and as you know this difference, you can compensate
> with the DDS ?
>
>
Exactly. The tune code for the daughterboard knows the step sizes
exactly. Knowing the requested frequency and actual setting that the LO
obtained, the CORDIC in the FPGA can compensate, down to sub Hz levels.
> 2) i understand the lo_offset (i think) and i can modify directly the
> .py file
> (i have more tests to do including timed commands so i think i will have
> to give up GRC).
>
> GRC gives me the following .py code for my sink :
>
> self.uhd_usrp_sink_0 = uhd.usrp_sink(
> device_addr="addr=163.173.96.128",
> stream_args=uhd.stream_args(
> cpu_format="fc32",
> channels=range(1),
> ),
> )
> self.uhd_usrp_sink_0.set_clock_source("external", 0)
> self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
> self.uhd_usrp_sink_0.set_center_freq(freq, 0)
> self.uhd_usrp_sink_0.set_gain(-20, 0)
> self.uhd_usrp_sink_0.set_antenna("TX/RX", 0)
>
>
> where should i insert your code in the flowgraph ?
>
> uhd.tune_request(desired_freq, lo_offset)
>
You can do this directly from GRC, just put this into the frequency
parameter box. It will generate code like so:
self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(desired_freq,
lo_offset), 0)
-josh
------------------------------
Message: 4
Date: Thu, 12 Jul 2012 10:41:08 -0700
From: Nick Foster <[email protected]>
To: Christophe ALEXANDRE <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
Message-ID:
<CALALHJVTbHCMcomSwT2tKY0fy+qr33=xRD=n_dfwn2_b19l...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
It is FOX924B.
Best,
Nick
On Thu, Jul 12, 2012 at 9:17 AM, Christophe ALEXANDRE <
[email protected]> wrote:
> Hi Josh,
>
> could you tell us the model number of the VCTCXOs ?
> i see U27 and U8 on the N2xx schematics, but no model number.
>
> Regards.
>
>
> Christophe ALEXANDRE
> Conservatoire National des Arts et M?tiers (CNAM)
> Laboratoire CEDRIC-LAETITIA
> D?partement EASY
> Acc?s 11B niveau -1, Case 2D2P10
> 292 rue Saint Martin
> 75141 PARIS CEDEX 03
> FRANCE
> email : [email protected]
> tel. 0140272699
> mob. 0651087311
> fax. 0140272994
>
>
> ----- Original Message ----- From: "Josh Blum" <[email protected]>
> To: <[email protected]>
> Sent: Thursday, July 12, 2012 10:39 AM
> Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
>
>
>
>
>>
>> On 05/24/2012 04:59 PM, Francois Quitin wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> I'm currently using a USRP N200 with a WBX daughterboard. We are using a
>>> gnuradio design (with some custom blocks) to synchronize the LOs of
>>> several
>>> USRPs to the LO of a master USRP using over-the air-signals.
>>>
>>>
>>>
>>> While the setup was working perfectly with our old USRP-2, I have some
>>> problems for it to work with the USRP-N200. The LOs of the latter seems
>>> to
>>> sometimes randomly "jump" by several tens of Hz.
>>>
>>>
>>>
>> You may be seeing the result of the onboard TCXO performing adjustments.
>> Unfortunately, the adjustments are digital and not analog, so it can be
>> seen a small jump.
>>
>> You might try set_clock_source("external"). I believe that you can
>> either apply an external 10 MHz reference, or allow the clock
>> synthesizer to free-run.
>>
>> Nick can confirm this tomorrow.
>>
>> -josh
>>
>> ______________________________**_________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>
>
>
> ______________________________**_________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120712/46a30a76/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 12 Jul 2012 21:52:50 +0200
From: "ALEXANDRE Christophe" <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <6138CB9760E84F258ABBC3FF1BF08207@fletan>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
i've tried this code :
> self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(desired_freq,
> lo_offset), 0)
directly from GRC and i see no change in the output frequency.
if i understand [email protected] explanations, when i use a lo_offset,
the analog LO freq will be shifted from lo_offset and the CORDIC will
compensate
exactly in the FPGA. The overall freq will stay the same. it's only to shift
the DC
out of band. is that true ?
if i want to adjust digitally the output freq, i suppose that i need to put
the tuning process
in MANUAL mode and set separately the analog LO freq and the digital CORDIC
freq.
is there any way for me to know the real frequency of the analog LO so that
i can compensate
the error + digitally shift the output frequency ?
regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 11B niveau -1, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
----- Original Message -----
From: "Josh Blum" <[email protected]>
To: "Christophe ALEXANDRE" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, July 12, 2012 7:22 PM
Subject: Re: [USRP-users] Two-stage tuning process
>
>
> On 07/12/2012 09:41 AM, Christophe ALEXANDRE wrote:
>> hi josh,
>>
>> 1) i have some difficulties to understand how the
>> tuning is done. I know that the frequency tuning is very precise
>> (locked on an external reference, i see 600 010 001 Hz
>> instead of 600,01 MHz in my test). So i wonder how this precision
>> is obtained.
>>
>> do you know the exact frequency of the analog LO, even if this frequency
>> is not very precise ? and as you know this difference, you can compensate
>> with the DDS ?
>>
>>
>
> Exactly. The tune code for the daughterboard knows the step sizes
> exactly. Knowing the requested frequency and actual setting that the LO
> obtained, the CORDIC in the FPGA can compensate, down to sub Hz levels.
>
>> 2) i understand the lo_offset (i think) and i can modify directly the
>> .py file
>> (i have more tests to do including timed commands so i think i will have
>> to give up GRC).
>>
>> GRC gives me the following .py code for my sink :
>>
>> self.uhd_usrp_sink_0 = uhd.usrp_sink(
>> device_addr="addr=163.173.96.128",
>> stream_args=uhd.stream_args(
>> cpu_format="fc32",
>> channels=range(1),
>> ),
>> )
>> self.uhd_usrp_sink_0.set_clock_source("external", 0)
>> self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
>> self.uhd_usrp_sink_0.set_center_freq(freq, 0)
>> self.uhd_usrp_sink_0.set_gain(-20, 0)
>> self.uhd_usrp_sink_0.set_antenna("TX/RX", 0)
>>
>>
>> where should i insert your code in the flowgraph ?
>>
>> uhd.tune_request(desired_freq, lo_offset)
>>
>
> You can do this directly from GRC, just put this into the frequency
> parameter box. It will generate code like so:
>
> self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(desired_freq,
> lo_offset), 0)
> -josh
>
------------------------------
Message: 6
Date: Thu, 12 Jul 2012 13:28:42 -0700
From: "Ed Jubenville" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Simple example built for UHD crashes when run.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I've built an example program in MSVC 10.0, trying to use the UHD binaries
on Windows to communicate with an Ettus N200. The source code is the
unmodified example file rx_samples_to_file.cpp.
It built fine, but crashed when run:
"Unhandled exception at 0x1000abcb in UHD_rx_samples_to_file.exe:
0xC0000005: Access violation reading location 0x00133000."
The callstack trace is:
uhd.dll!1000abcb()
[Frames below may be incorrect and/or missing, no symbols loaded for
uhd.dll]
uhd.dll!1000e5e5()
> msvcr100d.dll!_free_dbg(void * pUserData=0x00000004, int
nBlockUse=6838856) Line 1267 + 0xc bytes C++
msvcr100d.dll!operator delete(void * pUserData=0x003eb660) Line 57 +
0x7
bytes C++
UHD_rx_samples_to_file.exe!std::allocator<std::_Container_proxy>::dealloca
te(std::_Container_proxy * _Ptr=0x0012fe34, unsigned int
__formal=3437218560) Line 182 + 0x9 bytes C++
UHD_rx_samples_to_file.exe!std::_Vector_val<boost::io::detail::format_item
<char,std::char_traits<char>,std::allocator<char>
>,std::allocator<boost::io::detail::format_item<char,std::char_traits<char>,
std::allocator<char> > >
>::~_Vector_val<boost::io::detail::format_item<char,std::char_traits<char>,s
td::allocator<char>
>,std::allocator<boost::io::detail::format_item<char,std::char_traits<char>,
std::allocator<char> > > >() Line 459 + 0x28 bytes C++
UHD_rx_samples_to_file.exe!std::basic_string<char,std::char_traits<char>,s
td::allocator<char> >::length() Unknown
UHD_rx_samples_to_file.exe!boost::basic_format<char,std::char_traits<char>
,std::allocator<char>
>::~basic_format<char,std::char_traits<char>,std::allocator<char> >() +
0x93 bytes C++
0012fe34()
It died while executing this line of example code:
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
It didn't matter whether I specified "--args 192.168.10.2" on the command
line or not.
I should note that I don't have the Ettus device connected yet, so I was
assuming that UHD would behave gracefully and return a NULL pointer. If
that was my problem, please advise and read no further.
To build the example program, I followed the instructions I saw here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-October/002
487.html
Here is an extract that I followed. I used that version of UHD, customized
my include/lib paths, and am using Boost 1.50 (not 1.47).
> Eddie, it is not necessary to build UHD if you don't want to modify
> it. Just install UHD-003.002.004-win32.exe package from Ettus and use
> it in your app as a library. A few weeks ago, I started my work with
> fresh rx_samples_to_file.cpp from UHD examples:
>
> 1. create a new project in Vistual Studio - win32 console app, empty
> project
> 2. copy rx_samples_to_file.cpp to working dir
> 3. add existing files to project: rx_samples_to_file.cpp, C:\Program
> Files\UHD\lib\uhd.lib
> 4. change build type to Release (optional?)
> 5. add to include path: C:\Program Files\UHD\include;C:\Program
> Files\boost\boost_1_47;$(IncludePath)
> 6. add to library path: C:\Program Files\UHD\lib;C:\Program
> Files\boost\boost_1_47\lib;$(LibraryPath)
> 7. build
I'm a newbie to Boost, so perhaps I built it incorrectly. I followed the
Boost website instructions to build it:
bootstrap
.\b2
I didn't modify the project-config.jam file which had this content:
import option ;
using msvc ;
option.set keep-going : false ;
Was I supposed to do something different with the Boost build?
Ed
------------------------------
Message: 7
Date: Thu, 12 Jul 2012 13:36:17 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Simple example built for UHD crashes when
run.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/12/2012 01:28 PM, Ed Jubenville wrote:
> I've built an example program in MSVC 10.0, trying to use the UHD binaries
> on Windows to communicate with an Ettus N200. The source code is the
> unmodified example file rx_samples_to_file.cpp.
>
> It built fine, but crashed when run:
>
> "Unhandled exception at 0x1000abcb in UHD_rx_samples_to_file.exe:
> 0xC0000005: Access violation reading location 0x00133000."
>
Does the rx_samples_to_file.exe that ships with the installer work?
You might be mixing up debug/release mode or 32/64 bit builds.
> The callstack trace is:
>
> uhd.dll!1000abcb()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> uhd.dll]
> uhd.dll!1000e5e5()
>> msvcr100d.dll!_free_dbg(void * pUserData=0x00000004, int
> nBlockUse=6838856) Line 1267 + 0xc bytes C++
> msvcr100d.dll!operator delete(void * pUserData=0x003eb660) Line 57 +
> 0x7
> bytes C++
>
> UHD_rx_samples_to_file.exe!std::allocator<std::_Container_proxy>::dealloca
> te(std::_Container_proxy * _Ptr=0x0012fe34, unsigned int
> __formal=3437218560) Line 182 + 0x9 bytes C++
>
> UHD_rx_samples_to_file.exe!std::_Vector_val<boost::io::detail::format_item
> <char,std::char_traits<char>,std::allocator<char>
>> ,std::allocator<boost::io::detail::format_item<char,std::char_traits<char>,
> std::allocator<char> > >
>> ::~_Vector_val<boost::io::detail::format_item<char,std::char_traits<char>,s
> td::allocator<char>
>> ,std::allocator<boost::io::detail::format_item<char,std::char_traits<char>,
> std::allocator<char> > > >() Line 459 + 0x28 bytes C++
>
> UHD_rx_samples_to_file.exe!std::basic_string<char,std::char_traits<char>,s
> td::allocator<char> >::length() Unknown
>
> UHD_rx_samples_to_file.exe!boost::basic_format<char,std::char_traits<char>
> ,std::allocator<char>
>> ::~basic_format<char,std::char_traits<char>,std::allocator<char> >() +
> 0x93 bytes C++
> 0012fe34()
>
> It died while executing this line of example code:
>
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>
> It didn't matter whether I specified "--args 192.168.10.2" on the command
> line or not.
>
> I should note that I don't have the Ettus device connected yet, so I was
> assuming that UHD would behave gracefully and return a NULL pointer. If
> that was my problem, please advise and read no further.
>
> To build the example program, I followed the instructions I saw here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-October/002
> 487.html
>
> Here is an extract that I followed. I used that version of UHD, customized
> my include/lib paths, and am using Boost 1.50 (not 1.47).
>
I recommend first trying with boost 1.47, you can get pre-built from
boostpro's website.
-josh
>> Eddie, it is not necessary to build UHD if you don't want to modify
>> it. Just install UHD-003.002.004-win32.exe package from Ettus and use
>> it in your app as a library. A few weeks ago, I started my work with
>> fresh rx_samples_to_file.cpp from UHD examples:
>>
>> 1. create a new project in Vistual Studio - win32 console app, empty
>> project
>> 2. copy rx_samples_to_file.cpp to working dir
>> 3. add existing files to project: rx_samples_to_file.cpp, C:\Program
>> Files\UHD\lib\uhd.lib
>> 4. change build type to Release (optional?)
>> 5. add to include path: C:\Program Files\UHD\include;C:\Program
>> Files\boost\boost_1_47;$(IncludePath)
>> 6. add to library path: C:\Program Files\UHD\lib;C:\Program
>> Files\boost\boost_1_47\lib;$(LibraryPath)
>> 7. build
>
> I'm a newbie to Boost, so perhaps I built it incorrectly. I followed the
> Boost website instructions to build it:
>
> bootstrap
> .\b2
>
> I didn't modify the project-config.jam file which had this content:
> import option ;
> using msvc ;
> option.set keep-going : false ;
>
> Was I supposed to do something different with the Boost build?
>
> Ed
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Thu, 12 Jul 2012 22:42:04 +0200
From: "Simon HB9DRV" <[email protected]>
To: "'Ed Jubenville'" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] Simple example built for UHD crashes when
run.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ed,
You have quite a few hoops to jump through before you'll get UHD.dll working
in a Windows environment, sadly the steps you must follow aren't on the
Ettus website yet. Fortunately for you I've done this, the info you need is
on my blog:
http://www.dit-dit-dit.com/Blog/tabid/88/post/ettus-research-notes/Default.a
spx
Any problems just shout.
Simon Brown, HB9DRV
http://sdr-radio.com http://dit-dit-dit.com
You are standing at the end of a road before a small brick building. Around
you is a forest.
A small stream flows out of the building and down a gully. The sunspot count
is 285.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ed Jubenville
I've built an example program in MSVC 10.0, trying to use the UHD binaries
on Windows to communicate with an Ettus N200. The source code is the
unmodified example file rx_samples_to_file.cpp.
It built fine, but crashed when run:
...
------------------------------
Message: 9
Date: Thu, 12 Jul 2012 13:54:21 -0700
From: Josh Blum <[email protected]>
To: ALEXANDRE Christophe <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/12/2012 12:52 PM, ALEXANDRE Christophe wrote:
> i've tried this code :
>
>> self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(desired_freq,
>> lo_offset), 0)
>
> directly from GRC and i see no change in the output frequency.
Thats correct.
> if i understand [email protected] explanations, when i use a lo_offset,
> the analog LO freq will be shifted from lo_offset and the CORDIC will
> compensate
> exactly in the FPGA. The overall freq will stay the same. it's only to
> shift the DC
> out of band. is that true ?
>
>
Yes, the overall frequency of the RX chain will stay the same.
One possible use is to shift the LO out of band of interest.
> if i want to adjust digitally the output freq, i suppose that i need to
> put the tuning process
> in MANUAL mode and set separately the analog LO freq and the digital
> CORDIC freq.
>
> is there any way for me to know the real frequency of the analog LO so
> that i can compensate
> the error + digitally shift the output frequency ?
>
So the tune_result_t gives you all the result of the tune, RF and DSP
frequency.
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n176
Is there something specific you are trying to do? Like frequency hop
with the DSP, but leave the LO at a fixed frequency?
-josh
------------------------------
Message: 10
Date: Thu, 12 Jul 2012 14:51:40 -0700
From: "Ed Jubenville" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Simple example built for UHD crashes when
run.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Josh wrote:
> Does the rx_samples_to_file.exe that ships with the installer work?
> You might be mixing up debug/release mode or 32/64 bit builds.
Yes, the prebuilt rx_samples_to_file.exe works, but times out due to lack of
hardware.
Josh wrote:
> I recommend first trying with boost 1.47, you can get pre-built from
> boostpro's website.
Which Boost variant(s) should I install from BoostPro for compatibility with
the UHD binary?
They show eight options:
1) Multithreaded debug DLL
2) Multithreaded DLL
3) Multithreaded
4) Multithreaded debug
5) Multithreaded, static runtime
6) Multithreaded debug, static runtime
7) Single threaded, static runtime
8) Single threaded debug, static runtime
Ed
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Josh Blum
Sent: Thursday, July 12, 2012 1:36 PM
To: [email protected]
Subject: Re: [USRP-users] Simple example built for UHD crashes when run.
On 07/12/2012 01:28 PM, Ed Jubenville wrote:
> I've built an example program in MSVC 10.0, trying to use the UHD binaries
> on Windows to communicate with an Ettus N200. The source code is the
> unmodified example file rx_samples_to_file.cpp.
>
> It built fine, but crashed when run:
>
> "Unhandled exception at 0x1000abcb in UHD_rx_samples_to_file.exe:
> 0xC0000005: Access violation reading location 0x00133000."
>
Does the rx_samples_to_file.exe that ships with the installer work?
You might be mixing up debug/release mode or 32/64 bit builds.
> The callstack trace is:
>
> uhd.dll!1000abcb()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> uhd.dll]
> uhd.dll!1000e5e5()
>> msvcr100d.dll!_free_dbg(void * pUserData=0x00000004, int
> nBlockUse=6838856) Line 1267 + 0xc bytes C++
> msvcr100d.dll!operator delete(void * pUserData=0x003eb660) Line 57 +
0x7
> bytes C++
>
UHD_rx_samples_to_file.exe!std::allocator<std::_Container_proxy>::dealloca
> te(std::_Container_proxy * _Ptr=0x0012fe34, unsigned int
> __formal=3437218560) Line 182 + 0x9 bytes C++
>
UHD_rx_samples_to_file.exe!std::_Vector_val<boost::io::detail::format_item
> <char,std::char_traits<char>,std::allocator<char>
>>
,std::allocator<boost::io::detail::format_item<char,std::char_traits<char>,
> std::allocator<char> > >
>>
::~_Vector_val<boost::io::detail::format_item<char,std::char_traits<char>,s
> td::allocator<char>
>>
,std::allocator<boost::io::detail::format_item<char,std::char_traits<char>,
> std::allocator<char> > > >() Line 459 + 0x28 bytes C++
>
UHD_rx_samples_to_file.exe!std::basic_string<char,std::char_traits<char>,s
> td::allocator<char> >::length() Unknown
>
UHD_rx_samples_to_file.exe!boost::basic_format<char,std::char_traits<char>
> ,std::allocator<char>
>> ::~basic_format<char,std::char_traits<char>,std::allocator<char> >() +
> 0x93 bytes C++
> 0012fe34()
>
> It died while executing this line of example code:
>
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>
> It didn't matter whether I specified "--args 192.168.10.2" on the command
> line or not.
>
> I should note that I don't have the Ettus device connected yet, so I was
> assuming that UHD would behave gracefully and return a NULL pointer. If
> that was my problem, please advise and read no further.
>
> To build the example program, I followed the instructions I saw here:
>
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-October/002
> 487.html
>
> Here is an extract that I followed. I used that version of UHD,
customized
> my include/lib paths, and am using Boost 1.50 (not 1.47).
>
I recommend first trying with boost 1.47, you can get pre-built from
boostpro's website.
-josh
>> Eddie, it is not necessary to build UHD if you don't want to modify
>> it. Just install UHD-003.002.004-win32.exe package from Ettus and use
>> it in your app as a library. A few weeks ago, I started my work with
>> fresh rx_samples_to_file.cpp from UHD examples:
>>
>> 1. create a new project in Vistual Studio - win32 console app, empty
>> project
>> 2. copy rx_samples_to_file.cpp to working dir
>> 3. add existing files to project: rx_samples_to_file.cpp, C:\Program
>> Files\UHD\lib\uhd.lib
>> 4. change build type to Release (optional?)
>> 5. add to include path: C:\Program Files\UHD\include;C:\Program
>> Files\boost\boost_1_47;$(IncludePath)
>> 6. add to library path: C:\Program Files\UHD\lib;C:\Program
>> Files\boost\boost_1_47\lib;$(LibraryPath)
>> 7. build
>
> I'm a newbie to Boost, so perhaps I built it incorrectly. I followed the
> Boost website instructions to build it:
>
> bootstrap
> .\b2
>
> I didn't modify the project-config.jam file which had this content:
> import option ;
> using msvc ;
> option.set keep-going : false ;
>
> Was I supposed to do something different with the Boost build?
>
> Ed
>
>
> _______________________________________________
> 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: 11
Date: Thu, 12 Jul 2012 15:35:38 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Simple example built for UHD crashes when
run.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
>> I recommend first trying with boost 1.47, you can get pre-built from
>> boostpro's website.
>
> Which Boost variant(s) should I install from BoostPro for compatibility with
> the UHD binary?
> They show eight options:
> 1) Multithreaded debug DLL
> 2) Multithreaded DLL
> 3) Multithreaded
> 4) Multithreaded debug
> 5) Multithreaded, static runtime
> 6) Multithreaded debug, static runtime
> 7) Single threaded, static runtime
> 8) Single threaded debug, static runtime
>
Its really a question of preference, work flow, and delivery...
If you have the disk space, I recommend installing all of them for
convenience.
The installer you mentioned is 32 bit release mode, so that would
eliminate the need for any of the *debug* options if you only want to
build against the release mode version of the library.
Heres the breakdown:
UHD doesn't export anything of boost except for shared_ptr, so you only
minimally need the boost headers to compile a client app. Of course that
changes if the client app has boost dependencies; rx_samples_to_file for
example, would also require boost program options.
So, some general information of windows libraries and these options:
* The debug vs non debug options are for building in Debug and Release
mode respectively.
* The static vs DLL: do you want to statically link in boost to the
application, or depend on a DLL being in the %PATH%? This can be
controlled at compile time via defining BOOST_ALL_DYN_LINK.
* You can read more about the options here:
http://msdn.microsoft.com/en-us/library/2kzt1wy3%28v=vs.71%29.aspx
We have 32/64bit and release/debug pre-built versions of UHD:
http://files.ettus.com/binaries/uhd_stable/latest_release/
But please note that the boost pro installer only offers 32bit binaries.
You can find prebuilt 64bit pre-built boost binaries here:
http://boost.teeks99.com/ And can install these along side the 32 bit
boost; for use when compiling a 64 bit client application that requires
boost.
-josh
------------------------------
Message: 12
Date: Fri, 13 Jul 2012 10:11:39 +0930
From: John Buetefuer <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Problems building E110 FPGA images
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Josh - some follow-up comments/questions in-line below.
On 12/07/2012 5:39 PM, Josh Blum wrote:
>
> On 07/10/2012 08:29 PM, John Buetefuer wrote:
>> Josh/Philip,
>>
>> It also seems that I've been living in "version hell" a little. I'm
>> still getting used to "git" repositories. It seems I've been using the
>> head of the "master" branch, whereas perhaps I should be using "maint"..
>> Is there a document/wiki page somewhere that explains what is going on
>> in the "master" branch? I should also clarify that the "S" sync problems
>> I have been seeing were with the "master" UHD and fpgas.
>>
>> Should "master" be (relatively) stable and suitable for use?
>>
> Lets see if can clear this up.
>
> The uhd opkg images are for the latest release, so if you are using
> binaries from opkg with a custom FPGA, you should build that FPGA image
> from the "maint" branch".
>
> But, if you are building the host code too, just build FPGA and host
> from the same branch. The host code likes to verify the FPGA image via a
> hardcoded compatibility number in the FPGA. So it should at least warn
> you if you mix and match.
I discovered this early on, thus my goal has been to build GNURadio, UHD
and UHD-fpga from source to ensure that I have full control of what
version I'm using - and hopefully have a stable base for development. We
have plans for a custom FPGA implementation, and starting from a stable
base always helps :-).
What 'new things' are in the master branch, compared with maint?, and
how stable does the master code base tend to be?
>
> In regards to the S, this is sequence error on transmit. It looks like a
> bus timing issue got into the maint branch. I seem to have figured it
> out, so I should have an update for this tomorrow.
Very much looking forward to this fix. Transmit sequence errors were
also a problem for me in the master branch too.
>
>> I've now re-built for the E110 using the *maint branch*, with ISE12.2
>> (did not have 12.1 close at hand) and I get a compressed .bin file which
>> successfully programs.. My observations so-far:
>>
> We have managed to replicate this. It looks like the> 12.1 ISEs arent
> building a good bin file. Thats where the config done error is coming
> in. The compression option may be a good place to look, thanks for the clue.
There is a file I noticed that was generated by 13.4 which appeared to
contain all of the bitgen parameters used - I did notice that the
compression option was not in the list - running through this list might
help track it down perhaps (sorry, not sure of the filename don't have
my build machine handy).
Cheers
John
>
> -josh
>
------------------------------
Message: 13
Date: Fri, 13 Jul 2012 09:09:03 +0200
From: "Christophe ALEXANDRE" <[email protected]>
To: "Nick Foster" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
Message-ID: <6CA17109D3B244C39C1E8DC1FA995EE3@fletan>
Content-Type: text/plain; charset="iso-8859-1"
we have the same problem as Francois Quitin.
the unstable LO give us some headaches with
our CFO algorithms.
would it be possible to change this vctcxo
and use another model ? we own 5 N210.
Salutations.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 11B niveau -1, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
----- Original Message -----
From: Nick Foster
To: Christophe ALEXANDRE
Cc: [email protected] ; [email protected]
Sent: Thursday, July 12, 2012 7:41 PM
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
It is FOX924B.
Best,
Nick
On Thu, Jul 12, 2012 at 9:17 AM, Christophe ALEXANDRE
<[email protected]> wrote:
Hi Josh,
could you tell us the model number of the VCTCXOs ?
i see U27 and U8 on the N2xx schematics, but no model number.
Regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 11B niveau -1, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
----- Original Message ----- From: "Josh Blum" <[email protected]>
To: <[email protected]>
Sent: Thursday, July 12, 2012 10:39 AM
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
On 05/24/2012 04:59 PM, Francois Quitin wrote:
Hi all,
I'm currently using a USRP N200 with a WBX daughterboard. We are using a
gnuradio design (with some custom blocks) to synchronize the LOs of
several
USRPs to the LO of a master USRP using over-the air-signals.
While the setup was working perfectly with our old USRP-2, I have some
problems for it to work with the USRP-N200. The LOs of the latter seems
to
sometimes randomly "jump" by several tens of Hz.
You may be seeing the result of the onboard TCXO performing adjustments.
Unfortunately, the adjustments are digital and not analog, so it can be
seen a small jump.
You might try set_clock_source("external"). I believe that you can
either apply an external 10 MHz reference, or allow the clock
synthesizer to free-run.
Nick can confirm this tomorrow.
-josh
_______________________________________________
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/20120713/c30c570d/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 13 Jul 2012 09:34:46 +0200
From: "Christophe ALEXANDRE" <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <4FD38BF80B394C1B9E3E19CF62BDC49C@fletan>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
hi josh,
at this time, i'm trying to evaluate
if i could use 2 N210+SBX to realize
the electronic part of a high precision laser telemeter.
the problem can be seen as a phasemeter.
i need to set a frequency at about 3 GHz, then
measure a phase difference. the target is to find two
freq f1 and f2 that set to zero the phase difference.
for this application, i need phase alignment between 2 LO
(using MIMO cable synchro) and tuning speed.
timed command could be the solution for phase alignment
and digital offset for quick tuning.
my purpose is to find roughly the freq that nullify the phase diff
(LO tuning) then to refine the search using CORDIC tuning.
regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 11B niveau -1, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
----- Original Message -----
From: "Josh Blum" <[email protected]>
To: "ALEXANDRE Christophe" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, July 12, 2012 10:54 PM
Subject: Re: [USRP-users] Two-stage tuning process
>
>
> On 07/12/2012 12:52 PM, ALEXANDRE Christophe wrote:
>> i've tried this code :
>>
>>> self.uhd_usrp_sink_0.set_center_freq(uhd.tune_request(desired_freq,
>>> lo_offset), 0)
>>
>> directly from GRC and i see no change in the output frequency.
>
> Thats correct.
>
>> if i understand [email protected] explanations, when i use a lo_offset,
>> the analog LO freq will be shifted from lo_offset and the CORDIC will
>> compensate
>> exactly in the FPGA. The overall freq will stay the same. it's only to
>> shift the DC
>> out of band. is that true ?
>>
>>
>
> Yes, the overall frequency of the RX chain will stay the same.
>
> One possible use is to shift the LO out of band of interest.
>
>> if i want to adjust digitally the output freq, i suppose that i need to
>> put the tuning process
>> in MANUAL mode and set separately the analog LO freq and the digital
>> CORDIC freq.
>>
>> is there any way for me to know the real frequency of the analog LO so
>> that i can compensate
>> the error + digitally shift the output frequency ?
>>
>
> So the tune_result_t gives you all the result of the tune, RF and DSP
> frequency.
> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n176
>
> Is there something specific you are trying to do? Like frequency hop
> with the DSP, but leave the LO at a fixed frequency?
>
> -josh
------------------------------
Message: 15
Date: Fri, 13 Jul 2012 08:03:20 -0700
From: Nick Foster <[email protected]>
To: Christophe ALEXANDRE <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
Message-ID:
<CALALHJXMhn3YaRVcwNNSTMU7BCOZux=wfym7jqrgn+huaxf...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
There are three options:
1. Use an external 10MHz reference, such as a GPSDO or reference oscillator.
2. Change the TCXO to another device.
3. Set the N210 to use external reference, but do not connect an external
reference. This will let the N210 operate without a 10MHz reference. The
absolute frequency accuracy will be less, but the discontinuities will be
gone.
Let me know if these solutions are acceptable.
--n
On Fri, Jul 13, 2012 at 12:09 AM, Christophe ALEXANDRE <
[email protected]> wrote:
> **
> we have the same problem as Francois Quitin.
> the unstable LO give us some headaches with
> our CFO algorithms.
>
> would it be possible to change this vctcxo
> and use another model ? we own 5 N210.
>
> Salutations.
>
>
> Christophe ALEXANDRE
> Conservatoire National des Arts et M?tiers (CNAM)
> Laboratoire CEDRIC-LAETITIA
> D?partement EASY
> Acc?s 11B niveau -1, Case 2D2P10
> 292 rue Saint Martin
> 75141 PARIS CEDEX 03
> FRANCE
> email : [email protected]
> tel. 0140272699
> mob. 0651087311
> fax. 0140272994
>
>
> ----- Original Message -----
> *From:* Nick Foster <[email protected]>
> *To:* Christophe ALEXANDRE <[email protected]>
> *Cc:* [email protected] ; [email protected]
> *Sent:* Thursday, July 12, 2012 7:41 PM
> *Subject:* Re: [USRP-users] unstable LO of USRP-N200 and WBX
>
> It is FOX924B.
>
> Best,
> Nick
>
> On Thu, Jul 12, 2012 at 9:17 AM, Christophe ALEXANDRE <
> [email protected]> wrote:
>
>> Hi Josh,
>>
>> could you tell us the model number of the VCTCXOs ?
>> i see U27 and U8 on the N2xx schematics, but no model number.
>>
>> Regards.
>>
>>
>> Christophe ALEXANDRE
>> Conservatoire National des Arts et M?tiers (CNAM)
>> Laboratoire CEDRIC-LAETITIA
>> D?partement EASY
>> Acc?s 11B niveau -1, Case 2D2P10
>> 292 rue Saint Martin
>> 75141 PARIS CEDEX 03
>> FRANCE
>> email : [email protected]
>> tel. 0140272699
>> mob. 0651087311
>> fax. 0140272994
>>
>>
>> ----- Original Message ----- From: "Josh Blum" <[email protected]>
>> To: <[email protected]>
>> Sent: Thursday, July 12, 2012 10:39 AM
>> Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
>>
>>
>>
>>
>>>
>>> On 05/24/2012 04:59 PM, Francois Quitin wrote:
>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I'm currently using a USRP N200 with a WBX daughterboard. We are using a
>>>> gnuradio design (with some custom blocks) to synchronize the LOs of
>>>> several
>>>> USRPs to the LO of a master USRP using over-the air-signals.
>>>>
>>>>
>>>>
>>>> While the setup was working perfectly with our old USRP-2, I have some
>>>> problems for it to work with the USRP-N200. The LOs of the latter seems
>>>> to
>>>> sometimes randomly "jump" by several tens of Hz.
>>>>
>>>>
>>>>
>>> You may be seeing the result of the onboard TCXO performing adjustments.
>>> Unfortunately, the adjustments are digital and not analog, so it can be
>>> seen a small jump.
>>>
>>> You might try set_clock_source("external"). I believe that you can
>>> either apply an external 10 MHz reference, or allow the clock
>>> synthesizer to free-run.
>>>
>>> Nick can confirm this tomorrow.
>>>
>>> -josh
>>>
>>> ______________________________**_________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>
>>
>>
>> ______________________________**_________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120713/a6775961/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 13 Jul 2012 15:25:04 +0000
From: "Nowlan, Sean" <[email protected]>
To: "Nowlan, Sean" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] External and internal clock sources
Message-ID: <195933287DC65748BA7AE867BA8E430B62259403@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
Does FPGA sync its internal time register with PPS (if available and enabled)
or does it just increment based on the 100 MHz clock derived from the 10 MHz
reference?
From: [email protected]
[mailto:[email protected]] On Behalf Of Nowlan, Sean
Sent: Tuesday, July 10, 2012 1:40 PM
To: [email protected]
Subject: [USRP-users] External and internal clock sources
Hi all,
I wanted to know what kind of problems I might run into if I use an external
PPS and the internal 10 MHz reference (USRP N200). For our application we want
to study performance using both stable (e.g., GPSDO) and unstable (e.g.,
factory) clocks, but we want to have the ability to tag with accurate
timestamps.
Ideally the answer would be "timestamp = (time at PPS edge) + (sample rate) *
(sample offset)", but the freq synthesizer can run off of a reference
independent from the PPS. But I'm not sure if that's how it's implemented or if
it's possible. Thanks!
Best regards,
Sean Nowlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120713/cc68a099/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 23, Issue 12
******************************************
