Compiling OOT modules on WIndows

[Daniele Nicolodi]

Hello,

is there an "easy" way to compile OOT modules on Windows?

I found a couple of old threads on the mailing list describing with
instructions and, unless things got much simpler in recent times, it may
be simpler to convince my colleagues that having a Linux machine in the
lab is not that scary after all :-)

Thank you.

Cheers,
Dan

Re: Windows Installers 3.8.0.0 BETA Available

[Daniele Nicolodi]

Hello Geof,

I tried your binaries of GNURadio 3.8 on Windows 10 and they do not work
for me. None of the executables run on my system: launching any of them
nothing happens. I don't have much experience with developing
applications on Windows, thus I don't know where to look to be able to
report more useful information.

The GNURadio 3.7 binaries work fine.

Thank you.

Cheers,
Dan

On 11-11-2019 19:07, Geof Nieboer wrote:
> All,
> 
> A BETA version of the windows 64-bit installer for GR3.8 is available
> here http://www.gcndevelopment.com/gnuradio/index.htm

[Discuss-gnuradio] How to reference GNU Radio in a scientific paper

[Daniele Nicolodi]

Hello,

some co-workers and I are about to submit to a journal a paper in which
we use GNU Radio (and Ettus SDR) to obtain some of the results we
report.  Is there a canonical way (bibtex entry) to reference GNU Radio
in scientific literature?

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Frequency discriminator using a frequency to voltage converter

[Daniele Nicolodi]

On 09/11/15 13:48, Marcus Müller wrote:
> 
> Since it's a bit of a pain to make beautiful in the email itself, see
> the attached PDF. Here's the text of that:

Hello Marcus,

thank for spending time writing this down, but this is definitely not
the claim I was questioning (I completely agree with this statement).

The claim I was questioning is:

On 06/11/15 19:01, madengr wrote:
> Hmm.. maybe it is.  I have done it in (shudder) LabView and it's nice
> since noise reduces at 1/N instead of 1/sqrt(N); N is number of
> averages.

which does not make any sense to me.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Frequency discriminator using a frequency to voltage converter

[Daniele Nicolodi]

On 06/11/15 19:01, madengr wrote:
> Marcus Müller-3 wrote
>> Hi Lou,
>>
>> that's a pretty good application of the spectrum, I agree. One could
>> certainly modify the freq_sink to do that, however, as it is now, the
>> PSD calculation (based on the fft result) is done in a single VOLK
>> kernel, 32fc_s32f_x2_power_spectral_density_32, which probably has some
>> performance advantages, so changing that would mean to either abandon
>> that benefit or introduce a new "processing path" inside the frequency
>> sink.
>>
>> I'm a bit confused, though: The DFT is a linear operation. So averaging
>> k FFT vectors (linear operation) before or after the DFT wouldn't make a
>> difference, because
>>
>> $\sum_{n=1}^k \mathrm{DFT}(x_n) = \mathrm{DFT}(\sum_{n=1}^k x_n)$, with
>> $x_n$ being our DFT length-sized input sample vectors.
>>
>> You should be able to do $\sum_{n=1}^k x_n$ with a stream to vector->add
>> block combination in front of the normal frequency sink.
>
> Hmm.. maybe it is.  I have done it in (shudder) LabView and it's nice since
> noise reduces at 1/N instead of 1/sqrt(N); N is number of averages.  Maybe
> I'll try it tonight with just discrete blocks to compare them side by side. 
> Just something that can't be done with a normal spectrum analyzer.

Why does that hold true?

I don't think it is possible, at least in the general case.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] isolate channels from wideband

[Daniele Nicolodi]

On 22/07/15 15:40, Tom Rondeau wrote:
> On Wed, Jul 22, 2015 at 4:57 AM, Daniele Nicolodi  <mailto:dani...@grinta.net>> wrote:
> 
> On 21/07/15 21:39, Tom Rondeau wrote:
> > Here's my presentation from last GRCon:
> >
> > http://gnuradio.squarespace.com/grcon14-presentations#tut-rondeau
> 
> Hello Tom,
> 
> browsing through your presentation I see that on page 58 and 59 you
> recommend to use firdes filter design tool and not optfir to build re
> reconstruction filter.  However, I don't quite understand why the filter
> generated by one tool is better than the other is this case.
> 
> Can you please comment on it?
> 
> Thanks! Cheers,
> Daniele
> 
> 
> The shape of this filter matters greatly. The inband, transition, and
> stop band behavior all determine if the filter can be used for the
> reconstruction purposes. The image on slide 59 shows the specific
> transition between the pass band and stop bands. To match that with the
> PM (i.e., Remez) algorithm, you can't get the same stop band performance
> for that given transition. Plus the equal response in the stop band is
> bad when channelizing because all channels will alias at equal powers,
> whereas the roll off in frequency with the windowed (firdes) filter
> continues to decrease with f. Remez also produces a pass band ripple,
> which will also affect things. The ripple with the firdes is not
> equiripple like Remez promises, but it's much, much smaller.


Thanks Tom, very clear explanation.

Cheers,
Daniele


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

[Discuss-gnuradio] TX and RX synchronization to control latency

[Daniele Nicolodi]

Hello,

the recommended way to control latency due to buffers both in software
and hardware is to synchronize the TX and RX streams, namely to have a
mechanism that emits samples only when samples are received, minus a
maximum latency.

My naive solution to implement that is this:

class synchronize(gr.hier_block2):
def __init__(self, fs, delay):
gr.hier_block2.__init__(self, self.__class__.__name__,
gr.io_signature(2, 2, gr.sizeof_gr_complex),
gr.io_signature(1, 1, gr.sizeof_gr_complex))

delay = blocks.delay(gr.sizeof_gr_complex, int(fs * delay))
multiply = blocks.multiply_const_cc(0)
add = blocks.add_cc()
self.connect((self, 0), (add, 0))
self.connect((self, 1), delay, multiply, (add, 1))
self.connect(add, self)

Which is simple enough, but also probably not the most efficient or
elegant way. There is a better way of doing it, other than writing a new
block, probably based on the delay block?

Cheers,
Daniele

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

Re: [Discuss-gnuradio] The RF LO does not support the requested frequency

[Daniele Nicolodi]

On 30/07/15 05:06, Nur Jalaudin wrote:
> hi. i am using ubuntu 14.04 and i am trying run wifi_rx.grc.when i try
> run this wifi_rx.grc it comes out with this:

[snip]

> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 5000.00 MSps
> Actual sample rate: 50.00 MSps

[snip]

> UHD Warning:
> The total sum of rates (50.00 MSps on 1 channels) exceeds the
> maximum capacity of the connection.
> This can cause overflows (O).
> O
 Done
> 
> what should i do. i hope you can help me.

Hello,

what about reading and trying to understand the warning to obtain?

The first warning says that you requested a sampling rate of 5000 MSps,
or 5 GHz (!?!), which is obviously far higher that what the ADC can do,
I believe that there is no ADC that can sample at 5 GSps (if there is
one I would be very interested in getting one). The driver therefore
clamps your sample rate request to 50 MSps (which is the maximum
supported by your hardware).

The second warning is about the data transmission from the USRP (you do
not say, but from this message I believe it is an U2x0, with an USB
connection) to the host computer. The driver warns you that the
requested sampling rate (the 50 MSps from above), while supported by the
acquisition hardware, generates a volume of data that cannot be
transferred through the connection and that this will cause overflows.
Indeed this is what you obtain, as indicated by the 'O' that follows on
the output.

Are you sure you want a sampling rate of 5 GSps?

Cheers,
Daniele


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

Re: [Discuss-gnuradio] isolate channels from wideband

[Daniele Nicolodi]

On 21/07/15 21:39, Tom Rondeau wrote:
> Here's my presentation from last GRCon:
> 
> http://gnuradio.squarespace.com/grcon14-presentations#tut-rondeau

Hello Tom,

browsing through your presentation I see that on page 58 and 59 you
recommend to use firdes filter design tool and not optfir to build re
reconstruction filter.  However, I don't quite understand why the filter
generated by one tool is better than the other is this case.

Can you please comment on it?

Thanks! Cheers,
Daniele


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

[Discuss-gnuradio] Spam from Corgan Labs

[Daniele Nicolodi]

Hello,

it seems that Corgan Labs is scanning the list of the subscribed to this
mailing list to target them with unsolicited email advertising. I fond
this practice extremely annoying and counter-productive.

Can this practice be avoided in the future?

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Generate a specific wave form

[Daniele Nicolodi]

