Re: [Discuss-gnuradio] Clock rate change on x300

[Martin Braun]

A bit late here, but the X300 can now (at least on master) also do all the
other clock rates in between 184.32 and 200 Msps.

On Tue, Aug 6, 2019 at 11:56 AM Derek Kozel  wrote:

> Hi Paul,
>
> What rate do you want to adjust it to and for what purpose? The X300
> supports a master clock rate of 200 MS/s and 184.32 MS/s. The built in
> DSP can convert to an integer divisor sample rate of one of those two.
> Adding support for another rate would require either a lot of software
> work or implementing a rational resampler in the FPGA in which case you
> would need a Vivado license.
>
> https://files.ettus.com/manual/page_usrp_x3x0.html
>
> Regards,
> Derek
>
> On 06/08/2019 19:09, Mitchell, Paul wrote:
> > I need to adjust the clock rate on a USRP x300. Is there a simple way to
> do this or do I need to use Vivado to access the FPGA image somehow? I am
> using Linux for everything.
> >
> > Paul Mitchell
> > Engineering Technician IV
> > paul.mitch...@testllc.com
> > 256.716.9056 (Work)
> > 256.289.3581 (Cell)
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock rate change on x300

[Derek Kozel]

With the X300/X310 the clock rate must be specified, as show by Marcus,
in the Device Address field. The X300 cannot change clockrrdate after it
is configured, the B2x0, E3x0, and N310 can.

Regards,
Derek

On 07/08/2019 15:51, Marcus Müller wrote:
> You can!
>
> If you're using GRC to design your GNU Radio system, it's the "Clock
> Rate" property of the UHD USRP Source / Sink blocks; if you're directly
> coding, you want to call set_clock_rate() before doing anything else,
> or supplying "master_clock_rate=184.32e6" with your device address.
>
> Best regards,
> Marcus
>
> On Wed, 2019-08-07 at 14:30 +, Mitchell, Paul wrote:
>> Oh I see.  Does that mean that I can use GNU Radio to change it?  If
>> not, I’ll ask the USRP guys as you suggested.
>>  
>>  
>> Paul Mitchell
>> Engineering Technician IV
>> paul.mitch...@testllc.com
>> 256.716.9056 (Work)
>> 256.289.3581 (Cell)
>>  
>> From: Marcus Müller
>> Sent: Wednesday, August 7, 2019 9:27 AM
>> To: Mitchell, Paul; Derek Kozel; discuss-gnuradio@gnu.org
>> Cc: usrp-users
>> Subject: Re: [Discuss-gnuradio] Clock rate change on x300
>>  
>> Dear Paul,
>>
>> I'd recommend taking this to the USRP-users mailing list (in CC),
>> since
>> it's not really GNU Radio-related.
>>
>> Since that clock rate setting doesn't really "exist" until the device
>> is operating, you can't query that from any program than the program
>> currently using the USRP (but that program would know, anyway,
>> because
>> it either set the master clock rate to 184.32 MHz or it left it at
>> 200
>> MHz).
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2019-08-07 at 14:18 +, Mitchell, Paul wrote:
>>> I’m fine using one of the supported rates.  That’s totally fine.  I
>>> would just like to know how to check the clock rate and swap
>> between
>>> the two for experimentation purposes.  Is there a terminal string I
>>> can run in Linux to do this?
>>>  
>>>  
>>> Paul Mitchell
>>> Engineering Technician IV
>>> paul.mitch...@testllc.com
>>> 256.716.9056 (Work)
>>> 256.289.3581 (Cell)
>>>  
>>> From: Derek Kozel
>>> Sent: Tuesday, August 6, 2019 1:56 PM
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] Clock rate change on x300
>>>  
>>> Hi Paul,
>>>
>>> What rate do you want to adjust it to and for what purpose? The
>> X300
>>> supports a master clock rate of 200 MS/s and 184.32 MS/s. The built
>>> in
>>> DSP can convert to an integer divisor sample rate of one of those
>>> two.
>>> Adding support for another rate would require either a lot of
>>> software
>>> work or implementing a rational resampler in the FPGA in which case
>>> you
>>> would need a Vivado license.
>>>
>>> https://files.ettus.com/manual/page_usrp_x3x0.html
>>>
>>> Regards,
>>> Derek
>>>
>>> On 06/08/2019 19:09, Mitchell, Paul wrote:
>>>> I need to adjust the clock rate on a USRP x300. Is there a simple
>>> way to do this or do I need to use Vivado to access the FPGA image
>>> somehow? I am using Linux for everything. 
>>>> Paul Mitchell
>>>> Engineering Technician IV
>>>> paul.mitch...@testllc.com
>>>> 256.716.9056 (Work)
>>>> 256.289.3581 (Cell)
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>  ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock rate change on x300

[Marcus Müller]

You can!

If you're using GRC to design your GNU Radio system, it's the "Clock
Rate" property of the UHD USRP Source / Sink blocks; if you're directly
coding, you want to call set_clock_rate() before doing anything else,
or supplying "master_clock_rate=184.32e6" with your device address.

Best regards,
Marcus

On Wed, 2019-08-07 at 14:30 +, Mitchell, Paul wrote:
> Oh I see.  Does that mean that I can use GNU Radio to change it?  If
> not, I’ll ask the USRP guys as you suggested.
>  
>  
> Paul Mitchell
> Engineering Technician IV
> paul.mitch...@testllc.com
> 256.716.9056 (Work)
> 256.289.3581 (Cell)
>  
> From: Marcus Müller
> Sent: Wednesday, August 7, 2019 9:27 AM
> To: Mitchell, Paul; Derek Kozel; discuss-gnuradio@gnu.org
> Cc: usrp-users
> Subject: Re: [Discuss-gnuradio] Clock rate change on x300
>  
> Dear Paul,
> 
> I'd recommend taking this to the USRP-users mailing list (in CC),
> since
> it's not really GNU Radio-related.
> 
> Since that clock rate setting doesn't really "exist" until the device
> is operating, you can't query that from any program than the program
> currently using the USRP (but that program would know, anyway,
> because
> it either set the master clock rate to 184.32 MHz or it left it at
> 200
> MHz).
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-08-07 at 14:18 +, Mitchell, Paul wrote:
> > I’m fine using one of the supported rates.  That’s totally fine.  I
> > would just like to know how to check the clock rate and swap
> between
> > the two for experimentation purposes.  Is there a terminal string I
> > can run in Linux to do this?
> >  
> >  
> > Paul Mitchell
> > Engineering Technician IV
> > paul.mitch...@testllc.com
> > 256.716.9056 (Work)
> > 256.289.3581 (Cell)
> >  
> > From: Derek Kozel
> > Sent: Tuesday, August 6, 2019 1:56 PM
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Clock rate change on x300
> >  
> > Hi Paul,
> > 
> > What rate do you want to adjust it to and for what purpose? The
> X300
> > supports a master clock rate of 200 MS/s and 184.32 MS/s. The built
> > in
> > DSP can convert to an integer divisor sample rate of one of those
> > two.
> > Adding support for another rate would require either a lot of
> > software
> > work or implementing a rational resampler in the FPGA in which case
> > you
> > would need a Vivado license.
> > 
> > https://files.ettus.com/manual/page_usrp_x3x0.html
> > 
> > Regards,
> > Derek
> > 
> > On 06/08/2019 19:09, Mitchell, Paul wrote:
> > > I need to adjust the clock rate on a USRP x300. Is there a simple
> > way to do this or do I need to use Vivado to access the FPGA image
> > somehow? I am using Linux for everything. 
> > >
> > > Paul Mitchell
> > > Engineering Technician IV
> > > paul.mitch...@testllc.com
> > > 256.716.9056 (Work)
> > > 256.289.3581 (Cell)
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >  ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock rate change on x300

[Mitchell, Paul]

Oh I see.  Does that mean that I can use GNU Radio to change it?  If not, I’ll 
ask the USRP guys as you suggested.





Paul Mitchell

Engineering Technician IV

paul.mitch...@testllc.com<mailto:paul.mitch...@testllc.com>

256.716.9056 (Work)

256.289.3581 (Cell)



From: Marcus Müller<mailto:marcus.muel...@ettus.com>
Sent: Wednesday, August 7, 2019 9:27 AM
To: Mitchell, Paul<mailto:paul.mitch...@testllc.com>; Derek 
Kozel<mailto:de...@bitstovolts.com>; 
discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Cc: usrp-users<mailto:usrp-us...@lists.ettus.com>
Subject: Re: [Discuss-gnuradio] Clock rate change on x300



Dear Paul,

I'd recommend taking this to the USRP-users mailing list (in CC), since
it's not really GNU Radio-related.

Since that clock rate setting doesn't really "exist" until the device
is operating, you can't query that from any program than the program
currently using the USRP (but that program would know, anyway, because
it either set the master clock rate to 184.32 MHz or it left it at 200
MHz).

Best regards,
Marcus

On Wed, 2019-08-07 at 14:18 +, Mitchell, Paul wrote:
> I’m fine using one of the supported rates.  That’s totally fine.  I
> would just like to know how to check the clock rate and swap between
> the two for experimentation purposes.  Is there a terminal string I
> can run in Linux to do this?
>
>
> Paul Mitchell
> Engineering Technician IV
> paul.mitch...@testllc.com
> 256.716.9056 (Work)
> 256.289.3581 (Cell)
>
> From: Derek Kozel
> Sent: Tuesday, August 6, 2019 1:56 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Clock rate change on x300
>
> Hi Paul,
>
> What rate do you want to adjust it to and for what purpose? The X300
> supports a master clock rate of 200 MS/s and 184.32 MS/s. The built
> in
> DSP can convert to an integer divisor sample rate of one of those
> two.
> Adding support for another rate would require either a lot of
> software
> work or implementing a rational resampler in the FPGA in which case
> you
> would need a Vivado license.
>
> https://files.ettus.com/manual/page_usrp_x3x0.html
>
> Regards,
> Derek
>
> On 06/08/2019 19:09, Mitchell, Paul wrote:
> > I need to adjust the clock rate on a USRP x300. Is there a simple
> way to do this or do I need to use Vivado to access the FPGA image
> somehow? I am using Linux for everything.
> >
> > Paul Mitchell
> > Engineering Technician IV
> > paul.mitch...@testllc.com
> > 256.716.9056 (Work)
> > 256.289.3581 (Cell)
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock rate change on x300

[Marcus Müller]

Dear Paul,

