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: External and internal clock sources (Josh Blum)
2. Re: Simple example built for UHD crashes when run. (Ed Jubenville)
3. Re: Two-stage tuning process (Josh Blum)
4. Re: Simple example built for UHD crashes when run. (Josh Blum)
5. Problem running niUSRP with the Ettus USRP N200 (Dan Johnson)
6. Re: Problem running niUSRP with the Ettus USRP N200 (Josh Blum)
7. Re: Two-stage tuning process (ALEXANDRE Christophe)
8. Re: Two-stage tuning process (Nowlan, Sean)
9. Re: Two-stage tuning process (Nowlan, Sean)
10. Re: Two-stage tuning process (Josh Blum)
11. Re: Simple example built for UHD crashes when run. (Ed Jubenville)
12. Re: unstable LO of USRP-N200 and WBX (Francois Quitin)
----------------------------------------------------------------------
Message: 1
Date: Fri, 13 Jul 2012 09:55:54 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] External and internal clock sources
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/13/2012 08:25 AM, Nowlan, Sean wrote:
> 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?
>
The clock tick register always counts on every tick of the 100 MHz
clock. PPS is simply used as a trigger to latch a new time into these
registers. The effect is that N units latch a new time in on the same
PPS event and them march in lock-step.
-Josh
> 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
>
>
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Fri, 13 Jul 2012 09:58:53 -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"
I tried many of the Boost variants, but only one of them worked. This may
be because the UHD that I am using is a binary install, so it had been
prebuilt to expect a certain configuration of release vs. debug, static vs.
dynamic, DLL vs. not, and single vs. multithreading. Just guessing on that,
though.
I found that the BoostPro option #3 (Multithreaded) built and ran when I
compiled/linked MSVC for a release build. I needed to point the include
paths and library paths for boost and UHD, but that was the only real
customization required for the MSVC project.
BoostPro option #4 (Multithreaded debug) would build, but would crash upon
execution with the previously stated exception.
I'd like to be able to use debug mode for my own application during
development, but this doesn't seem to be compatible with the UHD binaries as
prebuilt. I'm hoping to stick with the UHD binaries because I am still
having trouble getting a successful UHD build from source on Windows.
Can anyone recommend a MSVC strategy for a debug build of an application
using the UHD binary installation?
Ed
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Josh Blum
Sent: Thursday, July 12, 2012 3:36 PM
To: [email protected]
Subject: Re: [USRP-users] Simple example built for UHD crashes when run.
>> 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
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Fri, 13 Jul 2012 10:02:07 -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/13/2012 12:34 AM, Christophe ALEXANDRE wrote:
> 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.
>
I see. So I believe you want to only set the cordic frequency and leave
the LO fixed. In this case, after the first tune, try something like this
t = uhd.tune_request(overall_target_freq)
t.rf_freq_policy = uhd.tune_request.NONE
t.dsp_freq_policy = uhd.tune_request.MANUAL
t.dsp_freq = <desired freq>
-josh
> 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: 4
Date: Fri, 13 Jul 2012 10:07:14 -0700
From: Josh Blum <[email protected]>
To: Ed Jubenville <[email protected]>
Cc: "[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=ISO-8859-1
On 07/13/2012 09:58 AM, Ed Jubenville wrote:
> I tried many of the Boost variants, but only one of them worked. This may
> be because the UHD that I am using is a binary install, so it had been
> prebuilt to expect a certain configuration of release vs. debug, static vs.
> dynamic, DLL vs. not, and single vs. multithreading. Just guessing on that,
> though.
>
Correct, that UHD installer was built for 32 bit release mode.
For some more details
* Boost was statically linked in, so you need to link boost by some
means if you plan to use boost in your client application/library
* The UHD dll was built with multithreading. Im not sure that
requirement is enforced on the client app.
> I found that the BoostPro option #3 (Multithreaded) built and ran when I
> compiled/linked MSVC for a release build. I needed to point the include
> paths and library paths for boost and UHD, but that was the only real
> customization required for the MSVC project.
>
> BoostPro option #4 (Multithreaded debug) would build, but would crash upon
> execution with the previously stated exception.
>
Thats correct, you cant mix debug and release mode libraries.
> I'd like to be able to use debug mode for my own application during
> development, but this doesn't seem to be compatible with the UHD binaries as
> prebuilt. I'm hoping to stick with the UHD binaries because I am still
> having trouble getting a successful UHD build from source on Windows.
>
> Can anyone recommend a MSVC strategy for a debug build of an application
> using the UHD binary installation?
>
We have installers for uhd built for
32bit release
32bit debug
64bit release
64bit debug
http://files.ettus.com/binaries/uhd_unstable/latest/
http://files.ettus.com/binaries/uhd_stable/latest_stable/
-josh
------------------------------
Message: 5
Date: Fri, 13 Jul 2012 14:48:28 -0400
From: Dan Johnson <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: [USRP-users] Problem running niUSRP with the Ettus USRP N200
Message-ID:
<CAOm7S4g=bn5gbnhfrhtco22ks81o13t0qc6aqf_d-szru5v...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I'm trying to bring up a USRP N200 with the WBX transceiver module. I can
communicate with the unit over the ethernet link but when I use the niUSRP
VIs I get this error. I understand that I need to modify the firmware but
I've been unable to find the correct firmware versions that will work with
this unit. Does anyone have this working now? Any help you can provide
would be greatly appreciated! Thanks in advance.
niUSRP Open Rx Session.vi<ERR>A runtime or configuration error occurred.
Code: 1440
Details: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected protocol compatibility number [7 to 10], but got 12:
The firmware build is not compatible with the host code build.
On another note... our unit only shipped with one SMA to front panel coax
connector. Did any of you that have N200 receive two cables or do I need to
purchase another one? Just curious..
--
Dan Johnson
R&D Engineer
[email protected]
502-365-5690
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120713/8276c505/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 13 Jul 2012 12:20:20 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problem running niUSRP with the Ettus USRP
N200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/13/2012 11:48 AM, Dan Johnson wrote:
> I'm trying to bring up a USRP N200 with the WBX transceiver module. I can
> communicate with the unit over the ethernet link but when I use the niUSRP
> VIs I get this error. I understand that I need to modify the firmware but
> I've been unable to find the correct firmware versions that will work with
> this unit. Does anyone have this working now? Any help you can provide
> would be greatly appreciated! Thanks in advance.
>
> niUSRP Open Rx Session.vi<ERR>A runtime or configuration error occurred.
> Code: 1440
>
> Details: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected protocol compatibility number [7 to 10], but got 12:
> The firmware build is not compatible with the host code build.
Sorry about that. I believe that this version of the software may want
images from the 3.3.* version of the driver:
http://files.ettus.com/binaries/uhd_stable/releases/uhd_003.003.002-release/images-only/
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#load-the-images-onto-the-on-board-flash-usrp-n-series-only
I think that will help you,
-Josh
------------------------------
Message: 7
Date: Fri, 13 Jul 2012 21:27:05 +0200
From: "ALEXANDRE Christophe" <[email protected]>
To: <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <7FE09824B8A34D909F8E7C1BE5F5A8BD@fletan>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
i will try your code on monday.
regarding gnuradio, i have some trouble understanding the principles.
for me, a flowgraph is a way to implement a parallel behavior. Each block
accepts some data at the input and produce some data at the output.
the flowgraph describes the behavior and when it runs, a scheduler launchs
all the blocks in parallel. there is no sequential code here.
but when i read your text :
> I see. So I believe you want to only set the cordic frequency and leave
> the LO fixed. In this case, after the first tune, try something like this
>
> t = uhd.tune_request(overall_target_freq)
> t.rf_freq_policy = uhd.tune_request.NONE
> t.dsp_freq_policy = uhd.tune_request.MANUAL
> t.dsp_freq = <desired freq>
for me, it's a sequential behavior (after the first tune, ...) and it
contradicts
the parallel behavior.
is there any doc that explain clearly that kind of concept with gnuradio ?
i'm used to use VHDL (parallel) and ANSI C (sequential) but i have some
difficulties
to understand the nature of gnuradio.
for my test, i will have to implement something like a controler :
1) set a frequency
2) read the phase diff
3) regarding the result, calculate new freq then goto 1)
i can think about the algorithm, but i don't know how to implement it
with gnuradio, because it's sequential by nature and i don't even have a
clock
to synchronize all the stuff.
i think i have no problem with speed and i can implement blocks directly in
python.
i spend some time last year with gnuradio and C++ blocks
but it was not obvious and we decided to use matlab for our
radio applications because the team is more signal processing than C++.
the telemeter is a good occasion to dig in gnuradio.
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: Friday, July 13, 2012 7:02 PM
Subject: Re: [USRP-users] Two-stage tuning process
>
>
> On 07/13/2012 12:34 AM, Christophe ALEXANDRE wrote:
>> 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.
>>
>
>
> I see. So I believe you want to only set the cordic frequency and leave
> the LO fixed. In this case, after the first tune, try something like this
>
> t = uhd.tune_request(overall_target_freq)
> t.rf_freq_policy = uhd.tune_request.NONE
> t.dsp_freq_policy = uhd.tune_request.MANUAL
> t.dsp_freq = <desired freq>
>
> -josh
>
>> 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: 8
Date: Fri, 13 Jul 2012 19:32:20 +0000
From: "Nowlan, Sean" <[email protected]>
To: ALEXANDRE Christophe <[email protected]>,
"[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <195933287DC65748BA7AE867BA8E430B622595A7@apatlisdmbx02>
Content-Type: text/plain; charset="iso-8859-1"
You can do what you're calling a "sequential" algorithm within a work function
of a processing block. You just need to use internal member variables to store
the state between the scheduler's calls to the work function of your block. For
instance, you can have a time variable that you increment by (number of samples
processed in this call to work) X (sample rate) to know how much to advance
your time register. Using this time variable and whatever other information you
need, you can determine when to retune. If you study the burst tagging example
in gr-uhd you'll hopefully understand what I mean.
Sean
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of ALEXANDRE Christophe
Sent: Friday, July 13, 2012 3:27 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Two-stage tuning process
i will try your code on monday.
regarding gnuradio, i have some trouble understanding the principles.
for me, a flowgraph is a way to implement a parallel behavior. Each block
accepts some data at the input and produce some data at the output.
the flowgraph describes the behavior and when it runs, a scheduler launchs all
the blocks in parallel. there is no sequential code here.
but when i read your text :
> I see. So I believe you want to only set the cordic frequency and
> leave the LO fixed. In this case, after the first tune, try something
> like this
>
> t = uhd.tune_request(overall_target_freq)
> t.rf_freq_policy = uhd.tune_request.NONE t.dsp_freq_policy =
> uhd.tune_request.MANUAL t.dsp_freq = <desired freq>
for me, it's a sequential behavior (after the first tune, ...) and it
contradicts the parallel behavior.
is there any doc that explain clearly that kind of concept with gnuradio ?
i'm used to use VHDL (parallel) and ANSI C (sequential) but i have some
difficulties to understand the nature of gnuradio.
for my test, i will have to implement something like a controler :
1) set a frequency
2) read the phase diff
3) regarding the result, calculate new freq then goto 1)
i can think about the algorithm, but i don't know how to implement it
with gnuradio, because it's sequential by nature and i don't even have a
clock
to synchronize all the stuff.
i think i have no problem with speed and i can implement blocks directly in
python.
i spend some time last year with gnuradio and C++ blocks
but it was not obvious and we decided to use matlab for our
radio applications because the team is more signal processing than C++.
the telemeter is a good occasion to dig in gnuradio.
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: Friday, July 13, 2012 7:02 PM
Subject: Re: [USRP-users] Two-stage tuning process
>
>
> On 07/13/2012 12:34 AM, Christophe ALEXANDRE wrote:
>> 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.
>>
>
>
> I see. So I believe you want to only set the cordic frequency and leave
> the LO fixed. In this case, after the first tune, try something like this
>
> t = uhd.tune_request(overall_target_freq)
> t.rf_freq_policy = uhd.tune_request.NONE
> t.dsp_freq_policy = uhd.tune_request.MANUAL
> t.dsp_freq = <desired freq>
>
> -josh
>
>> 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
>>
>>
>
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 9
Date: Fri, 13 Jul 2012 19:35:30 +0000
From: "Nowlan, Sean" <[email protected]>
To: ALEXANDRE Christophe <[email protected]>,
"[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Two-stage tuning process
Message-ID: <195933287DC65748BA7AE867BA8E430B622595B9@apatlisdmbx02>
Content-Type: text/plain; charset="iso-8859-1"
Sorry, two edits:
1) Everything I said assumes you're using GNU Radio
2) Increment time variable by (number of samples processed in this call to
work) / (sample rate) = (time elapsed).
-----Original Message-----
From: Nowlan, Sean
Sent: Friday, July 13, 2012 3:32 PM
To: 'ALEXANDRE Christophe'; [email protected]
Cc: [email protected]
Subject: RE: [USRP-users] Two-stage tuning process
You can do what you're calling a "sequential" algorithm within a work function
of a processing block. You just need to use internal member variables to store
the state between the scheduler's calls to the work function of your block. For
instance, you can have a time variable that you increment by (number of samples
processed in this call to work) X (sample rate) to know how much to advance
your time register. Using this time variable and whatever other information you
need, you can determine when to retune. If you study the burst tagging example
in gr-uhd you'll hopefully understand what I mean.
Sean
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of ALEXANDRE Christophe
Sent: Friday, July 13, 2012 3:27 PM
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Two-stage tuning process
i will try your code on monday.
regarding gnuradio, i have some trouble understanding the principles.
for me, a flowgraph is a way to implement a parallel behavior. Each block
accepts some data at the input and produce some data at the output.
the flowgraph describes the behavior and when it runs, a scheduler launchs all
the blocks in parallel. there is no sequential code here.
but when i read your text :
> I see. So I believe you want to only set the cordic frequency and
> leave the LO fixed. In this case, after the first tune, try something
> like this
>
> t = uhd.tune_request(overall_target_freq)
> t.rf_freq_policy = uhd.tune_request.NONE t.dsp_freq_policy =
> uhd.tune_request.MANUAL t.dsp_freq = <desired freq>
for me, it's a sequential behavior (after the first tune, ...) and it
contradicts the parallel behavior.
is there any doc that explain clearly that kind of concept with gnuradio ?
i'm used to use VHDL (parallel) and ANSI C (sequential) but i have some
difficulties to understand the nature of gnuradio.
for my test, i will have to implement something like a controler :
1) set a frequency
2) read the phase diff
3) regarding the result, calculate new freq then goto 1)
i can think about the algorithm, but i don't know how to implement it with
gnuradio, because it's sequential by nature and i don't even have a clock to
synchronize all the stuff.
i think i have no problem with speed and i can implement blocks directly in
python.
i spend some time last year with gnuradio and C++ blocks but it was not obvious
and we decided to use matlab for our radio applications because the team is
more signal processing than C++.
the telemeter is a good occasion to dig in gnuradio.
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: Friday, July 13, 2012 7:02 PM
Subject: Re: [USRP-users] Two-stage tuning process
>
>
> On 07/13/2012 12:34 AM, Christophe ALEXANDRE wrote:
>> 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.
>>
>
>
> I see. So I believe you want to only set the cordic frequency and leave
> the LO fixed. In this case, after the first tune, try something like this
>
> t = uhd.tune_request(overall_target_freq)
> t.rf_freq_policy = uhd.tune_request.NONE
> t.dsp_freq_policy = uhd.tune_request.MANUAL
> t.dsp_freq = <desired freq>
>
> -josh
>
>> 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
>>
>>
>
>
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 10
Date: Fri, 13 Jul 2012 12:37:36 -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/13/2012 12:27 PM, ALEXANDRE Christophe wrote:
> i will try your code on monday.
>
>
> regarding gnuradio, i have some trouble understanding the principles.
> for me, a flowgraph is a way to implement a parallel behavior. Each block
> accepts some data at the input and produce some data at the output.
> the flowgraph describes the behavior and when it runs, a scheduler launchs
> all the blocks in parallel. there is no sequential code here.
>
The work() functions of each block do exactly this in parallel, one
thread per work function. Consume input, produce output.
But at the end of the day, a flow graph is just a bunch of object. And
you can make function calls on these objects to change parameters.
Make a flow graph in GRC with a few GUI widgets sliders to control a
signal source frequency. Look at the generated code. Its just making
function calls on some objects. You too can make arbitrary code that
does that same.
-josh
------------------------------
Message: 11
Date: Fri, 13 Jul 2012 14:21:37 -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="iso-8859-1"
Thanks for clarifying the importance of matching the build configuration of
a specific UHD binary to the Boost library. They have to be a matched set.
That's what I had initially thought, but became confused by the earlier post
that said it was my preference as to which Boost configuration I could use
with the UHD binaries. I had been speaking of a specific UHD binary, but
you were probably speaking in general terms since you have multiple UHD
binaries available.
I'll grab the 32-bit debug UHD installer and give that a whirl.
Ed
-----Original Message-----
From: Josh Blum [mailto:[email protected]]On Behalf Of Josh Blum
Sent: Friday, July 13, 2012 10:07 AM
To: Ed Jubenville
Cc: [email protected]
Subject: Re: [USRP-users] Simple example built for UHD crashes when run.
On 07/13/2012 09:58 AM, Ed Jubenville wrote:
> I tried many of the Boost variants, but only one of them worked. This may
> be because the UHD that I am using is a binary install, so it had been
> prebuilt to expect a certain configuration of release vs. debug, static
vs.
> dynamic, DLL vs. not, and single vs. multithreading. Just guessing on
that,
> though.
>
Correct, that UHD installer was built for 32 bit release mode.
For some more details
* Boost was statically linked in, so you need to link boost by some
means if you plan to use boost in your client application/library
* The UHD dll was built with multithreading. Im not sure that
requirement is enforced on the client app.
> I found that the BoostPro option #3 (Multithreaded) built and ran when I
> compiled/linked MSVC for a release build. I needed to point the include
> paths and library paths for boost and UHD, but that was the only real
> customization required for the MSVC project.
>
> BoostPro option #4 (Multithreaded debug) would build, but would crash upon
> execution with the previously stated exception.
>
Thats correct, you cant mix debug and release mode libraries.
> I'd like to be able to use debug mode for my own application during
> development, but this doesn't seem to be compatible with the UHD binaries
as
> prebuilt. I'm hoping to stick with the UHD binaries because I am still
> having trouble getting a successful UHD build from source on Windows.
>
> Can anyone recommend a MSVC strategy for a debug build of an application
> using the UHD binary installation?
>
We have installers for uhd built for
32bit release
32bit debug
64bit release
64bit debug
http://files.ettus.com/binaries/uhd_unstable/latest/
http://files.ettus.com/binaries/uhd_stable/latest_stable/
-josh
------------------------------
Message: 12
Date: Fri, 13 Jul 2012 14:33:43 -0700
From: "Francois Quitin" <[email protected]>
To: "'Christophe ALEXANDRE'" <[email protected]>, "'Nick
Foster'" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] unstable LO of USRP-N200 and WBX
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Christophe,
Just saw you?re having the same problem as I had earlier. I was able to
solve my problem by setting my clock source to ?external?. The LO frequency
offset becomes an order of magnitude higher (around 10 kHz), but there are
no more random jumps in the LO clock offset, since the digital correction of
the clock is deactivated.
Hope this helps,
Fran?ois
De : [email protected]
[mailto:[email protected]] De la part de Christophe
ALEXANDRE
Envoy? : vendredi 13 juillet 2012 00:09
? : Nick Foster
Cc : [email protected]
Objet : Re: [USRP-users] unstable LO of USRP-N200 and WBX
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 <mailto:[email protected]>
To: Christophe <mailto:[email protected]> 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/a1c1e6af/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 13
******************************************