On 02/07/15 15:05, Antonny Caesar wrote:
> I'll send information only if no one else is sending. So, 0/1 will just 
> tell me when I can send my data (0 = I can't; 1 = I can).
> 
> Zero means another person is using the spectrum, so my data will be 
> lost, because that's not my band, I'm just using it for a short period 
> of time.
> One means "free", so I will pass/send my data.
> 
> I need to generate this 0/1 in a random way. That's it. In my 
> application, I'll always have 0 or 1.

Antony, you are starting to repeat yourself in circles. Somehow you are
unable to clearly express what you want to do (not the general concept,
but the fine details of it), which solutions you tries and what problems
you encounter.

Also, it does not help that you ignore the questions of whom is trying
to help you. I'll ask you again: do you mean that you want to "pause"
the transmission or that you want to "mute" the transmission?

It is still not clear where you are encountering problems. From the
above it seems that you do not know how to generate a 0/1 random stream.
Is it that your issue?

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Generate a specific wave form

[Daniele Nicolodi]

On 01/07/15 14:20, Antonny Caesar wrote:
> A primary user might be sending a signal all the time (this is my signal 
> source block). During this event, my Energy Detector will analyse the 
> spectro and pass or not the signal of my primary user (the entire 
> signal, everything that is being sent), because that's what a cognitive 
> radio does. So, when it's possible, I will use the spectro to send a few 
> informations.
> When the spectro is being used (vector = 0, for example), I can't send 
> information, because it would damage the signal of other person. I just 
> want to send data, when the spectro is not being used (vector = 1).

Do you mean that you want to "pause" the transmission or that you want
to "mute" the transmission?

Cheers,
Daniele


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

Re: [Discuss-gnuradio] High Flowgraph Latency in 3.6.4.1

[Daniele Nicolodi]

Hello,

I resurrect this old thread because I'm almost exactly in the situation
described below by Matt but I have an hard time to come up with a solution.

I'm working with an N210. In my application I generate a modulation
signal that is sent to a system and the response of the system is
demodulated and processed. The modulation signal is adjusted accordingly
to the result of this processing.

Because of the modulation-demodulation scheme, I like to keep a constant
phase relation between the tx and rx channels. To this purpose I use
set_start_time() calls for the tx and rx channels. The result of the
signal processing is communicated to the modulation source via
asynchronous messages. The sampling rate for tx and rx is 1.0 MHz.

What I observe is a ~250 ms delay between the asynchronous messages and
changes in the modulation signal. This delay scales linearly with the tx
sampling rate, thus I conclude it is due to buffering on the tx side.

I haven't managed to find a way to route any signal from the rx side to
the tx side without causing buffer under-runs, I think because the start
time of the tx and rx sides are fixed.

Does anyone has an idea on how to solve the problem?


On 17/10/14 19:16, Matt Ettus wrote:
> We see this issue a lot with applications that only transmit, and which
> transmit continuously.  The problem is that you end up generating
> samples far in advance of when you really know what you want to
> transmit, because there is no rate-limiting on the production side.
> 
> Some general principles -- Large buffers *allow* you to deal with high
> latency.  Large buffers do not *create* high latency unless the
> application is not designed properly.  A properly designed application
> will work with infinitely large buffers as well as it does with
> minimally sized ones.
> 
> Shrinking buffers may allow your application to work, but that isn't
> really the best way to solve this problem.  The best way to solve the
> problem is to modify your head-end source block to understand wall-clock
> time.  The easiest way to do that if you are using a USRP is to
> instantiate a UHD source (i.e. a receiver) at a relatively low sample
> rate and feed it into the source you have created.  
> 
> Your source block should then look at timestamps on the incoming samples
> (it can throw the samples themselves away).  It should generate only
> enough samples to cover the maximum latency you want, and it should
> timestamp those transmit samples.  For example, if it receives samples
> timestamped with T1, it should generate samples with timestamps from
> T1+L1 to T1+L1+L2, where L1 is the worst-case flowgraph and device
> latency, and L2 is the worst case reaction time you are looking for. 
> Thus, if you suddenly get a message from your operator to send a
> message, you know that you will never need to wait for more than L2
> seconds.  Thus, you can bound your worst case reaction time.
>
> I think we should generate an example app to do this, because the issue
> comes up periodically, especially among the space communications crowd. 
> It is a design pattern we really should document.


Any news about this example app?

Thank you! Cheers,
Daniele



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

Re: [Discuss-gnuradio] How to control latency

[Daniele Nicolodi]

Hello Marcus,

I went looking at the code and I found this:

d_fftsize = (int) (2 * pow(2.0, ceil(log(double(ntaps)) / log(2.0;
d_nsamples = d_fftsize - d_ntaps + 1;
set_output_multiple(d_nsamples);

which I'm not sure I understand, but is in agreement with what I
observe. Can someone explain the reason of the subtraction in line two
of the above code snippet?

Thanks. Cheers,
Daniele


On 13/05/15 18:45, Marcus Müller wrote:
> Hi Daniele,
> 
> alignment requirements for the FFTw aren't that strict, but you'll have
> to wait for a decimation*ntaps of samples to accumulate before you can
> do the FFT.
> 
> Greetings,
> Marcus
> 
> On 05/13/2015 05:47 PM, Daniele Nicolodi wrote:
>> On 01/04/15 00:30, Matt Ettus wrote:
>>> Daniele,
>>>
>>> GNU Radio tries to maximize the size of the chunks of data it deals
>>> with.  Clearly that works well for high rate data, but not low rate
>>> data.  There are some handles to control buffer sizes and things within
>>> GNU Radio, but you may have better luck just using a much higher sample
>>> rate.  If you just decimate less, and have a sample rate of about 10 kHz
>>> you won't have this problem.  You'll use more CPU, but it will still be
>>> a tiny amount.
>> Hello Matt,
>>
>> thank for your answer. Sorry if I come back to this so late.
>>
>> The low samples rate are unfortunately necessary in my application, or I
>> don't know how to avoid them.  What I'm implementing is a control loop
>> and the communication with the actuator is rather slow (commands send
>> through a RS232 connection).
>>
>> However, I found where the problem was coming from: I was using gnuradio
>> fft filter implementation, and it looks like that this block has a
>> minimum number of output elements that increases rapidly with increasing
>> number of taps.  I suspect this is due to alignment requirements of the
>> underlying fftw library, but I haven't check that. Indeed, using higher
>> hardware sampling rates required longer filters and made things worst.
>>
>> Switching from fft filter to simple fir filter blocks, the problem of
>> too large buffers goes away and at those modest sampling rates the
>> higher computational cost is not a problem.
>>
>> Cheers,
>> Daniele
>>
>>
>> ___
>> 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] How to control latency

[Daniele Nicolodi]

On 01/04/15 00:30, Matt Ettus wrote:
> 
> Daniele,
> 
> GNU Radio tries to maximize the size of the chunks of data it deals
> with.  Clearly that works well for high rate data, but not low rate
> data.  There are some handles to control buffer sizes and things within
> GNU Radio, but you may have better luck just using a much higher sample
> rate.  If you just decimate less, and have a sample rate of about 10 kHz
> you won't have this problem.  You'll use more CPU, but it will still be
> a tiny amount.

Hello Matt,

thank for your answer. Sorry if I come back to this so late.

The low samples rate are unfortunately necessary in my application, or I
don't know how to avoid them.  What I'm implementing is a control loop
and the communication with the actuator is rather slow (commands send
through a RS232 connection).

However, I found where the problem was coming from: I was using gnuradio
fft filter implementation, and it looks like that this block has a
minimum number of output elements that increases rapidly with increasing
number of taps.  I suspect this is due to alignment requirements of the
underlying fftw library, but I haven't check that. Indeed, using higher
hardware sampling rates required longer filters and made things worst.

Switching from fft filter to simple fir filter blocks, the problem of
too large buffers goes away and at those modest sampling rates the
higher computational cost is not a problem.

Cheers,
Daniele


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

[Discuss-gnuradio] How to control latency

[Daniele Nicolodi]

Hello,

I have a system where I acquire a signal through an Ettus N210 at 200
kHz and I process it through a few GNURadio blocks. Those blocks include
a first low pass filtering and decimation to 1 kHz sampling rate and
further resampling down to 10 Hz or so.

In this configuration the output samples are delivered to the last block
of the flow-graph bunched in packets so that a packet is received every
3 seconds.

This does not seem to depend on the last resampling neither on the
maximum buffer site (set calling `tb.run(size)` where `tb` is the top
block of the flow-graph). I also tried to change the UHD frame size with
the `recv_frame_size`, but it had no effect on the latency.

As I'm trying to implement a control loop, I would like to obtain data
at a real 10 Hz rate from my last block. I think the system should be
able to handle the computing overhead just fine.

How can I accomplish this?

Thank you. Cheers,
Daniele


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

Re: [Discuss-gnuradio] Definition of "radians per sample"

[Daniele Nicolodi]

Hello Mohamed,

I didn't consider the difference between baseband and passband bw, but
isn't the difference by a factor two going in the wrong direction here?

If I assume that the PLL blocks want the bw defined as passband, when I
get the signal out of the PLL blocks at baseband, I should see a bw that
is half of the one I specified at passband, not twice it.

If I assume that the PLL blocks want the bw defined as baseband, I
should see no difference in bw.

I'm still puzzled.

Cheers,
Daniele


On 25/03/15 15:25, Mohamed ABOUZRAR wrote:
> Hi Daniele,
> 
> I'm quite sure that there is a miss understanding of  the bandwidth
> notion here,
> Your first formula is certainly the right known one, so make sure you
> use the baseband bandwidth, which is equal to half passband bw.
> hope that helps.
> 
> Regards,
> Mohamed
> 
> 
> 
> On Wed, Mar 25, 2015 at 2:09 PM, Daniele Nicolodi  <mailto:dani...@grinta.net>> wrote:
> 
> Hello,
> 
> the documentation for the PLL blocks in GNURadio says: "All settings
> max_freq and min_freq are in terms of radians per sample, NOT HERTZ."
> 
> Therefore I thought that to specify a bandwidth `bw` it would have to
> converted from natural frequency units (Hz) into radians per sample with
> something like:
> 
> bw_rad_per_sample = bw * 2*pi / sampl_rate
> 
> where `sampl_rate` is of course the sampling rate in Hz.
> 
> However, looking at the PSD of the input and outputs to the PLL blocks,
> it looks like my understanding is wrong and that the bandwidth should be
> computed as
> 
> bw_rad_per_sample = bw * pi / sampl_rate
> 
> which differs from the former by a factor of 2.
> 
> Is the documentation right, and my understanding of it wrong, or the
> documentation is wrong?  In the former case, I think it would be better
> to clarify it a bit.
> 
> Thanks! Cheers,
> Daniele
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> -- 
> /*MSc, Supélec,*/
> /*Ingénieur d'Etat, INPT.*/


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

[Discuss-gnuradio] Definition of "radians per sample"

[Daniele Nicolodi]

Hello,

the documentation for the PLL blocks in GNURadio says: "All settings
max_freq and min_freq are in terms of radians per sample, NOT HERTZ."

Therefore I thought that to specify a bandwidth `bw` it would have to
converted from natural frequency units (Hz) into radians per sample with
something like:

bw_rad_per_sample = bw * 2*pi / sampl_rate

where `sampl_rate` is of course the sampling rate in Hz.

However, looking at the PSD of the input and outputs to the PLL blocks,
it looks like my understanding is wrong and that the bandwidth should be
computed as

bw_rad_per_sample = bw * pi / sampl_rate

which differs from the former by a factor of 2.

Is the documentation right, and my understanding of it wrong, or the
documentation is wrong?  In the former case, I think it would be better
to clarify it a bit.

Thanks! Cheers,
Daniele

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

[Discuss-gnuradio] PLL blocks parameters units

[Daniele Nicolodi]

Hello,

the documentation for the PLL blocks in GNURadio says: "All settings
max_freq and min_freq are in terms of radians per sample, NOT HERTZ."

Therefore I thought that to specify a bandwidth `bw` it would have to
converted from natural frequency units (Hz) into radians per sample with
something like:

bw_rad_per_sample = bw * 2*pi / sampl_rate

where `sampl_rate` is of course the sampling rate in Hz.

However, looking at the PSD of the input and outputs to the PLL blocks,
it looks like my understanding is wrong and that the bandwidth should be
computed as

bw_rad_per_sample = bw * pi / sampl_rate

with a missing factor of 2.

Is the documentation right, and my understanding of it wrong, or the
documentation is wrong?  In the former case, I think it would be better
to clarify it a bit.


Thanks! Cheers,
Daniele

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

[Discuss-gnuradio] Numerical stability and accuracy of PLL blocks

[Daniele Nicolodi]

Hello,

does anyone know if any stability and accuracy evaluation of the digital
PLL as implemented in GNU Radio exist?

I'm trying to measure the frequency of a very low phase-noise signal and
I see strange artifacts for certain combinations of detuning (residual
frequency difference between the signal and the N210 center frequency)
and PLL bandwidth.

I already have re-implemented the PLL blocks to measure phase using a
more accurate arctan2() function than the one provided by Volk (which
uses a linear approximation for small angles) but I still see strange
things that I believe are due to the control loop going nuts due to
numerical problems.

If some work has already been done in this regard I could probably save
some time.

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Phase locked loop

[Daniele Nicolodi]

On 17/03/15 15:08, Marcus Müller wrote:
> Hi Daniele,
> 
>> Also, I don't see why you cannot combine other blocks to realize
>> your own PLL implementation.  Where did you read that you "can’t use
>> companion to add and drop the current available blocks to construct a
>> phase locked loop"?
> Wai Yee has a point here -- you can't have a circle in your (sample
> stream) flow graph -- GNU Radio doesn't allow that for reasons of
> causality.
> 
> You can have a "loose" loop with feedback done with message ports, but
> that's not the same as a control loop (since there's no defined delay
> between the sample for which a error was estimated and the sample where
> the error correction is applied when using the asynchronous messages).
> 
> Thus, you can't drag'n'drop together a "proper" control loop from
> discrete things like adders and integrators  that you could design and
> analyze theoretically.

Hello Marcus,

I realized this while having my coffee this morning. I should avoid to
reply to emails before assuming the right amount of caffeine :)

> In effect, GNU Radio's control loops are monolithic blocks -- that's
> somewhat sad from a modularity perspective, but then again, there's the
> control loop base class that allows you to implement arbitrary control
> loops rather easily

Last time I looked into it, this base class is not that generic: it can
be easily used to implement phase-lock loops, but it did not seem
designed to control other quantities, like amplitude for example. But I
may have had a too quick loot at it.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Phase locked loop

[Daniele Nicolodi]

On 17/03/15 02:05, yee_yy1992 wrote:
> 
> Hi, Currently I am doing my Final Year Project to develop a phase
> measurement using Phase Locked Loop theory. I am using *USRP N210* for
> the hardware and I have installed *Gnuradio Companion* in *Ubuntu 12.04
> LTS* (running in VMplayer). I have studied online that I can’t use
> companion to add and drop the current available blocks to construct a
> phase locked loop.

Hello,

what to you mean by that last sentence? GNURadio comes with PLL blocks
in a few different fashions that can be used from the companion just
fine.  Also, I don't see why you cannot combine other blocks to realize
your own PLL implementation.  Where did you read that you "can’t use
companion to add and drop the current available blocks to construct a
phase locked loop"?

Cheers,
Daniele


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

Re: [Discuss-gnuradio] gr::block::add_item_tag not exposed to Python

[Daniele Nicolodi]

On 02/12/14 15:10, Martin Braun wrote:
> On 12/02/2014 03:01 PM, Daniele Nicolodi wrote:
>> Hello,
>>
>> there is a reason why the gr::block::add_item_tag() method and other
>> methods to operate on stream tags are not available from Python?
>>
>> Should I send a patch to add them to the SWIG class definition?
> 
> They are, see e.g. gr-blocks/python/blocks/qa_block_gateway.py.

Thanks Martin,

SWIG contortions make them hard to find... :)