I'd recommend taking this to the USRP-users mailing list (in CC), since
it's not really GNU Radio-related.

Since that clock rate setting doesn't really "exist" until the device
is operating, you can't query that from any program than the program
currently using the USRP (but that program would know, anyway, because
it either set the master clock rate to 184.32 MHz or it left it at 200
MHz).

Best regards,
Marcus

On Wed, 2019-08-07 at 14:18 +, Mitchell, Paul wrote:
> I’m fine using one of the supported rates.  That’s totally fine.  I
> would just like to know how to check the clock rate and swap between
> the two for experimentation purposes.  Is there a terminal string I
> can run in Linux to do this?
>  
>  
> Paul Mitchell
> Engineering Technician IV
> paul.mitch...@testllc.com
> 256.716.9056 (Work)
> 256.289.3581 (Cell)
>  
> From: Derek Kozel
> Sent: Tuesday, August 6, 2019 1:56 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Clock rate change on x300
>  
> Hi Paul,
> 
> What rate do you want to adjust it to and for what purpose? The X300
> supports a master clock rate of 200 MS/s and 184.32 MS/s. The built
> in
> DSP can convert to an integer divisor sample rate of one of those
> two.
> Adding support for another rate would require either a lot of
> software
> work or implementing a rational resampler in the FPGA in which case
> you
> would need a Vivado license.
> 
> https://files.ettus.com/manual/page_usrp_x3x0.html
> 
> Regards,
> Derek
> 
> On 06/08/2019 19:09, Mitchell, Paul wrote:
> > I need to adjust the clock rate on a USRP x300. Is there a simple
> way to do this or do I need to use Vivado to access the FPGA image
> somehow? I am using Linux for everything. 
> >
> > Paul Mitchell
> > Engineering Technician IV
> > paul.mitch...@testllc.com
> > 256.716.9056 (Work)
> > 256.289.3581 (Cell)
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock rate change on x300

[Mitchell, Paul]

I’m fine using one of the supported rates.  That’s totally fine.  I would just 
like to know how to check the clock rate and swap between the two for 
experimentation purposes.  Is there a terminal string I can run in Linux to do 
this?





Paul Mitchell

Engineering Technician IV

paul.mitch...@testllc.com<mailto:paul.mitch...@testllc.com>

256.716.9056 (Work)

256.289.3581 (Cell)



From: Derek Kozel<mailto:de...@bitstovolts.com>
Sent: Tuesday, August 6, 2019 1:56 PM
To: discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Clock rate change on x300



Hi Paul,

What rate do you want to adjust it to and for what purpose? The X300
supports a master clock rate of 200 MS/s and 184.32 MS/s. The built in
DSP can convert to an integer divisor sample rate of one of those two.
Adding support for another rate would require either a lot of software
work or implementing a rational resampler in the FPGA in which case you
would need a Vivado license.

https://files.ettus.com/manual/page_usrp_x3x0.html

Regards,
Derek

On 06/08/2019 19:09, Mitchell, Paul wrote:
> I need to adjust the clock rate on a USRP x300. Is there a simple way to do 
> this or do I need to use Vivado to access the FPGA image somehow? I am using 
> Linux for everything.
>
> Paul Mitchell
> Engineering Technician IV
> paul.mitch...@testllc.com
> 256.716.9056 (Work)
> 256.289.3581 (Cell)
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock rate change on x300

[Derek Kozel]

Hi Paul,

What rate do you want to adjust it to and for what purpose? The X300
supports a master clock rate of 200 MS/s and 184.32 MS/s. The built in
DSP can convert to an integer divisor sample rate of one of those two.
Adding support for another rate would require either a lot of software
work or implementing a rational resampler in the FPGA in which case you
would need a Vivado license.

https://files.ettus.com/manual/page_usrp_x3x0.html

Regards,
Derek

On 06/08/2019 19:09, Mitchell, Paul wrote:
> I need to adjust the clock rate on a USRP x300. Is there a simple way to do 
> this or do I need to use Vivado to access the FPGA image somehow? I am using 
> Linux for everything. 
>
> Paul Mitchell
> Engineering Technician IV
> paul.mitch...@testllc.com
> 256.716.9056 (Work)
> 256.289.3581 (Cell)
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock rate change on x300

[Mitchell, Paul]

I need to adjust the clock rate on a USRP x300. Is there a simple way to do 
this or do I need to use Vivado to access the FPGA image somehow? I am using 
Linux for everything. 

Paul Mitchell
Engineering Technician IV
paul.mitch...@testllc.com
256.716.9056 (Work)
256.289.3581 (Cell)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock recovery without change of phase

[Marcus Müller]

Hi George,

isn't the job of a clock recovery actually to *change* the phase of your
signal so that its original clocking is recovered?

I'm a bit confused; could you maybe elaborate on what you want to do
(what for/why/what specific output are you looking for)? Are you maybe
looking for the clock error signal?

Best regards,
Marcus


On 06/14/2017 12:26 PM, George Vardakis wrote:
> Hi all, 
>
> I need to perform clock recovery on a signal without constantly
> changing its phase. I think that the clock recovery block in Gnuradio
> does exactly that in order to maximize the energy of the signal. Is
> there any other way that does not tamper with the signal phase? 
>
> Thanks! 
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

[Andy Walls]

Hi Phil:

> Date: Thu, 15 Jun 2017 12:57:54 +
> From: Phil Frost:

> I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK
> where the pulses are a raised cosine (impulse, not frequency domain) twice
> the symbol duration[2], no error correction, at 31.25 baud. The transmitted
> signal has no ISI, but after matched filtering it does:
> 
> [image: 0SDEq.png]
> 
> I had hoped to do matched filtering and compensate ISI with a Viterbi
> equalizer, but I'm unsure how to do clock recovery.
> 
> I hoped to use the polyphase clock recovery block, but it seems this won't
> work since the derivative of the signal may not be zero at the ideal
> sampling points. Is that an accurate assessment?

Hmm not really.  As long as *some* of the symbols have a derivative of 0
at the optimal sampling point, and you have proper symbol clock
synchronization loop filer gains set, the (small) signal * slope ML
approximation Timing Error Detector should work.

> [image: 2017-06-15-083544_393x230_scrot.png]
> 
> Perhaps the clock recovery MM block?

Don't use the Complex M block in GNURadio. Its internal decision
slicer (M is decision directed) is horribly wrong.

>  The zero crossings aren't exactly in
> the middle of the ideal sampling points, but the error is probably
> negligible.

The M TED doesn't use zero crossings.  It uses values at symbol peaks.
ISI tends to throw it off a little bit.

>  I can't get it to work: I think it outputs the correct bits,
> but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1
> depending on the adjacent bits. I'm using the default settings. Is that the
> intended behavior?

No.  Something is really wrong.  It should never output exactly +/-1.0
for every symbol, if you know you have ISI.

> 
> [image: 2017-06-15-084108_1038x201_scrot.png]
> [image: 2017-06-15-084340_475x253_scrot.png]
> 
> Finally, any other algorithms I should be considering?

I encourage you to try the Symbol Synchronizer block in this OOT module:

https://github.com/awalls-cx18/gr-nwr

or in this pull request:

https://github.com/gnuradio/gnuradio/pull/1294
https://github.com/awalls-cx18/gnuradio/tree/symbol_sync2

The Symbol Synchronizer block is a replacement for the Polyphase Clock
Sync blocks, M clock recovery blocks, and the MSK Timing Recovery
Block; adds additional Timing Error Detectors.  It adds synchronization
restart on time_est or clock_est tags. It performs tag propagation
correctly (unlike all the in tree blocks).

The block also has diagnostic sample stream outputs, so you can tune the
P-I filter for the desired symbol synch PLL behavior.
The diagnostic outputs are:
  error: timing error detector output signal
  T_inst: instantaneous symbol clock period estimate in samples/symbol
  T_avg: average symbol clock period estimate in samples/symbol

I encourage you to play with the clock recovery example flowgraph, to
get a feel for how tweaking damping factor and loop bandwidth affect how
the PLL tracks the symbol clock.
https://github.com/awalls-cx18/gr-nwr/blob/master/examples/clock_recovery_test_complex.grc
FWIW, the above flowgraph operates on symbols with some ISI in them.


The TEDs available with the Symbol Synchronizer blocks are:
  M (decision directed)
  Modified M (decision directed)
  Zero Crossing (decision directed)
  Gardner (a crude small signal * slope ML approximation)
  Early-Late
  D'Andrea and Mengali General MSK
  Mengali and D'Andrea GMSK
  small signal * slope ML approximation
  large signal signum * slope ML approximation

The decision directed TEDs require a slicer constellation object, and
that the input stream be normalized to the same levels to which the
constellation object normalizes the constellation points.
 
The interpolating-resampler used in the Symbol Synchronizer blocks is
selectable between:
   MMSE 8-tap (a 128 arm PFB that the M block uses)
   PFB, no MF (the MMSE 8-tap PFB with a reduced number of arms)
   PFB, MF (just like what the PFB clock sync blocks use)


For a quick overview of symbol recovery, see this MatLab documentation:
https://www.mathworks.com/help/comm/ref/comm.symbolsynchronizer-class.html#bumtxky-18

For the PFB clock sync block algorithms specifically, see figure 10 of:

Fredric J. Harris, Michael Rice, "Multirate Digital Filters for Symbol
Timing Synchronization in Software Defined Radios",
_IEEE_Journal_on_Selected_Areas_in_Communications_, Vol. 19, No. 12,
December 2001, pp. 2346 - 2357
https://pdfs.semanticscholar.org/3077/d85fc72d89c72c4c6d11f1014c5175e319c3.pdf

(The gist is to combine the receive pulse matched filter with the
resampling interpolator filter to save filtering operations.  The
resampling interpolator filter is implemented with a PFB and a
derivative PFB, since the (approximate) maximum likelyhood timing error
detector needs the derivative of the signal too.)

Also see this for an additional explanation written by Tom Rondeau:

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

[GhostOp14]

I had messed with psk31 a while back.  There's a gnuradio module to decode
and some example GRC's to send and receive that I had used here:
https://github.com/tkuester/gr-psk31 that may help you out.  The flowgraphs
in the examples directory already have all the blocks set up to receive.



On Thu, Jun 15, 2017 at 9:29 AM, Federico 'Larroca' La Rocca <
flarr...@gmail.com> wrote:

> Hi,
> Nice problem you got there. In any case, have you considered performing
> matched filtering (thus maximizing SNR), outputting more than one sample
> per symbol (in fact, without decimation at all), then equalize (so that the
> signal looks as if it was sent and received with a squared-root Nyquist
> pulse) and after all that use a standard clock recovery block? Since you
> know the shaping pulse, and as long as it does not go to zero over the
> range of frequencies of interest, you should be able to transform it into a
> Nyquist pulse. I may be wrong, but in any case Viterbi decoding for symbols
> will be difficult, so this may be worth trying.
> best
> Federico
>
> 2017-06-15 9:57 GMT-03:00 Phil Frost :
>
>> I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK
>> where the pulses are a raised cosine (impulse, not frequency domain) twice
>> the symbol duration[2], no error correction, at 31.25 baud. The transmitted
>> signal has no ISI, but after matched filtering it does:
>>
>> [image: 0SDEq.png]
>>
>> I had hoped to do matched filtering and compensate ISI with a Viterbi
>> equalizer, but I'm unsure how to do clock recovery.
>>
>> I hoped to use the polyphase clock recovery block, but it seems this
>> won't work since the derivative of the signal may not be zero at the ideal
>> sampling points. Is that an accurate assessment?
>>
>> [image: 2017-06-15-083544_393x230_scrot.png]
>>
>> Perhaps the clock recovery MM block? The zero crossings aren't exactly in
>> the middle of the ideal sampling points, but the error is probably
>> negligible. I can't get it to work: I think it outputs the correct bits,
>> but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1
>> depending on the adjacent bits. I'm using the default settings. Is that the
>> intended behavior?
>>
>> [image: 2017-06-15-084108_1038x201_scrot.png]
>> [image: 2017-06-15-084340_475x253_scrot.png]
>>
>> Finally, any other algorithms I should be considering?
>>
>>   [1]: http://bipt106.bi.ehu.es/psk31.html
>>   [2]: https://ham.stackexchange.com/a/7744/218
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

[Phil Frost]

Do you mean the equalization would be performed with another linear filter?

matched filter -> equalizing filter -> clock recovery -> [...]

Wouldn't that be equivalent of convolving the input responses of the two
cascaded FIRs, with the net result being an unmatched filter?

Existing implementations of this mode take that approach, using a filter
which minimizes the ISI while attempting to be close to matched. I wrote
about some of them at https://ham.stackexchange.com/a/7744/218. I was
hoping to try something new, at least for educational purposes.

I'm beyond what I comfortably know at this point, but if someone can
confirm I'm on the right track I can continue researching the right things.
I think part of the problem of the approach above is after filtering, the
noise is no longer uncorrelated. Maybe the canonical solution is something
like this?

matched filter -> equalizing filter -> clock recovery -> decimate to 1
sample per symbol -> "whitening filter" -> Costas loop -> Viterbi detector

I haven't yet studied whitening filters in depth, but my guess is it
reverses the effects of the equalization filter so that the noise is again
uncorrelated. At that point we're back to having ISI, but now with
uncorrelated noise the Viterbi detector can deal with that optimally. Am I
on the right track?

On Thu, Jun 15, 2017 at 9:29 AM Federico 'Larroca' La Rocca <
flarr...@gmail.com> wrote:

> Hi,
> Nice problem you got there. In any case, have you considered performing
> matched filtering (thus maximizing SNR), outputting more than one sample
> per symbol (in fact, without decimation at all), then equalize (so that the
> signal looks as if it was sent and received with a squared-root Nyquist
> pulse) and after all that use a standard clock recovery block? Since you
> know the shaping pulse, and as long as it does not go to zero over the
> range of frequencies of interest, you should be able to transform it into a
> Nyquist pulse. I may be wrong, but in any case Viterbi decoding for symbols
> will be difficult, so this may be worth trying.
> best
> Federico
>
> 2017-06-15 9:57 GMT-03:00 Phil Frost :
>
>> I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK
>> where the pulses are a raised cosine (impulse, not frequency domain) twice
>> the symbol duration[2], no error correction, at 31.25 baud. The transmitted
>> signal has no ISI, but after matched filtering it does:
>>
>> [image: 0SDEq.png]
>>
>> I had hoped to do matched filtering and compensate ISI with a Viterbi
>> equalizer, but I'm unsure how to do clock recovery.
>>
>> I hoped to use the polyphase clock recovery block, but it seems this
>> won't work since the derivative of the signal may not be zero at the ideal
>> sampling points. Is that an accurate assessment?
>>
>> [image: 2017-06-15-083544_393x230_scrot.png]
>>
>> Perhaps the clock recovery MM block? The zero crossings aren't exactly in
>> the middle of the ideal sampling points, but the error is probably
>> negligible. I can't get it to work: I think it outputs the correct bits,
>> but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1
>> depending on the adjacent bits. I'm using the default settings. Is that the
>> intended behavior?
>>
>> [image: 2017-06-15-084108_1038x201_scrot.png]
>> [image: 2017-06-15-084340_475x253_scrot.png]
>>
>> Finally, any other algorithms I should be considering?
>>
>>   [1]: http://bipt106.bi.ehu.es/psk31.html
>>   [2]: https://ham.stackexchange.com/a/7744/218
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

[Federico 'Larroca' La Rocca]

Hi,
Nice problem you got there. In any case, have you considered performing
matched filtering (thus maximizing SNR), outputting more than one sample
per symbol (in fact, without decimation at all), then equalize (so that the
signal looks as if it was sent and received with a squared-root Nyquist
pulse) and after all that use a standard clock recovery block? Since you
know the shaping pulse, and as long as it does not go to zero over the
range of frequencies of interest, you should be able to transform it into a
Nyquist pulse. I may be wrong, but in any case Viterbi decoding for symbols
will be difficult, so this may be worth trying.
best
Federico

2017-06-15 9:57 GMT-03:00 Phil Frost :

> I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK
> where the pulses are a raised cosine (impulse, not frequency domain) twice
> the symbol duration[2], no error correction, at 31.25 baud. The transmitted
> signal has no ISI, but after matched filtering it does:
>
> [image: 0SDEq.png]
>
> I had hoped to do matched filtering and compensate ISI with a Viterbi
> equalizer, but I'm unsure how to do clock recovery.
>
> I hoped to use the polyphase clock recovery block, but it seems this won't
> work since the derivative of the signal may not be zero at the ideal
> sampling points. Is that an accurate assessment?
>
> [image: 2017-06-15-083544_393x230_scrot.png]
>
> Perhaps the clock recovery MM block? The zero crossings aren't exactly in
> the middle of the ideal sampling points, but the error is probably
> negligible. I can't get it to work: I think it outputs the correct bits,
> but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1
> depending on the adjacent bits. I'm using the default settings. Is that the
> intended behavior?
>
> [image: 2017-06-15-084108_1038x201_scrot.png]
> [image: 2017-06-15-084340_475x253_scrot.png]
>
> Finally, any other algorithms I should be considering?
>
>   [1]: http://bipt106.bi.ehu.es/psk31.html
>   [2]: https://ham.stackexchange.com/a/7744/218
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock recovery for BPSK with intentional ISI

[Phil Frost]

I am working on a receiver for the amateur radio mode PSK31[1]. It's BPSK
where the pulses are a raised cosine (impulse, not frequency domain) twice
the symbol duration[2], no error correction, at 31.25 baud. The transmitted
signal has no ISI, but after matched filtering it does:

[image: 0SDEq.png]

I had hoped to do matched filtering and compensate ISI with a Viterbi
equalizer, but I'm unsure how to do clock recovery.

I hoped to use the polyphase clock recovery block, but it seems this won't
work since the derivative of the signal may not be zero at the ideal
sampling points. Is that an accurate assessment?

[image: 2017-06-15-083544_393x230_scrot.png]

Perhaps the clock recovery MM block? The zero crossings aren't exactly in
the middle of the ideal sampling points, but the error is probably
negligible. I can't get it to work: I think it outputs the correct bits,
but exactly 1 or -1, even though I should be getting +/- 0.5, 0.75, or 1
depending on the adjacent bits. I'm using the default settings. Is that the
intended behavior?

[image: 2017-06-15-084108_1038x201_scrot.png]
[image: 2017-06-15-084340_475x253_scrot.png]

Finally, any other algorithms I should be considering?

  [1]: http://bipt106.bi.ehu.es/psk31.html
  [2]: https://ham.stackexchange.com/a/7744/218
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock recovery without change of phase

[Federico 'Larroca' La Rocca]

Hi,
I'm not sure if I understood correctly your question, but clock recovery
(such as MM or Polyphase clock sync) takes the incoming signal and by
default outputs a sample every $T_s$ seconds (symbol time) but at the point
where the eye is widest (and thus it interpolates as needed). Once it
converges, the block's output phase should be stable (I mean, the phase
will probably still vary but it will be due to the remaining frequency
error between transmission and reception, which should be taken care of by
a Costas Loop or similar, but it is not generated by the clock
synchronization block).
best
Federico

2017-06-14 7:26 GMT-03:00 George Vardakis :

> Hi all,
>
> I need to perform clock recovery on a signal without constantly changing
> its phase. I think that the clock recovery block in Gnuradio does exactly
> that in order to maximize the energy of the signal. Is there any other way
> that does not tamper with the signal phase?
>
> Thanks!
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock recovery without change of phase

[George Vardakis]

Hi all,

I need to perform clock recovery on a signal without constantly changing
its phase. I think that the clock recovery block in Gnuradio does exactly
that in order to maximize the energy of the signal. Is there any other way
that does not tamper with the signal phase?

Thanks!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Marcus Müller]

Hi Tom,

why do/I/ have to advertise the PFB approach? Arguing against Mueller 
Müller feels strange. Anyway:

Mueller  Müller in the classical, real valued approach [1, eq (49), p.
524] in its core is
eqn. (49) page 524

with $z_k$ being the timing estimate ,$x_k$ being the input samples, and
$a_k$ the decisions (in our case, -1/+1 [2], so $E\{a_k^2\}\equiv 1$).
Assume timing is correct, ie. $z_{k-1} = 0$, but we have fading so that
$|x_k| = \epsilon |x_{k-1}|,\quad 0\epsilon \ll 1$;
then regardless of $a_{k-1}$, the term $|x_k a_{k-1}| \ll|x_{k-1}a_k|$,
and hence
$z_k \approx -\frac12 {x_{k-1}a_k}$