Cheers,
Daniele



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

[Discuss-gnuradio] gr::block::add_item_tag not exposed to Python

[Daniele Nicolodi]

Hello,

there is a reason why the gr::block::add_item_tag() method and other
methods to operate on stream tags are not available from Python?

Should I send a patch to add them to the SWIG class definition?

Thanks. Cheers,
Daniele

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

[Discuss-gnuradio] Recording external events timestamps

[Daniele Nicolodi]

Hello,

I have an application where I acquire and process data through GNURadio
while I modify some system parameters via slow controls (USB, GPIB, or
network interfaces) handled in a separate python thread.

I would like to be able to relate the data saved by the GNURadio flow
graph execution to the external parameters changes. What is the best way
of achieving this?

I can think to a few possible solutions: one possibility could be to
extract sample timing from the GNURadio data stream at the time of the
parameters change and record it independently, another could be to
inject tags into the GNURadio data stream. In both cases I don't really
know how the implementation would look like.

Ideas?

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

On 28/10/14 11:54, Martin Braun wrote:
> On 10/28/2014 12:58 AM, Daniele Nicolodi wrote:
>> This is to inform you that I'm giving up trying to transition the swig
>> bindings to generate builtin classes. I may revisit this decision if
>> I'll get encouraging answers from swig developers on the swig mailing
>> lists, but I believe this is very unlikely.
>>
>> While the changes to the interface definition files are nominally
>> extremely small, I'm hitting bugs in swig that make the exercise
>> extremely painful and I fear impossible without patching swig itself.
>> I also fear that no matter what I can do, the binding egenrated are
>> going to stay sub-optimal due to intrinsic limitations of swig.
>>
>> I prefer to spent my spare time doing something more rewarding that
>> fighting an under documented, inconsistent, and buggy system.
> 
> Thanks for trying. Can't blame you for being fed up with SWIG.

It is not that I'm fed up, it is simply that SWIG cannot do what I would
like it to do. To help others that may venture down the same route, I
think the decision has to be better circumstanced.

The first road block I encountered is the fact that there is a bug in
SWIG that prevents to mix the -builtin (to enable the generation of
nicer python builtin objects instead of the usual abomination) and the
-keyword parameter (to enable calling the generated methods with keyword
arguments) when wrapping std::vector template instances. The generated
C++ simply does not compile.

Part of the problem comes from the fact that the C++ code SWIG generates
to wrap std::vector uses overloaded methods, and SWIG refuses to enable
keywords arguments for those. From there things are very brittle and
breaks in numerous ways.

By accident I found out that keyword arguments can be enabled and
disabled for specific classes (this is AFAIK undocumented), therefore
the problem could be in principle be circumvented adding some additional
SWIG directives to the interface description files.

The second road block is related to the first: the make() method of many
GNURadio blocks is an overloaded method, and for those SWIG refuses to
enable keywords arguments. For some reason keywords arguments work
anyway when bindings are generated without the -builtin option, but do
not work with it. Looking at the generated C++ code, it seems that
keywords arguments are enabled in some layers of the wrapping code, but
disabled where it matters.

A solution would be to give up the use of keyword arguments to method
calls, but I think this would be loosing a nice feature, just for a
limitation of a stupid tool.

While fixing SWIG is probably non trivial but possible, I don't think
that requiring a very recent SWIG would be accepted by the maintainers.
Therefore I decided to give up, the advantages are not worth fighting.

I prefer investing some times to experiment with the idea of generating
Cython wrappers and drop SWIG completely.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

Hello,

This is to inform you that I'm giving up trying to transition the swig
bindings to generate builtin classes. I may revisit this decision if
I'll get encouraging answers from swig developers on the swig mailing
lists, but I believe this is very unlikely.

While the changes to the interface definition files are nominally
extremely small, I'm hitting bugs in swig that make the exercise
extremely painful and I fear impossible without patching swig itself.
I also fear that no matter what I can do, the binding egenrated are
going to stay sub-optimal due to intrinsic limitations of swig.

I prefer to spent my spare time doing something more rewarding that
fighting an under documented, inconsistent, and buggy system.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

On 20/10/14 14:06, Daniele Nicolodi wrote:
> I'll try to have a branch with my changes ready to review soon, so we
> can talk about something more concrete.

Hello,

a short update on the progress of my branch.  So far I haven't
encountered major problems (the progress is limited by my limited free
time and the long compile times). However, I have hit what seems to be a
major limitation / bug of SWIG.

It seems impossible to use both the builtin and keyword options when
wrapping std::vector template classes.  Using the keyword option with
std::vector spits out a number of warning, but produces code that
compiles, adding the builtin option the code does not compile anymore.

At the beginning I simply dropped the keyword option, but now I hit some
tests that require methods wrapped with it, so I'm investigation what
may be a possible solution / workaround.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

On 20/10/14 13:46, Martin Braun wrote:
> On 10/20/2014 12:16 PM, Daniele Nicolodi wrote:
>>> Having to write .i files for everything would be a nuisance, given that
>>> we mostly got rid of that in 3.7.
>>
>> I don't understand what you mean with this. We have .i files for
>> everything! For out-of-tree modules they are auto-generated by
>> gr_modtool and some parts are hidden behind SWIG macros, but there
>> definitely are .i files for all the classes in GNURadio. It is how SWIG
>> works :)
> 
> No, we barely have any (unless you're using a very old GNU Radio). We
> have top-level .i files which include the actual block header,
> per-in-tree component if that's what you mean. We do *not* need to write
> .i files for every block (and are glad about it :).
> The few modifications we need these days are taken care of by modtool.

Now I see what you mean, but the fact that the .i files are quite small
and mostly auto-generated does not change the fact that we need the .i
files to tell SWIG to generate code for the blocks :)

The .i files for regular GNURadio blocks are not going to change much
with the switch to builtin object classes. The only changes required are
related to providing a __repr__() method because, unfortunately, the
glued on swig type system does not make it possible to have it inherited
from parent classes, at least as far as my understand of SWIG goes.

I'll try to have a branch with my changes ready to review soon, so we
can talk about something more concrete.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

On 20/10/14 11:50, Martin Braun wrote:
> On 10/20/2014 11:19 AM, Daniele Nicolodi wrote:
>> Hello Martin,
>>
>> thank you for reviewing this idea. I'm already working on a branch with
>> the required changes.
>>
>> The required changes are the build flag and some adjustment to the SWIG
>> bindings. With builtin object classes there isn't anymore a python
>> wrapper class therefore it is not possible to fiddle with the class
>> methods at runtime. For example, the __repr__() method cannot be patched
>> in at runtime but needs to be defined in the SWIG interface.
>>
>> So far I have gnuradio-runtime, including pmt, and gr-blocks compiling
>> and I haven't found any major change required and I'm looking for the
>> cleaner way to implement some things. I haven't yet tried to propagate
>> my changes to the other modules.
>>
>> I hope to have a proof of concept ready in the next few days. I'm not
>> familiar with SWIG (and it is not very friendly), so the process of
>> finding the right way of doing things has been mostly a process of try
>> and error.
> 
> Oh, we know what you're talking about :)
> 
> I'm interested what happens when you reach blocks that *do* fiddle with
> SWIG. gr-uhd does this, and in gr-digital with have a couple of tweaks.

I had a look at what gr-uhd does in its python code and it looks like it
mostly corrects for things that could be also solved easily in SWIG.
Worst case what can be done is that the SWIGGed class is renamed (with a
SWIG directive) and at is sub-classed in Python to tweat with it at
will. However, I don't see the need of it so far.

> Having to write .i files for everything would be a nuisance, given that
> we mostly got rid of that in 3.7.

I don't understand what you mean with this. We have .i files for
everything! For out-of-tree modules they are auto-generated by
gr_modtool and some parts are hidden behind SWIG macros, but there
definitely are .i files for all the classes in GNURadio. It is how SWIG
works :)

> Also, I'm very interested in benchmarks. If there's some effort involved
> here, it has to pay off in terms of speed.

I don't think there are any speed advantages for blocks coded in C++,
what can be sped up is instantiation and configuration of the blocks.
The actual work methods are already called in C++ context without Python
overhead, so there is nothing to to gain there.

This is different for blocks coded in Python, but to take advantage of
the improved SWIG wrappers other changes would be required, probably.
There is quite a bit of magic involved at the moment, that can be
probably simplified with better wrappers.

However, I have the feeling that if speed is a goal, SWIG is probably
not the right tool. The code it generates it sub-optimal under many
aspects (starting with the double type system it puts in place: the SWIG
type system somehow glued on top of the Python type system...)

> I'd suggest you open an issue on our tracker, and we take the discussion
> there. I'm hoping that that some people with more SWIG experience can
> chime in here, too.

I'll do.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

Hello Martin,

thank you for reviewing this idea. I'm already working on a branch with
the required changes.

The required changes are the build flag and some adjustment to the SWIG
bindings. With builtin object classes there isn't anymore a python
wrapper class therefore it is not possible to fiddle with the class
methods at runtime. For example, the __repr__() method cannot be patched
in at runtime but needs to be defined in the SWIG interface.

So far I have gnuradio-runtime, including pmt, and gr-blocks compiling
and I haven't found any major change required and I'm looking for the
cleaner way to implement some things. I haven't yet tried to propagate
my changes to the other modules.

I hope to have a proof of concept ready in the next few days. I'm not
familiar with SWIG (and it is not very friendly), so the process of
finding the right way of doing things has been mostly a process of try
and error.

Cheers,
Daniele


On 20/10/14 09:36, Martin Braun wrote:
> Daniele,
> 
> this is interesting. However, I'm not 100% clear about the implications
> this would have (i.e. which changes are necessary). Is it just the build
> flag, and then of course the accompanying limitations listed in the
> manual (those would not be a problem, as far as I can tell)?
> 
> One thing I can say for sure is that it won't be merged into GNU Radio
> 3.7, since it requires a compat bump for SWIG. However, we are planning
> that for 3.8, so this change is not unreasonable.
> 
> This is new to me, and I just gave the manual a quick browse. From that,
> it seems a good idea, but as I said, I can't quite see all the consequences.
> 
> If you could provide a branch with the necessary changes (an incomplete
> proof of concept would be fine, just so we can see what needs to be
> changed), branched off of next, that would be great.
> 
> Thanks for suggesting this!
> 
> Martin
> 
> On 10/15/2014 08:12 PM, Daniele Nicolodi wrote:
>> Hello,
>>
>> I use the vector_source_x and vector_sinc_x blocks quite a lot for
>> testing, debugging and simulations, even with quite large input and
>> output data streams.
>>
>> Therefore I was looking in speeding up the feeding and retrieval of data
>> by implementing the Python buffer interface [0] that permits to exposed
>> data to other components handling uniform vectors of data in a copy-free
>> manner.
>>
>> Investigating how to do that in SWIG I found that [1] the only supported
>> way of doing this is to compile the bindings with the SWIG -builtin
>> option [2] that modifies how the Python bindings are constructed. Making
>> a long story short, the Python class definition is not done anymore in
>> python code, but with a proper Python extension (in a more clean way, IMHO).
>>
>> At first I tried to implement this in an out-of-tree GNURadio module,
>> however I run into problems because SWIG is unable to generate bindings
>> with the -builtin flag for types subclassing from types defined in an
>> extension compiled without the -builtin option (sorry, that reads a bit
>> too convoluted...).
>>
>> There is interest in switching GNURadio over to the -builtin way of
>> generating the bindings? We would gain somehow cleaner bindings, the
>> possibility of populating the Python objects slots to implement specific
>> object behaviors (to get rid of the __repr__() override necessary for
>> each block, and the buffer interface, for example).
>>
>> If there is interest, I can look into providing a patch. A quick test
>> revealed no problems in adding the -builtin option to the makefiles.
>>
>> Thank you for reading all that :-)
>>
>> Cheers,
>> Daniele
>>
>>
>> [0] https://docs.python.org/2.7/c-api/buffer.html
>> [1]
>> http://swig.10945.n7.nabble.com/swig-python-extension-accessing-PyObject-to-implment-pep-3118-revised-buffer-Protocol-td2419.html
>> [2] http://quantlib.org/reposit/docs/swig/Python.html#Python_builtin_types
>>
>> ___
>> 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] Compiling SWIG python bindings with -builtin option

[Daniele Nicolodi]

Hello,

I use the vector_source_x and vector_sinc_x blocks quite a lot for
testing, debugging and simulations, even with quite large input and
output data streams.

Therefore I was looking in speeding up the feeding and retrieval of data
by implementing the Python buffer interface [0] that permits to exposed
data to other components handling uniform vectors of data in a copy-free
manner.

Investigating how to do that in SWIG I found that [1] the only supported
way of doing this is to compile the bindings with the SWIG -builtin
option [2] that modifies how the Python bindings are constructed. Making
a long story short, the Python class definition is not done anymore in
python code, but with a proper Python extension (in a more clean way, IMHO).

At first I tried to implement this in an out-of-tree GNURadio module,
however I run into problems because SWIG is unable to generate bindings
with the -builtin flag for types subclassing from types defined in an
extension compiled without the -builtin option (sorry, that reads a bit
too convoluted...).

There is interest in switching GNURadio over to the -builtin way of
generating the bindings? We would gain somehow cleaner bindings, the
possibility of populating the Python objects slots to implement specific
object behaviors (to get rid of the __repr__() override necessary for
each block, and the buffer interface, for example).

If there is interest, I can look into providing a patch. A quick test
revealed no problems in adding the -builtin option to the makefiles.

Thank you for reading all that :-)

Cheers,
Daniele


[0] https://docs.python.org/2.7/c-api/buffer.html
[1]
http://swig.10945.n7.nabble.com/swig-python-extension-accessing-PyObject-to-implment-pep-3118-revised-buffer-Protocol-td2419.html
[2] http://quantlib.org/reposit/docs/swig/Python.html#Python_builtin_types

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

Re: [Discuss-gnuradio] Sub-classing a block defined in an _impl class

[Daniele Nicolodi]