Now, $a_k$ is exactly the decision we don't want to put much trust in,
because it's a symbol decision with especially bad $\frac{E_s}{N_0}$.
Effectively, you get the bit error probability increase as a factor to
your timing error probability density, as if things weren't bad enough!

PFB is cooler because

 1. PFB!
 2. the derivate is a linear operation, so amplitude changes in the
input signal at least have the same effect on the error correction
magnitude.

Cheers,
Marcus

[1] http://2n3904.net/library/MM_Clock_Recovery.pdf
[2]
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L83
On 31.07.2015 01:06, Tom Rondeau wrote:
 On Thu, Jul 30, 2015 at 3:03 PM, Iluta V iluta2...@gmail.com
 mailto:iluta2...@gmail.com wrote:

 Hi, Tom,

 Could you be more specific where exactly it is not the right
 algorithm? We'd appreciate that and would correct that in own
 work as well, if Security Research Assessment made a mistake here.

 I will be looking forward to your response,

 Iluta



 Iluta,

 I shouldn't be so hard on the MM block. In most situations, it's
 tended to work fine, but it's suboptimal. It's based on hardware
 techniques of clock recovery that approximate a derivative. The PFB
 algorithm actually calculates the derivative to the numerical
 approximation required by setting the number of filterbank arms. So
 the results are much better. You also get to apply your own filter to
 this block so you don't have to apply a separate matched filter.

 Also, and I can't find any papers on this, but fred harris tells me
 that the MM algorithm behaves particularly poorly in fading environments.

 Tom


  

 On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondeau t...@trondeau.com
 mailto:t...@trondeau.com wrote:

 On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com
 mailto:iluta2...@gmail.com wrote:

 Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS
 (Examination of Using GNU Radio Companion for Security
 Research and Assessment) deals with Clock Recovery MM, I
 attached the paper, have a look at:

 6.Section 6.Counting the Bits
 7.Analyzing Demodulated Data

 Both deal with Clock Recovery MM usage and has flowgraphs.

 Best regards,

 Iluta



 That's great, and I'm glad they got it to work for their
 application. Looks like they provide a good explanation of its
 use, too. Still, it's not the right algorithm.


  

 Tom


  

 On Thu, Jul 30, 2015 at 9:23 PM, Tom Rondeau
 t...@trondeau.com mailto:t...@trondeau.com wrote:

 Another point to keep in mind is that the MM block
 isn't great in fading environments. It's really
 suboptimal in general. Look at the pfb_clock_recovery
 block, instead.

 Tom


 On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara
 danielcam...@gmail.com
 mailto:danielcam...@gmail.com wrote:

 Hi Klauss,

 You could also take a look at
 
 https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/
 
 https://www.tablix.org/%7Eavian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
 it helped me quite a bit!

  Best regards...

Daniel

 On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun
 martin.br...@ettus.com
 mailto:martin.br...@ettus.com wrote:

 Klaus,

 the manual page for this block has a paper
 reference in it:
 
 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation
 on MM algorithm block (paper
  for example). Any ideas ?
 
   

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Marcus Müller]

Hi Klauss,
  is it new ?

Not really, no. It's been around since ca April 2012.
If there's no Polyphase Clock Sync:
What version of GNU Radio are you using?

Best regards,
Marcus

PS: I always recommend not using ruby-forum but directly signing up to
the mailing list:
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
so much more comfortable! And with modern mail clients and webmail
interfaces, much better searchable.

On 31.07.2015 21:28, Klauss Wolfeinstein wrote:
 Wow ! Thank you all for your reply. Very interesting !

 Tom, I didn't find the pfb_clock_recovery block in my GNU Radio 
 Companion, is it new ?

 Best regards.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Klauss Wolfeinstein]

Wow ! Thank you all for your reply. Very interesting !

Tom, I didn't find the pfb_clock_recovery block in my GNU Radio 
Companion, is it new ?

Best regards.

-- 
Posted via http://www.ruby-forum.com/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Klauss Wolfeinstein]

Hi Marcus,

A it's the Polyphase Clock Sync, I didn't think about it ... :-D 
Thank you for the advice, I will use the mailing list next time.

Best regards.

Klauss.

-- 
Posted via http://www.ruby-forum.com/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Francisco Albani]

From Matlab MM documentation [1]:

[...] Typically, the input signal is the output of a receive filter that
is matched to the transmitting pulse shape. [...]

Assuming the MM Gnuradio implementation has the same hypothesis on the
input signal (anybody can confirm this?), I deduced this block is usually
misused when feed with a square signal, because it will take only one
sample per symbol discarding the rest (with useful energy). You can put a
Moving Average before for better results.

This is one of the reason why the pfb_clock_recovery block is better, but
unfortunately unfit for square signals [2]. I found even better results
using a gaussian filter inside pfb_clock_recovery as the pseudo-matched
filter to square pulses (with a proper bt value). (Obviously I can only
guarantee this for the specific signal I worked with)

[1] http://www.mathworks.com/help/comm/ref/muellermullertimingrecovery.html
[2] See discussion: http://gnuradio.org/redmine/issues/812

2015-07-30 16:03 GMT-03:00 Iluta V iluta2...@gmail.com:

 Hi, Tom,

 Could you be more specific where exactly it is not the right algorithm?
 We'd appreciate that and would correct that in own work as well, if
 Security Research Assessment made a mistake here.

 I will be looking forward to your response,

 Iluta



 On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com wrote:

 Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of
 Using GNU Radio Companion for Security Research and Assessment) deals with
 Clock Recovery MM, I attached the paper, have a look at:

 6.Section 6.Counting the Bits
 7.Analyzing Demodulated Data

 Both deal with Clock Recovery MM usage and has flowgraphs.

 Best regards,

 Iluta



 That's great, and I'm glad they got it to work for their application.
 Looks like they provide a good explanation of its use, too. Still, it's not
 the right algorithm.




 Tom




 On Thu, Jul 30, 2015 at 9:23 PM, Tom Rondeau t...@trondeau.com wrote:

 Another point to keep in mind is that the MM block isn't great in
 fading environments. It's really suboptimal in general. Look at the
 pfb_clock_recovery block, instead.

 Tom


 On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara danielcam...@gmail.com
 wrote:

 Hi Klauss,

 You could also take a look at
 https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
 it helped me quite a bit!

  Best regards...

Daniel

 On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com
 wrote:

 Klaus,

 the manual page for this block has a paper reference in it:

 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation on MM algorithm block
 (paper
  for example). Any ideas ?
 
  Thank you.
 
  Regards.
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 --
 Best regards...

  Daniel

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Tom Rondeau]

On Thu, Jul 30, 2015 at 3:03 PM, Iluta V iluta2...@gmail.com wrote:

 Hi, Tom,

 Could you be more specific where exactly it is not the right algorithm?
 We'd appreciate that and would correct that in own work as well, if
 Security Research Assessment made a mistake here.

 I will be looking forward to your response,

 Iluta



Iluta,

I shouldn't be so hard on the MM block. In most situations, it's tended to
work fine, but it's suboptimal. It's based on hardware techniques of clock
recovery that approximate a derivative. The PFB algorithm actually
calculates the derivative to the numerical approximation required by
setting the number of filterbank arms. So the results are much better. You
also get to apply your own filter to this block so you don't have to apply
a separate matched filter.

Also, and I can't find any papers on this, but fred harris tells me that
the MM algorithm behaves particularly poorly in fading environments.

Tom




 On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com wrote:

 Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of
 Using GNU Radio Companion for Security Research and Assessment) deals with
 Clock Recovery MM, I attached the paper, have a look at:

 6.Section 6.Counting the Bits
 7.Analyzing Demodulated Data

 Both deal with Clock Recovery MM usage and has flowgraphs.

 Best regards,

 Iluta



 That's great, and I'm glad they got it to work for their application.
 Looks like they provide a good explanation of its use, too. Still, it's not
 the right algorithm.




 Tom




 On Thu, Jul 30, 2015 at 9:23 PM, Tom Rondeau t...@trondeau.com wrote:

 Another point to keep in mind is that the MM block isn't great in
 fading environments. It's really suboptimal in general. Look at the
 pfb_clock_recovery block, instead.

 Tom


 On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara danielcam...@gmail.com
 wrote:

 Hi Klauss,

 You could also take a look at
 https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
 it helped me quite a bit!

  Best regards...

Daniel

 On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com
 wrote:

 Klaus,

 the manual page for this block has a paper reference in it:

 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation on MM algorithm block
 (paper
  for example). Any ideas ?
 
  Thank you.
 
  Regards.
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 --
 Best regards...

  Daniel

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Martin Braun]

Klaus,

the manual page for this block has a paper reference in it:
http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

M

On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
 Hello,
 
 I would like to find a proper documentation on MM algorithm block (paper
 for example). Any ideas ?
 
 Thank you.
 
 Regards.
 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Daniel Camara]

Hi Klauss,

You could also take a look at
https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
it helped me quite a bit!

 Best regards...

   Daniel

On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com
wrote:

 Klaus,

 the manual page for this block has a paper reference in it:

 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation on MM algorithm block (paper
  for example). Any ideas ?
 
  Thank you.
 
  Regards.
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




-- 
Best regards...

 Daniel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Tom Rondeau]

Another point to keep in mind is that the MM block isn't great in fading
environments. It's really suboptimal in general. Look at the
pfb_clock_recovery block, instead.

Tom


On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara danielcam...@gmail.com
wrote:

 Hi Klauss,

 You could also take a look at
 https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
 it helped me quite a bit!

  Best regards...

Daniel

 On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com
 wrote:

 Klaus,

 the manual page for this block has a paper reference in it:

 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation on MM algorithm block (paper
  for example). Any ideas ?
 
  Thank you.
 
  Regards.
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 --
 Best regards...

  Daniel

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock Recovery MM documentation

[Klauss Wolfeinstein]

Hello,

I would like to find a proper documentation on MM algorithm block (paper
for example). Any ideas ?

Thank you.

Regards.

-- 
Posted via http://www.ruby-forum.com/.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Iluta V]

Thanks for your explanation! That's worth while looking into!