On 10/10/14 14:29, Daniele Nicolodi wrote:
> I copied the _impl definition, however, I would prefer to do not copy
> the interface definition, therefore I defined my block as follows:
> 
> namespace gr {
>   namespace baz {
> 
> class BAZ_API pll_carriertracking_cc
>   : public gr::analog::pll_carriertracking_cc
> {
> public:
>   typedef boost::shared_ptr sptr;
>   static sptr make(float loop_bw, float max_freq, float min_freq);
> };
> 
>   } // namespace baz
> } // namespace gr
> 
> Then I copied the definition of the pll_carriertracking_cc_impl class
> implementation into my project and changed it where I wanted.
> 
> However, in this way, swig is not happy:

It seems to be a limitation of SWIG (which I don't know much, so I may
still be doing something wrong). If I define a virtual method in the
definition of my block interface, SWIG generates the correct C++ code.

I ended up adding a definition for the work() virtual method to fix the
issue. Again, not the most elegant thing to do, but it works...

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Sub-classing a block defined in an _impl class

[Daniele Nicolodi]

On 10/10/14 12:30, Sylvain Munaut wrote:
> Hi,
> 
>> There
>> is way to achieve this without copying around significant portions of code?
> 
> No, you'll need to copy the _impl

Ok. Thanks for confirming my understanding.

I copied the _impl definition, however, I would prefer to do not copy
the interface definition, therefore I defined my block as follows:

namespace gr {
  namespace baz {

class BAZ_API pll_carriertracking_cc
  : public gr::analog::pll_carriertracking_cc
{
public:
  typedef boost::shared_ptr sptr;
  static sptr make(float loop_bw, float max_freq, float min_freq);
};

  } // namespace baz
} // namespace gr

Then I copied the definition of the pll_carriertracking_cc_impl class
implementation into my project and changed it where I wanted.

However, in this way, swig is not happy:

 src/gr-baz/swig/baz_swigPYTHON_wrap.cxx: In function 'PyObject*
_wrap_new_pll_carriertracking_cc(PyObject*, PyObject*)':
 /home/manip/src/gr-baz/swig/baz_swigPYTHON_wrap.cxx:11071:87: error:
cannot allocate an object of abstract type 'gr::baz::pll_carriertracking_cc'
result = (gr::baz::pll_carriertracking_cc *)new
gr::baz::pll_carriertracking_cc();


But if I copy the definition of my block from the GNURadio definition,
swig is happy, the compilation goes fine, and I can correctly use the
block from Python.

What am I doing wrong?  Sorry if this is a trivial C++ error, but my C++
is definitely rusty...

Thanks!

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Sub-classing a block defined in an _impl class

[Daniele Nicolodi]

On 10/10/14 12:25, Johannes Demel wrote:
> _impl classes are not meant to be subclassed usually.
> GR distinguishes between interface or public headers, which are
> located in the include directory and private headers which are located
> in the lib directory.
> You can just add new classes to your lib folder and use them within
> this folder. But if you want to export these classes and make them
> accessable from Python, you need a public header for it.

That was my understanding. What I still don't understand is why things
are done in this way.

> On 10.10.2014 12:03, Daniele Nicolodi wrote:
>> The case at hand is subclassing gr::analog::pll_carriertracking_cc 
>> changing the phase_detector() method to use the regular atan2()
>> instead of the fast version.
>
> You may just change this in GR directly. You have a personal copy of
> the code so there is nothing that should contradict this approach.
> Unless you want to compare the two but even then you should be able to
> accomplish that.

Changing GNURadio code directly makes is very hard to redistribute my
code, and I would like to retain the possibility to use the original
GNURadio block.

I don't have a problem copying over the code and changing the methods I
want to change, it just does not feel as the most elegant solution.

Cheers,
Daniele

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

Re: [Discuss-gnuradio] Sub-classing a block defined in an _impl class

[Daniele Nicolodi]

Hello Martin,

I'm not sure I understand. Are you saying that there is no way of doing
what I want without copying over to my class the implementation of the
block that is in the _impl class?

Why is this a good thing?

Cheers,
Daniele



On 10/10/14 12:16, Martin Braun wrote:
> You're right -- that's one of the reasons why we try and keep the
> block's guts (their kernels) elsewhere than the actual block definition.
> 
> Not all of our blocks do this, though.
> 
> M
> 
> On 10/10/2014 12:03 PM, Daniele Nicolodi wrote:
>> Hello,
>>
>> this question my arise from my ignorance about C++, but I don't
>> understand how, if it is possible, to sub-class a GNURadio block that
>> has moat of his code in an _impl class.
>>
>> To my understanding I would need to subclass both the class defining the
>> block and his _impl class. However, it seems that the _impl class is not
>> part of the exposed API, therefore there is no way to subclass it. There
>> is way to achieve this without copying around significant portions of code?
>>
>> The case at hand is subclassing gr::analog::pll_carriertracking_cc
>> changing the phase_detector() method to use the regular atan2() instead
>> of the fast version.
>>
>> Thanks!
>>
>> Cheers,
>> Daniele
>>
>> ___
>> 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] Sub-classing a block defined in an _impl class

[Daniele Nicolodi]

Hello,

this question my arise from my ignorance about C++, but I don't
understand how, if it is possible, to sub-class a GNURadio block that
has moat of his code in an _impl class.

To my understanding I would need to subclass both the class defining the
block and his _impl class. However, it seems that the _impl class is not
part of the exposed API, therefore there is no way to subclass it. There
is way to achieve this without copying around significant portions of code?

The case at hand is subclassing gr::analog::pll_carriertracking_cc
changing the phase_detector() method to use the regular atan2() instead
of the fast version.

Thanks!

Cheers,
Daniele

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

[Discuss-gnuradio] Tracking PLL phase error

[Daniele Nicolodi]

Hello,

I'm using the gr::analog::pll_carriertracking_cc() block to track a very
stable signal of which I don't know the exact frequency and of which I
want to detect (small!) phase oscillations.

In my tests I discovered that the tracked signal has a residual phase
modulation that I would not expect to find.  I tried a simple test, very
similar to the qa test for the block, and indeed I found that even for a
constant frequency input signal the output has some residual phase
oscillations. The amplitude of the oscillations depends on the pll
bandwidth and on the frequency of the input signal, of the order of mrad
for this examples (qa_pll_carriertracking.py).

I need to get rid of those oscillations because they mask the phase
signal I want to measure. I'm going to investigate the issue further,
but does anyone have an idea about where those may come from? I suspect
the digital oscillator may introduce some numeric error that may explain
them, but they seem quite big...

Cheers,
Daniele

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

[Discuss-gnuradio] Control loop in GNURadio

[Daniele Nicolodi]

Hello,

I need to implement some control loops as GNURadio blocks, I had a look
at the code base and I found the gr::blocks::control_loop class which,
despite his name is specialized for phase lock loops. Am I missing
something or a general PID control loop implementation does not exist in
GNURadio?

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation

[Daniele Nicolodi]

On 14/08/2014 15:10, Tom Rondeau wrote:
> On Thu, Aug 14, 2014 at 5:15 AM, Daniele Nicolodi  <mailto:dani...@grinta.net>> wrote:
> 
> On 13/08/2014 16:37, Tom Rondeau wrote:
> > The version we have in there is much (MUCH) faster than the libm atan2
> > function. So yes, we trade off a bit of error for a massive
> > computational gain. The error is very small from what I recall, expect
> > in a few instances (near 0 or near pi/2 or something like that).
> Having
> > a graph of the error somewhere would be helpful.
> 
> I think it depends on the point of view, for me it is a bit of
> computational gain for a massive error :)
> 
> You say "massive error", but I've plotted the error between the fast
> atan and the libm atan function before and have not noticed any error to
> be "massive". On the other hand, the "bit" of computational gain is,
> indeed, quite a lot.

I was trying to stress that the speed vs correctness tradeoff should be
evaluated case by case on the base of the requirements and limitations
and that the results of this evaluation may be quite different depending
on the situation.

Indeed in my current project I'm using both the fast atan and the libm
atan to compute different hings in the same flow-graph (for a PLL loop
the linear approximation for small angles is perfectly fine, not so much
for other measurements).

I may have completely wrong expectations, but I'm used to mathematical
functions that, if not specified, return results exact within the
precision of the number representation used.  Any optimization trading
precision for speed should be documented.  I think we agree on that.
The remaining discussion is purely academic :)

Cheers,
Daniele


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

Re: [Discuss-gnuradio] blocks.complex_to_arg() implementation

[Daniele Nicolodi]

On 13/08/2014 16:37, Tom Rondeau wrote:
> The version we have in there is much (MUCH) faster than the libm atan2
> function. So yes, we trade off a bit of error for a massive
> computational gain. The error is very small from what I recall, expect
> in a few instances (near 0 or near pi/2 or something like that). Having
> a graph of the error somewhere would be helpful.

I think it depends on the point of view, for me it is a bit of
computational gain for a massive error :)

> The fast atan method we use is still faster than what we have in VOLK. I
> remember testing this out myself, which included putting that code into
> the constructor. However, take a look at this post:
> 
> http://www.trondeau.com/blog/2012/2/17/volk-benchmarking.html

I don't see anything specific to the atan2() and alignment there.

> We see an improvement in speed of blocks by doing the alignment.
> Actually, I think that all blocks should probably have their alignment
> set whether or not they use VOLK. But that would be a lot of work to do
> correctly with all of our blocks to make sure it's done right and is
> actually giving us a benefit. But having test this one in particular,
> no, I don't see any need to remove this code.

I see. Probably a comment in the code mentioning this, to avoid other
being puzzled, is in order here :)

Cheers,
Daniele


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

[Discuss-gnuradio] blocks.complex_to_arg() implementation

[Daniele Nicolodi]

Hello,

I haven't checked if it is true for the code currently in git (some
network problems here, I cannot access the repository), but in GNURadio
3.7.2 the complex_to_arg() block is implemented with an atan2() function
which has a quite large error (for my purposes, at least) and not the
standard math library atan2() function.

I think that this should be mentioned in the documentation. Should I
send a patch to add this info to the documentation?

Furthermore, even if the block does not use Volk for the computation the
block constructor still enforces alignment of the buffer to satisfy Volk
requirements, or at least this is what I believe the following code does:

  const int alignment_multiple =
volk_get_alignment() / sizeof(float);
  set_alignment(std::max(1,alignment_multiple));

I think this should be removed. Should I send a patch for this as well?

There is interest in adding a complex_to_arg_slow() or similar block
that trades execution speed for precision?

Thanks. Cheers,
Daniele

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

[Discuss-gnuradio] Filter in rational resampler

[Daniele Nicolodi]

Hello,

I was studying the code of the rational resampler block in
gnuradio/gr-filter/pythoin/rational_resampler.py and I have a doubt
about the low pass filter generated by the design_filter() function.

It seems that the generated filter does not take into account the
decimation factor. Is that correct? I don't see how this may result in
the correct anti-aliasing filter when it is applied by
rational_resampler_base_xxx.

Can someone point me to a relevant explanation?

Thanks a lot. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Messages and flow-graph termination

[Daniele Nicolodi]

On 30/07/2014 15:27, Tom Rondeau wrote:
> On Wed, Jul 30, 2014 at 7:50 AM, Daniele Nicolodi  <mailto:dani...@grinta.net>> wrote:
> 
> Hello,
> 
> as soon as I introduce a pair of block publishing and consuming
> messages, the GNURadio scheduler (version 3.7.2) does not terminate the
> execution of the flow-graph when the stream sources signal the end of
> the stream.
> 
> This is also reflected in how the test case qa_python_message_passing
> checks for the termination of the execution.
> 
> Is this by design, is it a known limitation, or is it a bug?
> 
> Cheers,
> Daniele
> 
> 
> Yes, this is a know bug fixed in 3.7.4. See the release notes under
> "Important Bug Fixes and Improvements":
> http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_4

Hello Tom,

thanks, I missed it from the release notes.

There is a known workaround to stop execution of the flow-graph?

Thanks. Cheers,
Daniele


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

[Discuss-gnuradio] Messages and flow-graph termination

[Daniele Nicolodi]

Hello,

as soon as I introduce a pair of block publishing and consuming
messages, the GNURadio scheduler (version 3.7.2) does not terminate the
execution of the flow-graph when the stream sources signal the end of
the stream.

This is also reflected in how the test case qa_python_message_passing
checks for the termination of the execution.

Is this by design, is it a known limitation, or is it a bug?

Cheers,
Daniele

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

Re: [Discuss-gnuradio] Slow control external hardware

[Daniele Nicolodi]

On 29/07/2014 19:29, mle...@ripnet.com wrote:
> There are rather a lot of ways to choke this particular cat, writing a
> block is just one of them.
> 
> I do "control external device" things from within GRC without custom 
> blocks, using "helper code" and a polling function at a low rate
> that drives a simple state machine. I use this for controlling a
> serial device that turns calibration sources on/off. It can get data
> out of the flow-graph if it needs to, with low-rate "probe" blocks.
>
> Some might call this inelegant, I call it saving the headache of
> writing/maintaining custom blocks when the functionality doesn't
> really require real-time access to the sample stream

Hello,

well, writing a block that listens to messages or that emits messages
takes less than 20 lines of python all included.  I would hardly call
this an "headache" to maintain :)

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Slow control external hardware

[Daniele Nicolodi]

On 29/07/2014 16:57, Martin Braun wrote:
> Daniele,
> 
> there's loads of blocks that use messages, as well as manual pages for
> that. And I would recommend you use them for this case. Create a block
> that talks to the serial port, and give it a message port.

Hello Martin,

thank for your answer. Can you please point me to an example of such
blocks from which I can take inspiration? I would like to code it in
python, therefore if a python block that uses the message passing
infrastructure exists, it would be great. Meanwhile I'm going to grep
through the code distribution...

Thanks! Cheers,
Daniele

> 
> M
> 
> On 07/29/2014 02:55 PM, Daniele Nicolodi wrote:
>> Hello,
>>
>> I need to control a RF synthesizer from within a GNURadio flowchart
>> updating some parameters on the base of some measurements obtained from
>> processing data collected by an USRP.
>>
>> The synthesizer is connected through a RS232 serial port, thus is quite
>> slow, but the bandwidth of the control is also very small, < 1Hz. One of
>> the parameters that needs to be controlled is the output power, and it
>> can be adjusted only in discrete steps of 0.01 dB, therefore I need to
>> correctly take care of the discretization.
>>
>> What is the best strategy to do that? Should I simply implement a sink
>> block? Would be better to implement the discretization in a sink block
>> that then sends messages to another block that handles the communication
>> with the synthesizer?
>>
>> As far as my experimentation goes, there are no blocks using messages in
>> the standard GNURadio distribution (version 3.7.2), therefore I don't
>> really have examples of use cases for it.
>>
>> Thanks. Cheers,
>> Daniele
>>
>> ___
>> 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] Slow control external hardware

[Daniele Nicolodi]

Hello,

I need to control a RF synthesizer from within a GNURadio flowchart
updating some parameters on the base of some measurements obtained from
processing data collected by an USRP.

The synthesizer is connected through a RS232 serial port, thus is quite
slow, but the bandwidth of the control is also very small, < 1Hz. One of
the parameters that needs to be controlled is the output power, and it
can be adjusted only in discrete steps of 0.01 dB, therefore I need to
correctly take care of the discretization.

What is the best strategy to do that? Should I simply implement a sink
block? Would be better to implement the discretization in a sink block
that then sends messages to another block that handles the communication
with the synthesizer?

As far as my experimentation goes, there are no blocks using messages in
the standard GNURadio distribution (version 3.7.2), therefore I don't
really have examples of use cases for it.

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Filter design

[Daniele Nicolodi]

On 23/07/2014 14:01, Daniele Nicolodi wrote:
> Hello,
> 
> GNURadio offers three different interfaces to design filters from Python
> code: gnuradio.filter.firdes.xxx, gnuradio.filter.firdes.xxx_2, and
> gnuradio.filter.optfir.xxx.
> 
> The three interfaces use different parameters to specify the filter
> properties, but the only obvious difference is that the optfir is coded
> in python and thus not available to be used elsewhere.
> 
> Which one is recommended to use? Can anyone suggest a reference that
> explains how the filter taps are computed?
> 
> In my data analysis code I usually use Butterworth filters. If there is
> any analogy, how do those map to the filters designed with the above tools?

Partially answering my own questions:

http://gnuradio.squarespace.com/examples/2010/9/12/basic-filtering.html

Cheers,
Daniele


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

[Discuss-gnuradio] Filter design

[Daniele Nicolodi]

Hello,

GNURadio offers three different interfaces to design filters from Python
code: gnuradio.filter.firdes.xxx, gnuradio.filter.firdes.xxx_2, and
gnuradio.filter.optfir.xxx.

The three interfaces use different parameters to specify the filter
properties, but the only obvious difference is that the optfir is coded
in python and thus not available to be used elsewhere.

Which one is recommended to use? Can anyone suggest a reference that
explains how the filter taps are computed?

In my data analysis code I usually use Butterworth filters. If there is
any analogy, how do those map to the filters designed with the above tools?

Thanks. Best,
Daniele

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

Re: [Discuss-gnuradio] Synchronizing N210 TX and RX channels

[Daniele Nicolodi]

Hello Marcus,

I'm aware of that, what I want to achieve at the moment is simply to
have a predictable phase delay between the tx and rx channels. This is
prerequisite to measure the round-trip time and account for it.

Cheers,
Daniele


On 22/07/2014 22:14, Marcus Müller wrote:
> Hi Daniele,
> 
> your problem is actually harder: The latency of digital signal
> processing depends on your desired decimation, and analog signal latency
> depends on a ton of factors like target RF frequency, adjustable filters
> (if your daughterboard has something like this), antenna and cabling
> delay, and so on.
> The only real way to know is to *measure* the roundtrip for each
> configuration, and that's exactly what echotimer is for.
> 
> With best regards,
> Marcus
> 
> On 22.07.2014 19:25, Daniele Nicolodi wrote:
>> Hello Stephan,
>>
>> thank for your reply.  What I would like to do is more simple than that:
>> I need to synchronize tx and rx of the same USRP, not of two different
>> devices.  But I need continuous streaming and not burst.
>>
>> Any help in this direction is much appreciated.
>>
>> Thanks. Best,
>> Daniele
>>
>>
>> On 22/07/2014 19:14, Stefan Wunsch wrote:
>>> Hey Daniele,
>>>
>>> I have done the radar toolbox and implemented a synced USRP interface
>>> (USRP Echotimer).
>>>
>>> You are right, the USRP Echotimer does align the timestamps of the TX/RX
>>> commands on both USRPs. But if you connect them by MIMO, the time and
>>> clock are pretty good in sync. Therefore I think the Echotimer can
>>> provide a sync with an accuracy of at least +- 1 sample. Check out [0]
>>> for a video of the sync. There is also a sync setup for testing
>>> (gr-radar/examples/usrp). Unfortunately the documentation is not
>>> finished yet.
>>>
>>> But care: The Echotimer bursts only a packet in sync, it does not stream
>>> the whole time! The packet is defined by a tagged stream.
>>>
>>> Greetings,
>>> Stefan
>>>
>>> [0]
>>> https://grradar.wordpress.com/2014/06/17/synchronisation-echotimer-usrp-interface/
>>>
>>> Am 22.07.2014 18:40, schrieb Daniele Nicolodi:
>>>> On 22/07/2014 18:18, Martin Braun wrote:
>>>>> On top of what Marcus' has said,
>>>>>
>>>>> the gr-radar toolbox might be helpful. It has a block that takes a
>>>>> tagged stream, and outputs a signal it acquired synchronously to the
>>>>> transmitted one.
>>>> Thanks Martin.  This seems to imply that there is no way to actually
>>>> synchronize the hardware, and that the synchronization can only be done
>>>> in software aligning the timestamps of the two streams. Is that the case?
>>>>
>>>> Thanks. Cheers,
>>>> Daniele
>>>>
>>>>
>>>> ___
>>>> 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] Synchronizing N210 TX and RX channels