On Fri, Jul 31, 2015 at 1:17 AM, Francisco Albani 
francisco.alb...@gmail.com wrote:

 From Matlab MM documentation [1]:

 [...] Typically, the input signal is the output of a receive filter that
 is matched to the transmitting pulse shape. [...]

 Assuming the MM Gnuradio implementation has the same hypothesis on the
 input signal (anybody can confirm this?), I deduced this block is usually
 misused when feed with a square signal, because it will take only one
 sample per symbol discarding the rest (with useful energy). You can put a
 Moving Average before for better results.

 This is one of the reason why the pfb_clock_recovery block is better, but
 unfortunately unfit for square signals [2]. I found even better results
 using a gaussian filter inside pfb_clock_recovery as the pseudo-matched
 filter to square pulses (with a proper bt value). (Obviously I can only
 guarantee this for the specific signal I worked with)

 [1]
 http://www.mathworks.com/help/comm/ref/muellermullertimingrecovery.html
 [2] See discussion: http://gnuradio.org/redmine/issues/812

 2015-07-30 16:03 GMT-03:00 Iluta V iluta2...@gmail.com:

 Hi, Tom,

 Could you be more specific where exactly it is not the right algorithm?
 We'd appreciate that and would correct that in own work as well, if
 Security Research Assessment made a mistake here.

 I will be looking forward to your response,

 Iluta



 On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com wrote:

 Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of
 Using GNU Radio Companion for Security Research and Assessment) deals with
 Clock Recovery MM, I attached the paper, have a look at:

 6.Section 6.Counting the Bits
 7.Analyzing Demodulated Data

 Both deal with Clock Recovery MM usage and has flowgraphs.

 Best regards,

 Iluta



 That's great, and I'm glad they got it to work for their application.
 Looks like they provide a good explanation of its use, too. Still, it's not
 the right algorithm.




 Tom




 On Thu, Jul 30, 2015 at 9:23 PM, Tom Rondeau t...@trondeau.com wrote:

 Another point to keep in mind is that the MM block isn't great in
 fading environments. It's really suboptimal in general. Look at the
 pfb_clock_recovery block, instead.

 Tom


 On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara danielcam...@gmail.com
  wrote:

 Hi Klauss,

 You could also take a look at
 https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
 it helped me quite a bit!

  Best regards...

Daniel

 On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com
  wrote:

 Klaus,

 the manual page for this block has a paper reference in it:

 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation on MM algorithm block
 (paper
  for example). Any ideas ?
 
  Thank you.
 
  Regards.
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 --
 Best regards...

  Daniel

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Tom Rondeau]

On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com wrote:

 Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of
 Using GNU Radio Companion for Security Research and Assessment) deals with
 Clock Recovery MM, I attached the paper, have a look at:

 6.Section 6.Counting the Bits
 7.Analyzing Demodulated Data

 Both deal with Clock Recovery MM usage and has flowgraphs.

 Best regards,

 Iluta



That's great, and I'm glad they got it to work for their application. Looks
like they provide a good explanation of its use, too. Still, it's not the
right algorithm.

Tom




 On Thu, Jul 30, 2015 at 9:23 PM, Tom Rondeau t...@trondeau.com wrote:

 Another point to keep in mind is that the MM block isn't great in fading
 environments. It's really suboptimal in general. Look at the
 pfb_clock_recovery block, instead.

 Tom


 On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara danielcam...@gmail.com
 wrote:

 Hi Klauss,

 You could also take a look at
 https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
 it helped me quite a bit!

  Best regards...

Daniel

 On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com
 wrote:

 Klaus,

 the manual page for this block has a paper reference in it:

 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation on MM algorithm block
 (paper
  for example). Any ideas ?
 
  Thank you.
 
  Regards.
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 --
 Best regards...

  Daniel

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM documentation

[Iluta V]

Hi, Tom,

Could you be more specific where exactly it is not the right algorithm?
We'd appreciate that and would correct that in own work as well, if
Security Research Assessment made a mistake here.

I will be looking forward to your response,

Iluta


On Thu, Jul 30, 2015 at 9:55 PM, Tom Rondeau t...@trondeau.com wrote:

 On Thu, Jul 30, 2015 at 2:38 PM, Iluta V iluta2...@gmail.com wrote:

 Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of
 Using GNU Radio Companion for Security Research and Assessment) deals with
 Clock Recovery MM, I attached the paper, have a look at:

 6.Section 6.Counting the Bits
 7.Analyzing Demodulated Data

 Both deal with Clock Recovery MM usage and has flowgraphs.

 Best regards,

 Iluta



 That's great, and I'm glad they got it to work for their application.
 Looks like they provide a good explanation of its use, too. Still, it's not
 the right algorithm.




 Tom




 On Thu, Jul 30, 2015 at 9:23 PM, Tom Rondeau t...@trondeau.com wrote:

 Another point to keep in mind is that the MM block isn't great in
 fading environments. It's really suboptimal in general. Look at the
 pfb_clock_recovery block, instead.

 Tom


 On Thu, Jul 30, 2015 at 2:18 PM, Daniel Camara danielcam...@gmail.com
 wrote:

 Hi Klauss,

 You could also take a look at
 https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/,
 it helped me quite a bit!

  Best regards...

Daniel

 On Thu, Jul 30, 2015 at 7:17 PM, Martin Braun martin.br...@ettus.com
 wrote:

 Klaus,

 the manual page for this block has a paper reference in it:

 http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html#details

 M

 On 30.07.2015 10:16, Klauss Wolfeinstein wrote:
  Hello,
 
  I would like to find a proper documentation on MM algorithm block
 (paper
  for example). Any ideas ?
 
  Thank you.
 
  Regards.
 


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 --
 Best regards...

  Daniel

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM

[Tom Rondeau]

On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:

 Hi all,

 looking at the clock recovery MM code, I wonder if d_omega_relative_limit
 is a relative or absolute deviation from d_omega.

 Here it looks like absolute

 https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107

 Here it is relative

 https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.h#L57

 (even though this code has no impact since d_{min,max}_omega is not used.)


 I don’t have access to the book linked in the docs atm.

 Best,
 Bastian



It is supposed to be relative. I'd have to verify the math on that line 107
in the .cc file, but it's supposed to adjust the center position of the
current omega estimate and then apply the clipping. Then it adds the mid
point back to get it back to where it's centered. Try walking through that
line one more time to verify that it's doing that properly. But yes, it's
supposed to be relative to the original setting of omega.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Recovery MM

[Bastian Bloessl]

On 09 Sep 2014, at 15:42, Tom Rondeau t...@trondeau.com wrote:

 On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl bloe...@ccs-labs.org wrote:
 Hi all,
 
 looking at the clock recovery MM code, I wonder if d_omega_relative_limit is 
 a relative or absolute deviation from d_omega.
 
 Here it looks like absolute
 https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107
 
 Here it is relative
 https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.h#L57
 
 (even though this code has no impact since d_{min,max}_omega is not used.)
 
 
 I don’t have access to the book linked in the docs atm.
 
 Best,
 Bastian
 
 
 It is supposed to be relative. I'd have to verify the math on that line 107 
 in the .cc file, but it's supposed to adjust the center position of the 
 current omega estimate and then apply the clipping. Then it adds the mid 
 point back to get it back to where it's centered. Try walking through that 
 line one more time to verify that it's doing that properly. But yes, it's 
 supposed to be relative to the original setting of omega.
 

So this line asserts that the current (absolute) deviation (d_mega - 
d_omega_mid) is smaller than the maximum allowed absolute deviation 
(d_omega_mid * d_omega_relative_limit). AFAIS, the second argument is missing 
“* d_omega_mid”.

I will create a patch, then you can check if I got you right.

Bastian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock Recovery MM

[Bastian Bloessl]

Hi all,

looking at the clock recovery MM code, I wonder if d_omega_relative_limit is a 
relative or absolute deviation from d_omega.

Here it looks like absolute
https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107

Here it is relative
https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.h#L57

(even though this code has no impact since d_{min,max}_omega is not used.)


I don’t have access to the book linked in the docs atm.

Best,
Bastian


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock synchronization B210

[Martin Braun]

On 08/29/2014 12:02 AM, Sharath Ananth wrote:
 Hello all,
 
  I am using the B210 without an external 10MHz clock and without a GPSDO
 mounted. As expected I see a frequency and sampling time error on the
 captured samples. Once this sampling time error is estimated, I would
 like to remove this in hardware by changing the sampling clock by a
 small amount. 
 Similarly once the frequency error is estimated, I would like to remove
 this in hardware by changing the LO frequency by a small amount.
 
 How can this be achieved in GRC? Is this by calling UHD_tune_req() in
 one of my custom blocks with the correct offset? Will this call modify
 the setting in the UHD source block already present in GRC

You can change the offsets in software, if that's what you're looking
for. A tune request does not know about these offsets, if you set an LO
offset, it will tune such that the LO is not on DC.

So, the easiest way is to imply subtract the offset from your actual
target frequency. Same goes for the master_clock_rate


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock synchronization B210

[Sharath Ananth]

Hello all,

 I am using the B210 without an external 10MHz clock and without a GPSDO 
mounted. As expected I see a frequency and sampling time error on the captured 
samples. Once this sampling time error is estimated, I would like to remove 
this in hardware by changing the sampling clock by a small amount. 
Similarly once the frequency error is estimated, I would like to remove this in 
hardware by changing the LO frequency by a small amount.

How can this be achieved in GRC? Is this by calling UHD_tune_req() in one of my 
custom blocks with the correct offset? Will this call modify the setting in the 
UHD source block already present in GRC

Thank you
Sharath___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock block slow in position satellite calculation

[caruiz.ext]

Hello,

I have this flowgraph in GNURadio: 
http://i1281.photobucket.com/albums/a515/Carlos_Alberto_Ruiz_Naranjo/esque_zpsd89166da.png


- Green: calculates the signal delay of a satellite.
- Yellow: a clock with a second precision.

If I run the clock separately I can see in the WX GUI Number Sink that 
it works. (0,1,2,3,4... each second)
But if I run the entire flowgraph I can see in the WX GUI Number Sink 
that clock becomes very slow. (0,1,2,3,4... each 2 second approximately)



Why is this? Any solution?

Thank you ;)


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock block slow in position satellite calculation

[Marcus Müller]

Hi!
You shouldn't use so many throttles in one flow graph; throttle limits
the number of samples going through in a given time, and as soon as the
upstream blocks have filled their output buffer, they will be limited
in throughput, too.
So I guess this is the effect of throttles blocking each other; however,
I don't really understand what's happening inside your flowgraph, so
this is a lot of guesswork.