[Daniele Nicolodi]

Hello Stephan,

thank for your reply.  What I would like to do is more simple than that:
I need to synchronize tx and rx of the same USRP, not of two different
devices.  But I need continuous streaming and not burst.

Any help in this direction is much appreciated.

Thanks. Best,
Daniele


On 22/07/2014 19:14, Stefan Wunsch wrote:
> Hey Daniele,
> 
> I have done the radar toolbox and implemented a synced USRP interface
> (USRP Echotimer).
> 
> You are right, the USRP Echotimer does align the timestamps of the TX/RX
> commands on both USRPs. But if you connect them by MIMO, the time and
> clock are pretty good in sync. Therefore I think the Echotimer can
> provide a sync with an accuracy of at least +- 1 sample. Check out [0]
> for a video of the sync. There is also a sync setup for testing
> (gr-radar/examples/usrp). Unfortunately the documentation is not
> finished yet.
> 
> But care: The Echotimer bursts only a packet in sync, it does not stream
> the whole time! The packet is defined by a tagged stream.
> 
> Greetings,
> Stefan
> 
> [0]
> https://grradar.wordpress.com/2014/06/17/synchronisation-echotimer-usrp-interface/
> 
> Am 22.07.2014 18:40, schrieb Daniele Nicolodi:
>> On 22/07/2014 18:18, Martin Braun wrote:
>>> On top of what Marcus' has said,
>>>
>>> the gr-radar toolbox might be helpful. It has a block that takes a
>>> tagged stream, and outputs a signal it acquired synchronously to the
>>> transmitted one.
>>
>> Thanks Martin.  This seems to imply that there is no way to actually
>> synchronize the hardware, and that the synchronization can only be done
>> in software aligning the timestamps of the two streams. Is that the case?
>>
>> Thanks. Cheers,
>> Daniele
>>
>>
>> ___
>> 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] Synchronizing N210 TX and RX channels

[Daniele Nicolodi]

On 22/07/2014 18:18, Martin Braun wrote:
> On top of what Marcus' has said,
> 
> the gr-radar toolbox might be helpful. It has a block that takes a
> tagged stream, and outputs a signal it acquired synchronously to the
> transmitted one.

Thanks Martin.  This seems to imply that there is no way to actually
synchronize the hardware, and that the synchronization can only be done
in software aligning the timestamps of the two streams. Is that the case?

Thanks. Cheers,
Daniele


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

Re: [Discuss-gnuradio] Synchronizing N210 TX and RX channels

[Daniele Nicolodi]

On 22/07/2014 17:18, Marcus D. Leech wrote:
> On 07/22/2014 11:14 AM, Daniele Nicolodi wrote:
>> Hello,
>>
>> I would like to synchronize the RX and TX channels on an N210 so that
>> the acquisition and transmission of data are triggered simultaneously.
>> I haven't found documentation on how to do that. Can someone, please,
>> point me in the right direction?
>>
>> Thanks! Cheers,
>> Daniele
>>
> You should probably look at the UHD examples: rx_timed_samples and 
> tx_timed_samples

Thanks Marcus,

but those examples use directly the UHD driver and I have an hard time
understanding how to translate them to use the GNURadio UHD source and
sink blocks.

Are you implying that what I want to do cannot be done with the standard
source and sync blocks and I would have to extend them for my purposes?

Thanks. Cheers,
Daniele


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

[Discuss-gnuradio] Synchronizing N210 TX and RX channels

[Daniele Nicolodi]

Hello,

I would like to synchronize the RX and TX channels on an N210 so that
the acquisition and transmission of data are triggered simultaneously.
I haven't found documentation on how to do that. Can someone, please,
point me in the right direction?

Thanks! Cheers,
Daniele

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

Re: [Discuss-gnuradio] Phase demodulation

[Daniele Nicolodi]

On 03/07/2014 18:41, Bill Dailey wrote:
> Can you explain this a little. I tried that the other night and
> couldn't get it to do anything. I suspect I am setting the bandwidth
> incorrectly or something. I tried that pi/200 - 2pi/100 thing.

Hello Bill,

first, I recommend you to address your replies to the mailing list and
not to me directly, you will have much more chances to receive some
useful answer.

Second, your description of the problem you are encountering is not very
explicative and it makes it very hard to guess what it may go wrong in
your application.

However, the bandwidth setting of the PLL block defines at which offset
frequency from the carrier you are trying to track the gain of the
control loop drops below 1. This affects the PLL capture range: you can
assume that the capture range is equal to the bandwidth, but it depends
on the signal to noise ratio as well.

What you want is to have a bandwidth that is as large as possible but
low enough to do not bleach the modulation you are trying to detect.  I
have absolutely no idea where the recommendation of the pi/200 value
comes from.

The settings for the PLL blocks in GNU radio use the not very intuitive,
but practical for the implementation, unit of rad/sample.  What I do is
to enter formulas that convert value is Hz to rad/sample based on the
sample rate.

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Phase demodulation

[Daniele Nicolodi]

On 27/06/2014 20:51, Daniele Nicolodi wrote:
> This question is not strictly GNURadio related, but I hope to find
> people more knowledgeable than me here...
> 
> I have a signal x(t) at a carrier frequency fc which is phase modulated.
> The phase modulation itself is modulated at a modulation frequency fmod:
> 
>   x(t) = Eo cos(2 pi fc t + m(t))
> 
>   m(t) = Ao cos(2 pi fmod + phi)
> 
> I know exactly fmod (it is a coherent modulation/demodulation
> experiment), and I have a good estimate of fc. I need to, extract
> amplitude Ao and phase phi of that modulation.


Hello,

the solution that I found (and that works very well) is to track the
carrier frequency with a digital PLL.  With the tracking PLL block in
GNURadio it is easy.  GNURadio is fun! :)

Cheers,
Daniele

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

[Discuss-gnuradio] Phase demodulation

[Daniele Nicolodi]

Hello,

This question is not strictly GNURadio related, but I hope to find
people more knowledgeable than me here...

I have a signal x(t) at a carrier frequency fc which is phase modulated.
The phase modulation itself is modulated at a modulation frequency fmod:

  x(t) = Eo cos(2 pi fc t + m(t))

  m(t) = Ao cos(2 pi fmod + phi)

I know exactly fmod (it is a coherent modulation/demodulation
experiment), and I have a good estimate of fc. I need to, extract
amplitude Ao and phase phi of that modulation.

I use an USRP to obtain the in-phase and quadrature component of the
x(t) signal at the carrier frequency.  The naive approach would be then
to extract the phase of x(t) from that and simply demodulate it
multiplying by a complex sine wave ans low pass filtering.

However, the fact that I only have an estimate of the carrier frequency
(and some low Fourier frequency noise on the carrier frequency) means
that I have a linear phase evolution.  This can be taken care with
unwrapping but I quickly end up with a very large phase.

I thought for a while about this but I cannot come up with a solution
that avoids extracting the phase from the I and Q components and doing
unwrapping. I'm sure I'm missing something.

What's the best approach to solve this problem?

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

[Daniele Nicolodi]

On 18/06/2014 01:25, Stephen Harrison wrote:
> There is a good treatment of errors in the CORDIC algorithm due to
> finite word length in this paper from IEEE transactions: The
> Quantization Effects of the CORDIC Algorithm (Yu Hen Hu, Senior Member,
> IEEE). I reproduced the results of section IV fairly easily a while ago.
> There are numerical errors in both amplitude and phase but you are
> right, this is not the cause of the frequency offset you observe. 

Just for the sake of academic discussion (and without having read the
paper): any amplitude error can be seen as a phase error, however in
this specific case I would expect those to have the same periodicity of
the generate sine wave. Therefore they cannot account for a frequency
error. Am I wrong?

Cheers,
Daniele


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

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

[Daniele Nicolodi]

I don't speak Verilog but I get the general gist of the code below.

Thanks. Cheers,
Daniele