Greetings,
Marcus
On 10.06.2014 09:23, caruiz.ext wrote:
 Hello,

 I have this flowgraph in GNURadio:
 http://i1281.photobucket.com/albums/a515/Carlos_Alberto_Ruiz_Naranjo/esque_zpsd89166da.png

 - Green: calculates the signal delay of a satellite.
 - Yellow: a clock with a second precision.

 If I run the clock separately I can see in the WX GUI Number Sink that
 it works. (0,1,2,3,4... each second)
 But if I run the entire flowgraph I can see in the WX GUI Number Sink
 that clock becomes very slow. (0,1,2,3,4... each 2 second approximately)


 Why is this? Any solution?

 Thank you ;)


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock block slow in position satellite calculation

[caruiz.ext]

Hi!


 RetardoSat:
1.Come three samples (method work)
- X: X position of receiver.
- Y: Y position of receiver.
- Z: Z position of receiver.
- ClK: seconds.

2. With Kepler paremeters calculates the satellite position, the 
distance between the satellite and the receiver and the signal delay.


3. Send to the output (t) the calculated delay.




float *out = (float*)output_items[0];
const float *inx = (const float *) input_items[0];
const float *iny = (const float *) input_items[1];
const float *inz = (const float *) input_items[2];
const float *inTOW = (const float *) input_items[3];



for(int i=0;inoutput_items;++i){
...
...
}











 Reloj:

*Precision = tiempo inicial
**Tasa = sample rate



++

namespace gr {
  namespace howto {

reloj_ff::sptr
reloj_ff::make(int tasa, int precision)
{
  return gnuradio::get_initial_sptr
(new reloj_ff_impl(tasa, precision));
}

/*
 * The private constructor
 */
reloj_ff_impl::reloj_ff_impl(int tasa, int precision)
  : gr::block(reloj_ff,
   gr::io_signature::make(1,1,sizeof(float)),
   gr::io_signature::make(1, 1, sizeof(float)))
{
this-d_tasa=tasa;
this-d_precision=(float)precision;
this-posicion=0;
}

/*
 * Our virtual destructor.
 */
reloj_ff_impl::~reloj_ff_impl()
{
}

void
reloj_ff_impl::forecast (int noutput_items, gr_vector_int 
ninput_items_required)

{
ninput_items_required[0] = noutput_items;
}

int
reloj_ff_impl::general_work (int noutput_items,
   gr_vector_int ninput_items,
   gr_vector_const_void_star input_items,
   gr_vector_void_star output_items)
{
float *out = (float*)output_items[0];
const float *in = (const float *) input_items[0];

for(int i=0;inoutput_items;++i){
if(posicion!=d_tasa){
out[i]=d_precision;
++posicion;
}
else{
d_precision=d_precision+1;
posicion=0;
out[i]=d_precision;
}
}

return noutput_items;
}

  } /* namespace howto */
} /* namespace gr */





++





#ifndef INCLUDED_HOWTO_RELOJ_FF_IMPL_H
#define INCLUDED_HOWTO_RELOJ_FF_IMPL_H

#include howto/reloj_ff.h

namespace gr {
  namespace howto {

class reloj_ff_impl : public reloj_ff
{
 private:
  // Nothing to declare in this block.

 public:
  reloj_ff_impl(int tasa, int precision);
  ~reloj_ff_impl();

int d_tasa;
float d_precision;
int posicion;

  // Where all the action really happens
  void forecast (int noutput_items, gr_vector_int 
ninput_items_required);


  int general_work(int noutput_items,
   gr_vector_int ninput_items,
   gr_vector_const_void_star input_items,
   gr_vector_void_star output_items);
};

  } // namespace howto
} // namespace gr

#endif /* INCLUDED_HOWTO_RELOJ_FF_IMPL_H */





;)



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock recovery in HRPT receiver

[Pablo Fernández Alonso]

Hi,

I am checking the HRPT receiver available in gr-noaa repository and I don't
understand the parameters of the Clock Recovery block with the information
available about the HRPT format. I roughly know how that block works,
but Ineedmore information.

Thank you in advance.

Pablo Fernandez.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock recovery in HRPT receiver

[Tom Rondeau]

On Mon, Apr 7, 2014 at 9:41 AM, Pablo Fernández Alonso 
pfernandezalons...@gmail.com wrote:

 Hi,

 I am checking the HRPT receiver available in gr-noaa repository and I don't
 understand the parameters of the Clock Recovery block with the
 information available about the HRPT format. I roughly know how that 
 blockworks, butIneedmore information.

 Thank you in advance.

 Pablo Fernandez.


Pablo,

This will give you a reference to the paper for the block's implementation:
http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1clock__recovery__mm__ff.html

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] clock synchronization by message passing

[Jay Prakash]

how can we set the time of usrp by sending it message. I know there are
function to (usrp.set_time_now()) do this from from top block variable but
can this be done by sending message at usrp port .
We can give internal reference signal of 10MHz  but is there also a way to
give pps signal internally i.e. without using any external hardware.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[John Malsbury]

The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not sure if
that's what you meant or not:
https://www.ettus.com/product/details/GPSDO-KIT

AFIAK, you cannot set the time of a USRP with a message. You may be able to
use the XML_RPC block in gr-extras to call the function if it is exposed
through gr-uhd.

-John


On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash jay.prakash.ec...@itbhu.ac.in
 wrote:

 how can we set the time of usrp by sending it message. I know there are
 function to (usrp.set_time_now()) do this from from top block variable but
 can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a way to
 give pps signal internally i.e. without using any external hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[Jay Prakash]

thanks for the clarification
so i checked the new grextras wiki it has uhd_control block i guess that
can be used for this job.

Jay Prakash
Senior Undergraduate
Electronics Engineering
IIT (BHU)
VARANASI

+91-9559475258
http://about.me/jay.prakash/
http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




On Sun, Jun 16, 2013 at 11:05 PM, John Malsbury john.malsb...@ettus.comwrote:

 The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not sure if
 that's what you meant or not:
 https://www.ettus.com/product/details/GPSDO-KIT

 AFIAK, you cannot set the time of a USRP with a message. You may be able
 to use the XML_RPC block in gr-extras to call the function if it is exposed
 through gr-uhd.

 -John


 On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 how can we set the time of usrp by sending it message. I know there are
 function to (usrp.set_time_now()) do this from from top block variable but
 can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a way
 to give pps signal internally i.e. without using any external hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[Adeel Anwar]

 so i checked the new grextras wiki it has uhd_control block i guess that