On 18/06/2014 01:09, Stephen Harrison wrote:
> The Verilog source for the USRP N210 is available online. You can see
> this in ddc_chain.v:
> 
>   wire [31:0] phase_inc;
>reg [31:0]  phase;
> ...
> 
>setting_reg #(.my_addr(BASE+0)) sr_0
>  (.clk(clk),.rst(rst),.strobe(set_stb),.addr(set_addr),
>   .in(set_data),.out(phase_inc),.changed());
> ...
> 
>// NCO
>always @(posedge clk)
>  if(rst)
>phase <= 0;
>  else if(~ddc_enb)
>phase <= 0;
>  else
>phase <= phase + phase_inc;
> ...
> 
>// CORDIC  24-bit I/O
>cordic_z24 #(.bitwidth(cwidth))
>  cordic(.clock(clk), .reset(rst), .enable(ddc_enb),
>.xi(to_cordic_i),. yi(to_cordic_q), .zi(phase[31:32-zwidth]),
>    .xo(i_cordic),.yo(q_cordic),.zo() );
> 
> 
> 
> 
> On Tue, Jun 17, 2014 at 4:02 PM, Daniele Nicolodi  <mailto:dani...@grinta.net>> wrote:
> 
> Thanks for the answers.
> 
> I didn't think that the sine wave in the FPGA were generated with an
> integer phase accumulator (I don't know much about how signal processing
> is done in FPGAs).  If this is the case, as I understand from Stephen
> email, now I know where the frequency error comes from.
> 
> On the other hand, I think that the fact that the sine is computed via
> the CORDIC method may introduce numerical errors in the amplitude only,
> which would not result in a frequency systematic error.
> 
> Cheers,
> Daniele
> 
> On 18/06/2014 00:43, Stephen Harrison wrote:
> > Just some quick calculations in python:
> >
> > exact phase increment for 10 MHz:
> >
> >>>> (10e6/100e6)*2**32
> > 429496729.6
> >
> > Closest phase increment:
> >
> >>>> np.round((10e6/100e6)*2**32)
> > 429496730.0
> >
> > Resulting frequency:
> >
> >>>> (np.round(10e6/100e6*2**32)/2**32)*100e6
> > 1000.009313226
> >
> > We are out by 9.3mHz!
> >
> >
> > On Tue, Jun 17, 2014 at 3:36 PM, Sylvain Munaut <246...@gmail.com
> <mailto:246...@gmail.com>
> > <mailto:246...@gmail.com <mailto:246...@gmail.com>>> wrote:
> >
> > Hi,
> >
> > > To start I want to characterize the phase noise of the device,
> > therefore
> > > I send to both the RX channel and to the frequency reference
> input the
> > > same 10 MHz signal. I configured the N210 for 200 kHz
> sampling and a
> > > carrier frequency of 10 MHz.
> >
> > The LFTRX doesn't have a tuner so if you set a carrier freq of
> 10 MHz
> > the frequency shift is done by the FPGA via CORDIC and  you'll
> have
> > numerical errors in there. You just can't get rid of them.
> >
> >
> > Cheers,
> >
> >Sylvain
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> <mailto:Discuss-gnuradio@gnu.org <mailto: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] Phase measurement with Ettus Research N210

[Daniele Nicolodi]

Thanks for the answers.

I didn't think that the sine wave in the FPGA were generated with an
integer phase accumulator (I don't know much about how signal processing
is done in FPGAs).  If this is the case, as I understand from Stephen
email, now I know where the frequency error comes from.

On the other hand, I think that the fact that the sine is computed via
the CORDIC method may introduce numerical errors in the amplitude only,
which would not result in a frequency systematic error.

Cheers,
Daniele

On 18/06/2014 00:43, Stephen Harrison wrote:
> Just some quick calculations in python:
> 
> exact phase increment for 10 MHz:
> 
 (10e6/100e6)*2**32
> 429496729.6
> 
> Closest phase increment:
> 
 np.round((10e6/100e6)*2**32)
> 429496730.0
> 
> Resulting frequency:
> 
 (np.round(10e6/100e6*2**32)/2**32)*100e6
> 1000.009313226
> 
> We are out by 9.3mHz!
> 
> 
> On Tue, Jun 17, 2014 at 3:36 PM, Sylvain Munaut <246...@gmail.com
> > wrote:
> 
> Hi,
> 
> > To start I want to characterize the phase noise of the device,
> therefore
> > I send to both the RX channel and to the frequency reference input the
> > same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
> > carrier frequency of 10 MHz.
> 
> The LFTRX doesn't have a tuner so if you set a carrier freq of 10 MHz
> the frequency shift is done by the FPGA via CORDIC and  you'll have
> numerical errors in there. You just can't get rid of them.
> 
> 
> Cheers,
> 
>Sylvain
> 
> ___
> 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] Phase measurement with Ettus Research N210

[Daniele Nicolodi]

Hello Marcus,

thank for your detailed response. Some comments and further questions:

On 17/06/2014 22:04, Marcus Müller wrote:
> The N210 has a fixed master clock rate of 100MHz, generated from the
> 10MHz reference by using PLL controlled clock multipliers.
> The ADC always samples at 100MHz complex,

What do you mean by complex in this context? ADCs saple voltages, which
are a real quantity...

> then passes this 100MS/s
> signal to the FPGA, which then shifts it (if you use an RF frequency
> that cannot be synthesized by the daughterboard in use exactly)
> digitally by multiplying it with a complex sine, lowpasses it to fulfill
> nyquist for your desired sampling rate, and then decimates it. The
> sample stream at your desired rate is then passed on via gigabit ethernet.

Ok, I think that in the case of the LFRX daughter board the signal is
acquired as-it-is and the demodulation is done completely in the FPGA.

> First of all, let's get a relative error estimate: 9.32e-3/10e6 is about
> 1ppb error, which is fantastically low from my point of view; this might
> as well be caused by numerical accuracy in the FPGA, e.g. when shifting
> the signal or decimating it; this is all fixed point arithmetic!

Uhm, this is not a phase accuracy error (which I could maybe agree can
be explained by numerical issues) but a frequency accuracy error: the
phase error adds systematically.

> Then, your 200kHz sampling rate is an odd fraction of 100MHz; try
> 250kHz, to get nicer low pass filtering (I always thought 250kHz was the
> minimum usable sampling rate).

I'll try to see if this makes a difference. The minimum sampling rate I
can program is ~193 kHz (it is a strange fraction that I cannot check
right now).

> Also, how long did you observe your phase drift? To estimate a relative
> error of 1e-9 reliably, you'll need a lot of samples (remember: you
> always have quantization noise in digital systems, so even given perfect
> analog signals and analog components at 0K temperature, you don't get
> infinite SNR).

1e-9 is the relative frequency error: the phase drift is ~58 mrad/s
which is 0.58 rad in 10 seconds and this is very easily accessible.

> Hope that was a little helpful!

It is helpful, thanks. However, I believe that the source of the problem
cannot be finite numerical accuracy.

Given your explanation I believe that the issue may come from finite
accuracy in the generation of the 100 MHz sampling rate: how is the 100
MHz clock generated exactly?  If the 100 MHz clock is divided with a DDS
to be compared to the 10 MHz clock to derive the error signal for the
PLL, the finite precision of the DDS control register may explain the
small frequency error (a 32 bit DDS would introduce the right order of
magnitude effect, but I haven't check the exact number).

Cheers,
Daniele


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

[Discuss-gnuradio] Phase measurement with Ettus Research N210

[Daniele Nicolodi]

Hello,

I'm using an Ettus Research N210 with a LFRX daughter-board to do data
measure the phase of a signals referred to a 10 MHz clock.

To start I want to characterize the phase noise of the device, therefore
I send to both the RX channel and to the frequency reference input the
same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
carrier frequency of 10 MHz.

When I look at the data I obtain, I see a constant phase drift
corresponding to a 9.32 mHz frequency different between the signal I
send to the RX channel and the frequency at which the N210 does the
demodulation.

Given that the signal and the clock are derived from the same oscillator
(in this simple case are the exact same signal), where does this
difference come from? How can I get rid of it?

I imagine it comes from the fact that the ADC sampling frequency is not
an exact multiple of the signal frequency, but I haven't found details
on how the ADC sampling frequency is generated, thus I have no idea
about how to make it an exact multiple of the signal frequency.

Thanks. Cheers,
Daniele

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

Re: [Discuss-gnuradio] Phase unwrapping

[Daniele Nicolodi]

On 16/06/2014 19:47, Michael Berman wrote:
> I have worked on this problem for a specific case as well.  I have a
> document with source code and a short description of what's happening
> that can be found here

Hello Michael,

thank for your example code, but the algorithm is trivial, what I don't
yet know is how to implement it in such a way that it can be used within
the gnuradio framework.  I'm having a look at the documentation now.

Cheers,
Daniele





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

Re: [Discuss-gnuradio] Phase unwrapping

[Daniele Nicolodi]

Hello Matt,

thank for your answer. I'm aware of the problem and in my application I
can keep phase bounded, but not bounded to (-pi, +pi]  therefore I need
unwrapping to make sense of my modulation data.

If such feature does not exist in GNU radio, I hope it is not too hard
to code it myself.

Thanks. Cheers,
Daniele


On 16/06/2014 15:44, Matt Ettus wrote:
> 
> Daniele,
> 
> The problem with phase unwrapping is that it is unbounded, and will tend
> to infinity.  Once it gets very big, when you try to add a small number
> to a very big number, floating point loses precision.  Eventually,
> adding small to extremely big returns the big number unchanged.  This
> isn't that useful.
> 
> Matt
> 
> 
> 
> On Mon, Jun 16, 2014 at 2:40 PM, Daniele Nicolodi  <mailto:dani...@grinta.net>> wrote:
> 
> Hello,
> 
> I just started to work with GNU radio for my very basic needs, so please
> excuse my naive questions and probably my inappropriate use of the
> jargon.
> 
> My first trivial application of GNU radio is to simply measure the phase
> of a phase modulated signal with an Ettus Research USRP N210 and a LFRX
> daughter-board.
> 
> Everything works as expected, but I haven't found a way to do phase
> unwrapping (removing the 2pi ambiguity in the phase obtained from the
> arctan function looking at discontinuities in the phase data). Is this
> functionality offered somewhere, and I missed it, or should I look into
> implementing it myself?
> 
> Thanks. Cheers,
> Daniele
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto: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] Phase unwrapping

[Daniele Nicolodi]

Hello,

I just started to work with GNU radio for my very basic needs, so please
excuse my naive questions and probably my inappropriate use of the jargon.

My first trivial application of GNU radio is to simply measure the phase
of a phase modulated signal with an Ettus Research USRP N210 and a LFRX
daughter-board.

Everything works as expected, but I haven't found a way to do phase
unwrapping (removing the 2pi ambiguity in the phase obtained from the
arctan function looking at discontinuities in the phase data). Is this
functionality offered somewhere, and I missed it, or should I look into
implementing it myself?

Thanks. Cheers,
Daniele

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