can be used for this job.
uhd_control block  supports only a subset of usrp-functions (exposed
through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
currently it doesn't support set_time_now()
https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp

-Adeel


On Sun, Jun 16, 2013 at 11:06 AM, Jay Prakash jay.prakash.ec...@itbhu.ac.in
 wrote:

 thanks for the clarification
 so i checked the new grextras wiki it has uhd_control block i guess that
 can be used for this job.

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:05 PM, John Malsbury 
 john.malsb...@ettus.comwrote:

 The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not sure if
 that's what you meant or not:
 https://www.ettus.com/product/details/GPSDO-KIT

 AFIAK, you cannot set the time of a USRP with a message. You may be able
 to use the XML_RPC block in gr-extras to call the function if it is exposed
 through gr-uhd.

 -John


 On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 how can we set the time of usrp by sending it message. I know there are
 function to (usrp.set_time_now()) do this from from top block variable but
 can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a way
 to give pps signal internally i.e. without using any external hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[Jay Prakash]

so do we have any other block to do that. I did'nt find XML_RPC block in
the new gr-extras


Jay Prakash
Senior Undergraduate
Electronics Engineering
IIT (BHU)
VARANASI

+91-9559475258
http://about.me/jay.prakash/
http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




On Sun, Jun 16, 2013 at 11:43 PM, Adeel Anwar adeela...@gmail.com wrote:

  so i checked the new grextras wiki it has uhd_control block i guess that
 can be used for this job.
 uhd_control block  supports only a subset of usrp-functions (exposed
 through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
 currently it doesn't support set_time_now()

 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp

 -Adeel


 On Sun, Jun 16, 2013 at 11:06 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 thanks for the clarification
 so i checked the new grextras wiki it has uhd_control block i guess that
 can be used for this job.

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:05 PM, John Malsbury 
 john.malsb...@ettus.comwrote:

 The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not sure
 if that's what you meant or not:
 https://www.ettus.com/product/details/GPSDO-KIT

 AFIAK, you cannot set the time of a USRP with a message. You may be able
 to use the XML_RPC block in gr-extras to call the function if it is exposed
 through gr-uhd.

 -John


 On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 how can we set the time of usrp by sending it message. I know there are
 function to (usrp.set_time_now()) do this from from top block variable but
 can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a way
 to give pps signal internally i.e. without using any external hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[John Malsbury]

XML_RPC block in the new gr-extras

XML_RPC would have been subject to the same limitations.  It could only
call set_time_next_pps if set_time_next_pps was in the uhd_sink/source
blocks.  Maybe you can update them to include the function.

Let me ask a more fundamental questions - why do you want to reset the
time?

-John


On Sun, Jun 16, 2013 at 11:20 AM, Jay Prakash jay.prakash.ec...@itbhu.ac.in
 wrote:

 so do we have any other block to do that. I did'nt find XML_RPC block in
 the new gr-extras


 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:43 PM, Adeel Anwar adeela...@gmail.com wrote:

  so i checked the new grextras wiki it has uhd_control block i guess
 that can be used for this job.
 uhd_control block  supports only a subset of usrp-functions (exposed
 through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
 currently it doesn't support set_time_now()

 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp

 -Adeel


 On Sun, Jun 16, 2013 at 11:06 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 thanks for the clarification
 so i checked the new grextras wiki it has uhd_control block i guess that
 can be used for this job.

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:05 PM, John Malsbury john.malsb...@ettus.com
  wrote:

 The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not sure
 if that's what you meant or not:
 https://www.ettus.com/product/details/GPSDO-KIT

 AFIAK, you cannot set the time of a USRP with a message. You may be
 able to use the XML_RPC block in gr-extras to call the function if it is
 exposed through gr-uhd.

 -John


 On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 how can we set the time of usrp by sending it message. I know there
 are function to (usrp.set_time_now()) do this from from top block variable
 but can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a
 way to give pps signal internally i.e. without using any external 
 hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[Jay Prakash]

I think i can use set_command_time (which i guess set the next time of
transmission/command?).
how can i make the usrp send its time when configured for synchronization?

Jay Prakash
Senior Undergraduate
Electronics Engineering
IIT (BHU)
VARANASI

+91-9559475258
http://about.me/jay.prakash/
http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




On Sun, Jun 16, 2013 at 11:58 PM, John Malsbury john.malsb...@ettus.comwrote:

 XML_RPC block in the new gr-extras

 XML_RPC would have been subject to the same limitations.  It could only
 call set_time_next_pps if set_time_next_pps was in the uhd_sink/source
 blocks.  Maybe you can update them to include the function.

 Let me ask a more fundamental questions - why do you want to reset the
 time?

 -John


 On Sun, Jun 16, 2013 at 11:20 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 so do we have any other block to do that. I did'nt find XML_RPC block in
 the new gr-extras


 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
  http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:43 PM, Adeel Anwar adeela...@gmail.comwrote:

  so i checked the new grextras wiki it has uhd_control block i guess
 that can be used for this job.
 uhd_control block  supports only a subset of usrp-functions (exposed
 through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
 currently it doesn't support set_time_now()

 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp

 -Adeel


 On Sun, Jun 16, 2013 at 11:06 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 thanks for the clarification
 so i checked the new grextras wiki it has uhd_control block i guess
 that can be used for this job.

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:05 PM, John Malsbury 
 john.malsb...@ettus.com wrote:

 The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not sure
 if that's what you meant or not:
 https://www.ettus.com/product/details/GPSDO-KIT

 AFIAK, you cannot set the time of a USRP with a message. You may be
 able to use the XML_RPC block in gr-extras to call the function if it is
 exposed through gr-uhd.

 -John


 On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 how can we set the time of usrp by sending it message. I know there
 are function to (usrp.set_time_now()) do this from from top block 
 variable
 but can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a
 way to give pps signal internally i.e. without using any external 
 hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[John Malsbury]

how can i make the usrp send its time when configured for synchronization?

I might be misunderstanding the question, but here's an answer.  The USRP
source outputs stream tags on the first sample when streaming.  The three
tags are 1) rx_time 2) rx_rate 3)  frequency.  Using (1) and (2), you
should be able to determine and track the time of the USRP.

You would use set_command_time for anything with commands - gpio, tuning,
etc.  This is in the control plane. You do timed bursts in the data plane
with stream tags - tx_sob, tx_time, tx_eob.

If these terms are foreign to you, Google introduction to stream tags by
Tom R.

-John


On Sun, Jun 16, 2013 at 12:02 PM, Jay Prakash jay.prakash.ec...@itbhu.ac.in
 wrote:

 I think i can use set_command_time (which i guess set the next time of
 transmission/command?).
 how can i make the usrp send its time when configured for synchronization?

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:58 PM, John Malsbury 
 john.malsb...@ettus.comwrote:

 XML_RPC block in the new gr-extras

 XML_RPC would have been subject to the same limitations.  It could only
 call set_time_next_pps if set_time_next_pps was in the uhd_sink/source
 blocks.  Maybe you can update them to include the function.

 Let me ask a more fundamental questions - why do you want to reset the
 time?

 -John


 On Sun, Jun 16, 2013 at 11:20 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 so do we have any other block to do that. I did'nt find XML_RPC block in
 the new gr-extras


 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
  http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:43 PM, Adeel Anwar adeela...@gmail.comwrote:

  so i checked the new grextras wiki it has uhd_control block i guess
 that can be used for this job.
 uhd_control block  supports only a subset of usrp-functions (exposed
 through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
 currently it doesn't support set_time_now()

 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp

 -Adeel


 On Sun, Jun 16, 2013 at 11:06 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 thanks for the clarification
 so i checked the new grextras wiki it has uhd_control block i guess
 that can be used for this job.

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:05 PM, John Malsbury 
 john.malsb...@ettus.com wrote:

 The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not
 sure if that's what you meant or not:
 https://www.ettus.com/product/details/GPSDO-KIT

 AFIAK, you cannot set the time of a USRP with a message. You may be
 able to use the XML_RPC block in gr-extras to call the function if it is
 exposed through gr-uhd.

 -John


 On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 how can we set the time of usrp by sending it message. I know there
 are function to (usrp.set_time_now()) do this from from top block 
 variable
 but can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a
 way to give pps signal internally i.e. without using any external 
 hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[Jay Prakash]

I went through the stream tagging pdf.

The tags from source has time,freq and rate.

I am interested in insuring that transmitter sets a particular frequency of
transmission ie Tx_Next_freq and time at which the transmitter starts
sending data packets at an instance.

The set_command_time as you suggested should work.

I see the features being implemented in Pre-cog.Can I get a heading of how
has these two features been insured?


The sole purpose of my questions is setting a synchronized frequency
hopping and unbroken data transfer at these hopping channels.

I have a set of TX frequencies [f1,f2,..fn]
and Receiver two has the knowledge of the frequency table.

Now I have a file and want to send certain chunks at different frequencies
and insure Receiver receives them without error.
For this Receiver will have to be synchronized with Tx and hop instances of
rx/tx should not be lagging.

Setting time of transmission/freq hop from tx side and getting rx_time info
from tags can help in establishing the channel I want.

Please help me figuring out the synchronization with respect to Pre-cog
implementation.

Jay Prakash



On Mon, Jun 17, 2013 at 12:43 AM, John Malsbury john.malsb...@ettus.comwrote:

 how can i make the usrp send its time when configured for
 synchronization?

 I might be misunderstanding the question, but here's an answer.  The USRP
 source outputs stream tags on the first sample when streaming.  The three
 tags are 1) rx_time 2) rx_rate 3)  frequency.  Using (1) and (2), you
 should be able to determine and track the time of the USRP.

 You would use set_command_time for anything with commands - gpio, tuning,
 etc.  This is in the control plane. You do timed bursts in the data plane
 with stream tags - tx_sob, tx_time, tx_eob.

 If these terms are foreign to you, Google introduction to stream tags by
 Tom R.

 -John


 On Sun, Jun 16, 2013 at 12:02 PM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 I think i can use set_command_time (which i guess set the next time of
 transmission/command?).
 how can i make the usrp send its time when configured for synchronization?

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:58 PM, John Malsbury 
 john.malsb...@ettus.comwrote:

 XML_RPC block in the new gr-extras

 XML_RPC would have been subject to the same limitations.  It could only
 call set_time_next_pps if set_time_next_pps was in the uhd_sink/source
 blocks.  Maybe you can update them to include the function.

 Let me ask a more fundamental questions - why do you want to reset the
 time?

 -John


 On Sun, Jun 16, 2013 at 11:20 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 so do we have any other block to do that. I did'nt find XML_RPC block
 in the new gr-extras


 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
  http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:43 PM, Adeel Anwar adeela...@gmail.comwrote:

  so i checked the new grextras wiki it has uhd_control block i guess
 that can be used for this job.
 uhd_control block  supports only a subset of usrp-functions (exposed
 through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
 currently it doesn't support set_time_now()

 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp

 -Adeel


 On Sun, Jun 16, 2013 at 11:06 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 thanks for the clarification
 so i checked the new grextras wiki it has uhd_control block i guess
 that can be used for this job.

 Jay Prakash
 Senior Undergraduate
 Electronics Engineering
 IIT (BHU)
 VARANASI

 +91-9559475258
 http://about.me/jay.prakash/
 http://www.linkedin.com/profile/view?id=91120191trk=hb_tab_pro_top




 On Sun, Jun 16, 2013 at 11:05 PM, John Malsbury 
 john.malsb...@ettus.com wrote:

 The GPSDO can provide an internal 10 MHz/1 PPS signal.  I'm not
 sure if that's what you meant or not:
 https://www.ettus.com/product/details/GPSDO-KIT

 AFIAK, you cannot set the time of a USRP with a message. You may be
 able to use the XML_RPC block in gr-extras to call the function if it is
 exposed through gr-uhd.

 -John


 On Sun, Jun 16, 2013 at 10:30 AM, Jay Prakash 
 jay.prakash.ec...@itbhu.ac.in wrote:

 how can we set the time of usrp by sending it message. I know there
 are function to (usrp.set_time_now()) do this from from top block 
 variable
 but can this be done by sending message at usrp port .
 We can give internal reference signal of 10MHz  but is there also a
 way to give pps signal internally i.e. without using any external 
 hardware.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 

Re: [Discuss-gnuradio] clock synchronization by message passing

[Josh Blum]

On 06/16/2013 02:13 PM, Adeel Anwar wrote:
 so i checked the new grextras wiki it has uhd_control block i guess that
 can be used for this job.
 uhd_control block  supports only a subset of usrp-functions (exposed
 through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
 currently it doesn't support set_time_now()
 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp
 

I didnt add every possible setting. But I am happy to add more on
request! I'm gathering that someone would like to make a configuration
and control block that could perform the synchronization tasks w/ a
GPSDO or some external clock and time source.

The intention of the UHDControlPort block was to help clean up much of
the messy control logic in pre-cog. We were passing messages into a
python block that was executing python functions onto the flowgraph.
Sure it worked though :-) But now there is an API to do configuration
and control nicely.

My intention with the UHDControlPort was to allow for frequency hopping
control in a programatic way (and other stuff too). The UHDControlPort
block uses the property interface to expose device properties that can
be set by another entity -- like some sort of configuration block.
https://github.com/guruofquality/gras/wiki/Properties

So lets say the control block intended to frequency hop and perform a
new transmission:

1) This control block would find the UHDControlPort in the element tree
(you would probably do this once in the notify_active() callback).

2) The control block calls
uhd_control_block-set(command_time, t0);
uhd_control_block-set(tx_freq, new_freq);

3) The control block now causes a time-tagged message to be sent to the
transmit chain. control_block - packet_framer - modulator - usrp_sink
The time of the transmission would be t0 + some delta to allow the
command of tuning the frontend to have settle time.

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[Josh Blum]

On 06/16/2013 10:44 PM, Josh Blum wrote:
 
 
 On 06/16/2013 02:13 PM, Adeel Anwar wrote:
 so i checked the new grextras wiki it has uhd_control block i guess that
 can be used for this job.
 uhd_control block  supports only a subset of usrp-functions (exposed
 through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
 currently it doesn't support set_time_now()
 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp

 
 I didnt add every possible setting. But I am happy to add more on
 request! I'm gathering that someone would like to make a configuration
 and control block that could perform the synchronization tasks w/ a
 GPSDO or some external clock and time source.
 

OK, exposed access to time source, clock source, and time registers. Use
it in good health!

https://github.com/guruofquality/grextras/commit/341f351159961acc0bb6e46402e9ed28d618cd64

-josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] clock synchronization by message passing

[Adeel Anwar]

Josh,

I didnt add every possible setting. But I am happy to add more on
request! I'm gathering that someone would like to make a configuration
and control block that could perform the synchronization tasks w/ a
GPSDO or some external clock and time source.

I think it will also be very useful to add set_rate()  get_rate. This
will help in dynamic re-configuration of Tx-RX Bandwidth to/from USRP.
USRP source/sink blocks already generates a tag on sampling-rate change .

Thanks,
   Adeel


On Mon, Jun 17, 2013 at 8:40 AM, Josh Blum j...@joshknows.com wrote:



 On 06/16/2013 10:44 PM, Josh Blum wrote:
 
 
  On 06/16/2013 02:13 PM, Adeel Anwar wrote:
  so i checked the new grextras wiki it has uhd_control block i guess
 that
  can be used for this job.
  uhd_control block  supports only a subset of usrp-functions (exposed
  through gr-uhd) e.g. set_command_time, set/get_gain/freq etc BUT
  currently it doesn't support set_time_now()
 
 https://github.com/guruofquality/grextras/blob/master/lib/uhd_control_port.cpp
 
 
  I didnt add every possible setting. But I am happy to add more on
  request! I'm gathering that someone would like to make a configuration
  and control block that could perform the synchronization tasks w/ a
  GPSDO or some external clock and time source.
 

 OK, exposed access to time source, clock source, and time registers. Use
 it in good health!


 https://github.com/guruofquality/grextras/commit/341f351159961acc0bb6e46402e9ed28d618cd64

 -josh

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock Sync Problems + Timestamp question

[Tim Pearce]

Hi,

I've been trying to get two USRP2's with their clocks both synced to a 10MHz
reference (for now the same reference from the back of some test equipment)
- to do this I'm using the following code:

in_pipe1=usrp2.source_32fc('eth0')
in_pipe2=usrp2.source_32fc('eth2')

in_pipe1.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)
in_pipe2.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)

As a quick test I then connected each usrp2 to a complex oscilloscope (i.e
scopesink2.scope_sink_c)

This sort of works -- checking on the test clock pins on each USRP2 the
100MHz clocks are locked.

Unfortunately putting in a sine wave from a lab sig gen garbage is seen -- a
constant DC signal on the BasicRX and what looks like modulated noise on the
DBSRX (testing at different frequencies on both boards) -- the signal looks
as expected if the config_mimo line is commented (and the usrp2's
restarted).

Am I missing something obvious?

Both USRP's have the latest compiled firmware I could find (11370). We're on
a svn version from a few months ago due to the old short packet problem --
could this be the issue though it seems more hardware-y as from reading the
firmware code all that command should do is change one of the output
registers on the microprocessor?



I'm also trying to attach the timestamp data do each sample -- as far as I
can tell this is sent to give the sample timestamp for the first sample in
each ethernet frame (then incremented by 1 for each subsequent sample in the
frame)

I think I have to create a new C++ block based on USRP2_SOURCE_32FC() to
define a second output stream and connect the rx-metadata::timestamp (which
is a uint32) to this output -- is this correct or can I access the data
within a custom (or current) block further down the line somehow already?

Thanks in advance,

Tim
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

[Matt Ettus]

Tim Pearce wrote:

Hi,

I've been trying to get two USRP2's with their clocks both synced to a 
10MHz reference (for now the same reference from the back of some test 
equipment) - to do this I'm using the following code:


in_pipe1=usrp2.source_32fc('eth0')
in_pipe2=usrp2.source_32fc('eth2')
   
in_pipe1.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)

in_pipe2.config_mimo(usrp2.MC_WE_LOCK_TO_SMA)

As a quick test I then connected each usrp2 to a complex oscilloscope 
(i.e scopesink2.scope_sink_c)


This sort of works -- checking on the test clock pins on each USRP2 the 
100MHz clocks are locked.


Unfortunately putting in a sine wave from a lab sig gen garbage is seen 
-- a constant DC signal on the BasicRX and what looks like modulated 
noise on the DBSRX (testing at different frequencies on both boards) -- 
the signal looks as expected if the config_mimo line is commented (and 
the usrp2's restarted).


Am I missing something obvious?



There is no frequency which can be received by both the BasicRX and the 
DBSRX.  What frequency are you putting in?  What frequency are you 
telling the USRP2s to tune to?


Matt



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

[Douglas Geiger]

On Tue, Oct 20, 2009 at 12:20 PM, Tim Pearce timothy.pea...@gmail.com wrote:

 I'm also trying to attach the timestamp data do each sample -- as far as I
 can tell this is sent to give the sample timestamp for the first sample in
 each ethernet frame (then incremented by 1 for each subsequent sample in the
 frame)

 I think I have to create a new C++ block based on USRP2_SOURCE_32FC() to
 define a second output stream and connect the rx-metadata::timestamp (which
 is a uint32) to this output -- is this correct or can I access the data
 within a custom (or current) block further down the line somehow already?

 Thanks in advance,

 Tim


One thing to keep in mind: the timestamp increments at the FPGA's
clock (100Mhz), so depending on your decimation you'd be incrementing
at some multiple of that for each sample on the host. You are correct
in that you need a custom version of the source block to pass along
timestamps with each sample.
 Doug

-- 
Doug Geiger
doug.gei...@bioradiation.net


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

[Tim Pearce]

 There is no frequency which can be received by both the BasicRX and the
 DBSRX.  What frequency are you putting in?  What frequency are you telling
 the USRP2s to tune to?

 Matt


Hi,

Sorry I probably confused things by mentioning the BasicRX

DBSRX is the only receiver we have 2 of at the moment so I was testing with
a 2 GHz Sine wave, tuning the USRP2 to 2GHz and setting decim to 50.

The problem was seen on both usrp2's after enabling the 10MHz ref lock.

Before enabling the ref lock the sine wave appeared on the oscilloscope as
expected.

I tried one USRP2 with the BasicRX just to check the same problem was
appearing -- a 25MHz and 150MHz signal were tested (same decim and tuning to
the frequency the sig gen is generating on). Both frequencies looked correct
on the scope sink until the program was run with the clock locked to the
reference in. - the symptom was slightly different (appearing as a DC signal
rather than noise) which is why I mentioned.

Thanks,

Tim
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

[Matt Ettus]

Tim Pearce wrote:




There is no frequency which can be received by both the BasicRX and
the DBSRX.  What frequency are you putting in?  What frequency are
you telling the USRP2s to tune to?

Matt


Hi,

Sorry I probably confused things by mentioning the BasicRX

DBSRX is the only receiver we have 2 of at the moment so I was testing 
with a 2 GHz Sine wave, tuning the USRP2 to 2GHz and setting decim to 50.


The problem was seen on both usrp2's after enabling the 10MHz ref lock.



When you lock the reference of the USRP2, it will be exactly on 2 GHz. 
So if you put in a 2 GHz sine wave which is also locked to the same 
reference or locked to something very close, it will also be at exactly 
2 GHz.  Thus, when it is downconverted to baseband, it will be at DC, 
and will be removed by the DC offset correction.  Everything is 
functioning exactly as it should.



Before enabling the ref lock the sine wave appeared on the oscilloscope 
as expected.


That is because without the ref lock you will have some frequency error, 
and the signal won't be on exactly 2 GHz.




I tried one USRP2 with the BasicRX just to check the same problem was 
appearing -- a 25MHz and 150MHz signal were tested (same decim and 
tuning to the frequency the sig gen is generating on). Both frequencies 
looked correct on the scope sink until the program was run with the 
clock locked to the reference in. - the symptom was slightly different 
(appearing as a DC signal rather than noise) which is why I mentioned.


The BasicRX has no DC offset correction, so you will see a DC level, 
which is exactly what you are asking for.


I think that what you really want is to tune the USRP2 and the sig gen 
to different frequencies.


Matt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Clock Sync Problems + Timestamp question

[Tim Pearce]

Ah! The 10MHz was coming out the back of the siggen so would have been
locked to the same reference.

Thanks for your help Doug/Matt -- next time I'll stop and think through my
test setup!

Cheers,

Tim

On Tue, Oct 20, 2009 at 6:16 PM, Matt Ettus m...@ettus.com wrote:

 Tim Pearce wrote:




There is no frequency which can be received by both the BasicRX and
the DBSRX.  What frequency are you putting in?  What frequency are
you telling the USRP2s to tune to?

Matt


 Hi,

 Sorry I probably confused things by mentioning the BasicRX

 DBSRX is the only receiver we have 2 of at the moment so I was testing
 with a 2 GHz Sine wave, tuning the USRP2 to 2GHz and setting decim to 50.

 The problem was seen on both usrp2's after enabling the 10MHz ref lock.



 When you lock the reference of the USRP2, it will be exactly on 2 GHz. So
 if you put in a 2 GHz sine wave which is also locked to the same reference
 or locked to something very close, it will also be at exactly 2 GHz.  Thus,
 when it is downconverted to baseband, it will be at DC, and will be removed
 by the DC offset correction.  Everything is functioning exactly as it
 should.


  Before enabling the ref lock the sine wave appeared on the oscilloscope as
 expected.


 That is because without the ref lock you will have some frequency error,
 and the signal won't be on exactly 2 GHz.


 I tried one USRP2 with the BasicRX just to check the same problem was
 appearing -- a 25MHz and 150MHz signal were tested (same decim and tuning to
 the frequency the sig gen is generating on). Both frequencies looked correct
 on the scope sink until the program was run with the clock locked to the
 reference in. - the symptom was slightly different (appearing as a DC signal
 rather than noise) which is why I mentioned.


 The BasicRX has no DC offset correction, so you will see a DC level, which
 is exactly what you are asking for.

 I think that what you really want is to tune the USRP2 and the sig gen to
 different frequencies.

 Matt

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock input level

[Juha Vierinen]

Hi,

What is the voltage level for the USRP external clock? Is 1V peak to
peak ok? I am planning to drive the board using a high accuracy
reference clock.

juha


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] clock

[Zhuocheng Yang]

Hello:

Does anyone know the clock speed of master_clk, serial_clk and tx_clk?
Which one is fastest and which one is slowest?

Leo



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Clock Recovery

[pilla]

Hi, I'm an Italian student and I'm searching for documents concerning Mueller 
Muller clock recovery method used from gnuradio.
Thanks a lot


This message was sent using IMP, the Internet Messaging Program.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio