Re: Symbol timing estimator block and CPM modulations

[Andy Walls]

Hi Nick:

On Fri, 2020-07-31 at 17:21 -0700, Nick Foster wrote:
> Thanks for the feedback, Andy! I'm back at this now. I've filed a bug
> on it with my findings so far. Comments welcome.
> 
> https://github.com/gnuradio/gnuradio/issues/3678

I've added some comments, some plots, and an Octave script to the issue
on github.

TL;DR:

The original TED from the paper is correct, if computed when shifted by
a 1/4 symbol and the result negated. 

-Andy

Fwd: Clock recovery / Symbol sync of a C4FM / 4FSK Signal

[Andy Walls]

From:   HLL
Date:   Sun, 16 Aug 2020 10:23:06 +0300

> Hello all,
> 
> I Am in the information security industry (so I do not have a signal
> processing background) and I'm trying to properly extract symbols of
> a signal.
> The device that I have access to (and no real internal documentation,
> I'm reverse-engineering it 'from the outside') can be triggered to
> send the data, I do not have access to the internal hardware.
> Also, The product is outside the US, but I think I've managed to find
> a similar device which the data does make sense for.
> 
> Measured Frequency deviation ~600hz (for +1, for +3 1800)

When I look at the difference between symbols where ISI isn't dragging
things towards 0 (i.e. the flat regions), I get levels of +/- 2100 Hz
and +/- 700 Hz, so essentially 1400 Hz between each of the nominal
signal levels.

> FCC: Channel width: 12.5khz, I do not know how to measure it (?)

The spectrum of your input signal shows that it has been filtered to
fit into a 25 kHz channel for sure, with a very steep filter.

There looks to be another narrower stage of filtering (maybe just a
Gaussian pulse filter?)  At the -40 dB down points, the spectrum is
taking up about 13kHz to 14 kHz.  Maybe it's supposed to fit in a
12.5kHz channel, if the specification is for the signal to be only -30
dB down in the adjacent channel.

> FCC: Symbol rate 6kb/s ; I Measured 5900~6010 Sym/s

I estimated about 17 samples/symbol at 100 ksps (~5882.4 symbols/sec)
so 6 kbaud sounds right.  At 2 bits per symbol, that's 12 kbps.
 
> FCC: Modulation 4 Level FSK, (Seems to make sense, see capture)

!t certainly looks like 4 FSK.  The preamble and first few symbols stay
at the +/-3 levels probably to facilitate CFO correction and symbol
timing synchronization.


> Googling, I've found 2 Related things:
> 1. C4FM Demodulator via gnuradio - As it seems, I have almost exact
> modulation, I've tried to change the symbol rate accordingly, but I
> did not get any proper results
> 2. I Have checked out the OOT Blocks that are referenced here, but
> they are for an ancient version of GR; In order to port it I'd have
> to somehow understand both the old and the new version.
> 
> I've scoured the internet trying to understand how to perform this
> task independently while I'm no math expert.
> What I've tried:
> *I tried using various configurations of RRC (as I understood that's
> the filter I should feed into the symbol synchronizer block) I
> somehow manage to configure it in such a way as intended, I believe
> so that the value is that; but do I really need such a filter?

I tried a couple different iterations of an RRC filter with various
bandwidth factors and filter length.  All of them made the ISI worse
not better.  I suspect this data is not RRC filterd on Tx, as I would
expect overshoots in the pulses, that just aren't in your data.


> If I'm not mistaken, the fm-demodulated time domain looks like a
> gaussian filter, not a RRC one.

I tend to agree.  It would be pretty mild though, probably a pretty
high BT


> *Tried using polyphase clock sync (the old version and the 'symbol
> sync' version) with various values, again usually the sampling
> doesn't occur at the best position and slicer can't properly tell
> between +3 and +1 etc) .

The Maximum Likelyhood, small signal approximation TED in the polyphase
clock sync block assumes 2-level pulses, not 4-level.  It's the wrong
tool for the job.

The M TED is designed for mutli-level pulses.  You'll have to use the
one is the symbol sync block, along with a 4-level constellation
object.

Be warned that the GNURadio constellation object autoscales your
constellation so that the symbol levels have a mean magnitude of 1.0. 
(e.g. 4FSK levels would be +/-0.5 and +/-1.5, even though you told the
constellation object +/-1 and +/-3).  I don't particularly like this
"feature" but you have to deal with it.  That means adjusting the gain
of your input burst of pulses so that the excursions match the
constellation object the M TED is using to make symbol decisions.


Also, if just used the quadrature demod block to perfom FM
demodulation, you should squelch the FM noise output between bursts. 
This noise will have the symbol sync block pulled off into la-la-land
and make acquisition of symbol timing at the next burst take much
longer.

> *Universal radio hacker" somehow did the trick, but I guess
> "autodetect" for the 4 level does not work properly and I can't
> configure the values so that I would have consistent results.

I don't think stock GNURadio has a 4-level slicer.  You'll probably
have to write your own block for that.


> If someone could point me out to how to properly and reliably extract
> the symbols from these kinds of signals, I would greatly appreciate
> it.

GNURadio comes with a sample flowgraph for playing around with the
symbol synch block and a two level burst signal with some ISI.

Re: Correlation Estimator Questions

[Andy Walls]

> Date: Sat, 18 Jul 2020 12:06:11 -0400
> From: Nicholas Savka 
> To: discuss-gnuradio@gnu.org
> Subject: Correlation Estimator Questions
> 
> Hello,
> 
> My ultimate goal is to use the correlation estimator block for
> synchronization using a preamble in order to send packets of digital
> data
> from one sdr to another, both running gnu-radio. In order to
> understand how
> the correlation estimator works, I am looking at the provided example
> "example_corr_est_and_phase_sync." It looks like this example is
> using a
> BPSK modulation scheme and I am trying to modify it to work with QPSK
> instead to make sure I know how it works, but I am running into
> problems. I
> have four questions:
> 
> 1.)
> I do not understand the purpose of the "tag marking delay" entry in
> the
> correlation estimator block. How should this value be determined?

The block will output a tag on the output sample stream when it detects
a correlation.

By default (delay of 0) this tag will be set at the start of your
preamble.

The tag marking delay lets you adjust the position of the output tag in
units of samples.  You should set this empirically to be at the center
of the first symbol in the preamble.


> 2.)
> How does the correlation estimator "talk to" the costas loop and
> Polyphase
> Clock Sync blocks? Is there something going on behind the scenes here
> that
> I cannot see? Is it somehow passing the frequency/phase correction
> information to these blocks?

Using the time_est tag on the output sample stream, to tell the clock
sync blocks, "This is the approximate center of a symbol, reset your
symbol clock timing recovery".

A CPO estimate is also output on the "phase_est", but I don't think any
block uses it.


> 3.)
> I think my main issue is that I do not understand how to format the
> "Data
> Vector" entry in the "Modulate Vector" block. This is my (probably
> incorrect) understanding:
> 
> I want my preamble symbols to be [1+1j, 1+1j, 1+1j, -1-1j, -1-1j,
> 1+1j,
> -1-1j]
> 
> My constellation object has the following parameters:
> Symbol Map: [0,1,2,3]
> Constellation Points: [(-1-1j),(-1+1j),(1-1j),(1+1j)]
> 
> Therefore, my desired preamble would map to: [3,3,3,0,0,3,0]
> So, in the "Data Vector" box in the "Modulate Vector" block, I should
> enter:  [0x3,0x3,0x3,0x0,0x0,0x3,0x0]



> 4.)
> Why is the Modulate Vector block needed at all? Why can I not simply
> enter
> [1+1j, 1+1j, 1+1j, -1-1j, -1-1j, 1+1j, -1-1j] into the field for
> "Symbols"
> in the correlation estimator block?

The corr_est block "Symbols" input wants the correlation/matched filter
taps (*before* time-reversal and conjugation) for the preamble it is
trying to match.

It can't use symbols from the constellation, because it doesn't make
any assumptions about your pulse filter, you modulation, or how you
truncate the transient of pulse filtering your preamble symbols.

I suggest that you do not use the Modulate Vector block, as it doesn't
give you insight or much control into what it is actually producing.

Instead, produce your correlation/matched filter taps yourself using
MatLab or Octave or Python.  See the attached Octave scripts for a QPSK
example with your preamble and symbol mapping.

BTW, the GNURadio Constallation object will silently scale your
constellation so that the constellation points have an average radius
of 1.  So your constealltion points are really 1/sqrt(2) * [(-1-1j),(-
1+1j),(1-1j),(1+1j)], as far as GNURadio is concerned.


Regards,
Andy

pkg load signal;  % Octave needs this
Fs = 2;  % sample rate
fc = Fs/4 * 1; % optional IF frequency
Rs = 2000;   % symbol rate
sps = Fs/Rs; % samples per symbol

%
% Root raised cosine pulse filter
% https://www.michael-joost.de/rrcfilter.pdf
%
r = 0.22; % bandwidth factor

ntaps = 8 * sps + 1;
st = [-floor(ntaps/2):floor(ntaps/2)] / sps;
hpulse = 1/sqrt(sps) * (sin ((1-r)*pi*st) + 4*r*st.*cos((1+r)*pi*st)) ./ (pi*st.*(1-(4*r*st).^2));

% fix the removable singularities
hpulse(ceil(ntaps/2)) = 1/sqrt(sps) * (1 - r + 4*r/pi); % t = 0 singulatiry
sing_idx = find(abs(1-(4*r*st).^2) < 0.01);
for k = [1:length(sing_idx)]
hpulse(sing_idx) = 1/sqrt(sps) * r/sqrt(2) * ((1+2/pi)*sin(pi/(4*r))+(1-2/pi)*cos(pi/(4*r)));
endfor

% normalize to 0 dB gain
hpulse = hpulse / sum(hpulse);
delay_hpulse = (ntaps-1)/2;

%
% Create a correlation filter for a QPSK preamble
%

% 
preamble_symbols = [3 3 3 0 0 3 0];
constellation_map = 1/sqrt(2) * [-1-1j -1+1j 1-1j 1+1j];

% Map the preamble symbols to the constellation points
preamble_qpsk = constellation_map(preamble_symbols+1);

% Upsample and pulse shape the preamble
x = sps*[upsample(preamble_qpsk, sps), zeros(1, delay_hpulse)];
preamble_bb_init = filter(hpulse, [1], x);

% Discard the most of the transient
preamble_bb = preamble_bb_init(floor(delay_hpulse*0.70)+1:end);
% Set the correlation preak ref to the middle of the last symbol
preamble_bb = preamble_bb(1:(end-ceil(sps*0.75)));

% Modulate the preamble up to IF and then create the 

Re: Symbol timing estimator block and CPM modulations

[Andy Walls]

Hi Nick:

On Wed, 2020-06-24 at 17:39 -0700, Nick Foster wrote:
> Hi,
> 
> I'm finally getting around to doing some more CPM work 

I forgot to mention, my company found the GMSK demoulation technique
found in this paper:

https://www.researchgate.net/publication/241629765_Coherent_demodulation_of_AIS-GMSK_signals_in_co-channel_interference

coupled with the "method 0" CFO correction in this paper:

https://www.researchgate.net/publication/290776860_Preprocessing_AIS_Signals_for_Demodulation_in_Co-Channel_Interference

along with analog RF components in front of an SDR, and precise timing
with a GPSDO w/PPS to aid in looking for preambles, gave us fantastic
results for AIS reception in GNURadio.

Although it required quite a few custom blocks.

Anyway, Douglas Nelson seems to have a lot of cool papers available in the 
public:

https://www.researchgate.net/profile/Douglas_Nelson8

Regards,
Andy

> Best,
> Nick

Re: Symbol timing estimator block and CPM modulations

[Andy Walls]

On Mon, 2020-06-29 at 14:11 -0500, Alex Roberts wrote:
> Copy that. Would a preamble with better properties like a gold code
> allow to raise that threshold? I guess I need to dig into what that
> threshold means. On the examples I’ve seen it’s always 0.9 or higher.
> 

You could use a Gold code.  Although the length 13 Barker code is
probably good too, just to play around with.
Yeah, so the fixed correlation threshold algorithm is somewhat staright
forward, but I caused to to have a bit of a wrinkle.
You'll notice in the algorithm, it checks using the square of the
correlation's magnitude.  That's because long ago, to save CPU cycles,
I coded the block to compute the magnitude squared of the correlation
and check against that.  Taking the square-root of every I^2+Q^2 sample
of the correlation output seemed like a waste of CPU to me at the
time.  I now regret that decision, as it has been a source of confusion
for people working with this block, oh well.
The block has undergone a few revisions regarding the thresh holding
algorithm, since I last touched it myself.  I know that the dynamic
algorithm only works with preambles with good correlation properties
(gold codes, barker codes).
The non-adaptive algorithm is sensitive to the incoming signal level
compared to the reference level of the correlation filter taps.  In
hindsight, I probably should have had my correlation filter taps script
normalize h_iq to some nominal gain value.
Anyway, I highly recommend you do test correlation runs in
Matlab/Octave first, duplicating the corr_est block's thresh hold
crossing detection algorithm, before jumping into a GNURadio
implementation.  The analysis in Matlab/Octave will much better inform
you on how your GNURadio parameters should be set.
Regards,Andy

> On Monday, June 29, 2020, Andy Walls 
> wrote:
> > On Sun, 2020-06-28 at 16:31 -0500, Alex Roberts wrote:
> > 
> > > Andy, 
> > 
> > > 
> > 
> > > I had a copy of an old flowgraph that you posted on the mailing
> > list
> > 
> > > a long while back (
> > 
> > > 
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00735.html
> > 
> > > ). This is what initially confused me on what to pass in as gmsk
> > 
> > > symbols to corr_est block as it has strictly real values.
> > 
> > > 
> > 
> > > I modified it to mux in the preamble that's in the octave code
> > with a
> > 
> > > random source. I also modified the octave code to match the
> > samples
> > 
> > > per symbol of the flowgraph (10) and generated the modulated
> > symbols
> > 
> > > for the corr_est block. The corr_est block does indeed
> > 
> > > perform conjugation and reversal of the symbols, so I used the
> > "h_iq"
> > 
> > > value from the octave code as the modulated symbols since it has
> > not
> > 
> > > been conjugated or reversed. I'm not getting corr_est tags. 
> > 
> > 
> > 
> > On that flowgraph, set your threshold on the corr_est block to
> > 0.23.
> > 
> > 
> > 
> > BTW, that preamble has horrible correlation properties.
> > 
> > 
> > 
> > 
> > 
> > > Thanks,Alex.
> > 
> > 
> > 
> > -Andy
> > 
> > 
> > 
> > 

Re: Symbol timing estimator block and CPM modulations

[Andy Walls]

On Sun, 2020-06-28 at 16:31 -0500, Alex Roberts wrote:
> Andy, 
> 
> I had a copy of an old flowgraph that you posted on the mailing list
> a long while back (
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00735.html
> ). This is what initially confused me on what to pass in as gmsk
> symbols to corr_est block as it has strictly real values.
> 
> I modified it to mux in the preamble that's in the octave code with a
> random source. I also modified the octave code to match the samples
> per symbol of the flowgraph (10) and generated the modulated symbols
> for the corr_est block. The corr_est block does indeed
> perform conjugation and reversal of the symbols, so I used the "h_iq"
> value from the octave code as the modulated symbols since it has not
> been conjugated or reversed. I'm not getting corr_est tags. 

On that flowgraph, set your threshold on the corr_est block to 0.23.

BTW, that preamble has horrible correlation properties.


> Thanks,Alex.

-Andy

Re: Symbol timing estimator block and CPM modulations

[Andy Walls]

Hi Alex:

On Sat, 2020-06-27 at 19:42 -0500, Alex Roberts wrote:
> Andy,
> 
> I’m not sure how integrate the correlation sync block with gmsk.

The correlate_and_sync block is an old block that was specific to RRC
filtered PSK.  You must mean the corr_est block.

>  It expects modulated symbols and I’m not sure how to generate a
> modulated vector of gmsk symbols.  There doesn’t seem to be a gmsk
> class that can be used by the modulate vector block.

You can create a modulated GMSK preamble with the modulate vector block
in GNURadio.  However, I do not recommend it.  It provides little
insight or control over the exact correlation filter taps, so trimming
off start and end transients becomes a hassle.

Instead, generate your correlation filter taps in MatLab or Octave. 
Then you can also use Matlab or Octave to assess the performance of
your correlation filter taps against real or simulated data.

See the attached script for an example of generating GMSK correlation
filter taps.  Note that this script generates the conjugated and time
reversed filter taps.  You'll have to check what the corr_est block is
expecting, as it may be performing a conjugation and time reversal for
you, under the assumption that you didn't do it.

Regards,
Andy


> Thanks,
> Alex 
> 
> On Thursday, June 25, 2020, Andy Walls 
> wrote:
> > Recommend reading
> >  
> > https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf
> > 
> > Yeah, the MSK TED selections for the symbol sync block expect the
> > constant envelope FSK waveform on the input.  Demodulation from FSK
> > to baseband pulses should happen after the symbol sync block.
> 
> 
pkg load signal;  % Octave needs this

% One of the possible encodings of the AIS preamble symbols
h_bits = [-1,-1, 1, 1, ...
  -1,-1, 1, 1, ...
  -1,-1, 1, 1, ...
  -1,-1, 1, 1, ...
  -1,-1, 1, 1, ...
  -1,-1, 1, 1, ...
  -1,-1,-1,-1,-1,-1,-1, 1].';

% AIS specific GMSK parameters
Rb = 9600;
BT = 0.4;
L = 3;
modulation_index = 1/2;

% Working sample rate
sps = 5;
Fs = Rb * sps;

% Build Gaussian pulse filter
Ls = round(L*sps);
alpha = sqrt(2/log(2)) * pi * BT;
k = [(-Ls/2+1):1:(Ls/2-1)];
taps = (erf(alpha*(k/sps + 0.5)) - erf(alpha*(k/sps - 0.5)))*0.5/sps;
K = length(taps);
if (mod(K,2) == 0)
   delay = K/2;
else
   delay = (K-1)/2;
end

% Upsample and pulse shape the correlation sequence
x = sps*[upsample(h_bits,sps); zeros(delay, size(h_bits)(2))];
h_ibaseband = filter(taps, [1], x);
% Trim the pulse shaped correlation sequence
h_baseband = h_ibaseband((delay):(end-(sps-1)),:);

% modulate the correlation sequence
fm_gain = pi/(Fs/2) * Rb/2 * modulation_index;
x = h_baseband * fm_gain;
phase = cumsum(x); % phase is integral of frequency
h_iq = exp(1i*mod(phase, 2*pi));

% create the correlation filter
h = conj(h_iq(end:-1:1,:));

figure(1);
t1 = [1:size(h_ibaseband)(1)];
plot(t1, h_ibaseband(:,1), 'x-');
title('Premable Baseband Gaussian Pulses');

figure(2);
t2 = [1:size(h_baseband)(1)];
plot(t2, h_baseband(:,1), 'x-');
title('Trimmed Premable Baseband Gaussian Pulses');

figure(3);
t3 = [1:size(h)(1)];
plot(t3, real(h(:,1)), 'x-', t3, imag(h(:,1)), 'x-');
title('Correlation Filter Taps');
h(:,1)

Re: Symbol timing estimator block and CPM modulations

[Andy Walls]

Recommend reading
 
https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf

Yeah, the MSK TED selections for the symbol sync block expect the constant 
envelope FSK waveform on the input.  Demodulation from FSK to baseband pulses 
should happen after the symbol sync block.

Re: FSK and Timing Recovery Questions

[Andy Walls]

> Message: 3
> Date: Wed, 8 Jan 2020 13:57:09 -0600
> From: Alex Roberts
> To: GNURadio Discussion List
> Subject: FSK and Timing Recovery Questions
> 
> Hello Mailing List,
> 
> Happy New Year!
> 
> I've been playing around with this (
> http://aaronscher.com/GNU_Radio_Companion_Collection/Audio_Modem_loop_back_test_FSK.html)
> FSK audio modem and have a few issues/questions.
> 
> 1) Is the PFB block the way to go for FSK timing recovery?

I recommend the new Symbol Synchronizer block.  It is a superset of all
the other GNURadio PLL timing recovery blocks, and it address a lot of
bugs that the old blocks have.  (To be fair the PFB clock-sync block is
the least buggy/best block of the old bunch.)

Please take a few minutes to read:
https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf

Slide 21 is where the theory ends and the practical begins.

>  I have issues
> where if I start the receiver before the transmitter, the system
> doesn't
> work. And if I start the transmitter before the receiver, it will
> eventually lose sync and never recover. I added a message strobe to
> send
> dummy data once a second (like a keep alive/heartbeat) and this helps
> it
> from losing sync in between time of when I send meaningful data.

Yeah, tracking loops can wander way off when there is no signal and it
trying to just track on noise.

With all fixed-gain PLL tracking loops (aka feedback tracking loop),
there is a trade off between long term tracking stability (low jitter)
and rapid acquisition.

The clock sync block's processing of the "time_est" tag or "clock_est"
tag is meant to be used in a data-aided timing acquisition scheme to
jump start packet symbol timing acquisition.  Some block ahead of the
symbol timing sync block needs to detect the preamble and then open-
loop, feedforward estimate where the center of one symbol is, and then
tag that symbol center.

> 1a) Reading docs on both PFB and M blocks, do I need a moving avg.
> filter
> after quad demod to round out the square pulses to allow PFB and M
> to
> better find peaks or is the moving avg filter implemented within the
> block?

The M block certainly needs a peaking filter, usually a matched
filter, out front.

The PFB clock sync block implements that filter for you.  However, it
crashes on filter designs for square pulses, because internally the PFB
clock-sync block builds a derivative matched filter.  That derivative
doesn't work out so well numerically with a square pulse filter as an
input parameter.


> 2) Is the pre-amble being muxed doing anything more than just padding
> my
> data to help the PFB lock in before actual data arrives?

Well that's part of the point of a preamble, to aid in symbol timing
acquisition.

Not that the PFB clock synch block does any of the following, but:

Preambles can also be used to estimate and correct carrier frequency
offset.

Preambles can also be used for adaptive channel equalization (e.g. RLS
or LMS adaptive filter).


> 3) Would the Correlation Estimator help since it can send "time_est"
> tags
> downstream to the PFB and if so, where would be the ideal place to
> put it?

Yes.  But that block tries to use an adaptive thresholding algorithm
that doesn't work well with preambles with poor auto-correlation
properties.

Regards,
Andy

> Cheers,
> Alex

Re: Discuss-gnuradio Digest, Vol 206, Issue 5

[Andy Walls]

> Date: Fri, 6 Dec 2019 07:22:11 +0100
> From: "Lukas Haase" 

> Hi,
> 
> I am using GRC 3.7.11 on Ubuntu (WSL). When I use the M Clock
> Recovery block GRC crashes randomly with this message:
> 
> 
> clock_recovery_mm_cc: ii > ninput_items[0] (3168 > 3167
> python: /build/gnuradio-BBYmSv/gnuradio-3.7.11/gr-
> digital/lib/clock_recovery_mm_cc_impl.cc:214: virtual int
> gr::digital::clock_recovery_mm_cc_impl::general_work(int,
> gr_vector_int&, gr_vector_const_void_star&, gr_vector_void_star&):
> Assertion `0' failed.
> 
> > > > Done (return code -6)

The M clock recovery block obviously has an off-by-one error in its
processing.

The M clock recovery block is obsolete.  Use the Symbol Synchronizer
block instead, if you must use the M TED.


> Based on the plots, the block seems to be working (I get the proper
> bits).
> 
> My input signal comes in small bursts (asynchronously at random times
> which is why I need M).
> First I need to filter the signal and center it on its mean value.
> I use the following block for it:
> 
> https://paste.pics/4573d1f2cf7df0d5e039874c51127dd9
> 
> This shows a screenshot, triggered to one of the bursts:
> 
> https://paste.pics/a48ec4aef5ddeeef74e96255d72288b3
> 
> The original bits can be seen (blue/red) and the filtered, mean-
> centered version that will go into the M block (green/black).
> 
> Finally the M block looks like this:
> 
> https://paste.pics/db179025b5c6e98c3b20e76d56bcf139
> 
> 
> 
> The output of the block looks as expected ... until GRC crashes.
> 
> 
> Is there anything I am doing wrong?

You may want to read this presentation:
https://www.gnuradio.org/grcon/grcon17/presentations/symbol_clock_recovery_and_improved_symbol_synchronization_blocks/Andy-Walls-Samples-to-Digital-Symbols.pdf


Regards,
Andy


> Thanks,
> Luke
> 

Re: creating a 57 KHz signal from 19 KHz reference

[Andy Walls]

> From: Kristoff
> Date: Thu, 14 Nov 2019 23:39:32 +0100

[snip]

> Question:
> 
> I am trying to find a way to use the 19 KHz stereo-pilot signal to
> create a 57 KHz carrier (to down-convert the FM/RDS carrier at 57
> KHz).
> 
> How do I do this?

Use the PLL carrier tracking block which will simultaneously:

1) phase lock to the 19 kHz pilot tone
2) shift (in reality rotate) the spectrum of the signal so the 19 kHz
tone gets moved to 0 Hz.

After that use a Rotator block to shift the spectrum another 38 kHz =
57 kHz - 19 kHz

Then use an FIR/FFT filter block with low pass taps to isolate your RDS
signal. 

> 
> Itried using a PLL carrier-tracking block to extract the 19 KHz
> carrier (which seams to work) and direct that carrier to a 3 input
> multiplier block, but that does not seams to work. Even after
> filtering out DC and the carrier at  -19 KHz (negative frequency),
> the output of the multiplier is always zero. (*)

You have neglected that that PLL block performs a spectrum shift as
well as tracking the pilot signal.  Put a QT GUI Freq sink on the
output of the PLL carrier tracking block to see.
> 
> Or is there a better way to generate a 57 KHz complex sine-wave from
> a 19 KHz reference signal?

There is no need to have a locally generated 57 kHz carrier, when you
can just use a PLL to phase lock and then a rotator to shift the
spectrum.

-Andy

Re: [Discuss-gnuradio] debugging uhd_corr_and_sync example

[Andy Walls]

Hi Achilleas:

> From: Achilleas Anastasopoulos
> Date: Wed, 10 Jul 2019 08:45:03 -0400
> Hi Ernest,
> 
> Although this explains why the system breaks when the noise becomes
> large (~10dB) and so the overall signal amplitude increases beyond
> (~1), it cannot explain why the system does not recover AFTER 
> all amplitudes are set back to normal values (~1) and noise back to
> -30dB ...
> 
> It was my impression that the polyphase sync block will completely
> reset once it sees a tag from the correlate and sync block, but this
> does not seem to be the actual behavior...

It does not, unfortunately.

The nominal symbol clock period, which is stored in the integral branch
of the loop filter internal to the pfb_clock_sync block, is not reset
upon receipt of a "time_est" tag.

If processing the noise pulled the nominal clock symbol period estimate
way off from the actual symbol clock period, the pfb_clock_sync block
could take a long time to recover depending on the damping factor and
loop bandwidth you provided.  The pfb_clock_sync block (errantly)
defaults to extremely overdamped, BTW.

The new symbol_sync block does reset it's nominal symbol clock period
estimate on receipt of a "time_est" (or "clock_est") tag, but can be
configured to act like the pfb_clock_sync block in other respects.

Regards,
Andy


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

Re: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio

[Andy Walls]

Hi Johannes:

On Tue, 2019-02-26 at 11:05 +, Johannes Demel wrote:
> Hi Andy,
> 
> thanks for your answer and help. That's the pointer I was looking
> for.
> 
> Just for clarification, I' refering to this schematic:
> https://files.ettus.com/schematics/ubx/ubx.pdf
> 
> The 'SKyWorks SKY13350-385LF' switch is this SPDT component in the
> TXPA 
> block?

Yes, on Sheet 1.

It is also depicted on Sheet 11, Grid C-2, designated U32.


> I expect a configuration with separate antennas for TX and RX. But
> since 
> isolation between TX and RX chains is limited by the switch, this is
> the 
> component I need to worry about?

In my opinion, yes.

It seems kind of funny that Ettus would make a board that can blast out
20 dBm on Tx, can only tolerate -15 dBm max on Rx, and then have only a
single device that provides only 17-20 dB isolation between the Tx and
Rx.

If all the specifications from the UBX-160 page are to be believed, 
you always have to have the UBX Tx gain turned down by at least 15 dB
to not damage your UBX board.




> Otherwise I'd just separate my TX and RX antennas spatially. But
> that 
> doesn't make sense in my case since the critical component is this 
> switch in my case.

Right.

Although antenna separation needs to happen as well, so you have at
least 35 dB loss over the air.  Keep in mind that equations derived
from far field approximations don't necessarily hold in the near field.


> I aim at working in the 3.7GHz band. Thus, I assume that my receive 
> signal goes through the VMMK-3603 LNA in the RXLNA block in the 
> schematic. I wonder how that component right after the RX2 SMA works?
> I 
> assume this is a Skyworks AS236-321LF as shown on page 11 of the
> schematic.
> 
https://store.skyworksinc.com/Products/Detail/AS236321LF-Skyworks-Solutions-Inc/88944/

Take a look at the SPDT switch in Figure 1 here:
http://www.skyworksinc.com/uploads/documents/PB_RFSwitches_PB121_15B.pdf

It's not too hard to imagine what a DPDT switch looks like from there.


> Are there in fact 2 switches concatenated? Would it be appropriate
> to 
> just add up their isolation values?

Ah, yes.  As long as the USRP switches this one over to RX2, (and that
sounds like your configuration,) it looks like you get an additional
13-15 dB of isolation.  Still not enough to cover the whole 35 dB, but
you're up to a worst case minimum 30 dB isolation.

If all of the specifications are to be believed, and you know you'll
receive negligible energy on the RX2 port antenna, you only need set Tx
output gain to 5 dB of attenuation, and make sure you are using RX2 for
Rx.


> Another thought, would it be possible to configure a USRP in GR such 
> that it does continuously receive on TX/RX and then switch for the 
> duration of a transmit burst and switch back afterwards? Of course, 
> preferably this happens automagically.

I'm pretty sure this already is handled automatically by the
USRP/libuhd, but it would take a bit of searching through code to
verify.

In the case of telling the USRP you're using the TX/RX port for both Tx
and Rx, you may not get that Skyworks AS236-321LF switch switched into
the position to get the additional isolation.  You'll have to check the
code or check with Ettus.


> This thread [0] suggests that there is some kind of control. But so
> far, 
> I didn't find a definite way to tell if this covers my case with GNU 
> Radio. Also, in [1] it sounds like switching is done automagically. 

In GNURadio you should be able to set a USRP Sink to "TX/RX" and a USRP
Source to "TX/RX", and libuhd should take care of the switching
automatically, if I recall correctly.  Again, you might not get the
isolation of the second Rx switch using this configuration.


> Though, I wonder if I can just use 'UHD: USRP Sink' and 'Source' or
> if I 
> need to use the Async Sink?

I have no idea.  Never used it.

Regards,
Andy

> Cheers
> Johannes
> 
> [0] 
> 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-October/050112.html
> [1] 
> 
https://stackoverflow.com/questions/39321262/switching-usrp-from-rx-to-tx-using-gnuradio
> 
> Am 25.02.19 um 20:30 schrieb Andy Walls:
> > 
> > > Date: Mon, 25 Feb 2019 10:29:56 +
> > > From: Johannes Demel
> > > To: "discuss-gnuradio@gnu.org" 
> > > Subject: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio
> > > 
> > > Hi all,
> > > 
> > > I plan to implement a TDD system with GNU Radio and X310s w
> > > UBX160s.
> > > My
> > > lab setup is as follows:
> > > - multiple USRPs (start with 2, extend to more)
> > > - each USRP shall use 1 TX and one RX port. Preferably on one
> > > daughterboard in order to extend it to MIMO later on.
> > > 
> &g

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 196, Issue 21

[Andy Walls]

> Date: Mon, 25 Feb 2019 10:29:56 +
> From: Johannes Demel 
> To: "discuss-gnuradio@gnu.org" 
> Subject: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio
> 
> Hi all,
> 
> I plan to implement a TDD system with GNU Radio and X310s w UBX160s.
> My 
> lab setup is as follows:
> - multiple USRPs (start with 2, extend to more)
> - each USRP shall use 1 TX and one RX port. Preferably on one 
> daughterboard in order to extend it to MIMO later on.
> 
> At the moment the receiver runs continuously. While TX bursts happen 
> occasionally. I'd like to turn up TX power as much as possible. But
> I'm 
> concerned that this will damage the RX frontend. Especially if the
> RX 
> gain is set to some high value too. Should I be concerned about that?

Yes.

https://kb.ettus.com/UBX

"TX Power (Max)

 10 MHz - 3 GHz: 20 dBm
 3 - 6 GHz: 8 - 20 dBm"

"Input Power Levels

The maximum input power for the UBX is -15 dBm."


The TX chain is isolated from the Rx chain by a SKyWorks SKY13350-385LF 
switch.
https://files.ettus.com/schematics/ubx/ubx.pdf
http://www.skyworksinc.com/Product/712/SKY13350-385LF

which claims typical isolation of 25 dB at 3 GHz on the webpage, but
the datasheet indicates 20 dB is actually typical and 17 dB is minimum.
UBX-160 board design, if not done right, can degrade that.

17 dB of isolation is does not cover the 35 dB difference between max
TX power and max Rx input power.


> Or 
> does the USRP take care of that automatically? e.g. turn down RX
> gain 
> during transmission?

I don't think so. 


> Even if a transmission is received at the same receiver, I'd expect
> my 
> RX DSP chain to just demodulate that burst and later on this packet 
> would be discarded.

That's my experience with WBX-120 boards installed in a working
system: the radio can hear itself.


>  Also, I'd envision a block that 'blanks' my RX 
> samples whenever TX is expected.

It's easy enough to throw away these packets at the MAC layer. 
Receiving them is also a rudimentary check for a continuous built in
test to detect if the transmitter has completely failed. 


> All in all the questions are:
> - do I need to implement some logic in GR to turn down RX gain (or
> shut 
> off RX) during a TX burst?

Given the numbers above, I would think you need to keep the gain down.


> - does UHD take care of that?

I don't think so.


> - If I need to take care of that, how did you guys handle that
> problem?

Don't run the RX chain at full gain.

Put an LNA and limiter out in front of the USRP's Rx port.

And if you're using one antenna for both Tx and Rx, on the TX/RX and
RX2 ports respectively, you'll need a PIN diode RF T/R switch out in
front of the USRP as well.

Regards,
Andy

> Cheers
> Johannes
> 


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

Re: [Discuss-gnuradio] Pulse on FSK Preamble

[Andy Walls]

> Date: Tue, 22 Jan 2019 10:42:19 +0100
> From: samuel verdon 
>
> hello Everybody,
> 
> I am trying to recover my fsk signal with the Muller block.
> Here is my configuraiton:
> Sample rate of USRP = 240K
> bitrate of signal = 9600bps
> 
> receiving the signal from the USRP,
>  apply a low pass filter -> quadrature demod ->rational resampler ->
> m
> sync block
> 
> 
> My signal contain a preamble of 100ms of 1010 (0x55). after my
> Muller block, I can see the recovering working for my signal
> but not
> for my Preamble. I have pulse on the preamble which sometime are
> visible on
> the data part as well.
> https://ibb.co/hfLt62K  <https://ibb.co/hfLt62K>
> https://ibb.co/xqRkRP7

The M Timing Error Detector (TED) gain collapses to 0 when operating
on "clock patterns" of 1010101, so the M TED works horribly on trying
to acquire such a preamble.

>  I have tried also with Polyhpase clock sync block but this one took
> to
> much time to be syncronised with my preamble.
> 
> Can someone help me by explaining this pulse? I porbably do not use
> correctly the sync block ( I have left the default value except for
> the
> omega=sps ). Can someone redirect me to a documentation to use it
> correctly?
> let me know if I have to give more information.

Switch to using the Symbol Synchronizer Block.

You should read this brief:

https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf

And read my recent comments in this GNURadio Issue:

https://github.com/gnuradio/gnuradio/issues/2134#issuecomment-456238039

Regards,
Andy

> Thank you in advance for your help
> 


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

[Discuss-gnuradio] Wildlife Tracking (Re: fast parallel filtering)

[Andy Walls]

Hi Dirk:

On Sat, 2019-01-12 at 18:40 +, Dirk Gorissen wrote:
> Better late than never, but massive thanks to Andy, Marcus and the
> GnuRadio community:
> 
> https://dirkgorissen.com/2019/01/06/wheres-pinoh-tracking-orangutans-
> with-drones-and-gnu-radio/

You're welcome.  It was our pleasure to help.

I was wondering when the report would come out.  I had periodically
checked your Twitter for the few months following March 2018, but never
saw anything.

I'm sure the data analysis is fascinating, even though the collection
was degraded by the sub-optimal antenna.  I've been in a similar
situation: collect data with sub-optimal system, get tantalizing bits
of good data along with lots of noisy data, fix system and wait for
opportunity to collect more data.  Waiting for the time window to get
more data with the fixed system is frustrating. :P

In your report you mention:

1. "Some implants seemed to transmit much longer and stronger than the
10ms pulse they should be transmitting."

That lengthened pulse will widen your time domain correlation "peaks". 
The stronger pulse will muck with your thresholds, if the thresholds
aren't adaptive. Or maybe you're using a CFAR detector? (As I write
this, I'm musing how similar this is to RADAR or IFF: pulse compression
followed by a CFAR filter/detector.) 


2. "The pulse would also be mirrored in the spectrum at times [...]"

An impairment common to almost all SDR hardware is I/Q imbalance (along
with DC offset).  I/Q imbalance will result in the spectrum having a
weaker image of the signal spectrum reflected about 0 Hz.  If the SDR
manufacturer hasn't calibrated most of the imbalance away for you using
harware chip functions, you have to get rid of I/Q imbalance and DC
offset using software.

Some more reading on the topic, if it matters to you: 
https://www.analog.com/media/en/technical-documentation/application-notes/AN-1039.pdf
https://www.faculty.ece.vt.edu/swe/argus/iqbal.pdf
https://cgit.osmocom.org/gr-iqbal/


Also, unless "Alan Walls" speaks up, I think you typo'ed my name at the
end of your write-up. :)


Anyway, great work.  Being the Principal Investigator and doing all the
hardware, software, analysis, and field data collection legwork is a
big job for one person.


Regards,
Andy

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

Re: [Discuss-gnuradio] symbol_sync_cc stuck when error too large (resulting d_avg_period goes negative)

[Andy Walls]

Hello:

> Date: Mon, 7 Jan 2019 20:24:57 +0800
> Bug
> 
> When input amplitude is too large, symbol_sync_cc get stuck.
> Screenshot
> 
> frame1
> frame2
> Tracing
> 
> in file symbol_sync_cc_impl.cc line 537:
>   error = -488.4;
>   advance_loop(error);
> in file clock_tracking_loop.cc line 128 function advance_loop(float 
> error) :
>   before: d_avg_period=10.771521, d_beta=0.0090558, error=-488.4;
>   d_avg_period = d_avg_period + d_beta * error;
>   after: d_avg_period = -0.417
>   out of range [d_min_avg_period, d_max_avg_period]
> back to file symbol_sync_cc_impl.cc line 540:
>   d_clock->phase_wrap();
> in file clock_tracking_loop.cc line 145 function phase_wrap()
> 
> phase = -87.227, limit=-0.417/2=-0.20895, now we stuck in these while
> loops;

Thank you! for the detailed tracing of the problem you encountered.

Please report the bug on the github.com/gnuradio Issue tracker:

https://github.com/gnuradio/gnuradio/issues

So this is certainly a problem with the block: it should never hang
even if used improperly.

However, given the large error sample value of -488.4, it looks like
you are not properly conditioning your input sample stream to the
block.

For best results with the symbol_sync_cc block, please ensure:

1. You have a filter block acting as a channel filter or IF filter,
filtering noise from the input signal

2. You use an Automatic Gain Control block to control the amplitude of
the input signal to a consistent value.  Your input amplitude should be
what the derivation of the particular Timing Error Detector (TED) in
use is expecting.  For Decision Directed TEDs, the input amplitudes
should match what the slicer constellation is expecting.  For the
signal*slope ML approximation TED, the input amplitude should be
significantly less than 1.0.  For the signum*slope TED, the amplitude
should be greater than 1.0.

3. Use a level shifter/DC removal block.  Almost all of the TED's
expect the amplitude excursions to be centered about 0.

4. You have a matched filter conditioning the input stream, either out
in front of the block, or done by the block's internal PFB
interpolation filter, to peak the symbol centers and reduce noise.  If
you have rectangular pulses and use a TED that requires a derivative,
you must use an external filter block for the matched filter.

5. That you have set the TED gain based of the slope of the TED S-Curve 
at timing offset = 0.  The TED S-Curve for you situation must be
determined from modeling and simulation of the TED with various timing
offsets in your specific Signal/Noise/ISI situation in MatLab, Octave,
Python, R, or some other mathematical simulation tool.


If you are doing all of the above and the problem is induced by AGC
amplifying up noise in between received bursts, I would like to know.


> ps: i think period should be d_avg_period, because avg period is
> estimated symbol period. when loop bandwidth relatively larger (
> 0.05~0.25 ), limiting d_inst_period can make tracking error larger,
> even loop unlock. i'll benchmark both later.
> Workaround
> 
> apply limit to d_avg_period immediately after d_avg_period changed

It is a potential change to make when fixing the block.

I pondered this choice when I initially wrote the block.  Back then I
decided to let the out of limits d_avg_period be applied to the
feedback, thinking that the excursion could never be so large as to
cause a problem, and that it might speed lock-in.  I never imagined the
error signal being so large with proper conditioning of the input and
setting of the TED gain.

Regards,
Andy

> in file clock_tracking_loop.cc line 127
> 
> Ultimate solution
> 
> check every input, state and output in range when calculate
> control loop
> 
> 


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

Re: [Discuss-gnuradio] sound card output issue

[Andy Walls]

> From: Jean-Michel FRIEDT
> Date: Thu, 19 Jul 2018 16:17:10 +0200

> Indeed I have since checked any source of crosstalk and removed all links from
> source to audio sink but the one going to input number 3 and still the same
> issue is observed. However remplacing 9 Hz output (at 192000 Hz sampling
> rate) with 9.1 Hz solves the issue of the unexpected shape at the output
> of the sound card. It seems to me we have a strange relation when incrementing
> the NCO phase, but I fail to identify the cause of the problem, and why
> moving the frequency as the flowgraph is running solves the output shape.
> I thought that incrementing and decrementing the frequency defined as a
> 
> floating point number might lead me to a value slightly different from 90.0 
> kHz,
> 
[snip]

> On Thu, Jul 19, 2018, 4:49 AM Jean-Michel FRIEDT <
> address@hidden> wrote:
[snip]
> When first launched with an output frequency set to 90 kHz, the sound 
> card
> output looks like jmfriedt.org/snd1.png, ie with some spectral 
> component
> around 6 kHz whose origin I am unable to identify. If, using the 
> slider, I
> change the frequency and set it back to its original value of 90 kHz, 
> I get
> the fine output of jmfriedt.org/snd2.png which looks as good as I can
> expect from an output frequency so close to the Nyquist frequency.
[snip]

Having the benefit of hindsight, I'll guess it is a beat frequency,
since GCD(192000, 9) = 6000.

If a QT Freq Sink (with 8192 points and a Kaiser window) doesn't show
the 6 kHz component, I'd blame the sound card.

-Andy




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

Re: [Discuss-gnuradio] Bug in fmdet_cf_imp.cc

[Andy Walls]

> From: Eugene Grayver
> Subject:  [Discuss-gnuradio] Bug in fmdet_cf_imp.cc
> Date: Fri, 8 Jun 2018 18:48:56 +
> 
> Hello,
> 
>  
> 
> There is a bug in the FM demod.  Unbelievably (almost), I reported a
> bug in the same line a couple of years ago.  At that time I also
> goofed (should have not retyped it).  The equation is STILL wrong!

Issues submitted to the mailing list will ultimately be forgotten. 
Issues submitted in GitHub shouldn't get lost.
https://github.com/gnuradio/gnuradio/issues
  
> 
> Sdot = d_scl * (-S0+d_8*S1-d_8*S2+S4);
> 
>  
> 
> Should be
> 
>  
> 
> Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4);
> 
>  
> 
>  
> 
>  
> 
> It is crazy that the basic FM demo works at all.

Well, all of these discrete derivatives are approximations.  Depending
on the input, the filter still might be close enough.

What's really crazy is that this block is implementing an FIR in that
"Sdot =" line and storing input sample history itself in some other
lines, in a C++ loop.  This block should be using volk SIMD
implementations for the FIR filtering and using the block's history
functionality to handle the history.

In fact, to get an even better derivative, instead of using the
existing taps, this block could use the MMSE interpolating
differentitator (with a mu fixed at 0.0) to get a better derivative and
use a volk implementation at the same time.

Regards,
Andy

> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
> 


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

Re: [Discuss-gnuradio] Selecting the precise sampling point from many samples

[Andy Walls]

> From: Carlo Manfredini
> Date: Fri, 1 Jun 2018 21:24:26 +1000
> Hello,
> I have a 2kbps bipolar data stream (in hardware) which I will sample
> at 48kSps and bring into GR.
> Once in GR, I wish to be able to sample only once per bit...so I use
> the "Keep 1 in N" block (where N=24) and this reduces my rate to
> 2kSps...with 1 sample per original data bit.
> 
> However, I wish to be able to control exactly at which point in the
> 48kSps stream that I sample down to 2kSps.
> 
> This is equivalent in hardware terms to being able to select at which
> point in each bit period that I sample once per bit.ie: selecting the
> decision point in an eye pattern).
> 
> The reason for this process is that I simply wish to read in the
> original 2kbps bit stream so that I can use this data to do some PSK
> modulation in GR etc...but my inputting device only runs at 48kSps.
> 
> Is there some way with existing GR blocks that I can tell where
> abouts in the 48kSps stream that I have actually sampled ? so that I
> can manually set this sampling point.

This is precisely the function of the Symbol Synchronization blocks.

https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf

You should play with the example here:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/demod/symbol_sync_test_float.grc
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/demod/symbol_sync_test_float_ted_gain.m


You'll probably want to do something like:

 -> Decimating FIR filter -> FIR Filter -> Symbol Sync -> Binary Slicer -> 

The first decimating FIR filter would anti-alias filter and downsample
by, let's say, 2 or 4, to bring the stream down to either 12 or 6
samples per symbol.

The second FIR filter would be a pulse matched filter, to get rid of
noise and peak the symbol centers.  (You can merge this filter into the
previous filter, if you want.)

The Symbol Sync block estimates the exact symbol centers, and
downsamples to just those sample points.

The binary slicer just thresholds its input samples to give you 1 or 0
valued samples on output.

> Perhaps a simpler question is : how do I know where the "Keep 1 in N"
> block is sampling ?

You don't.

Regards,
Andy

> Thanks for any hints...hopefully I have explained this adequately.


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

[Discuss-gnuradio] GRCon 17 presentation slides page broken/gone.

[Andy Walls]

Oh, those who are so wise in the ways of the GNURadio website:

The following link returns "gr-404"

https://www.gnuradio.org/grcon-2017/program/grcon17-presentations/

I'm not sure if that is intentional or not.

Regards,
Andy

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

Re: [Discuss-gnuradio] Square Wave Pulse Shapping Filter

[Andy Walls]

Hi Jose:

Please keep conversations on the list.

On Sun, 2018-05-20 at 00:54 -0300, Jose Marcelo Lima Duarte wrote:
> Andy,
> 
> Thank you very much for all information.

You're welcome.  But after I thought about it, it may not work in your
situation.

The GNURadio symbol timing synchronization blocks require symbol
centers to be "peaked" to perform their function properly.  Matched
Filtered RRC pulsed QPSK and Matched Filtered Square pulsed baseband
PAM are nicely peaked.

I'm not sure a Matched Filter will do anything to peak Square pulsed
QPSK unless there are spaces in between the pulses or the pulses are
not truly square.  Recovery of symbol centers of Square pulsed QPSK
will be very difficult, given that the QPSK can have an arbitrary phase
rotation in the receiver.

However, I don't believe engineers of an old satellite system would
make reception so difficult; especially if they were content to waste
TX energy in square pulses (which would be fairly broad spectrum).

Does the downlink provide an explicit symbol clock, on a frequency
separate from the data?  Is the satellite downlink specification
publically available?



> I will use the architecture you propose with minor parameters change.
> I am planing to work with a very high oversample rate to make ISI
> insignificant, 32 or higher prior to the MF and 16 after it.

Note that square pulse matched filters are not good antialias filters. 
Don't decimate with the MF.  Do the anti-alias filtering and down-
sampling with a separate Decimating FIR filter.


> Thus, I won't need more than 2 tap at the interpolation filter.

Well the GNURadio 8-tap MMSE interpolation filter used by the symbol
synch blocks is fixed at 8-taps, since the taps are all precomputed
offline and compiled in as constants.

Note that the MMSE interpolation filter is only MMSE (i.e. bounded
error) when the input signal is band-limited to the frequencies in the
interval [-Fs/4, Fs/4].  When using a high number of samples per
symbol, like 16, usually you'll be OK.

 
I would say, for more information, please see my presentation on Symbol
Synchornization here:

https://www.gnuradio.org/grcon-2017/program/grcon17-presentations/

but the web page seems to be broken/gone.

Instead, you can suffer through the video of me talking through my
slides, if you want:

https://www.youtube.com/watch?v=uMEfx_l5Oxk

Regards,
Andy

> Regards
> 
> Marcelo
> 
> 
> 
> On Sat, May 19, 2018 at 6:32 PM, Andy Walls <andy@silverblocksystems.
> net> wrote:
> > > Date: Sat, 19 May 2018 11:29:14 -0300
> > > From: Jose Marcelo Lima Duarte <jmarcel...@gmail.com>
> > 
> > > Hello everyone,
> > > 
> > > I was giving the task of quickly develop a receiver for an old
> > > satellite system that use a pulse shaping filter with square wave
> > > impulse response and QPSK constelation.
> > > 
> > > Does GNU Radio has a prompt solution for this? By a prompt
> > solution a
> > > mean a single block in GNU Radio Companion that handles carrier
> > phase
> > > synch, symbol time synch and sampling. From its documentation its
> > > seams to me that it lacks of prompt solution for old fashion
> > square
> > > wave pulse shaped signals. Am I right?
> > 
> > You are correct in that there is no single block in GNURadio that
> > handles all that.
> > 
> > 
> > > I have seen that GNU Radio has a prompt solution for demodulating
> > > QPSK signals with Squared RRC filter. And I known that it can be
> > used
> > > for square wave signals too. However, I want to avoid the
> > performance
> > > degradation from not using a matching filter at the receiver end.
> > 
> > Actually the one in GNURadio specifically can't be used for square
> > pulses, if it uses the Polyphase Clock Sync block in the underlying
> > implementation, as that block can't make a proper derivative pulse
> > filter for a square wave.
> > 
> > > Any suggestion for a quick solution for my problem?
> > 
> > For coarse carrier frequency synchronization, if you don't have
> > high
> > doppler, the "FLL band-edge" block will keep RRC pulse filtered PSK
> > signals roughly on frequency.  You can probably abuse it for PSK
> > with
> > square pulses too.
> > 
> > For matched filtering of a square pulse, just use a "Decimating FIR
> > Filter" block with a decimation of 1 (no decimation) and taps of
> > [1.0/N]*N  where N is the number of samples in th unit pulse width.
> > This will introduce receiver side ISI, since your square pulses are
> > not
> > Nyquist pulses, but you should get nice triangular pulse peaks.
> > 
> > For

Re: [Discuss-gnuradio] Square Wave Pulse Shapping Filter

[Andy Walls]

> Date: Sat, 19 May 2018 11:29:14 -0300
> From: Jose Marcelo Lima Duarte 

> Hello everyone,
> 
> I was giving the task of quickly develop a receiver for an old
> satellite system that use a pulse shaping filter with square wave
> impulse response and QPSK constelation.
> 
> Does GNU Radio has a prompt solution for this? By a prompt solution a
> mean a single block in GNU Radio Companion that handles carrier phase
> synch, symbol time synch and sampling. From its documentation its
> seams to me that it lacks of prompt solution for old fashion square
> wave pulse shaped signals. Am I right?

You are correct in that there is no single block in GNURadio that
handles all that.


> I have seen that GNU Radio has a prompt solution for demodulating
> QPSK signals with Squared RRC filter. And I known that it can be used
> for square wave signals too. However, I want to avoid the performance
> degradation from not using a matching filter at the receiver end.

Actually the one in GNURadio specifically can't be used for square
pulses, if it uses the Polyphase Clock Sync block in the underlying
implementation, as that block can't make a proper derivative pulse
filter for a square wave.

> Any suggestion for a quick solution for my problem?

For coarse carrier frequency synchronization, if you don't have high
doppler, the "FLL band-edge" block will keep RRC pulse filtered PSK
signals roughly on frequency.  You can probably abuse it for PSK with
square pulses too.

For matched filtering of a square pulse, just use a "Decimating FIR
Filter" block with a decimation of 1 (no decimation) and taps of
[1.0/N]*N  where N is the number of samples in th unit pulse width.
This will introduce receiver side ISI, since your square pulses are not
Nyquist pulses, but you should get nice triangular pulse peaks.

For symbol syncronization, use a "Symbol Sync" block with the signal
times slope ML approximation TED.  Also select the 8 tap MMSE
interpolation filter. 

For fine carrier frequency and phase synchronization use the "Costas
Loop" block.

Regards,
Andy 

> 

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

Re: [Discuss-gnuradio] gain setting in osmosdr block

[Andy Walls]

> From: Dirk Gorissen
> Date: Thu, 3 May 2018 22:25:09 +0100
> 
> Hello,
> 
> Im using an airspy mini through the osmosdr block. I would like
> control over the 3 gains the airspy has (IF, Mixer, LNA) but the
> osmossdr block does not seem to expose this. Is there a workaround?

The C++ and Python interfaces look like they support setting them:

https://github.com/osmocom/gr-osmosdr/blob/master/include/osmosdr/source.h#L185
https://github.com/osmocom/gr-osmosdr/blob/master/lib/source_impl.h#L59
https://github.com/osmocom/gr-osmosdr/blob/master/lib/source_impl.cc#L667
https://github.com/osmocom/gr-osmosdr/blob/master/lib/source_iface.h#L165
https://github.com/osmocom/gr-osmosdr/blob/master/lib/airspy/airspy_source_c.h#L108
https://github.com/osmocom/gr-osmosdr/blob/master/lib/airspy/airspy_source_c.cc#L533

but the GRC file for the GUI block doesn't appear to let you call these
from GRC.

Workaround:

In the Python script generated by GRC, you should be able to make the
following calls where appropriate:

# Turn off hardware AGC
source_block_instance.set_gain_mode(False, 0)

# Set gains
source_block_instance.set_gain(desired_lna_gain, 'LNA', 0)
source_block_instance.set_gain(desired_mix_gain, 'MIX', 0)

source_block_instance.set_gain(desired_if_gain,  'IF',  0)


The proper fix, is to fix this GRC block XML generator script to
present a tab for input of named gains, and to add callbacks for those
named gains:

https://github.com/osmocom/gr-osmosdr/blob/master/grc/gen_osmosdr_blocks.py


Regards,
Andy

> Cheers
> Dirk


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

Re: [Discuss-gnuradio] CIC + halfband filter compensation

[Andy Walls]

> From: Geoffrey Mainland
> Date: Wed, 25 Apr 2018 16:39:11 -0400
> 
> I hope you will forgive a few naive signal processing questions :)
> 
> 1) What is the frequency response of the CIC and halfband filters in
> the
> USRP? This was addressed long ago on the mailing list
> (https://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00191
> .html),
> but the associated MATLAB script is no longer available now that the
> nabble archive is gone.

Attached are images generated from an Octave script, showing the
performance of the X310's CIC filter and 3 half-band filters,
filtering, decimating, and folding-in from the radio's 200 Msps down to
6.25 Msps.

The CIC filter is in blue.  It's droop hardly worth mentioning.

The Octave script is also attached.  It is far from generic.  It will
need significant modification if you have a different situation.


> 2) How do I design a filter to compensate appropriately?
>
> I know there are other methods for avoiding CIC droop, like
> oversampling, but I'd like to understand how to compensate with a
> filter
> as well.

As far as CIC compensation filters go:

http://lmgtfy.com/?q=cic+compensation+filter

:)

Seriously, there is plenty of reading material out there.

Regards,
Andy

> Thanks!
> Geoff
%
% (C) 2018 Andy Walls <a...@silverblocksystems.net>
%

% The X310 DDC chain has 4 Integrator Stages  and 4 single delay Comb stages
% followed by a decimation stage.  We'll model that here, using the
% equations in https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an455.pdf

M = 1; % differential delay
N = 4; % stages
R = 4; % decimation rate to go from 200 Msps down to 50 Msps
d = ones(1, R*M); % FIR filter coefficients before raising to N
  % Since it is like a cascade of N identical filters
[hd, wd] = freqz(d, [1], R*8*1024);
hd = hd .^ N;
hd = hd/hd(1);
wdturn = [wd(1:(R*8*1024/R))' wd((R*8*1024/R):-1:1)' ...
  wd(1:(R*8*1024/R))' wd((R*8*1024/R):-1:1)'] * 50/pi; % Fs = 200, fold into 0-50 multiple times

% The X310 DDC uses up to 3 x% Nyquist Half-band filters

% Coefficients from
% uhd/fpga-src/usrp3/top/x300/coregen_dsp/hb47.coe
% Generated with round((2^18-2)*halfgen_test(.21,12,1))
%  83% effective BW, 64dB to 85dB rolloff

a = [   -62, 0,194, 0,  -440, 0,   855, 0,  -1505, 0,  2478, 0, ...
  -3900, 0,   5990, 0, -9187, 0, 14632, 0, -26536, 0, 83009, ...
 131071, ...
  83009, 0, -26536, 0, 14632, 0, -9187, 0,   5990, 0, -3900, 0, ...
   2478, 0,  -1505, 0,   855, 0,  -440, 0,194, 0, -62];
b = a;

% Coefficients from
% uhd/fpga-src/usrp3/top/x300/coregen_dsp/hb63.coe
% Generated with round((2^18-2)*halfgen_test(.22,16,1))
%  88% effective BW, 64dB to 87dB rolloff
c = [ -35, 0, 95, 0, -195, 0, 352, 0, -582, 0, 907, 0, -1354, 0, 1953, 0, ...
  -2751, 0, 3813, 0, -5249, 0, 7264, 0, -10296, 0, 15494, 0, -27083, 0, ...
  83196, 131071, 83196, ...
  0, -27083, 0, 15494, 0, -10296, 0, 7264, 0, -5249, 0, 3813, 0, -2751, ...
  0, 1953, 0, -1354, 0, 907, 0, -582, 0, 352, 0, -195, 0, 95, 0, -35];

[ha,wa] = freqz(a, [1], 8*1024);
ha = ha/ha(1);
[hb,wb] = freqz(b, [1], 4*1024);
hb = hb/hb(1);
[hc,wc] = freqz(c, [1], 2*1024);
hc = hc/hc(1);

% Fold freq axis to show aliasing into final passband
% Scale to original 50 Msps Fs
waturn = [wa(1:(8*1024/2))' wa((8*1024/2):-1:1)'] * 25/pi; % Fs = 50, fold 25-50 onto 25-0
wbturn = [wb(1:(4*1024/2))' wb((4*1024/2):-1:1)'] * 12.5/pi; % Fs = 25, fold 12.5-25 onto 12.5-0
wcturn = [wc(1:(2*1024/2))' wc((2*1024/2):-1:1)'] * 6.25/pi; % Fs = 12.5, fold 6.25-12.5 onto 6.25-0

clf;
plot( ...
 wdturn, 20*log10(abs(hd)), ';CIC filter 200 Msps folded to 50 Msps;', ...
 waturn, 20*log10(abs(ha)), ';1st HB filter 50 Msps folded to 25 Msps;', ...
 wbturn, 20*log10(abs(hb)), ';2nd HB filter 25 Msps folded to 12.5 Msps;', ...
 wcturn, 20*log10(abs(hc)), ';3rd HB filter 12.5 Msps folded to 6.25 Msps;');
title('X310 DDC CIC & Default Halfband Filters Alias Folding Performance');
ylabel('Gain (dB)');
xlabel('Frequency (MHz)');
grid on;
hold off;

% Passband droop at the final fold
% At Fs/2 = 6.25 MHz
worst_pass = ...
   20*log10(abs(hd(R*8*1024/32))) ...
 + 20*log10(abs(ha(8*1024/8))) ...
 + 20*log10(abs(hb(4*1024/4))) ...
 + 20*log10(abs(hc(2*1024/2)))
ideal_pass = ...
   20*log10(abs(hd(1))) ...
 + 20*log10(abs(ha(1))) ...
 + 20*log10(abs(hb(1))) ...
 + 20*log10(abs(hc(1)))
worst_droop = ideal_pass - worst_pass

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

Re: [Discuss-gnuradio] Best in-tree blocks for clock recovery of 8FSK

[Andy Walls]

On Mon, 2018-04-02 at 13:44 -0400, Andy Walls wrote:

> > All PLL based symbol clock recovery blocks/methods in GNURadio
> require
> symbol centers to be peaked.

Slight correction.  The MSK TED's don't require the input pulses to be
peaked, but that's because they operate on the FM'ed pulses, and not
the levels of the baseband pulses.

-Andy

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

Re: [Discuss-gnuradio] Best in-tree blocks for clock recovery of 8FSK

[Andy Walls]

> Date: Mon, 2 Apr 2018 09:48:00 +0100
> From: Thomas Habets
> Hi.
> 
> As an experiment I'm trying to decode an FT8 signal I've captured.
> I've
> gotten far enough that I can clearly see the packet (
> https://blog.habets.se/tmp/ft8_packet.png), but now I want to
> actually turn
> that into bits.
> 
> I know it's 8FSK (the above screenshot is quad demod of that), but I
> have a
> few questions on clock recovery:
> 
> * Is the GFSK block only for BFSK? If so then that's out.

Generally yes, it is for recovery of 2 level signals.

> * Is there a "best" clock recovery block nowadays? I seem to recall
> "Clock
> Recovery MM" being discouraged in favor of "Polyphase Clock Sync".

Use the new Symbol Synchronizer blocks that are on the master branch
and hopefully in the latest release by now.  That block is a superset
of of all the other PLL-based clock sync blocks currently in tree.

If you haven't seen my brief on this subject already, please
read/watch:

https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf

https://www.youtube.com/watch?v=uMEfx_l5Oxk



> * I'm trying to read up on the parameters Polyphase Clock Sync wants,
> but
> any pointers would be helpful.

The small signal ML approximation TED that the polyphase clock sync
block uses was derived with only 2 level signals in mind.  It might not
work so well.

The M TED was derived with multi-level signals in mind.  But you must
provide a proper constellation (M points on the real axis), and you
must scale the input signal to match the constellation points the M
TED is expecting.  Note that is GNURadio, this is complicated by the
Constellation object automatically and silently scaling a user
specified constellation.


> * Would it be a good idea to throw in a costas loop for frequency
> tuning?

Um, no.

You'll need frequency correction, both coarse and fine, but how best to
accomplish that is another lengthy discussion.


> * Does Polyphase Clock Sync have the same dislike of "staircase"
> inputs?
> That is, I should try to make the center of the bits more "pointy"?
> (e.g.
> lowpass filter them)

All PLL based symbol clock recovery blocks/methods in GNURadio require
symbol centers to be peaked.

So yes, the input signals must be put through a pulse matched filter
first to peak the symbols.  With the new symbol sync blocks you can
either have the matched filter external to the block, or let the block
do it.  (As long as you use a TED that doesn't need a derivative of a
square pulse shape.)


> I've done some custom OOT decoders before, so I'm not shy about that.
> Maybe
> the best thing is some whole-packet clock recovery[1]. But if I just
> write
> a block that takes the quad demod (see above screenshot) and finds
> the
> "platforms", outputting a message that is a list of floats, and then
> another block that takes a list of floats and the number 8 and
> decodes it
> as 8FSK, well it seems like I may be reimplementing things where I'm
> guessing someone might say "oh just use this block".
> 
> Also for experimentation and my own understanding I'd like to turn it
> into
> bits using in-tree blocks, if possible.

For frequency correction, you will be forced to use out of tree blocks
or write your own.  There's nothing in tree that will do what you need
aside from maybe the PLL blocks; and they likely won't do the job well
for 8FSK bursts.


> Maybe a correct Polyphase Clock Sync of the quad demod followed by a
> Constellation decoder? I could use the float as the phase, with
> magnitude
> 1. Does that make sense? Is it a good idea?

The simplest thing to do is something like:

signal -> channel filter -> coarse freq correction -> correlators/burst
tagger -> quad demod -> offset correction -> matched filter ->
amplitude correction (agc) -> symbol synch -> m-level slicer ->  

And of that proposed DSP chain, there is a lot missing, if you only use
in-tree blocks.  My gr-nwr OOT module has some of those missing blocks,
but they were geared for relatively high SNR SAME 2-FSK bursts.

Regards,
Andy

> What I have so far is:
> Data:
>   https://blog.habets.se/tmp/ft8-burst-10k.raw (10k samp_rate)
> 
> GRC:
>   https://blog.habets.se/tmp/ft8_decode.grc
> 
> Screenshot:
>   https://blog.habets.se/tmp/ft8_decode_grc.png
> (everything off-screen to the right is failed clock recovery
> experiments)
> 
> Quad demod
>   https://blog.habets.se/tmp/ft8_packet.png
> 
> 
> [1] Like https://www.youtube.com/watch?v=rQkBDMeODHc which I turned
> into
> https://github.com/ThomasHabets/radiostuff/blob/master/
> gr-habets/python/magic_decoder.py
> 

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

Re: [Discuss-gnuradio] High Pass and Low Pass performance not inverse

[Andy Walls]

> From: John Ackermann N8UR
> Date: Tue, 13 Mar 2018 09:15:33 -0400

> I'm setting up a measurement program to look at the channel power
> inside and outside a defined bandwidth centered at zero. The idea is
> to get the ratio of the power within a low pass filter (nominally 500
> Hz), and the power in the rest of the spectrum (192 kHz) with that
> same 500 Hz chunk notched out. Attached are a screenshot of the the
> flowgraph and of an FFT showing the results.
> 
> 
> What puzzles me is that the low pass filter has a defined flat-top,
> while the high pass filter shows a very narrow notch. I would expect
> the two to have a similar shape. (I'm using rectangular windows
> because I want to get the actual noise power for the given
> bandwidth.)
> 
> 
> Any thoughts on why this is happening, or on ways to make the two
> responses more precisely mirror each other?

I think this is the skirt of the HPF (with real taps) folding at DC,
i.e. an alias.

Try with the equivalent 1-sided HPF (with complex taps) and see if it's
more vertical on the transition.  If it is, then you know.  But,
unfortunately cascading two 1-sided HPFs (one for positive freqs, one
for negative freqs) won't fix your problem.

Regards,
Andy


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

Re: [Discuss-gnuradio] pfb_clock_sync fails with high signal amplitudes

[Andy Walls]

Hi Milos,

Please keep the discussion on list.

On Mon, 2018-03-12 at 18:06 +, Milos Milosavljevic wrote:
> Thank you Andy. Much appreciated the comments.
> 
> I checked the AGC. It is not that. Even if I bypass the AGC and
> manually change the gain on my signal it obviously crashes when the
> amplitude goes high. The high amplitude spikes I am talking about are
> not something I produce. They are more interference like that I cant
> control. It looks like that spikes in the signal just kind of lock
> the pfb and it wont return to its normal operation when the signal
> drops in amplitude. I suspect that with AGC control loop it takes
> time to adjust causing the pfb to go into this state. So now I am not
> surprised the there might be momentary signal spikes from the AGC. 

[snip]

> Do you know why the pfb has assumptions for the signal of [-1,1]?

The timing error detector in use is a small signal approximation of 

   e(kT) = tanh( 2E/No * y(kT) ) * y'(kT)

See equation (5) of this paper:

https://pdfs.semanticscholar.org/3077/d85fc72d89c72c4c6d11f1014c5175e319c3.pdf

and the paragraph just before equation (6).


Or see the derivation leading up to equation (3.31) in this paper:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.46.2884=rep1=pdf

and also look at the discussion around equations (3.32) and (3.33).

For large signals, tanh(x) ~= sgn(x).
For small signals, tanh(x) ~= x.

The PFB clock sync TED, uses the small signal approximation; hence the
input amplitude must be small.


>  Do you by any chance have any ideas how I can circumvent this
> problem?

Well the problem is you're violating the assumption made in the
derivation for the TED to work as expected.  Don't violate the
assumption, and you won't have the problem. :)

Or use a different TED, such as the large signal ML approximation TED,
which is one of the options provided in the new symbol sync blocks on
the GNUradio master branch.

Please see the second half of this brief on the proper use of all these
PLL-based synchronizer blocks.

https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf


> I am confident going into the code and modifying the pfb but dont
> really know where to start. 

Any meaningful bug the PFB clock sync block had was fixed in the new
symbol synch blocks (which are a superset of all the existing symbol
sync blocks).


If you must use the existing pfb_clock_sync block, the first two things
you need to do are:

1. Limit the input into the pfb_clock_sync block to +/-1.0 in
amplitude, using a smarter AGC block and/or rail blocks.

2. Prevent NaNs from flowing to the input of the pfb_clock_sync block,
if that has happened in any of your experiments/tests.

Regards,
Andy

> Many thanks. 
> Milos
> 
> 
> On 12 March 2018 at 13:19, Andy Walls <a...@silverblocksystems.net>
> wrote:
> > > From: Milos Milosavljevic
> > > Date: Sun, 11 Mar 2018 14:36:19 +
> > > Dear All,
> > >
> > > I am using the pfb_clock_sync to estimate the timing offset in my
> > > QPSK receiver and I have a problem that I would like to ask
> > about.
> > >
> > > Basically if the amplitude of the incoming signal is set
> > relatively
> > > high (havent checked what actual threshold is) the flowgraph just
> > > hangs. After the process of elimination I discovered that it is
> > > actually the pfb_clock_sync block that causes this. Then I put
> > some
> > > printf statements in the code and found out that the d_k (phase)
> > > value becomes -NaN when signal amplitude becomes high. The same
> > thing
> > > is with the d_error from here d_error = (error_i + error_r) /
> > 2.0.
> > >
> > > I suspect it is due to some filtering (either the RC or diff
> > filter).
> > >
> > > Do you have any suggestions on where this might be coming from?
> > >
> > > Any comments will be highly appreciated.
> > 
> > This sounds like the pfb_clock_sync block is getting a NaN passed
> > in on
> > the input stream:
> > 
> > input is NaN => filtered input is NaN => d_error is NaN =>
> > d_k is NaN .
> > 
> > Look at your upstream AGC blocks and division blocks as likely
> > culprits
> > for generating NaNs, since you say "the amplitude of the incoming
> > signal is set relatively high".
> > 
> > 
> > BTW, the small signal, low SNR, Maximum Likelyhood approximation,
> > Timing Error Detector (TED) used in the pfb_clock_sync block has a
> > built in assumption that the input amplitude should be noticeably
> > smaller than +/-1.0 .  Also, for consistent results, you always
> > want to
> > go into a clock sync block with a controlled signal amplitude.
> > 
> > Regards,
> > Andy
> > 
> > 
> > 
> > 
> > 
> > >
> > > Many thanks,
> > >
> > > Kind Regards
> > > Milos
> 
> 
> 

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

[Discuss-gnuradio] pfb_clock_sync fails with high signal amplitudes

[Andy Walls]

> From: Milos Milosavljevic
> Date: Sun, 11 Mar 2018 14:36:19 +
> Dear All,
> 
> I am using the pfb_clock_sync to estimate the timing offset in my
> QPSK receiver and I have a problem that I would like to ask about.
> 
> Basically if the amplitude of the incoming signal is set relatively
> high (havent checked what actual threshold is) the flowgraph just
> hangs. After the process of elimination I discovered that it is
> actually the pfb_clock_sync block that causes this. Then I put some
> printf statements in the code and found out that the d_k (phase)
> value becomes -NaN when signal amplitude becomes high. The same thing
> is with the d_error from here d_error = (error_i + error_r) / 2.0. 
> 
> I suspect it is due to some filtering (either the RC or diff filter).
> 
> Do you have any suggestions on where this might be coming from?
> 
> Any comments will be highly appreciated.

This sounds like the pfb_clock_sync block is getting a NaN passed in on
the input stream:

input is NaN => filtered input is NaN => d_error is NaN => d_k is NaN .

Look at your upstream AGC blocks and division blocks as likely culprits
for generating NaNs, since you say "the amplitude of the incoming
signal is set relatively high".


BTW, the small signal, low SNR, Maximum Likelyhood approximation,
Timing Error Detector (TED) used in the pfb_clock_sync block has a
built in assumption that the input amplitude should be noticeably
smaller than +/-1.0 .  Also, for consistent results, you always want to
go into a clock sync block with a controlled signal amplitude.

Regards,
Andy





> 
> Many thanks,
> 
> Kind Regards
> Milos

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

Re: [Discuss-gnuradio] Is it safe to use get_tags_in_range within forecast?

[Andy Walls]

> From: Markus Wirsing
> Date: Tue, 16 Jan 2018 10:24:50 +0100

> Hello,
> 
> I am trying to write a block that produces a different amount of
> output 
> depending on the tags.
> For that I would need to access the tags in the forecast function.
> Would it be 
> safe to do that?

Yes, for the tags.  However, you will be introducing inefficiency.

The block executor calls forecast() multiple times in an effort to give
the block a number of input samples that will produce some output.  So
forecast() can be called many times before general_work(), and you will
have to refetch and process the tags on every call to forecast().

Be careful with your return value from forecast().  If you're smart
about it, you can probably minimize the number of time you go around in
the 'try_again' loop in the scheduler.

https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/block_executor.cc#L397


I'll ask some leading questions:

What happens if there are no tags on input?  Do you say you can't
produce output?  If so, what if the input buffer is full, such that no
new tags will ever appear, until some input is drained?


> Or can the tags still change in between the call to forecast and the
> call to 
> general_work?

Yes, they can.  In the small window of time between the final call to
forecast() and the call general_work(), you can get additional tags;
tags won't be removed.

-Andy

> I was not able to find information about that in the documentation.
> And I don't 
> have sufficient knowledge of gnuradio's inner workings to certainly
> answer that 
> question myself.
> 
> Thanks for any help.
> 
> Markus


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

Re: [Discuss-gnuradio] FM pre-emphasis and de-emphasis

[Andy Walls]

From:   Richard Lamont
Date:   Wed, 10 Jan 2018 20:41:06 +

> On 10/01/18 18:53, Andy Walls wrote:

[snip]

> > The filters stay within 0.1 dB of each other up through 5000 Hz,
> but by
> > then your tabular response has noticeably started to bend
> upward.  The
> > difference between the two filters is 3.44 dB at 15000 Hz.
> 
> It bends up because your plot has got one log axis and one linear
> one.

Ah yes, of course.

And on that note, the bilinear transform design method warps the
GNURadio FM de-emphasis filter line downward on the log-log graph,
which is expected.

Regards,
Andy

> If plotted with a log frequency axis rather than a linear one then
> the
> slope at the right should tend to a straight line of 6.02 dB/octave
> or
> 20 dB/decade. Indeed the idea of dB/octave or dB/decade only makes
> sense
> if you use a log frequency axis.
> 
> Alternatively, you could use a linear voltage axis instead of dB, and
> a
> linear frequency axis. That should also tend towards a straight line
> on
> the right hand side.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FM pre-emphasis and de-emphasis

[Andy Walls]

> Date: Tue, 9 Jan 2018 00:32:41 +
> From: Richard Lamont

[snip]

> Fair enough. I've just started playing with grc and did the usual FM
> broadcast RX thing as my Hello World - and, as a former broadcast
> engineer with pretty good ears - I immediately noticed that there was
> far too much 'top' in the the audio. I have been using the FM
> de-emphasis block that is shipped in the Ubuntu gnuradio 3.7.9
> package -
> I have added any others yet.

[snip]

> When working correctly, the amplitude/frequency response should be
> within, ideally, 0.1 dB of the values shown. I've shown values for
> both
> 75 and 50 microsecond time constants.
> 
> Freq (Hz) Gain dB (75us) Gain dB (50us)
> 
> 30 0.000.00
> 300   -0.09   -0.04
> 500   -0.23   -0.11
> 1000  -0.87   -0.41
> 3000  -4.77   -2.76
> 5000  -8.16   -5.40
> 8000 -11.82   -8.64
> 1-13.65  -10.36
> 12500-15.52  -12.15
> 15000-17.07  -13.65
> 

FWIW, the attached plots compare the 50 us de-emphasis filter response
of GNURadio 3.7.10 vs. the numbers you provided.

The filters stay within 0.1 dB of each other up through 5000 Hz, but by
then your tabular response has noticeably started to bend upward.  The
difference between the two filters is 3.44 dB at 15000 Hz.

So hopefully you won't hear to much 'top' in your audio using 3.7.10's
filter.

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

Re: [Discuss-gnuradio] FM pre-emphasis and de-emphasis

[Andy Walls]

> From: Richard Lamont
> Date: Mon, 8 Jan 2018 20:09:23 +
> 
> I'm new to this, so my apologies if I'm being thick. I have spent
> hours
> trying to resolve this.
> 
> The FM pre-emphasis and de-emphasis blocks do not appear to implement
> the amplitude-frequency response I would expect - equivalent to a
> simple
> analog RC filter.
> 
> Is this a known bug? (version 3.7.9)

Yes.

I implemented the pre-emphasis filter in 3.7.10 and reworked the de-
emphasis filter at the same time.

Here's the python code that does the filter generation for both
filters:

https://github.com/gnuradio/gnuradio/blob/master/gr-analog/python/analog/fm_emph.py

But you would need to fix more than just that file. The complete
changeset to fix 3.7.9 is viewable under closed pull request #777:

https://github.com/gnuradio/gnuradio/pull/777/files

They are all text files and scripts, so you could conceivably fix up
all your installed files without recompiling anything.  It would be
better to upgrade to a later version though.

Regards,
Andy


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

Re: [Discuss-gnuradio] Write WAV file in integer format?

[Andy Walls]

> From: John Ackermann N8UR
> Date: Sun, 7 Jan 2018 16:59:32 -0500
> 
> I need to output IQ data from a Gnuradio script in 2-channel WAV
> format using integer rather than floating point, as required by the
> target program.
> 
> 
> Starting with a complex stream, is there a trick in GRC to output
> integer WAV data? I think I recall a reference to doing a "mult
> const" but Google isn't helping me find it.


Ensure your I & Q components are scaled down to +/-1.0 max, then just
use a "Complex to Float" block feeding a 2 channel "Wav File Sink"
block set for 16 bits per sample.

-Andy

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

Re: [Discuss-gnuradio] Two more potential tag propagation improvements

[Andy Walls]

On Sat, 2018-01-06 at 12:13 -0500, Jeff Long wrote:
> How much error would be produced by having the executor determine 
> rr_in_offset and rr_out_offset by assuming the current rate holds
> over 
> the current window of data?
> 
> offset = (new_tag.offset - rr_in_offset) * mp_rrate + rr_out_offset
> + 
> one_half;

Because the runtime is making _assumptions_, ultimately the error is
unbounded as time progresses.  The growth of the error depends on the
particular situation.

So think of a graph with input offset as the x-axis, output offset on
the y-axis, and a piecewise linear curve with line segments joining
tuples (0, 0), (in1, out1), (in2, out2), (in3, out3), ...
with the slope of the the line segment joining any two points being the
current relative rate.

My suggestion has the runtime being told the (inN, outN) coordinates
and the slopes (aka relative rates), directly by the block's
general_work() function.  So the runtime's graph of input tag offset vs
output tag offset will be correct.


Your suggestion has the runtime making a guess at what the (inN, outN)
coordinates should be based on assumptions made by the runtime, and (I
think) the block informing the runtime of the slopes (aka relative
rates).  So in this case the runtime's graph will only be correct, if
the assumptions aren't violated.  If the assumptions are violated, the
graph in use can ever increasingly diverge from the correct grpah as
time goes on.

On a relative rate change, the runtime could guess at what the (inN,
outN) coordinate should be, using the resonable assumption that they
are the input and output tag offsets at the beginning (or end) of the
current call to general_work().  This could be error free as long as
block behaved as follows:

1. only one relative rate change is allowed in any one call to
general_work()

2. the relative rate change only happens at samples at the beginning
(or end) of work.

> This would not require an API change.
> 
> You could add a field rr_offset_mode to Block, give it default 
> RR_OFFSET_MODE_GLOBAL for the usual case, and RR_OFFSET_MODE_WINDOW
> for 
> those blocks that want to use the current rate for the current
> window.

I don't an explicit mode needs to be set by the block.  This can be
selected implicitly by the block with default arguments to the
set_relative_rate() calls, I think.

> RR_OFFSET_MODE_GLOBAL:
> offset = tag.offset * mp_rrate + one_half;
> 
> RR_OFFSET_MODE_WINDOW
> offset = (tag.offset - window_start_in) * mp_rrate + window_start_out
> + 
> one_half;
> 
> If there are blocks where this local linear assumption causes too
> much 
> error, those blocks can do their own tag propagation.

Yeah, that's always the fallback. :)


I'm a little leary of building in a mode where the runtime is making
assumptions, and needs those assumption not to be violated to get
things right.  I think it's asking for disappointing end user
experience in the long run.

But hey, I'll write up a changeset with both modes of operation in
place and see what it looks like. 

-Andy

> On 01/06/2018 10:01 AM, Andy Walls wrote:
> > Hi Marcus and Jeff:
> > 
> > So now that I've got something working for correct tag propagation
> > with
> > a static relative rate through one block, I'm ready to tackle some
> > other problems.
> > 
> > 1. The runtime performing (or at least assisting) correct tag
> > propagation for blocks with a changing relative rate.
> > 
> > 2. Precision tag propagation through multiple rate changing blocks
> > using fractional tag offsets.  See the discussion at
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2017-11/msg0008
> > 9.html
> > for the gist of this one.
> > 
> > (If some thinks either of the above shouldn't be implemented, let
> > me know.
> > I don't want to waste time on dead-ends.)
> > 
> > The conceptual solutions for these require API changes that are not
> > backward compatable.  They can't be fixed on the master branch, and
> > they have to be fixed on the next branch.
> > 
> > #2 above is a big, wide ranging change, and Marcus has already
> > provided
> > a sketch of some of it, so I'll do that one last. :)
> > 
> > Regarding #1:
> > Off list, Jeff requested that the runtime be fixed to correct tag
> > propagation for block that change their relative rate.  My initial
> > response was not to bother trying, since the runtime doesn't have
> > enough information - only the block itself can perform correct tag
> > propagation.
> > 
> > However, if we allow blocks that change their relative rate to give
> > the
> > runtime more information about the rate change, then the runtime
> > can
> > actually do most of the work for tag propagat

[Discuss-gnuradio] Two more potential tag propagation improvements

[Andy Walls]

Hi Marcus and Jeff:

So now that I've got something working for correct tag propagation with
a static relative rate through one block, I'm ready to tackle some
other problems.

1. The runtime performing (or at least assisting) correct tag
propagation for blocks with a changing relative rate.

2. Precision tag propagation through multiple rate changing blocks
using fractional tag offsets.  See the discussion at
https://lists.gnu.org/archive/html/discuss-gnuradio/2017-11/msg00089.html
for the gist of this one.

(If some thinks either of the above shouldn't be implemented, let me know.
I don't want to waste time on dead-ends.)

The conceptual solutions for these require API changes that are not
backward compatable.  They can't be fixed on the master branch, and
they have to be fixed on the next branch.

#2 above is a big, wide ranging change, and Marcus has already provided
a sketch of some of it, so I'll do that one last. :)

Regarding #1:
Off list, Jeff requested that the runtime be fixed to correct tag
propagation for block that change their relative rate.  My initial
response was not to bother trying, since the runtime doesn't have
enough information - only the block itself can perform correct tag
propagation.

However, if we allow blocks that change their relative rate to give the
runtime more information about the rate change, then the runtime can
actually do most of the work for tag propagation.

For some background, my latest pull request for a tag propagation fix
made these relevant changes:

1. Modified or added these API methods:

gr::block::set_relative_rate(double relative_rate);
gr::block::set_relative_rate(uint64_t interpolation, uint64_t decimation);
gr::block::set_inverse_relative_rate(double inverse_relative_rate);

2. Changed the tag offset propagation arithmetic to use multiple
precision integer rationals:

 ...
 static const mpq_class one_half(1, 2);
 ...
  else {
mpz_class offset;
for(t = rtags.begin(); t != rtags.end(); t++) {
  tag_t new_tag = *t;
  offset = new_tag.offset * mp_rrate + one_half;
  new_tag.offset = offset.get_ui();
  out_buf->add_item_tag(new_tag);
}
  }
 ...


The expression

offset = new_tag.offset * mp_rrate + one_half;

can be viewed as a degenerate case of a more general expression

offset = (new_tag.offset - rr_in_offset) * mp_rrate + rr_out_offset + 
one_half;

Where rr_in_offset is the input sample offset where the particular
mp_rrate value is first valid, and rr_out_offset is the output sample
offset where the particular mp_rrate value is first valid.

The runtime currently assumes these rr_(in|out)_offset values are
always 0.

So the solution, at a high level, is for the blocks performing relative
rate changes to provide values for rr_in_offset and rr_out_offset along
with every change to the relative rate.  Then the runtime can take care
of the rest of the tag propagation headaches.

So the API for setting relative rate then becomes:

gr::block::set_relative_rate(double relative_rate, uint64_t in_offset = 
0, uint64_t out_offset = 0);
gr::block::set_relative_rate(uint64_t interpolation, uint64_t 
decimation, uint64_t in_offset = 0, uint64_t out_offset = 0);
gr::block::set_inverse_relative_rate(double inverse_relative_rate, 
uint64_t in_offset = 0, uint64_t out_offset = 0);

But since the runtime would now maintian a dynamic structure of
(relative rate, in offset, out offset) tuples, the external API for
getting relative rate gets a little messy/ambiguous.  I'm not sure what
to do about that yet.

This concept can support blocks that change their relative rate with
every output sample, such as the PFB clock sync blocks and the symbol
synchronizer blocks.

I suppose I'll test it with the symbol synchronizer blocks, since I now
see that they don't do correct tag propagation if their output rate is
set to anything higher than 1 sample/symbol. :P

Regards,
Andy

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Andy Walls]

>1. The gnuradio-runtime propagated tags with double arithmetic; the
>fractional resampler block used mixed float & double arithmetic to
>propagate tags.
>

Oops:

mixed float & double arithmetic to generate output sample intervals.

-Andy

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Andy Walls]

On Wed, 2017-12-27 at 16:18 -0500, Andy Walls wrote:
> Hi Eugene
> 
> > From:   Eugene Grayver
> > Date:   Thu, 9 Nov 2017 19:52:35 +
> > 
> > There is a major problem with the way tags are propagated in blocks
> > with non-integer relative rate. If the ratio is not a power of two,
> > the numerical accuracy of the floating point will cause the output
> > tags to diverge from the input tags.  Consider the fractional
> > resampler. It accumulates the timing offset in the range of 0 to 1.
> > However tag propagation multiplies the ratio by the sample number.
> > As
> > the sample number grows the LSB accuracy of the ratio gets scaled
> > by
> > the ever larger value. For a ratio of 1.001 we saw divergence of
> > 1000s of samples over a few minutes at 10msps.

OK, I've got a working fix for this:

https://github.com/gnuradio/gnuradio/pull/1543
or
https://github.com/awalls-cx18/gnuradio.git  branch tag_fix4

You will need to install the mpir and mpir-devel packages for your
distro, as this change adds a dependency on the MPIR library
(libmpirxx.so and libmpir.so).

With the attached GRC flowgraph, the fixed code shows no slips after 8
hours of continuous running on a modest laptop.  Compare that with the
baseline of gnuradio master, where after 8 hours, the tags have slipped
5 output samples to the right.

You were right about it being a floating point precision problem, but
the problem with the fractional resampler over short runs was (moslty)
not in the gnuradio runtime, but the fractional resampler block itself:

1. The gnuradio-runtime propagated tags with double arithmetic; the
fractional resampler block used mixed float & double arithmetic to
propagate tags.

2. Floating point reciprocals aren't exact in the lsb's, so specifying
set_relative_rate(1.0/resamp_ratio) was also introducing errors.  I.e.:

[andy@pinto sw]$ ./rational3 1.001
Resample ratio: 1.0009
Resample ratio: 2254051613498933/2251799813685248
Numerator: 2254051613498933
Denominator: 2251799813685248

Relative rate: 0.99900099900099915
Relative rate: 4499100526843653/4503599627370496
Numerator: 4499100526843653
Denominator: 4503599627370496

Notice how the relative rate's numerator and denominator are not the
same as the resample ratio's denominator and numerator.

Geof:

Could you please take a look at the newly added cmake module
FindMPIR.cmake to see if it need changes for the Windows build?


Jeff and Marcus:

I'll address possible solutions for your observations (non-fixed
relative rate and fraction tag offsets) in a separate post.
I have a concept on how to address both, I think, but they can't be on
master branch due to API changes.

Regards,
Andy


tag_prop_test.grc
Description: XML document
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
double resamp_ratio = strtod(argv[1], NULL);
double relative_rate = 1/resamp_ratio;

std::cout.precision(std::numeric_limits::max_digits10);
//-
// Using MPIR's C++ interface
static const mpq_class one_half(1,2);
mpq_class resamp_ratio_q(resamp_ratio);
mpq_class relative_rate_q(relative_rate);
//ratio.canonicalize();
std::cout << "Resample ratio: " << resamp_ratio << std::endl;
std::cout << "Resample ratio: " << resamp_ratio_q << std::endl;
std::cout << "Numerator: " << resamp_ratio_q.get_num().get_ui() << std::endl;
std::cout << "Denominator: " << resamp_ratio_q.get_den().get_ui() << std::endl;
std::cout << std::endl;
std::cout << "Relative rate: " << relative_rate << std::endl;
std::cout << "Relative rate: " << relative_rate_q << std::endl;
std::cout << "Numerator: " << relative_rate_q.get_num().get_ui() << std::endl;
std::cout << "Denominator: " << relative_rate_q.get_den().get_ui() << std::endl;
std::cout << std::endl;
#if 0
//mpz_class offset(0x0803);
uint64_t offset = 0x0803;
mpq_class scaled = offset*ratio;
mpz_class rscaled(scaled + one_half);
mpz_class rscaled2;
rscaled2 = offset * ratio + one_half;
rscaled2 = offset * ratio + one_half + 2;
std::cout << "Offset:" << offset << std::endl;
std::cout << "Scaled offset: " << scaled << std::endl;
std::cout << "Rounded scaled offset: " << rscaled << std::endl;
std::cout << "Rounded scaled offset2: " << rscaled2 << std::endl;
uint64_t rscaledint = rscaled.get_ui();
std::cout << "Native rounded scaled offset: " << rscaledint << std::endl;
#endif
exit(0);
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Signal Conditioner - input filter

[Andy Walls]

Hi Herb,

> From: Sims, William Herb (MSFC-ES63)
> Date: Thu, 4 Jan 2018 13:37:25 +
> 
> Question:  Concerning the Signal Conditioner block, and more
> specifically the input fiter.
> 
> If I am using the decimation part of the filter, are the band edges
> (band1_begin, etc.) associated with the DECIMATED signal (Fs/2 =
> 2Msps) or PRIOR to decimation (Fs/2=8Msps)?

There is no block in the main GNURadio source tree named "Signal
Conditioner" nor does git grep 'band1_begin' on the source tree return
any results.

You may be dealing with a block from a (private? closed-source?) Out of
Tree module.

I suspect no one here will be able to help, unless the source code for
the block is available somewhere.

-Andy

> Thanks,
> 
> Herb
> 
> Dr. Herb Sims
> 
> 

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

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Andy Walls]

Hi Marcus:

On Sun, 2017-12-31 at 15:09 +, Müller, Marcus (CEL) wrote:
> Hi Andy, hi Eugene
> 
> Hm, coming back to an idea I had not so long ago:
> 
> tag offset should not be 64bit unsihned integers only, but also have
> a
> 64 bit fractional part.
> 
> That would not immediately solve the computational inaccurracy during
> resampling, but would at least for multi (as in >2) rate systems (eg.
> rational resampling for sample rate reduction, arbitrary resampling
> for
> clock recovery) at least give the option of having consistent
> tagging.

IMO, adding a fractional part does not solve the problem at hand -
correct tag propagation through 1 block - but it probably is required
for precise propagation through multiple rate changing blocks.

I'm keeping it in mind, but I want to avoid changing existing
interfaces right now.  I.e. get_tags_in_[range|window]() runs into a
backward compatability issue for a tag that comes < 0.5 samples before
the beginning of the requested range: should the tag offset -0.49
samples realtive to the start of the window be returned or not?


> Personally, my gut feeling is that for this kind of divisional math,
> floating point is not the number format of choice

Agreed.

>  (for multiple (as in
> > 2) reasons).
> 
> This actually doesn't apply to the arbitrary resampling case as much,
> but the d_relative_rate property of a block shouldn't be a floating
> point,

Internal to the gnuradio-runtime there are a number of places where,
for estimating, using a floating point d_relative_rate is just fine. 
It is expedient and avoids the problem of interger overflow for cases
where one has large integer interpolation and decimation factors.

> but a ratio of two integers, one of them being signed. Maybe I
> should be adding a set_relative_rate(int64_t numerator, uint_64_t
> denominator) to block, and make set_relative_rate(double) a wrapper
> for
> that (and of course change the block_executor to do fractional rather
> than floating point math);

So that's what my change does. :)  I also changed all the blocks, that
could easily easily call the integer version of
set_relataive_rate(interpolation, decimation), to do so.

To avoid integer overflow, I picked an algoritm in the new
set_relative_rate(double) wrapper, to convert the relative rate to a
ratio of two integers that got within 1 ppm of the passed in relative
rate.  Because sane users only use relative rates of 1/25 or 1001/1000
or 255/256 or 2/3 or something like that, and whacky relative rates
using large (>16 bit) integers in the ratio are just a product of
rounding, right?  Well I was wrong. :(

Unfortunately, the fractional resampler is a corner case that actually
uses the rounded (in binary) version of the resampling rate, that the
user specifies, in its actual operation. Computing exact integer ratios
to represent the double can lead to 53 bit numbers (IIRC), which can
lead to integer overflows when multiplying uint64_t's together. :(

So what I'm left with are two broad options to deal with handling a
double relative rate (like the fractional resampler uses):

1. Implement an method like Eugene suggests: do a double multiply, get
a rounded result, do a double division to get back to an initial
offset, subtract off that initial offset, do a double multiply again,
and then a final add.

or

2. Allow and compute large, exact integer ratios of
interpolation/decimation rate and use multiple precision (128 bit)
arithmetic when overflow out of 64 bits is possible.
Maybe using boost::multiprescision with the MIPR library on the
backend.
http://www.boost.org/doc/libs/1_66_0/libs/multiprecision/doc/html/index
.html
http://mpir.org/
(MPIR is supposedly better for Windows compatability than GMP.)


I'm leaning towards option 2.

> I find that I never calculate a rate other
> than by calculating the floating point approximation of a fraction of
> integers, and that there's always been subtle problems when running
> odd
> ratios for prolonged times. 

Technically a finite precision double can always be represented by a
ratio of integers, but those integers can be very (2^53-ish) large. 

Thanks for the feedback.

Regards,
Andy

> Best regards,
> Marcus
> 
> On Sat, 2017-12-30 at 18:24 -0500, Andy Walls wrote:
> > Hi Eugene:
> > 
> > On Wed, 2017-12-27 at 16:18 -0500, Andy Walls wrote:
> > > Hi Eugene
> > > 
> > > > From:   Eugene Grayver
> > > > Date:   Thu, 9 Nov 2017 19:52:35 +
> > > > 
> > > > There is a major problem with the way tags are propagated in
> > > > blocks
> > > > with non-integer relative rate. If the ratio is not a power of
> > > > two,
> > > > the numerical accuracy of the floating point will cause the
> > > > output
> > > > tags to 

Re: [Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Andy Walls]

Hi Eugene:

On Wed, 2017-12-27 at 16:18 -0500, Andy Walls wrote:
> Hi Eugene
> 
> > From:   Eugene Grayver
> > Date:   Thu, 9 Nov 2017 19:52:35 +
> > 
> > There is a major problem with the way tags are propagated in blocks
> > with non-integer relative rate. If the ratio is not a power of two,
> > the numerical accuracy of the floating point will cause the output
> > tags to diverge from the input tags.  Consider the fractional
> > resampler. It accumulates the timing offset in the range of 0 to 1.
> > However tag propagation multiplies the ratio by the sample number.
> > As
> > the sample number grows the LSB accuracy of the ratio gets scaled
> > by
> > the ever larger value. For a ratio of 1.001 we saw divergence of
> > 1000s of samples over a few minutes at 10msps.
> 
> Could you please test the following branch to see if it fixes the
> problem?  Maybe test something simple first, like an FIR filter
> decimating by 5 or 3?
> 
> https://github.com/awalls-cx18/gnuradio.git branch: tag_fix3

Don't bother testing.  See below.

> Or if you have a GRC or python script I can use myself for testing,
> that would be great.
> 
> >  I rewrote tag propagation for the resampler but did not rework the
> > generic logic. I think the key point is to use the delta between
> > read
> > and written items to take out the large integer difference and then
> > apply the scaling to a local delta within the current window.
> > 
> 
> The fix that I have made stores the relative_rate as an integer
> numerator and an integer denominator, and it uses integer arithmetic
> to
> propagate tags. (Except if enable_update_rate() is True, in which
> case,
> precision tag placement was abandonded by the block author anyway.)

So this fix makes the fraction resampler tag propagation actually
perform worse.  The reason appears to be that, at least for
resamp_ratios very close to 1.0, the fractional resampler isn't really
running at the requested rate, but some rounded (in binary) rate.

So I have a test flowgraph with a single fractional respampler in it,
with a resample ratio of 1.001 specified.  Here are the parameters
reported by my patched GNURadio:

[andy@pinto grcs]$ ./tag_prop_test.py 
Fractional Resampler resamp ratio:  1.0014673
Block relative rate:  0.999000952364
Block relative rate i:  1000
Block relative rate d:  1001

So we can see that the block is really running with a resampling ratio
of 1.0014673.  The relative rate of 0.999000952364 does appear to
be the correct reciprocal of 1.0014673.  My patch's back-figuring
of a relative rate of 1000/1001 (= 0.999000999 = 1/1.001) is in fact
what the user wanted.  But when propagating tags using those integers,
tags start sliding very soon, since 0.999000999 is not the
0.999000952364 that the block is actually operating at.

I'll have to think about how to deal with this sort of situation.

Regards,
Andy

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

[Discuss-gnuradio] Serious bug in tag propagation with non-integer relative rate

[Andy Walls]

Hi Eugene

> From: Eugene Grayver
> Date: Thu, 9 Nov 2017 19:52:35 +
> 
> There is a major problem with the way tags are propagated in blocks
> with non-integer relative rate. If the ratio is not a power of two,
> the numerical accuracy of the floating point will cause the output
> tags to diverge from the input tags.  Consider the fractional
> resampler. It accumulates the timing offset in the range of 0 to 1.
> However tag propagation multiplies the ratio by the sample number. As
> the sample number grows the LSB accuracy of the ratio gets scaled by
> the ever larger value. For a ratio of 1.001 we saw divergence of
> 1000s of samples over a few minutes at 10msps.

Could you please test the following branch to see if it fixes the
problem?  Maybe test something simple first, like an FIR filter
decimating by 5 or 3?

https://github.com/awalls-cx18/gnuradio.git branch: tag_fix3

Or if you have a GRC or python script I can use myself for testing,
that would be great.

>  I rewrote tag propagation for the resampler but did not rework the
> generic logic. I think the key point is to use the delta between read
> and written items to take out the large integer difference and then
> apply the scaling to a local delta within the current window.
> 

The fix that I have made stores the relative_rate as an integer
numerator and an integer denominator, and it uses integer arithmetic to
propagate tags. (Except if enable_update_rate() is True, in which case,
precision tag placement was abandonded by the block author anyway.)

Thanks,
Andy

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

Re: [Discuss-gnuradio] resample ratio for fractional_resampler

[Andy Walls]

On Tue, 2017-10-24 at 08:16 -0400, Andy Walls wrote:
> Hi Marcus:
> 
> Nice insights and plots.
> 
> > From:   Marcus Müller
> > Date:   Mon, 23 Oct 2017 20:10:23 +0200
> 
> [snip]
> > From the above figure, I'd say: go for 256 taps; 50 dB of anti-
> > aliasing should probably suffice.
> > On my machine, the 256 tap FIR filter with decimation=64 ran about
> > 20% faster than the fractional resampler; comparing what they do to
> > white noise, I'd say that whilst the spectral shape of the 256 tap
> > FIR is not perfect, the MMSE is pretty much unusable, I guess:
> 
> I'd just like to interject here that GNURadio's MMSE filterbank is
> only
> MMSE for input spectral components in the range [-sample_rate/4,
> sample_rate/4].
> 
> Also it appears that the mmse/fractional_resampler blocks don't
> perform
> any explicit anti-alias filtering.  So that's another reason to have
> a
> band-limiting filter out in front of it.

Oopsie, and maybe one after it too, since we're talking about
decimation.

-Andy

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

Re: [Discuss-gnuradio] resample ratio for fractional_resampler

[Andy Walls]

Hi Marcus:

Nice insights and plots.

> From: Marcus Müller
> Date: Mon, 23 Oct 2017 20:10:23 +0200
[snip]
> From the above figure, I'd say: go for 256 taps; 50 dB of anti-
> aliasing should probably suffice.
> On my machine, the 256 tap FIR filter with decimation=64 ran about
> 20% faster than the fractional resampler; comparing what they do to
> white noise, I'd say that whilst the spectral shape of the 256 tap
> FIR is not perfect, the MMSE is pretty much unusable, I guess:

I'd just like to interject here that GNURadio's MMSE filterbank is only
MMSE for input spectral components in the range [-sample_rate/4,
sample_rate/4].

Also it appears that the mmse/fractional_resampler blocks don't perform
any explicit anti-alias filtering.  So that's another reason to have a
band-limiting filter out in front of it.

-Andy

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

Re: [Discuss-gnuradio] error compiling gnuradio-digital

[Andy Walls]

The compilation works on Fedora 26 and the Ubuntu versions tested by the github 
pull request build bot.

However, a fix is ready to go.  Please provide feedback:

https://github.com/gnuradio/gnuradio/issues/1388
https://github.com/gnuradio/gnuradio/pull/1389

Regards,
Andy

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

Re: [Discuss-gnuradio] block history question

[Andy Walls]

From:   Harper, Andrew
Date:   Fri, 29 Apr 2016 21:29:42 +
> Hello all,
> 
>  
> 
> We’re exploring the nuances of the block feature “history.” We’ve
> created a couple slides based on information we’ve gathered from the
> mailing list and our own experimentation. It outlines how we believe
> this function works. Can anyone confirm or deny the correctness of
> the information in our slides?
> 

I like your efforts to clearly explain things to others.  So please
don't take the comments below as throwing stones; they are just what I
see wrong.
  

Slide 1:
"The scheduler *requires* the data input buffer to be processed
piecewise ..."

A block really doesn't have much choice in the matter. :)


Slide 1:
"Let’s say the first 3 work calls give *ninput_items[0]* values ..." 

The general case block gets supplied both a vector of ninput_items and
an noutput_items.  For synchronous blocks, the value noutput_items and
the declared block interpolation or decimation rate imply
ninput_items[].
Since you're focusing on history() and the effects on the number of
input items, you should explcitly use ninput_items[] in your
dissussion.


Slide 1:
You should rename your red bracket in the picture from "noutput_items"
to "ninput_items[0]".  You should also right align that short bracket
with the buffer.  Making it clear that the history() (or in this case
the initial 0 history()) samples are old, repeated input data. 


Slide 2, "2nd call to work":
Same thing: change to "ninput_items[0]" and right align.  You want to
emphasize that items 9 and 10 are repeated items that were available in
the previous call to work.


Slide 3, "3rd call to work":
Same thing.


Slide 4:
"... This is done by providing the n-1 last items from the previous
call to work() at the beginning of the current call to work().  At
flowgraph start, the n-1 initial items are zero-valued." 


Slide 4, bullet 1:
*ninput_items[input_connection_number]* Don't use noutput_items unless
you are specifically talking about a synchronous 1:1 block.


Slide 4, bullet 2:
The statement about block latency is not true in the general case,
although it can be true in specific cases.  Latency is determined by
the algorithm the block is implementing.


Slide 4, bullet 3:
Output tags can be set on tag offsets nitems_written(0) to
nitems_written(0) + 'items produced' - 1.  Tagging "backward in time"
is not a correct way to think about it, since you're tagging the
output, which can in a trivial example case be just a delayed copy of
the input (e.g. FIR filter with taps [0, 0, 0, 1, 0, 0, 0]).  It's
really called "not accounting for algorithm delay properly when
propagating tags from input to output".

I did rework the guts of a block (the corr_est block) that does
conceptually tag "backward in time", since that was its functional
requirement: tag the beginning of a correlation sequence once you've
found the correlation peak.  The GNURadio runtime does not allow
tagging of output items with offsets less than nitems_written() in a
call to work(), so the corr_est block uses history() to artifically
delay the primary output port so it can do this tagging "backward in
time".The restriction here though is nitems_written() on the
subject output port, and not really about the input items.

Regards,
Andy


> 
> Many thanks!
> 
>  
> 
> Andrew Harper
> 
> Research Engineer
> 
> Georgia Tech Research Institute

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

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Andy Walls]

From:   Cinaed Simson
Date:   Fri, 14 Jul 2017 00:33:27 -0700
>> On 07/12/2017 03:56 AM, HLL wrote:
[snip]
> > 
> > The wavelength for 450 is 1.5 meters. I really don't know where the
> > boundary is between near field and far field - but I would guess far
> > field the other side of a full wave length.
> 
> Opps - Andy Walls I had the numbers upside down - should have checked
> the units.
> 
> In any case, the wave length is 2/3 of meter and not 1.5 meters.

I always mentally check against the data point: 300 MHz => 1 meter
(since c ~= 300 Mm/s).  Above that should be less than 1m; below that
should be greater than 1m.

[snip]


> But then power is
> 116 dBm - you could probably use a paper clip soldered into a SMA
> connector :).

30 dBm = 1 W = 0 dBW.  IIRC.

116 dBm = 86 dBW = 10^(8.6) W = 398 MW !!!

That's the sort of power that is used for time machines in
science-fiction movies.  You might want to check that number. :)


Regards,
Andy



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

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Andy Walls]

From:   HLL
Date:   Mon, 10 Jul 2017 20:44:01 +0300
> Hi,
> Thank you very much!!
> I Need to thoroughly go over your response and understand it all, but
> thanks :)
> 
> I also noticed the 2 different in bit timings, I thought it's
> something electrically, since I noticed the "long" lows and highs are
> on some specific timings and the shorts have another timing.
> 
> Before experimenting with the graph (and the said OOT modules). I'm
> going over it and trying to understand it,
> what the rotator does, and what it it's role?

It performs a (cyclic) frequency shift of the signal spectrum.  It is
called a rotator because the DFT of a sampled signal "lives" on the
unit circle of the z-plane.  The rotator block rotates the entire z-
plane about its origin by a certain number of radians, thus effectively
 shifting the spectrum of the signal.

I use the rotator block to shift the audio frequency bins of +350 Hz
and +940 Hz down to -295 Hz and +295 Hz respectively.  Then I filter
off what were the negative audio frequency bins, the DC spike from the
FM CFO, and a lot of the spectrum which is just noise.

> The part with 2 pll carrier tracking is used for locking the carrier
> of the low and high freq as I understand (I.E. The cheap digital PWM
> or clock devider)

Yes, but they both track *and* downconvert the tracked tone to DC.

This is a coherent FSK receiver design, which is probably overkill for
this application, but I used it to handle uncertainty in the actual
audio tone bins used for the mark and space frequencies.

> what is the role of the complex conjugates (mirror over the real
> axis?),

The complex conjugate is to handle a quirk of the GNURadio PLL block
before the subtraction.  When the PLL carrier tracking block does it's
downconversion of the tracked tone to DC, it doesn't have a phase angle
of 0 degrees (a purely real number), instead it has a phase angle of
something a bit less than pi/4 radians.

The complex conjugate is so when I do the following subtract, I will
get constellation points on opposite sides of the circle in the I-Q
plane.


>  subtract,

This is standard for a coherent FSK demodulator and for certain non-
coherent FSK demodulators.  Google images should show a number of block
diagrams doing this.


>  c-to-f and add part?

Well, after the subtraction you have I-Q plane constellation points of
about A*exp(j*pi/4) and A*exp(j*5*pi/4), and a fuzzy trajectory line
going approximately straight between those points.  I needed to convert
those to real values.

I could have taken the complex magnitude and the complex argument and
somehow tried to assign the proper sign to the complex magnitude, but
that was work. :)  Since the two constellation points and the
trajectory is restricted to quadrants I and III of the I-Q plane, it
was easier to just add combine the real and imaginary parts to get a
real number. 


>   Are you "subtracting" the (locked) `0` square wave from the `1`
> square wave, why?

No.

Let's pretend GNURadio's quirky almost pi/4 angle output from the
downconverted tone is actually 0 radians instead of almost pi/4.

When the mark PLL is locked on to the mark tone, it will output a value
of A.  When the space PLL is locked on to a space tone, it will output
a value of A as well.

To have a mark symbol represented by A and a space symbol represented
by -A, we have to invert the output value of the space PLL, hence the
subtraction.

Also note, that one should not receive mark and space tones at the same
time, so when the mark PLL is outputting A, the space PLL is ideally
outputting 0, and vice-versa.


> I think I understand most of the rest (the `missing block` from their
> names :) )
> 
> Thanks,
> HLL
> 
> P.S. FYI, The capture I'v attached contains 4 bursts of 2 devices, 2
> from device A and 2 from device B.

Yes, I noticed 4 bursts, two at one energy level and two at another
energy level.

Regards,
Andy

> P.S.2 It is probably some cheapo electronic components or re-using
> the micro that is already there.

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

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Andy Walls]

From:   Cinaed Simson
Date:   Sun, 9 Jul 2017 23:04:26 -0700

> On 07/09/2017 12:15 PM, Andy Walls wrote:
> > On Sat, 2017-07-08 at 21:38 -0400, Andy Walls wrote:
> >>> Date: Fri, 7 Jul 2017 19:50:55 +0300
> >>> From: HLL
> >>> Hi all,
> >>>
> >>> I'm relatively new to DSP and gnuradio but I tried tons of stuff
> >>> and
> >>> I couldn't decode a fairly simple FSK data.
> >>> baudrate seems around 600-700 bps and fsk deviation is less then
> >>> 3k.
> >>
> >>
> >> Hmmm.  I took a look at your signal and tried building a coherent 2-
> >> FSK 
> >> demodulator.  Under the assumption that it was straight 2-FSK, the
> >> signaling tones looked to be at +/- 1200 Hz when properly centered.
> 
> Just to be clear - doesn't 2FSK have 4 tones? I'm not sure what you mean
> by signaling tones.

"2 Frequency Shift Keying" uses 2 frequencies (aka tones) to send symbols.
When I write "signaling tones" for a 2-FSK, I mean the "mark" frequency
and the "space" frequency tones.  (Assign symbol values of -1 and 1 to
mark and space as appropriate for the encoding scheme in use.)


> I just looked at it in inspectrum and there are 4 visually identical
> structures - and I would guess the fact there are 4 structures is just a
> coincidence.
> 
> They're roughly 1.45 seconds long with blank spacers varying from 116 ms
> to 200 ms.

Those are the actual RF bursts for each packet.  There are 4 packets in
the file.


> I must be doing something wrong.

The modulation scheme for this unit appears to be Audio Frequency Shift
Keying: 2-FSK performed with 2 (real) square wave audio tones (at 350 Hz
and 940 Hz fundamental frequencies) that are then FM modulated.
The baud rate appears to be 233 symbols/second.  It does not appear to
me that the bits are Manchester encoded.


Using square waves for the FSK tones is a unusual, unless a cheap
digital microcontroller is generating the tones on a digital output pin.

Look at the blue signal trace in the first image in this mailing list
post, and ignore the level wobble the author is focusing on:
http://lists.gnu.org/archive/html/discuss-gnuradio/2017-07/msg00071.html

The blue line is not showing bits directly.  It is showing intervals of
square waves at two different frequencies: 350 Hz and 940 Hz.  The
frequencies are what are encoding the symbols, not the amplitudes.  This
is 2-FSK with the tones generated by a really cheap square wave
generator.


Given the FCC documents cited, I doubt this signal was generated by the
devices in the FCC documents.  Probably some other device in the same
ISM band generated this signal.

-Andy

> -- Cinaed


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

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Andy Walls]

> Date: Fri, 7 Jul 2017 19:50:55 +0300
> From: HLL

> Hi all,
> 
> I'm relatively new to DSP and gnuradio but I tried tons of stuff and
> I couldn't decode a fairly simple FSK data.
> baudrate seems around 600-700 bps and fsk deviation is less then 3k.


Hmmm.  I took a look at your signal and tried building a coherent 2-FSK 
demodulator.  Under the assumption that it was straight 2-FSK, the
signaling tones looked to be at +/- 1200 Hz when properly centered. The
fastest bit rate appeared to be 1880 bits/sec.

But in reality that doesn't work.  I could never get good symbol timing
recovery as the "FSK" signal appeared to have two different baud rates.

After some reflection, the signal you have appears to actually be AFSK
inside of FM.  Zoom out a little on the output of the quad demod, and
your eye can see the two tones.  The two tones appear to be at 350 Hz
and 940 Hz.  The tones are unusual in that they are square wave tones
vs. sine wave.

I haven't worked you the baud rate yet.  I'll hack away at it more
tomorrow. 

Regards,
Andy

> 
> Thanks for the help
> HLL.

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

Re: [Discuss-gnuradio] cross correlation in the time domain and through Fourier tranform ?

[Andy Walls]

From:   jmfriedt
Date:   Thu, 22 Jun 2017 20:00:55 +0200
> 
> 
> However I'd like to demonstrate the same effect when going through the 
> Fourier 
> domain. I convert
> the stream to vector (4096 sample long is much more than the about 256-sample 
> long PRN), multiply
> one vector with the complex conjugate of the other, iFFT the result, making 
> sure I don't swap
> quadrants (I checked that FFT -> iFFT without swapping creates the same 
> original signal), back to stream
> and display the result -> same pictures as above, top graphs.
> 1. is this the correct way of processing Fourier transforms of incoming 
> signals

Well, for cross correlation, you want f[n] * conj(g[-n]) and it looks
like your math is performing that using F(s)conj(G(s)) so I think that
is OK.  Note that the time reversal really doesn't work for arbitrary
g[n], unless g[n] is of finite length or is periodic (which it is in
your simulation).


> 2. why are the cross-correlation peaks generated in the Fourier domain not 
> located at the exact same time
> than those generated in the time domain ? I could understand some lag due to 
> the low pass filter or 
> accumulating the data in the vector, but here I get a bit of jitter of cross 
> correlation peaks generated
> through the Fourier transform wrt those generated in the time domain.

Probably because the cyclic convolution != the linear convolution
without sufficient zero padding.  Without zero padding, you're going to
get aliasing at the start or end the output of your frequency domain
convolution.

See section 9.9 of 
http://www.ece.rutgers.edu/~orfanidi/intro2sp/orfanidis-i2sp.pdf
equations 9.9.1, 9.9.3, 9.9.7, and especially 9.9.10.
Also see section 9.9.2 on the Overlap-Add and Overlap-Save methods of
filtering a continuous stream using FFT's and fast convolution.



> Obvisouly this should all end up in a passive radar measurement: I can live 
> with time-domain 
> cross-correlation calculation, but this is the first time I am using the 
> stream 
> -> vector 
> functionality so I'd like to understand the consequences.

If you can detect the Tx pulses, track the PRIs, and work a Tx pulse
interval at a time, you should be able to do the proper zero padding and
perform fast convolution.

However your simulation doesn't look like a passive radar setup to me.

Regards,
Andy

> Thanks, JM
> 
> -- 
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000 
> Besancon, France


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

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

[Andy Walls]

Hi Phil:

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

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

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

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

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

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

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

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

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

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

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

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

or in this pull request:

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

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

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

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


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

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


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

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

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

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

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

Re: [Discuss-gnuradio] PFB Clock Sync stops producing samples

[Andy Walls]

>  From: 
> devin kelly
>   Subject: 
> Re: [Discuss-gnuradio] PFB Clock
> Sync stops producing samples
>  Date: 
> Thu, 8 Jun 2017 15:41:38 -0400
> 
> __
> OK, I'll give that block a try.  Are you saying there's a bug in the
> PFB Clock Sync block?

Yes.

I'm also saying that since there are two fundamental bugs (incorrect tag
propagation, and conflation of symbol clock phase with resampling
interpolator sample phase) which both take a lot of work to fix and
should be fixed together, that it's not worth anyone's time to fix the
PFB clock sync blocks (complex IO and float IO).  The M clock sync
blocks (complex IO and float IO) and the MSK timing recovery block
(complex IO) also have those same two bugs.

Properly fixing those bugs for just the PFB clock sync blocks, results
in the PFB clock sync blocks evolving into a partial implementation of
the Symbol Synchronizer blocks, and still leaves the other 3 blocks
broken.  Properly fixing those bugs for all 5 of the in-tree
synchronizer blocks, in one place, results in most of the implementation
of the Symbol Synchronizer blocks.  There is no point in fixing the
existing blocks.

> That was my suspicion but I'm not sure I understand what the block is
> doing well enough to know with certainty.

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

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

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

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

Also see this for an additional explanation written by Tom Rondeau:
https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation#7.6.1._Details_of_the_PFB_Clock_Recovery_Block


For the Symbol Synchronizer blocks, see this napkin diagram:
https://github.com/gnuradio/gnuradio/files/950045/Symbol_Synchronizer_block_diagram.pdf
and this comment:
https://github.com/gnuradio/gnuradio/pull/1294#issuecomment-296628308

For the symbol clock phase tracking loop transfer function and gain
computation, see this document:
https://github.com/awalls-cx18/gr-nwr/blob/master/docs/clock_loop.pdf


And now you can be certain that if I don't want to fix the existing PFB
clock sync blocks, neither do you. :)

-Andy


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

Re: [Discuss-gnuradio] PFB Clock Sync stops producing samples

[Andy Walls]

One minor correction on the settings to use, since it appears the
PFB_clock_synch block uses a ridiculously over-damped loop filter:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L82

So the revised settings guidance to get exactly what the PFB clock synch
block does is:
Damping Factor:  Use 2 times whatever you're using now for Filter Size


However, that seems silly to me.  I normally use one of:

0.707 (underdamped, but maximally flat, loop filter),
1.0 (critically damped loop filter),
1.5 (overdamped loop filter), or
2.0 (overdamped loop filter) 

for the damping factor.

-Andy

On Thu, 2017-06-08 at 14:08 -0400, Andy Walls wrote:
> For a block that performs the identical function of the PFB clock synch
> block with correct tag propagation, use the Symbol Synchronizer Block
> available in this pull request:
> 
> https://github.com/gnuradio/gnuradio/pull/1294
> https://github.com/awalls-cx18/gnuradio/tree/symbol_sync2
> 
> or this OOT module:
> 
> https://github.com/awalls-cx18/gr-nwr
> 
> Use the following settings:
> Timing Error Detector:   y[n]y'[n] Maximum Likelyhood
> Samples per Symbol:  whatever you're using now
> Loop Bandwidth:  whatever you're using now (may need tweaking)
> Damping Factor:  1.0/math.sqrt(2.0)
> Maximum Deviation:   whatever you're using now
> Output Samples/Symbol:   whatever you're using now
> Interpolating Resampler: Polyphase Filterbank, MF
> Filterbank Arms: whatever you're using now for Filter Size
> PFB MF Taps: whatever prototype filter taps you're using now
> 
> 
> Properly fixing the tag propagation in the PFB_clock_sync block is a
> major change, which is one reason I wrote the new Symbol Synchronizer
> blocks.
> 
> FWIW, I also do think get_tags_in_range() could stand to perform a
> sanity check, but that won't fix the underlying problem.
> 
> -Andy
> 
> 
> >  From: 
> > devin kelly
> >   Subject: 
> > [Discuss-gnuradio] PFB Clock Sync
> > stops producing samples
> >  Date: 
> > Thu, 8 Jun 2017 12:08:12 -0400
> > 
> > __
> > I'm having a problem with the Polyphase Clock Sync block.  I believe
> > what's happening is that the block is calling get_tags_in_range
> > improperly and then causing an infiite loop in
> > gnuradio-runtime/lib/buffer.cc, at this point the PFB Clock Sync block
> > stops emitting samples.
> > 
> > 
> > The problem occurs in the PFB clock sync block here:
> > https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L473
> > 
> > 
> > The PFB block calls get_tags_in_range where the start sample number is
> > greater than then end sample number, here's the code in buffer.cc that
> > may be getting stuck in an infiite loop.
> > 
> > 
> > The entire file is here:
> > https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/buffer.cc#L354
> 
> [snip]
> > When I run into this problem, my code seems to get stuck on itr++ (see
> > debugger output below).  Though I'm not sure if the itr++ call just
> > stalls or if itr just never equals itr_end.
> > 
> > 
> > When the PFB Clock Sync block stalls, I attach with GDB, find the PFB
> > thread and get a back trace, I then go to the PFB general_work frame
> > and print the two inputs to get_tags_in_range
> 
> [snip]
> 
> >I've also found (separately, using breakpoints) that sometimes count is
> >negative.  Is that the way it should be?
> 
> [snip]
> 
> 
> > I'm not sure if we're putting bad data into the PFB block or if
> > there's some bug in the PFB block.  Or should there be some checking
> > in get_tags_in_range that checks if start > end.  What's the best way
> > to proceed?
> > 
> > 
> > Thanks,
> > 
> > Devin
> 



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

[Discuss-gnuradio] PFB Clock Sync stops producing samples

[Andy Walls]

For a block that performs the identical function of the PFB clock synch
block with correct tag propagation, use the Symbol Synchronizer Block
available in this pull request:

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

or this OOT module:

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

Use the following settings:
Timing Error Detector:   y[n]y'[n] Maximum Likelyhood
Samples per Symbol:  whatever you're using now
Loop Bandwidth:  whatever you're using now (may need tweaking)
Damping Factor:  1.0/math.sqrt(2.0)
Maximum Deviation:   whatever you're using now
Output Samples/Symbol:   whatever you're using now
Interpolating Resampler: Polyphase Filterbank, MF
Filterbank Arms: whatever you're using now for Filter Size
PFB MF Taps: whatever prototype filter taps you're using now


Properly fixing the tag propagation in the PFB_clock_sync block is a
major change, which is one reason I wrote the new Symbol Synchronizer
blocks.

FWIW, I also do think get_tags_in_range() could stand to perform a
sanity check, but that won't fix the underlying problem.

-Andy


>  From: 
> devin kelly
>   Subject: 
> [Discuss-gnuradio] PFB Clock Sync
> stops producing samples
>  Date: 
> Thu, 8 Jun 2017 12:08:12 -0400
> 
> __
> I'm having a problem with the Polyphase Clock Sync block.  I believe
> what's happening is that the block is calling get_tags_in_range
> improperly and then causing an infiite loop in
> gnuradio-runtime/lib/buffer.cc, at this point the PFB Clock Sync block
> stops emitting samples.
> 
> 
> The problem occurs in the PFB clock sync block here:
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L473
> 
> 
> The PFB block calls get_tags_in_range where the start sample number is
> greater than then end sample number, here's the code in buffer.cc that
> may be getting stuck in an infiite loop.
> 
> 
> The entire file is here:
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/buffer.cc#L354

[snip]
> When I run into this problem, my code seems to get stuck on itr++ (see
> debugger output below).  Though I'm not sure if the itr++ call just
> stalls or if itr just never equals itr_end.
> 
> 
> When the PFB Clock Sync block stalls, I attach with GDB, find the PFB
> thread and get a back trace, I then go to the PFB general_work frame
> and print the two inputs to get_tags_in_range

[snip]

>I've also found (separately, using breakpoints) that sometimes count is
>negative.  Is that the way it should be?

[snip]


> I'm not sure if we're putting bad data into the PFB block or if
> there's some bug in the PFB block.  Or should there be some checking
> in get_tags_in_range that checks if start > end.  What's the best way
> to proceed?
> 
> 
> Thanks,
> 
> Devin



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

Re: [Discuss-gnuradio] Process Naming

[Andy Walls]

From: Dave NotTelling Date: Thu, 4 May 2017 21:52:04 -0400:
> 
> __
> I can see that the threads are showing up with meaningful names using
> `top -H`.  Names like `zmq_pub_sink_c1`.  The `ps` command doesn't
> usually show me anything special :( 

ps -eLo pcpu,pid,tid,cls,rtprio,pcpu,comm | grep  | sort -n

ZeroMQ block threads will have names, but the I/O threads that ZeroMQ
spawns will still be named "python".

The same goes for GUI displays, the block will have a thread name, but
the GUI window display processing happens in a thread named "python".

Regards,
Andy


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

Re: [Discuss-gnuradio] ferna...@samara.com.es,

[Andy Walls]

>  From: 
> Fernando
>   Subject: 
> [Discuss-gnuradio] WBFM
> modulation/demodulation high
> frequencies highly attenuated
>  Date: 
> Wed, 26 Apr 2017 20:02:29 +0200
> 
> 
> 
> __
> I'm modulating/demodulating a wide band FM signal and I observe that
> high frequencies are highly  attenuated.
> 
> This is the diagram
> 
> 
> High frequencies are attenuated more than 40dB over low frequencies.
> 
> It seems to happen for frequencies above 20Khz.
> 
> Changing max deviation in WBFM Transmit has no effect.
> 
> What am I doing wrong?

You are making a bad assumption about what the WBFM block actually does.

See the audio filter cutoff and attenuation level in the WBFM Tx block
here:

https://github.com/gnuradio/gnuradio/blob/master/gr-analog/python/analog/wfm_tx.py#L67

-Andy


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

Re: [Discuss-gnuradio] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Andy Walls]

So I did some thinking about how to synchronize to the 2*pi*f0*t phase
term.

After checking the papers again and the particular GMSK example in
test_cpm.py, that phase term cycles over 4 symbol periods, so it
definitely adds phase ambiguity.  Resetting it at every symbol is
definitely the wrong thing to do.

So I plugged in some real numbers from AIS to see what f0 actually was:

Rb = 1/T = 9600 bits/sec
h = 1/2 = f_dev / (Rb/2)  => f_dev = 2400 Hz

so the AIS GMSK signaling freqs are +/-2400 Hz.

From Achilleas' paper, the expression for f0 is:

M = 2
f0 = -h(M-1)/(2T) = -9600/4 = -2400 Hz

So f0 is really the lower signaling frequency, at least for the
specific case of binary MSK.  (Achilleas, maybe you can comment on what
f0 is in the general case?)

I'm thinking that if I can pick off the phase of the lower signaling
frequency during the AIS preamble (where I know there are always spots
of -2400 Hz when a symbol repeats ), I can properly initialize the
phase of the the frequency shift by f0.

That seems kind of hokey to me, so I'm open to better ideas.  I'd also
like to hear if anyone thinks what I suggested will work or not.

I was trying to contemplate how the t in 2*pi*f0*t could be
incorporated into the FSM state, since this phase term appears to be
part of the phase memory of the system, though not part of the
modulation memory.  I couldn't see an obvious way to do that.

Regards,
Andy


On Thu, 2017-04-06 at 15:36 -0400, Andy Walls wrote:
> On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> > sure, feel free to look into the gr-trellis documentation and
> > provide
> > some feedback.
> > If you have further questions please let us know.
> > 
> > best,
> > Achilleas
> 
> Hi Achilleas:
> 
> My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver,
> using
> the Viterbi algorithm for optimal demodulation of the CPM symbols.
> 
> In examining gr-trellis/examples/python/test_cpm.py, I see that
> everything is perfectly synchronized, for the purposes of
> demonstration. (The addition of a 0.0 to the end of the 99% energy
> orthonormal basis vectors for the matched filter correlators, to have
> the taps completely fall into the initial all-0 history of the fir
> filter blocks, was a nice trick BTW).
> 
> In my design concept for a receiver, I believe I have worked out
> carrier frequency offset correction, phase offset correction, symbol
> timing recovery at either 4 or 5 samples per symbol, and injecting
> samples to properly realign the symbols entering the decimating
> matched
> filter correlators when a new burst is received.
> 
> What I can't quite figure out is how to properly synchronize the
> correction of f0T carrier frequency shift introduced by the CPM
> decomposition, without unintentionally adding an arbitrary phase
> shift
> to the symbol's signal in the CPM decomposition.
> 
> Do I restart the complex exponential frequency shift sequence with a
> phase of 0 at the start of each symbol?  I think that works for Q=4. 
> But what about for Q=5?  
> 
> The reason I ask is that it appears the phase of the complex
> correlation output by the matched filters will affect the metric for
> which CPM decomposition signal gets selected as the best match.
> 
> Looking at the 16, 99% energy CPM decomposition signals generated by
> the test_cpm.py script:
> 
> > > > print abs(Sf.transpose())
> 
> [[ 1.81592306  0.83465307]
>  [ 1.81592306  0.83465307]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.96823385  0.34970555]
>  [ 1.96823385  0.34970555]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.96823385  0.34970555]
>  [ 1.96823385  0.34970555]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.81592306  0.83465307]
>  [ 1.81592306  0.83465307]]
> 
> Many of the signals can only be distinguished from each other
> properly
> when the correlator outputs have proper phase.
> 
> Thank you for any advice you can provide.
> 
> Regards,
> Andy

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

Re: [Discuss-gnuradio] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Andy Walls]

On Thu, 2017-04-06 at 20:55 +, Nick Foster wrote:
> Unrelated to the question at hand, but since you're on the subject:
> how are you resetting the Viterbi decoder state between packets? I
> tried the same thing some years ago and it worked well except for
> that problem.
> 
> --n

I haven't gotten that far yet. :P

I have a symbol synchronizer block (using the MSK TED that the MSK
timing recovery block uses) that will give me Q samples/symbol out,
synchronized to the symbol centers.  It also propagates tags properly,
so I'll have the center of one of the first symbols in a packet marked
with a tag (using the corr_est block).

I was planning on writing a block to inject samples, if needed, near
that marked symbol to keep the decimating matched filters and viterbi
inputs properly aligned (so they will always process fully aligned
symbols).

I had not looked into what state the metrics and viterbi decoder might
be keeping.  If they need explicit reseting, I was going to modify them
to watch for a tag.

So a lot of my design concept for feeding the gr-trellis CPM processing
methodology depends on this symbol synchronizer block:

https://github.com/awalls-cx18/gr-nwr/blob/master/grc/nwr_symbol_sync_x
x.xml

and another (to be written) custom block for injecting < Q samples to
preserve alignment, and perhaps yet another (to be written) custom
block to handle the f0T frequency correction.  (The GNURadio stock
rotator block actually drifts slightly over a great many samples due to
numerical roundoff, plus it can't be synchronously reset).

I was hoping using gr-trellis practically would have been a little bit
easier. :(  

-Andy

> On Thu, Apr 6, 2017 at 12:38 PM Andy Walls
> <a...@silverblocksystems.net> wrote:
> > On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> > > sure, feel free to look into the gr-trellis documentation and
> > provide
> > > some feedback.
> > > If you have further questions please let us know.
> > >
> > > best,
> > > Achilleas
> > 
> > Hi Achilleas:
> > 
> > My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver,
> > using
> > the Viterbi algorithm for optimal demodulation of the CPM symbols.
> > 
> > In examining gr-trellis/examples/python/test_cpm.py, I see that
> > everything is perfectly synchronized, for the purposes of
> > demonstration. (The addition of a 0.0 to the end of the 99% energy
> > orthonormal basis vectors for the matched filter correlators, to
> > have
> > the taps completely fall into the initial all-0 history of the fir
> > filter blocks, was a nice trick BTW).
> > 
> > In my design concept for a receiver, I believe I have worked out
> > carrier frequency offset correction, phase offset correction,
> > symbol
> > timing recovery at either 4 or 5 samples per symbol, and injecting
> > samples to properly realign the symbols entering the decimating
> > matched
> > filter correlators when a new burst is received.
> > 
> > What I can't quite figure out is how to properly synchronize the
> > correction of f0T carrier frequency shift introduced by the CPM
> > decomposition, without unintentionally adding an arbitrary phase
> > shift
> > to the symbol's signal in the CPM decomposition.
> > 
> > Do I restart the complex exponential frequency shift sequence with
> > a
> > phase of 0 at the start of each symbol?  I think that works for
> > Q=4.
> > But what about for Q=5?
> > 
> > The reason I ask is that it appears the phase of the complex
> > correlation output by the matched filters will affect the metric
> > for
> > which CPM decomposition signal gets selected as the best match.
> > 
> > Looking at the 16, 99% energy CPM decomposition signals generated
> > by
> > the test_cpm.py script:
> > 
> > >>> print abs(Sf.transpose())
> > [[ 1.81592306  0.83465307]
> >  [ 1.81592306  0.83465307]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.96823385  0.34970555]
> >  [ 1.96823385  0.34970555]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.96823385  0.34970555]
> >  [ 1.96823385  0.34970555]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.81592306  0.83465307]
> >  [ 1.81592306  0.83465307]]
> > 
> > Many of the signals can only be distinguished from each other
> > properly
> > when the correlator outputs have proper phase.
> > 
> > Thank you for any advice you can provide.
> > 
> > Regards,
> > Andy
> > 
> > ___
> > 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] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Andy Walls]

On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> sure, feel free to look into the gr-trellis documentation and provide
> some feedback.
> If you have further questions please let us know.
> 
> best,
> Achilleas

Hi Achilleas:

My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver, using
the Viterbi algorithm for optimal demodulation of the CPM symbols.

In examining gr-trellis/examples/python/test_cpm.py, I see that
everything is perfectly synchronized, for the purposes of
demonstration. (The addition of a 0.0 to the end of the 99% energy
orthonormal basis vectors for the matched filter correlators, to have
the taps completely fall into the initial all-0 history of the fir
filter blocks, was a nice trick BTW).

In my design concept for a receiver, I believe I have worked out
carrier frequency offset correction, phase offset correction, symbol
timing recovery at either 4 or 5 samples per symbol, and injecting
samples to properly realign the symbols entering the decimating matched
filter correlators when a new burst is received.

What I can't quite figure out is how to properly synchronize the
correction of f0T carrier frequency shift introduced by the CPM
decomposition, without unintentionally adding an arbitrary phase shift
to the symbol's signal in the CPM decomposition.

Do I restart the complex exponential frequency shift sequence with a
phase of 0 at the start of each symbol?  I think that works for Q=4. 
But what about for Q=5?  

The reason I ask is that it appears the phase of the complex
correlation output by the matched filters will affect the metric for
which CPM decomposition signal gets selected as the best match.

Looking at the 16, 99% energy CPM decomposition signals generated by
the test_cpm.py script:

>>> print abs(Sf.transpose())
[[ 1.81592306  0.83465307]
 [ 1.81592306  0.83465307]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.96823385  0.34970555]
 [ 1.96823385  0.34970555]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.96823385  0.34970555]
 [ 1.96823385  0.34970555]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.81592306  0.83465307]
 [ 1.81592306  0.83465307]]

Many of the signals can only be distinguished from each other properly
when the correlator outputs have proper phase.

Thank you for any advice you can provide.

Regards,
Andy

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

Re: [Discuss-gnuradio] gr-trellis test_cpm.py question

[Andy Walls]

Ah, OK.  Thank you.
I don't need anything that adaptive or automatic myself.

I plan to play around with viterbi demodulation of GMSK and maybe SOQPSK
this week.

As I dig into the gr-trellis implementation I may have more questions.

Regards,
Andy

On Mon, 2017-04-03 at 08:50 -0400, Achilleas Anastasopoulos wrote:
> Here is what needs to be done (simple).
> 
> 
> N is the dimensionality of the signal space (found earlier in the
> code). 
> Now we need to set up a filter bank to project the incoming signal to
> all its dimensions. These filters are held on the MF[] array.
> Now (due to laziness) i didn't write a for loop that instantiates N
> filter blocks, but I just instantiated them manually for the case of
> N=2 in
> 
> 
> filter_fir_filter_xxx_0_0 = filter.fir_filter_ccc(Q,
> MF[0].conjugate())
> 
> filter_fir_filter_xxx_0_0_0 = filter.fir_filter_ccc(Q,
> MF[1].conjugate())
> 
> 
> 
> So what needs to be done is (through a for loop) instantiate these N
> filter blocks
> and appropriately modify the code (in the "connections" part) to make
> the right 
> connections to and from these blocks.
> 
> 
> best,
> Achilleas
> 
> 
> 
> On Sun, Apr 2, 2017 at 6:58 PM, Andy Walls
> <a...@silverblocksystems.net> wrote:
> Hi Achilleas:
> 
> In the test_cpm.py example under gr-trellis, there is a
> comment:
> 
> "# only works for N=2, do it manually for N>2..."
> 
> https://github.com/gnuradio/gnuradio/blob/master/gr-trellis/examples/python/test_cpm.py#L108
> 
> Could you, or anyone else, elaborate on what need to be done
> manually for N>2?
> 
> Thanks,
> Andy
> 
> 



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

[Discuss-gnuradio] gr-trellis test_cpm.py question

[Andy Walls]

Hi Achilleas:

In the test_cpm.py example under gr-trellis, there is a comment:

"# only works for N=2, do it manually for N>2..."
https://github.com/gnuradio/gnuradio/blob/master/gr-trellis/examples/python/test_cpm.py#L108

Could you, or anyone else, elaborate on what need to be done manually for N>2?

Thanks,
Andy

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

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

Hi Dirk:

Since you asked about how to set PLL values, I've worked up a version
5 of the flowgraph (attached) to help with that.

First you'll need to build and install my OOT NOAA Weather Radio module:
https://github.com/awalls-cx18/gr-nwr
to get a modified version of the PLL Ref Out block.  The modified PLL
Ref Out block has extra input parameters available from the GUI and
extra diagnostic output streams.

In the new flowgraph you can now modify both the PLL's loop bandwidth
and its damping factor.  You can also observe the PLL's internal
instantaneous frequency and internal average frequency (both
normalized by 10 kHz for the scope), since they are now brought out to
optional output streams.  You'll want to pay more attention to the
average PLL frequency during a pulse, and you will usually want to
ignore the instantaneous PLL frequency during a pulse.

So now you can see the effect of setting the loop bandwidth very low.
If it is set to 0.01, you can see how much the PLL likes to track an
interference spike and not move off of it.  This sluggish PLL response
is undesirable for your application of finding short pulses of
"unknown" frequency.

I left the loop bandwidth at 0.35, because the PLL seemed to be
reactive enough to lock on to most of the pulses.  At 0.3 to 0.24, the
PLL was still reactive and locked, but sometimes it locked-on "wrong".
Instead of being at a stable -1 kHz during a pulse, it would lock at
an unstable +2 kHz.  And, as I mentioned before, a very low loop
bandwidth made the PLL very non-reactive and useless to quickly find
the pulses.  There doesn't seem to be much penalty for setting the
loop bandwidth higher, except there do seem to be "dead zones" of
values that don't work.

Regarding damping factor, I left it at the default of 1/sqrt(2), which
results in a maximally flat loop filter response.  FWIW, a damping
factor of 1.0 is a critically damped system, and >1.0 is an overdamped
system.  For your application, you definitely want an underdamped
system.  You might want to experiment with damping factors less than
the default.

Also, in this flowgraph, I separated the out the final, non-decimating
lowpass filter from the final decimating filter stage. It saves some
CPU.

Regards,
Andy


implant_pulse_detect_5.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

Bah, I messed up my filter designs in that last flowgraph.
(Transition BW != Stopband Freq).
Never drink beer while designing filters. :)

See the attached, fixed flowgraph (v4).

-Andy

On Mon, Mar 20, 2017 at 9:30 PM, Andy Walls <a...@silverblocksystems.net> wrote:
> Hi Dirk:
>
> On Mon, Mar 20, 2017 at 1:04 PM, Dirk Gorissen <dgoris...@gmail.com> wrote:
>> Hi Andy,
>>
>> I have been experimenting with the flowgraphs, tried with some live
>> data and it all works as expected. Just had to switch the threshold to
>> 2 orders of magnitude smaller when using an airspy.
>
> Yeah, that's expected really.
> You might want to write a block that implements a (F)CME algorithm in the
> time domain, to periodically determine an adapted threshold between correlator
> noise output vs correlator signal output.  I mention FMCE and CME because
> it has a well defined Pfa input parameter.
>
> Or you you could just grab 3 seconds of
> correlator output every 1.5 seconds and use CME, or your favorite statistical
> measure or distance metric for outlier detection, to find correlator
> output signal
> peaks.
>
>> So thank you again for your time on this, I will ensure to give credit
>> when the final thing is tested & operational :)
>
> Thank you.
>
>> Some comments/questions inline below:
>>
>>>To get faster lock in, you may want your frequency range of interest to
>>>be somewhere in between Fs/4 and Fs/2; and not near DC.
>>
>> Actually my channel is 2khz wide, not 10khz so that does make life a
>> bit easier. So in this case I should be decimating Fs down to
>> something like 4k say. Correct?
>
> Yes.  See the attached flowgraph, version 3, where I knock it down to
> 4ksps and have the filter starting to roll off at +/- 1kHz
>
>
>> As you say this should also let me lower the pll bandwidth. Though I
>> haven't quite grasped the intuition behind this. Experimenting a bit
>> it seems a bit smaller than you set is better, definitely not larger.
>
> Well yes, but too small is bad as well.
>
>
>> How did you pick your ranges, they dont align with what the docs are
>> saying ( around pi/200 - 2pi/100).
>
> Empirically.  :)  Mostly...
>
> So the theory behind what the parameters mean is a lecture on second order
> control systems, which I will spare you.  (Also GNRadio is funny in that
> the user specifies 2nd order *analog* control system parameters for
> poles in the complex s-plane [Laplace transform plane] and then
> approximately warps them over to the z-plane [Z transform plane]
> into poles for a discrete 2nd order control system - it's kind of silly 
> really.)
>
> The short story is GNURadio picks the damping factor of 1.0/sqrt(2.0)
> for a maximally flat second order PLL filter response, and then the user
> sets loop_bw (aka. omega_n_T) to set how wide the PLL loop filter response
> is.
>
> The maximum loop_bw could really be is pi/(1.0/sqrt(2)), and that would be
> a wide filter going from +/- the Nyquist rate of the phase detector
> error signal;
> which is useless.  So you need a smaller number.
>
> Smaller loop_bw values result in a more sluggish PLL.
> Larger loop_bw values result in a more reactive PLL.
>
> For rapid locking on to an intermittent pulse that pops up with random
> initial phase (compared to the PLL's currently unlocked wandering phase),
> we want a more reactive PLL so a larger loop bandwidth.
>
> If the PLL is too reactive it wont lock.
> If the PLL is too slow, the pulse will be gone before it gets into lock.
>
>
>>
>>>b. Once you find some pulses, extract what frequency they were at from
>>>the PLL's loop filter state at the time it was locked on the pulse.  You
>>>can then use this exact frequency information for a dedicated
>>>correlation filter to pull even weaker pulses out of the noise, and
>>>maintain track.
>>
>> Yes this is what I had in mind as well. I looked around the carrier
>> block docs, source code, and wider gr wiki but couldn't find how I can
>> get my hands on that internal state?
>
> It's not easy.  From python, you can call the get_frequency() method of
> the block and get it asynchronously, but the units are funny (and it might
> even be the period vs the frequency, I have to take a harder look).
>
> An easier thing to do is to take the properly scaled d(phi)/dt of the
> PLL's locked output and use that as an instantaneous frequency
> value that is sample synchronous with the main sample stream.
> That number is clean for strong pulses, and a meandering mess for
> weak pulses.
>
> See the lowest, disabled branch of the attached flowgraph.
> I 

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

Hi Dirk:

On Mon, Mar 20, 2017 at 1:04 PM, Dirk Gorissen  wrote:
> Hi Andy,
>
> I have been experimenting with the flowgraphs, tried with some live
> data and it all works as expected. Just had to switch the threshold to
> 2 orders of magnitude smaller when using an airspy.

Yeah, that's expected really.
You might want to write a block that implements a (F)CME algorithm in the
time domain, to periodically determine an adapted threshold between correlator
noise output vs correlator signal output.  I mention FMCE and CME because
it has a well defined Pfa input parameter.

Or you you could just grab 3 seconds of
correlator output every 1.5 seconds and use CME, or your favorite statistical
measure or distance metric for outlier detection, to find correlator
output signal
peaks.

> So thank you again for your time on this, I will ensure to give credit
> when the final thing is tested & operational :)

Thank you.

> Some comments/questions inline below:
>
>>To get faster lock in, you may want your frequency range of interest to
>>be somewhere in between Fs/4 and Fs/2; and not near DC.
>
> Actually my channel is 2khz wide, not 10khz so that does make life a
> bit easier. So in this case I should be decimating Fs down to
> something like 4k say. Correct?

Yes.  See the attached flowgraph, version 3, where I knock it down to
4ksps and have the filter starting to roll off at +/- 1kHz


> As you say this should also let me lower the pll bandwidth. Though I
> haven't quite grasped the intuition behind this. Experimenting a bit
> it seems a bit smaller than you set is better, definitely not larger.

Well yes, but too small is bad as well.


> How did you pick your ranges, they dont align with what the docs are
> saying ( around pi/200 - 2pi/100).

Empirically.  :)  Mostly...

So the theory behind what the parameters mean is a lecture on second order
control systems, which I will spare you.  (Also GNRadio is funny in that
the user specifies 2nd order *analog* control system parameters for
poles in the complex s-plane [Laplace transform plane] and then
approximately warps them over to the z-plane [Z transform plane]
into poles for a discrete 2nd order control system - it's kind of silly really.)

The short story is GNURadio picks the damping factor of 1.0/sqrt(2.0)
for a maximally flat second order PLL filter response, and then the user
sets loop_bw (aka. omega_n_T) to set how wide the PLL loop filter response
is.

The maximum loop_bw could really be is pi/(1.0/sqrt(2)), and that would be
a wide filter going from +/- the Nyquist rate of the phase detector
error signal;
which is useless.  So you need a smaller number.

Smaller loop_bw values result in a more sluggish PLL.
Larger loop_bw values result in a more reactive PLL.

For rapid locking on to an intermittent pulse that pops up with random
initial phase (compared to the PLL's currently unlocked wandering phase),
we want a more reactive PLL so a larger loop bandwidth.

If the PLL is too reactive it wont lock.
If the PLL is too slow, the pulse will be gone before it gets into lock.


>
>>b. Once you find some pulses, extract what frequency they were at from
>>the PLL's loop filter state at the time it was locked on the pulse.  You
>>can then use this exact frequency information for a dedicated
>>correlation filter to pull even weaker pulses out of the noise, and
>>maintain track.
>
> Yes this is what I had in mind as well. I looked around the carrier
> block docs, source code, and wider gr wiki but couldn't find how I can
> get my hands on that internal state?

It's not easy.  From python, you can call the get_frequency() method of
the block and get it asynchronously, but the units are funny (and it might
even be the period vs the frequency, I have to take a harder look).

An easier thing to do is to take the properly scaled d(phi)/dt of the
PLL's locked output and use that as an instantaneous frequency
value that is sample synchronous with the main sample stream.
That number is clean for strong pulses, and a meandering mess for
weak pulses.

See the lowest, disabled branch of the attached flowgraph.
I converted the Carrier Tracking PLL to a Reference Out PLL
block followed by a Multiply Conjugate.  It is functionally
identical, but now we have the PLL's locked
output available.

>>I wasn't intending to tweak the flowgraph, but today I decided to try
>>with a correlation filter with -5 kHz to +5 kHz chirp taps.  That
>>method turned out to be inferior to the PLL, so I didn't leave it in
>>the flowgraph.
>
> Thats good to know, thats what I was doing originally.
>
>>My gut feeling is that to detect these weak pulses
>>in the original file, you're going to have to tolerate a fairly high
>>false alarm rate, if you want to detect the pulses.
>
> Agreed. I would probably be somewhat permissive initially and then do
> some further filtering in a post processing step.
>
>>Doing things to not allow noise into the system in the first place,
>>such as a VHF 

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

You're welcome.

I can report, that I can now see/detect pulses in the original I/Q
file you provided, using the latest flowgraph I provided.  I had to
set the trigger threshold down to 0.1 (down from my original 0.3).

I know they are pulses and not false alarms, because I can often see
two correlation peaks spaced at about 1.5 seconds apart.

In a real system, I'd try to dynamically adapt the threshold decision
point between correlator signal output and noise output for a given
false alarm rate.  My gut feeling is that to detect these weak pulses
in the original file, you're going to have to tolerate a fairly high
false alarm rate, if you want to detect the pulses.

Doing things to not allow noise into the system in the first place,
such as a VHF bandpass filter before the SDR unit, and proper
adjustment of the SDR's LNA and IF gains for best noise performance
would help.

Also being able to narrow down the possible variation in frequencies
where the signal might be at, say a 2 kHz channel vs. a 10 kHz
channel, would allow additional noise filtering and lower PLL loop
bandwidth, so that weaker signals could be pulled out.

Fun stuff.

Regards,
Andy


On Sat, Mar 18, 2017 at 6:30 PM, Dirk Gorissen <dgoris...@gmail.com> wrote:
> Amazing Andy, thank you for putting this time in. Im still digesting
> this but will report back
>
> On 18 March 2017 at 20:45, Andy Walls <a...@silverblocksystems.net> wrote:
>> Dirk,
>>
>> Here is a revised flowgraph, slightly tweaked to reduce the
>> computational cost of the rotator and the filters.
>>
>> I wasn't intending to tweak the flowgraph, but today I decided to try
>> with a correlation filter with -5 kHz to +5 kHz chirp taps.  That
>> method turned out to be inferior to the PLL, so I didn't leave it in
>> the flowgraph.
>>
>> Regards,
>> Andy
>>
>> On Fri, Mar 17, 2017 at 11:46 AM, Andy Walls
>> <a...@silverblocksystems.net> wrote:
>>> On Thu, 2017-03-16 at 21:02 -0400, Andy Walls wrote:
>>>> Hi Dirk,
>>>>
>>>> Thanks.
>>>>
>>>> Try the attached flowgraph.  The pulse indicator output is a little crude
>>>> at the moment (it needs some latching persistence for a human to read),
>>>> but it does the job for a proof of concept.
>>>>
>>>> Note that in the future, you really do want to tune such the the SDR's 
>>>> center
>>>> freq spike is not in the band of interest.  That will prevent false lock 
>>>> on the
>>>> DC spike by the PLL.
>>>>
>>>> Regards,
>>>> Andy
>>>
>>> I should also mention a few things:
>>>
>>> 1. You could handle multiple channels in one of at least two ways:
>>>
>>> a. A polyphase channelizer with each channel having a PLL and Moving
>>> average filter instance.  (This can get CPU intensive.) Or...
>>>
>>> b. Scanning by stepping through and dwelling for a bit on your 10 kHz
>>> channels of interest.
>>>
>>>
>>> 2. You can get better sensitivity the the PLL+Moving average correlation
>>> solution by going to a 2 stage process:
>>>
>>> a. Use the PLL+Moving Average filter to initially acquire some pulses.
>>>
>>> b. Once you find some pulses, extract what frequency they were at from
>>> the PLL's loop filter state at the time it was locked on the pulse.  You
>>> can then use this exact frequency information for a dedicated
>>> correlation filter to pull even weaker pulses out of the noise, and
>>> maintain track.  You'll have to use the magnitude of the correlation and
>>> not just the real part (because you'll have an arbitrary phase shift,
>>> since a straight correlation filter is a phase offset detector and not
>>> phase tracker like a PLL).
>>>
>>> Regards,
>>> Andy
>>>
>>>
>>>> On Thu, Mar 16, 2017 at 7:12 PM, Dirk Gorissen <dgoris...@gmail.com> wrote:
>>>> > Hi Andy,
>>>> >
>>>> > Very quickly collected some data off a different Tx. First at very
>>>> > close range, moving away, and then back again. It was quick and
>>>> > antenna was close to computer so perhaps quite noisy but should
>>>> > definitely have some strong pulses:
>>>> >
>>>> > https://drive.google.com/open?id=0B5dKo9igl8W4WkRkUGQzcVJsQnc
>>>> >
>>>> > Havent managed to look at the pll stuff yet. Aim to do so this weekend.
>>>> > Cheers
>>>> > Dirk
>>>> >
>>>> > On 16 Mar

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

Dirk,

Here is a revised flowgraph, slightly tweaked to reduce the
computational cost of the rotator and the filters.

I wasn't intending to tweak the flowgraph, but today I decided to try
with a correlation filter with -5 kHz to +5 kHz chirp taps.  That
method turned out to be inferior to the PLL, so I didn't leave it in
the flowgraph.

Regards,
Andy

On Fri, Mar 17, 2017 at 11:46 AM, Andy Walls
<a...@silverblocksystems.net> wrote:
> On Thu, 2017-03-16 at 21:02 -0400, Andy Walls wrote:
>> Hi Dirk,
>>
>> Thanks.
>>
>> Try the attached flowgraph.  The pulse indicator output is a little crude
>> at the moment (it needs some latching persistence for a human to read),
>> but it does the job for a proof of concept.
>>
>> Note that in the future, you really do want to tune such the the SDR's center
>> freq spike is not in the band of interest.  That will prevent false lock on 
>> the
>> DC spike by the PLL.
>>
>> Regards,
>> Andy
>
> I should also mention a few things:
>
> 1. You could handle multiple channels in one of at least two ways:
>
> a. A polyphase channelizer with each channel having a PLL and Moving
> average filter instance.  (This can get CPU intensive.) Or...
>
> b. Scanning by stepping through and dwelling for a bit on your 10 kHz
> channels of interest.
>
>
> 2. You can get better sensitivity the the PLL+Moving average correlation
> solution by going to a 2 stage process:
>
> a. Use the PLL+Moving Average filter to initially acquire some pulses.
>
> b. Once you find some pulses, extract what frequency they were at from
> the PLL's loop filter state at the time it was locked on the pulse.  You
> can then use this exact frequency information for a dedicated
> correlation filter to pull even weaker pulses out of the noise, and
> maintain track.  You'll have to use the magnitude of the correlation and
> not just the real part (because you'll have an arbitrary phase shift,
> since a straight correlation filter is a phase offset detector and not
> phase tracker like a PLL).
>
> Regards,
> Andy
>
>
>> On Thu, Mar 16, 2017 at 7:12 PM, Dirk Gorissen <dgoris...@gmail.com> wrote:
>> > Hi Andy,
>> >
>> > Very quickly collected some data off a different Tx. First at very
>> > close range, moving away, and then back again. It was quick and
>> > antenna was close to computer so perhaps quite noisy but should
>> > definitely have some strong pulses:
>> >
>> > https://drive.google.com/open?id=0B5dKo9igl8W4WkRkUGQzcVJsQnc
>> >
>> > Havent managed to look at the pll stuff yet. Aim to do so this weekend.
>> > Cheers
>> > Dirk
>> >
>> > On 16 March 2017 at 07:22, Dirk Gorissen <dgoris...@gmail.com> wrote:
>> >> Mmm, thats odd. Those settings should be correct, maybe something went
>> >> wrong with the recording :(  I'll try to check in between things at
>> >> work today else will do so tonight.
>> >> Thanks for taking the time to look though.
>> >>
>> >> On 16 March 2017 at 00:39, Andy Walls <a...@silverblocksystems.net> wrote:
>> >>> Hi Dirk:
>> >>>
>> >>> In the IQ data file you provided I can seem to find any pulses of the
>> >>> nominal 10 msec length, no matter how I filter and rotate the
>> >>> spectrum.
>> >>> There is a lot of EMI, which looks like the intermodulation products
>> >>> of a continuously on guy who is drifting/chirping down in frequency.
>> >>>
>> >>> So could you please confirm or clarify the following:
>> >>>
>> >>> 1. The format of the binary data file.  I am assuming 32 bit float I
>> >>> and 32 bit float Q pairs, as that is what the GNURadio file sink would
>> >>> normally create.
>> >>> 2. The sample rate.  I am assuming 1 Msps.
>> >>> 3. The center freq.  I am assuming 150.22 MHz.
>> >>> 4. The pulse duration. I am assuming 10 milliseconds.
>> >>> 5. At what frequency offset, from the center frequency, should the
>> >>> pulse be at?  I'm assuming somewhere withing +/- 5 kHz of the center
>> >>> spike, but there are at least two EMI spikes in that range.
>> >>>
>> >>> Thanks.
>> >>>
>> >>> -Andy
>> >>>
>> >>> On Wed, Mar 15, 2017 at 5:23 AM, Dirk Gorissen <dgoris...@gmail.com> 
>> >>> wrote:
>> >>>> Hi Andy, Marcus,
>> >>>>
>> >>

Re: [Discuss-gnuradio] Problem with underruns

[Andy Walls]

On Fri, 2017-03-17 at 14:36 -0400, Andy Walls wrote:
> > Hi Sverre,
> > 
> > hm, I've taken the time to look at pulse_shaper_bs.py[1], but I didn't
> > fully understand what it does, mathematically/technically. 
> > 
> > 
> > 
> > It does in fact look like a very complicated way to do something that
> > I'm not 100% sure wouldn't be covered by a simple FIR filter, but
> > lacking a bit of documentation, and not finding the time to go into
> > all the if()-cases right now, can you explain what it does? 
> 
> Hi Marcus:
> 
> The pulse shaper bs block looks like an MSK I or Q bit to half-sine
> pulse convertor, which one would use when generating MSK as an Offset
> QPSK with half-sine shaped pulses.
> Definitely the hard way to generate MSK, when using FSK with square
> pulses is much easier.
> 
> The pulse shape block seems fairly inflexible WRT sample rate, and is
> using integers - as if it were a prototype for an FPGA implementation.

FWIW: The original pulse shaper implementation seems to be described in
section 7.3.1 of this paper:
https://brage.bibsys.no/xmlui/bitstream/handle/11250/2369767/350718_FULLTEXT01.pdf?sequence=1=y

See appendix A, Listing A.3 for the original C++ code.

This paper describes the current python pulse shaper implementation in
question on pages 26 and 27:
https://brage.bibsys.no/xmlui/bitstream/handle/11250/2405115/14772_FULLTEXT.pdf

Which all would have been very nice to have with the original posed
question.

-Andy


> Sverre,
> The whole block would be much faster in C++ instead of python.
> If it is just straight MSK that you need to generate, just use a repeat
> block followed by a frequency modulator block and then a filter block to
> limit the occupied bandwidth.
> 
> I'm not that familiar with DSRC, but that's an odd pulse shaping for ASK
> (ASK usually has no pulse shaping).  Also ASK is usually horrible for
> anything but the simplest remote functions.  Is another aspect of the
> system that uses PSK or FSK?
> 
> -Andy
> 
> > You told me the bit rate, but not the sampling rate of the USRP sink,
> > but that would be very relevant here!
> > 
> > Best regards,
> > Marcus 
> > 
> > [1]
> > https://github.com/sverrets/dsrc/blob/master/gr-dsrcmod/python/pulse_shaper_bs.py
> > On 03/17/2017 01:04 PM, Sverre Turter Sandvold wrote:
> > 
> > > Hi, thank you for answering!
> > > 
> > > 
> > > I'm using a USRP N200 with a CBX daughterboard. 
> > > 
> > > 
> > > 
> > > I think the problem is that the block "pulse_shaper_bs" is not
> > > processing fast enough, and then the USRP Sink don't receive data
> > > fast enough and this causes the underrun. 
> > > 
> > > 
> > > 
> > > I want to send a packet with bits to a DSRC-unit. The main specs
> > > are:
> > > 
> > >   * Carrier Frequency: 5,8025 GHz
> > >   * Modulation: Two level amplitude modulation
> > >   * Data Coding: FM0
> > >   * Bit rate: 500 kbit/s
> > > 
> > > SverreTS
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Fra: Discuss-gnuradio <address@hidden> på vegne av Marcus Müller
> > > <address@hidden>
> > > Sendt: 16. mars 2017 19:38
> > > Til: address@hidden
> > > Emne: Re: [Discuss-gnuradio] Problem with underruns 
> > >  
> > > Hi SverreTS,
> > > 
> > > 
> > > can you be more specific? Why do you think it's the problem? Can you
> > > give us a rough idea of what your program does? At which rates are
> > > you working, with which hardware, and so on.
> > > 
> > > 
> > > 
> > > Best regards,
> > > 
> > > Marcus
> > > 
> > > 
> > > 
> > > On 03/16/2017 01:52 PM, Sverre Turter Sandvold wrote:
> > > 
> > > > Hi!
> > > > 
> > > > 
> > > > Need some help with this gnuradio-block called "pulse_shaper_bs":
> > > > https://github.com/sverrets/dsrc/blob/master/gr-dsrcmod/python/pulse_shaper_bs.py
> > > >  used in this program:  https://github.com/sverrets/dsrc . I got alot 
> > > > of underruns and think the "pulse_shaper_bs" is causing the problem. 
> > > > 
> > > > 
> > > > 
> > > > Anyone want to help?
> > > > 
> > > > 
> > > > SverreTS
> > > > 
> > > > 
> > > > 
> 



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

Re: [Discuss-gnuradio] Problem with underruns

[Andy Walls]

> Hi Sverre,
> 
> hm, I've taken the time to look at pulse_shaper_bs.py[1], but I didn't
> fully understand what it does, mathematically/technically. 
> 
> 
> 
> It does in fact look like a very complicated way to do something that
> I'm not 100% sure wouldn't be covered by a simple FIR filter, but
> lacking a bit of documentation, and not finding the time to go into
> all the if()-cases right now, can you explain what it does? 

Hi Marcus:

The pulse shaper bs block looks like an MSK I or Q bit to half-sine
pulse convertor, which one would use when generating MSK as an Offset
QPSK with half-sine shaped pulses.
Definitely the hard way to generate MSK, when using FSK with square
pulses is much easier.

The pulse shape block seems fairly inflexible WRT sample rate, and is
using integers - as if it were a prototype for an FPGA implementation.

Sverre,
The whole block would be much faster in C++ instead of python.
If it is just straight MSK that you need to generate, just use a repeat
block followed by a frequency modulator block and then a filter block to
limit the occupied bandwidth.

I'm not that familiar with DSRC, but that's an odd pulse shaping for ASK
(ASK usually has no pulse shaping).  Also ASK is usually horrible for
anything but the simplest remote functions.  Is another aspect of the
system that uses PSK or FSK?

-Andy

> You told me the bit rate, but not the sampling rate of the USRP sink,
> but that would be very relevant here!
> 
> Best regards,
> Marcus 
> 
> [1]
> https://github.com/sverrets/dsrc/blob/master/gr-dsrcmod/python/pulse_shaper_bs.py
> On 03/17/2017 01:04 PM, Sverre Turter Sandvold wrote:
> 
> > Hi, thank you for answering!
> > 
> > 
> > I'm using a USRP N200 with a CBX daughterboard. 
> > 
> > 
> > 
> > I think the problem is that the block "pulse_shaper_bs" is not
> > processing fast enough, and then the USRP Sink don't receive data
> > fast enough and this causes the underrun. 
> > 
> > 
> > 
> > I want to send a packet with bits to a DSRC-unit. The main specs
> > are:
> > 
> >   * Carrier Frequency: 5,8025 GHz
> >   * Modulation: Two level amplitude modulation
> >   * Data Coding: FM0
> >   * Bit rate: 500 kbit/s
> > 
> > SverreTS
> > 
> > 
> > 
> > 
> > 
> > 
> > Fra: Discuss-gnuradio  på vegne av Marcus Müller
> > 
> > Sendt: 16. mars 2017 19:38
> > Til: address@hidden
> > Emne: Re: [Discuss-gnuradio] Problem with underruns 
> >  
> > Hi SverreTS,
> > 
> > 
> > can you be more specific? Why do you think it's the problem? Can you
> > give us a rough idea of what your program does? At which rates are
> > you working, with which hardware, and so on.
> > 
> > 
> > 
> > Best regards,
> > 
> > Marcus
> > 
> > 
> > 
> > On 03/16/2017 01:52 PM, Sverre Turter Sandvold wrote:
> > 
> > > Hi!
> > > 
> > > 
> > > Need some help with this gnuradio-block called "pulse_shaper_bs":
> > > https://github.com/sverrets/dsrc/blob/master/gr-dsrcmod/python/pulse_shaper_bs.py
> > >  used in this program:  https://github.com/sverrets/dsrc . I got alot of 
> > > underruns and think the "pulse_shaper_bs" is causing the problem. 
> > > 
> > > 
> > > 
> > > Anyone want to help?
> > > 
> > > 
> > > SverreTS
> > > 
> > > 
> > > 



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

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

On Thu, 2017-03-16 at 21:02 -0400, Andy Walls wrote:
> Hi Dirk,
> 
> Thanks.
> 
> Try the attached flowgraph.  The pulse indicator output is a little crude
> at the moment (it needs some latching persistence for a human to read),
> but it does the job for a proof of concept.
> 
> Note that in the future, you really do want to tune such the the SDR's center
> freq spike is not in the band of interest.  That will prevent false lock on 
> the
> DC spike by the PLL.
> 
> Regards,
> Andy

I should also mention a few things:

1. You could handle multiple channels in one of at least two ways:

a. A polyphase channelizer with each channel having a PLL and Moving
average filter instance.  (This can get CPU intensive.) Or...

b. Scanning by stepping through and dwelling for a bit on your 10 kHz
channels of interest.


2. You can get better sensitivity the the PLL+Moving average correlation
solution by going to a 2 stage process:

a. Use the PLL+Moving Average filter to initially acquire some pulses.

b. Once you find some pulses, extract what frequency they were at from
the PLL's loop filter state at the time it was locked on the pulse.  You
can then use this exact frequency information for a dedicated
correlation filter to pull even weaker pulses out of the noise, and
maintain track.  You'll have to use the magnitude of the correlation and
not just the real part (because you'll have an arbitrary phase shift,
since a straight correlation filter is a phase offset detector and not
phase tracker like a PLL).

Regards,
Andy


> On Thu, Mar 16, 2017 at 7:12 PM, Dirk Gorissen <dgoris...@gmail.com> wrote:
> > Hi Andy,
> >
> > Very quickly collected some data off a different Tx. First at very
> > close range, moving away, and then back again. It was quick and
> > antenna was close to computer so perhaps quite noisy but should
> > definitely have some strong pulses:
> >
> > https://drive.google.com/open?id=0B5dKo9igl8W4WkRkUGQzcVJsQnc
> >
> > Havent managed to look at the pll stuff yet. Aim to do so this weekend.
> > Cheers
> > Dirk
> >
> > On 16 March 2017 at 07:22, Dirk Gorissen <dgoris...@gmail.com> wrote:
> >> Mmm, thats odd. Those settings should be correct, maybe something went
> >> wrong with the recording :(  I'll try to check in between things at
> >> work today else will do so tonight.
> >> Thanks for taking the time to look though.
> >>
> >> On 16 March 2017 at 00:39, Andy Walls <a...@silverblocksystems.net> wrote:
> >>> Hi Dirk:
> >>>
> >>> In the IQ data file you provided I can seem to find any pulses of the
> >>> nominal 10 msec length, no matter how I filter and rotate the
> >>> spectrum.
> >>> There is a lot of EMI, which looks like the intermodulation products
> >>> of a continuously on guy who is drifting/chirping down in frequency.
> >>>
> >>> So could you please confirm or clarify the following:
> >>>
> >>> 1. The format of the binary data file.  I am assuming 32 bit float I
> >>> and 32 bit float Q pairs, as that is what the GNURadio file sink would
> >>> normally create.
> >>> 2. The sample rate.  I am assuming 1 Msps.
> >>> 3. The center freq.  I am assuming 150.22 MHz.
> >>> 4. The pulse duration. I am assuming 10 milliseconds.
> >>> 5. At what frequency offset, from the center frequency, should the
> >>> pulse be at?  I'm assuming somewhere withing +/- 5 kHz of the center
> >>> spike, but there are at least two EMI spikes in that range.
> >>>
> >>> Thanks.
> >>>
> >>> -Andy
> >>>
> >>> On Wed, Mar 15, 2017 at 5:23 AM, Dirk Gorissen <dgoris...@gmail.com> 
> >>> wrote:
> >>>> Hi Andy, Marcus,
> >>>>
> >>>> Thanks very much for taking the time to think about this.
> >>>>
> >>>> Just to answer your questions:
> >>>>
> >>>>>Dirk's problem was the low SNR in his recording, so he'd like to take
> >>>>>the shape of his pulse into consideration, but he doesn't know the
> >>>>>spectral position of the same – Dirk, can you confirm?
> >>>>
> >>>> Yes, Im dealing with a very weak signal against quite a bit of
> >>>> background noise so the more prior knowledge I can leverage the
> >>>> better.
> >>>>
> >>>>>Dirk, thinking about this, the relation of the spectral uncertainty to
> >>>>>the bandwidth of the pulse would be interesting  – can you

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

Hi Dirk,

Thanks.

Try the attached flowgraph.  The pulse indicator output is a little crude
at the moment (it needs some latching persistence for a human to read),
but it does the job for a proof of concept.

Note that in the future, you really do want to tune such the the SDR's center
freq spike is not in the band of interest.  That will prevent false lock on the
DC spike by the PLL.

Regards,
Andy

On Thu, Mar 16, 2017 at 7:12 PM, Dirk Gorissen <dgoris...@gmail.com> wrote:
> Hi Andy,
>
> Very quickly collected some data off a different Tx. First at very
> close range, moving away, and then back again. It was quick and
> antenna was close to computer so perhaps quite noisy but should
> definitely have some strong pulses:
>
> https://drive.google.com/open?id=0B5dKo9igl8W4WkRkUGQzcVJsQnc
>
> Havent managed to look at the pll stuff yet. Aim to do so this weekend.
> Cheers
> Dirk
>
> On 16 March 2017 at 07:22, Dirk Gorissen <dgoris...@gmail.com> wrote:
>> Mmm, thats odd. Those settings should be correct, maybe something went
>> wrong with the recording :(  I'll try to check in between things at
>> work today else will do so tonight.
>> Thanks for taking the time to look though.
>>
>> On 16 March 2017 at 00:39, Andy Walls <a...@silverblocksystems.net> wrote:
>>> Hi Dirk:
>>>
>>> In the IQ data file you provided I can seem to find any pulses of the
>>> nominal 10 msec length, no matter how I filter and rotate the
>>> spectrum.
>>> There is a lot of EMI, which looks like the intermodulation products
>>> of a continuously on guy who is drifting/chirping down in frequency.
>>>
>>> So could you please confirm or clarify the following:
>>>
>>> 1. The format of the binary data file.  I am assuming 32 bit float I
>>> and 32 bit float Q pairs, as that is what the GNURadio file sink would
>>> normally create.
>>> 2. The sample rate.  I am assuming 1 Msps.
>>> 3. The center freq.  I am assuming 150.22 MHz.
>>> 4. The pulse duration. I am assuming 10 milliseconds.
>>> 5. At what frequency offset, from the center frequency, should the
>>> pulse be at?  I'm assuming somewhere withing +/- 5 kHz of the center
>>> spike, but there are at least two EMI spikes in that range.
>>>
>>> Thanks.
>>>
>>> -Andy
>>>
>>> On Wed, Mar 15, 2017 at 5:23 AM, Dirk Gorissen <dgoris...@gmail.com> wrote:
>>>> Hi Andy, Marcus,
>>>>
>>>> Thanks very much for taking the time to think about this.
>>>>
>>>> Just to answer your questions:
>>>>
>>>>>Dirk's problem was the low SNR in his recording, so he'd like to take
>>>>>the shape of his pulse into consideration, but he doesn't know the
>>>>>spectral position of the same – Dirk, can you confirm?
>>>>
>>>> Yes, Im dealing with a very weak signal against quite a bit of
>>>> background noise so the more prior knowledge I can leverage the
>>>> better.
>>>>
>>>>>Dirk, thinking about this, the relation of the spectral uncertainty to
>>>>>the bandwidth of the pulse would be interesting  – can you refresh our
>>>>>memory? I think the pulse was 10ms long (so, pretty long) but I forgot
>>>>>how it looked like.
>>>>
>>>> Yes, 10ms long (this is pretty exact), occurring every 1.5 seconds, in
>>>> the 150MHz range. My input stream is coming from an SDR.
>>>> As an aside I actually have multiple transmitters each pulsing at
>>>> slightly different frequencies (e.g., 150.10, 150.22, ...) but Im
>>>> happy to treat them independently so you can ignore that and assume
>>>> there is just one.
>>>>
>>>> You can see pictures of the pulse (taken a while back, for a specific
>>>> tx frequency) here: https://goo.gl/photos/Y3Ea6kJo1ewrcDYM8
>>>>
>>>> Note though that this is taken with the transmitter very close to the
>>>> antenna so the signal is unrealistically strong. So its just to
>>>> illustrate.
>>>>
>>>> I also quickly captured a file with raw IQ samples (File sink) in case
>>>> anybody is interested. It starts with the transmitter very close to
>>>> antenna, moves progressively further until out of range and then back.
>>>> Its only about a minute or two tops but at 1msps it ended
>>>> up as 813 MB though.
>>>>
>>>> https://drive.google.com/drive/folders/0B5dKo9igl8W4dWpiMmlEYWx3b0k?usp=sharing

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

Hi Dirk:

In the IQ data file you provided I can seem to find any pulses of the
nominal 10 msec length, no matter how I filter and rotate the
spectrum.
There is a lot of EMI, which looks like the intermodulation products
of a continuously on guy who is drifting/chirping down in frequency.

So could you please confirm or clarify the following:

1. The format of the binary data file.  I am assuming 32 bit float I
and 32 bit float Q pairs, as that is what the GNURadio file sink would
normally create.
2. The sample rate.  I am assuming 1 Msps.
3. The center freq.  I am assuming 150.22 MHz.
4. The pulse duration. I am assuming 10 milliseconds.
5. At what frequency offset, from the center frequency, should the
pulse be at?  I'm assuming somewhere withing +/- 5 kHz of the center
spike, but there are at least two EMI spikes in that range.

Thanks.

-Andy

On Wed, Mar 15, 2017 at 5:23 AM, Dirk Gorissen <dgoris...@gmail.com> wrote:
> Hi Andy, Marcus,
>
> Thanks very much for taking the time to think about this.
>
> Just to answer your questions:
>
>>Dirk's problem was the low SNR in his recording, so he'd like to take
>>the shape of his pulse into consideration, but he doesn't know the
>>spectral position of the same – Dirk, can you confirm?
>
> Yes, Im dealing with a very weak signal against quite a bit of
> background noise so the more prior knowledge I can leverage the
> better.
>
>>Dirk, thinking about this, the relation of the spectral uncertainty to
>>the bandwidth of the pulse would be interesting  – can you refresh our
>>memory? I think the pulse was 10ms long (so, pretty long) but I forgot
>>how it looked like.
>
> Yes, 10ms long (this is pretty exact), occurring every 1.5 seconds, in
> the 150MHz range. My input stream is coming from an SDR.
> As an aside I actually have multiple transmitters each pulsing at
> slightly different frequencies (e.g., 150.10, 150.22, ...) but Im
> happy to treat them independently so you can ignore that and assume
> there is just one.
>
> You can see pictures of the pulse (taken a while back, for a specific
> tx frequency) here: https://goo.gl/photos/Y3Ea6kJo1ewrcDYM8
>
> Note though that this is taken with the transmitter very close to the
> antenna so the signal is unrealistically strong. So its just to
> illustrate.
>
> I also quickly captured a file with raw IQ samples (File sink) in case
> anybody is interested. It starts with the transmitter very close to
> antenna, moves progressively further until out of range and then back.
> Its only about a minute or two tops but at 1msps it ended
> up as 813 MB though.
>
> https://drive.google.com/drive/folders/0B5dKo9igl8W4dWpiMmlEYWx3b0k?usp=sharing
>
>>What you really care about is
>>that there's a *tone* for about 8ms < t < 12ms where there is none else
>>(to rule out detection of spurs and other interference), is that right?
>
> Yes. The "tone" happens every 1.5 seconds and I want to catch as many
> of those occurrences as possible as the receiver moves through space.
> So for every 1.5 seconds I need to make a decision: was there one, or
> not.
>
> Note that the receiver is moving. So perhaps initially I may be well
> out of range of the signal and get nothing. But as I move closer as
> some point I will start picking up those pulses. The earlier and more
> reliably I can pick them up the better.
>
> I actually did spend some time looking at PLLs & the gnu radio block
> at some point. However I readily admit to being a software person not
> a DSP/Radio person. I have the day job to deal with today but I will
> have a study of the PLL block given Andy's tips and report back.
>
> Cheers
> Dirk
>
>
>
>
>
> On 14 March 2017 at 16:37, Andy Walls <a...@silverblocksystems.net> wrote:
>> On Tue, 2017-03-14 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
>> wrote:
>>> Date: Tue, 14 Mar 2017 15:49:44 +0100
>>> From: Marcus M?ller <marcus.muel...@ettus.com>
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] fast parallel filtering
>>
>>> Hi Andy,
>>>
>>> Dirk's problem was the low SNR in his recording, so he'd like to take
>>> the shape of his pulse into consideration, but he doesn't know the
>>> spectral position of the same ? Dirk, can you confirm?
>>
>> Ah, OK.
>>
>>
>>> Dirk, thinking about this, the relation of the spectral uncertainty to
>>> the bandwidth of the pulse would be interesting  ? can you refresh our
>>> memory? I think the pulse was 10ms long (so, pretty long) but I forgot
>>> how it looked like.
>>>
>>> Having slept about this a couple of times: What y

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

On Tue, 2017-03-14 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Tue, 14 Mar 2017 15:49:44 +0100
> From: Marcus M?ller <marcus.muel...@ettus.com>
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] fast parallel filtering

> Hi Andy,
> 
> Dirk's problem was the low SNR in his recording, so he'd like to take
> the shape of his pulse into consideration, but he doesn't know the
> spectral position of the same ? Dirk, can you confirm?

Ah, OK.


> Dirk, thinking about this, the relation of the spectral uncertainty to
> the bandwidth of the pulse would be interesting  ? can you refresh our
> memory? I think the pulse was 10ms long (so, pretty long) but I forgot
> how it looked like.
> 
> Having slept about this a couple of times: What you really care about
> is
> that there's a *tone* for about 8ms < t < 12ms where there is none
> else
> (to rule out detection of spurs and other interference), is that
> right?
> 
> Maybe we've been focussing too much on filter-based detection. What if
> we just *use* that feature of the signal being periodic for a duration
> of t, and not else? A PLL would be able to "lock" on the tone (much
> like
> an FM Radio with a PLL will lock on the station's carrier), and if we
> observe the phase error being limited for t, we can derive there was a
> pulse.
> 
> Andy, does that sound like a feasible approach?

Yes.  With the added benefit of GNURadio's carrier tracking PLL actually
performing part of the correlation operation for you, if it works out.

So use the carrier_tracking_pll block.  If it locks onto a good signal,
it will mix it down to DC.  Then all you need is an averaging filter,
like the single pole IIR filter block or the moving average filter
block, operating on the real part of that output.  That will act as a
lock detector, and, I think, also completes a correlation operation, if
you use a non-normalized moving average filter (since the carrier
tracking PLL block gives you a point by point complex multiply with the
conjugate of the complex carrier tone).

You'll want to set the PLL allowed min and max frequency bounds
properly; be careful since the input arguments have tricky units.

You'll also want the loop bandwidth set pretty wide, since you want to
lock-in rapidly.

Also, if I'm thinking about this properly:
To get faster lock in, you may want your frequency range of interest to
be somewhere in between Fs/4 and Fs/2; and not near DC.  If you're
within the lock-in range of the PLL, you'll lock within 1 cycle.  If
you're in the pull-in range of the PLL, it can take many cycles to get
into lock.

Regards,
Andy

> Cheers,
> 
> Marcus
> 
> 
> On 14.03.2017 14:18, Andy Walls wrote:
> > If there is no information on the signal, why not just do a straight
> > energy detector:
> >
> > source -> complex bandpass filter -> complex to mag -> burst/energy
> detector -> QT Time sink (triggering on start of burst tag)
> >
> > The complex bandpass filter just has to catch all the frequencies of
> > interest.  (A complex bandpass filter does not have a symmetrical
> image
> > around DC.)
> >
> > The burst/energy detector has to detect some minimum number of time
> > domain samples contiguously above some noise/signal threshold that
> you
> > set, and tag the pulse.  It also has to detect when the time domain
> > samples fall below the threshold.  The burst/energy detector can
> work
> > with a preset noise/signal threshold, or you could periodically
> > re-estimate that threshold.
> >
> > GNURadio does not have a stock block that does burst/energy
> detection,
> > so you'll have to find one on the 'Net or write one yourself.
> >
> > -Andy
> >
> >
> > Dirk Gorissen wrote:
> >> Hi Martin,
> >>
> >> The aim is to check for the existence of a 10ms pulse in the
> incoming
> >> radio signal (from an sdr). The thing is I only know the frequency
> of
> >> the pulse to within ~1khz.
> >>
> >> So a single filter in my case is: generate a synthetic pulse
> (complex
> >> sin wave) of the same length and with a frequency f. Then take the
> >> reverse of the complex conjugate of this pulse to give me the taps
> for
> >> a FIR filter.
> >>
> >> Repeat the above for each frequency I want to check. E.g., 10
> filters
> >> each 100Hz apart.
> >> Then I just take the magnitude of each filter output and push
> through
> >> a Max to get my final correlations.
> >>
> >> I can come up with an algorithm that tries to be clever and with
> some
> >> accounting tries to find what frequency matters most bu

Re: [Discuss-gnuradio] fast parallel filtering

[Andy Walls]

If there is no information on the signal, why not just do a straight
energy detector:

source -> complex bandpass filter -> complex to mag -> burst/energy detector -> 
QT Time sink (triggering on start of burst tag)

The complex bandpass filter just has to catch all the frequencies of
interest.  (A complex bandpass filter does not have a symmetrical image
around DC.)

The burst/energy detector has to detect some minimum number of time
domain samples contiguously above some noise/signal threshold that you
set, and tag the pulse.  It also has to detect when the time domain
samples fall below the threshold.  The burst/energy detector can work
with a preset noise/signal threshold, or you could periodically
re-estimate that threshold.

GNURadio does not have a stock block that does burst/energy detection,
so you'll have to find one on the 'Net or write one yourself.

-Andy


Dirk Gorissen wrote:
> Hi Martin,
> 
> The aim is to check for the existence of a 10ms pulse in the incoming
> radio signal (from an sdr). The thing is I only know the frequency of
> the pulse to within ~1khz.
> 
> So a single filter in my case is: generate a synthetic pulse (complex
> sin wave) of the same length and with a frequency f. Then take the
> reverse of the complex conjugate of this pulse to give me the taps for
> a FIR filter.
> 
> Repeat the above for each frequency I want to check. E.g., 10 filters
> each 100Hz apart.
> Then I just take the magnitude of each filter output and push through
> a Max to get my final correlations.
> 
> I can come up with an algorithm that tries to be clever and with some
> accounting tries to find what frequency matters most but I wouldnt be
> surprised if there is some theory you can use to do this more
> efficiently or even in a single shot. But this is where Im unsure.
> 
> Cheers
> Dirk
> 
> 
> On 14 March 2017 at 01:09, Martin Braun  wrote:
> > How related are those filters? Is this a candidate for polyphase DSP?
> >
> > -- M
> >
> > On 03/11/2017 02:01 PM, Dirk Gorissen wrote:
> >>  Hi Marcus,
> >>
> >>  Sorry, I should have clarified. You may recall an earlier thread from
> >>  mine where Im looking to pick out a short pulse from background noise
> >>  but I dont know the exact frequency of the pulse. Thought I would
> >>  start a new thread with a clear, specific question.
> >>
> >>  There is an uncertainty of +/- 1khz. So I can define multiple filters,
> >>  correlating for different pulse frequencies across the 1khz range. I
> >>  can implement this with different filters running in parallel but I
> >>  was looking for a more flexible / efficient way.
> >>
> >>  If you think this is out of scope for this list no problem at all,
> >>  just let me know.
> >>
> >>  Cheers
> >>  Dirk
> >>
> >>> On 11 March 2017 at 20:02, Marcus Müller  wrote:
>  Hi Dirk,
> 
>  this is more of a general DSP question than a GNU Radio question:
> 
>  How do these filters relate to each other?
> 
>  My gut feeling is that this gets a lot easier as soon as you tell us why
>  you're doing this, i.e. for what purpose :)
> 
>  Best regards,
>  Marcus
> 
>  On 11.03.2017 19:28, Dirk Gorissen wrote:
> > Hello all,
> >
> > Given a stream of samples I would like to apply n slightly different
> > filters to it with n being able to be chosen at runtime. Then combine
> > the results back to a single stream.
> >
> > As a test I built a flowgraph with the following chains in parallel for 
> > n 
> > = 6
> >
> > | ->  decimating fir filter 1 -> complex to mag ->|
> > stream -> | ->  decimating fir filter 2 -> complex to mag ->|  -> 
> > Max 
> > -> ...
> > |  
> > |
> > | ->  decimating fir filter n -> complex to mag ->|
> >
> > So the same stream is sent to each chain (decimation is 1) and the
> > output of each chain is pushed through a big Max block with 6 inputs.
> >
> > This works but not particularly elegant and a bit annoying to change
> > if I suddenly decide I want to change n. In particular it also does
> > not seem computationally efficient.
> >
> > What I would like is to replace the above by a single block that
> >
> > - replicates the input n times
> > - applies each filter on each replica
> > - combines the output again to a single stream
> > - have a tunable n parameter
> > - is fast
> >
> > I did this with an Embedded python block doing essentially this:
> >
> > for i in range(n):
> >  out[i] = scipy.signal.lfilter(taps[i], 1, input)
> >
> > This is using exactly the same taps as in the chain case. This works
> > but the output is different and worse than what I get with the
> > separate chains. As a test, instead of lfilter I tried:
> >
> 

Re: [Discuss-gnuradio] Improve FSK4 decodes in OP25

[Andy Walls]

On Sun, 2017-01-22 at 20:22 -0500, Luke Berndt wrote:

> Thanks again for all the help! It is great to be getting clear audio
> and having things look right on the charts.

> - Luke

You're welcome.

One thing I forgot to mention, that might also help reception:

Use antennas that are at least a quarter wavelength long with a good
ground plane and halfway decent antenna cable.

A 1/4 wavelength at 450 MHz is

  (299.8e6 m/s / 450e6 Hz) * 1/4 ~= 0.167 m ~= 6.6 in

The stock RTL-SDR antennas are shorter than 6.6 in and are thus
"electrically small".

Amazon's stores have a few reasonable priced ones right off the first
page of the search for scanner antennas:
https://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Daps=scanner+antenna=i%3Aaps%2Ck%3Ascanner+antenna
https://www.amazon.com/1094-BNC-Scanner-Antenna-BNC-Male-Connector/dp/B01DUSBHDM/ref=sr_1_1?s=electronics=UTF8=1485176439=1-1=scanner+antenna
https://www.amazon.com/Scanner-Radio-Magnet-Mobile-Antenna/dp/B004C1T7PC/ref=sr_1_19?s=electronics=UTF8=1485176541=1-19=scanner+antenna

with enough cable to move the antennas farther from indoor UHF noise sources.


-Andy


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

Re: [Discuss-gnuradio] Improve FSK4 decodes in OP25

[Andy Walls]

On Sun, Jan 22, 2017 at 7:53 PM, Andy Walls <a...@silverblocksystems.net> wrote:
> On Sun, Jan 22, 2017 at 7:19 PM, Luke Berndt <l...@robotastic.com> wrote:
>
>> Well, there was definitely a lot of noise! and I am pretty sure the source
>> was my computer. I got a couple of USB extension cables so I could get away
>> from the computer and the USB hub and that helped a lot. I was able to noise
>> floor by about 20db.
>>
>> Almost every transmission is coming in clear now.
>
> Yay!
>
>
>> Oddly enough though when I
>> do a debug recording, it still doesn’t give me the 4 distinct levels. Any
>> thoughts on what could be up?
>
> You might be looking at a section of the IQ where there is no
> transmission ongoing?
>
> Or you've tweaked something (e.g. baseband level with a multiply
> const) such that the
> joint tracking loop in the 4FSK demod block loses track of the symbol clock?
>
> IDK.

FWIW, the gr-op25 block I'm using came from:

git://op25.osmocom.org/op25.git

the head of the master branch.  At the time I checked it out,
the head commit was:

commit d34fbe52edcfcb79dac349f221e5181adcf2eb8f
Author: Max <ikj12...@yahoo.com>
Date:   Wed Oct 7 16:08:29 2015 -0400

reduce skip time


My GNURadio is from the head of the master branch from a few weeks ago:
v3.7.10.1-191-g0971afba


- Andy

>> Here is an example of the new and improved reception:
>> https://www.dropbox.com/s/7is60h94ctf6d0t/34800-1485122982_4.90888e%2B08.raw
>
> With this file, and the flowgraph I provided to you, I get the four
> levels  (see one of the
> two attached pictures).  The levels are a little noisy, but the symbol
> slicer should sort
> them out with only a few errors, and error correcting code should fix
> the stray symbol errors.
>
> There are parts in the IQ data where no transmission is being sent,
> which will look like a
> mess.  See the second attached picture.
>
>
>
>>  - Luke
>
> Regards,
> Andy

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

Re: [Discuss-gnuradio] Improve FSK4 decodes in OP25

[Andy Walls]

Hi Luke:

On Tue, 2017-01-17 at 12:50 -0500, Luke Berndt wrote:
> Andy - Thank you so much, this was extremely helpful. I switched to
> your RF chain and I think it helped a bit.

I'm glad it helped.

FWIW I tried an alternate FM demod approach - 4 PLLs one at each tone -
but the tones turned out to be not spaced far enough apart for that to
work well.  I'd didn't bother with the 4 bandpass filter, non-coherent
approach that Marcus mentioned, since 4 coherent PLL's didn't work out.

Stick with either the FM detector or Quad Demod.

> As you can probably guess, I am more of a programmer than an RF
> expert.

I'm not very good a great many things myself. :)

> 
> It does look like Max has a branch of OP25 which has a deemphasis
> filter that has been tuned for P25.
> https://git.osmocom.org/op25/tree/op25/gr-op25_repeater/apps/tx/op25_c4fm_mod.py?h=max
>  It might be tricky to port to C++ because it uses Numpy, but I am going to 
> give it a shot.

Don't bother.  That's just a moving average filter of approximately the
symbol length.  The same one I have in the flowgraph I gave you.  The
sinc(4800f) in the frequency domain, works out to a boxcar in the time
domain.

Now the APCO P25 transmitters' pre-emphasis filter is a little weird,
since it is 1/sinc(4800f) in the frequency domain and goes infinite.
However it is truncated at 2880 Hz, before it hits it's first infinity.
Luckily you don't need the pre-emphasis filter.

> 
> I do think you are right though, the underlying problem is that there
> is a lot of noise. This may sound crazy, but I think it is coming from
> the USB hub I am using. I know USB2 operates around 480MHz and I am
> trying to record at 490MHz. I am going to experiment with my setup a
> bit to see if this is it.

Not crazy; EMI is a real thing in UHF.

The source can also be PC DRAM clocks, PC monitors, etc.

Funny side note: my directional TV antenna gets lots of noise at least
once a day when it points at the galactic disc.  Apparently the Milky
Way is a large source of UHF noise.


> 
> Thanks again for taking the time to put this all together. I will
> report back on how things are going and if mange to get clean
> recordings.

It was fun.  Down where I live they've just upgraded to APCO P25, but
its all new and all Phase II, so no C4FM signals for me. :(

Good luck!

-Andy

> 
>  - Luke
> 
> On Sun, Jan 15, 2017 at 6:58 PM, Andy Walls
> <a...@silverblocksystems.net> wrote:
> Hi Luke,
> 
> 
> See the attached GRC for what can be done in GNURadio.
> 
> 
> 1. You need the baseband noise filter.
> 
> 2. You may or may not need the deemphasis filter.  It appears
> to make things better,
> but it introduces receiver side ISI, since the filter doesn't
> get dumped at every symbol
> peak. (APCO 25 expects an integrate and dump deemphasis
> filter, this one just
> integrates).
> 
> 3. You may wish to use the FM detector PLL instead of the Quad
> Demod block.  You
> can limit symbol peak frequency deviation using the Max Freq
> and Min Freq parameters.
> Currently, I have them set at +/-3 * 600 Hz * 190%.  Leave the
> loop bandwidth alone;
> 
> it is set at symbol_rate/2 * 1.20 Hz = 2880 Hz, which is where
> the transmitter Nyquist
> 
> filter should cut off.
> 
> 
> The signal you provided really does have a very poor SNR.  The
> attached low SNR
> 
> png shows the best I could do with it.  There are some of the
> 4 levels visible in the chaos,
> 
> but it's not good.  I have attached a png from a high SNR test
> signal for comparison.
> 
> 
> So what you can do "outside" of GNURadio:
> 
> 
> 1. Attach an external receiver bandpass filter for the 470 -
> 512 MHz safety
> 
> band to your radio.  The only small, reasonably priced, off
> the shelf ones I could find
> are ceramic packages that are expected to be soldered to a
> board. :(
> 
> 
> 2. Set your gains on your SDR smartly to maximize your
> receiver noise figure.
> 
> Set the RF gain as high as you can without clipping the IF
> stage, set the 
> 
> IF gain as high as you can without clipping the Base Band
> stage.  Set the Base
> 
> Band gain as high as you can without clipping the ADC inputs.
> 
> https://en.wikipedia.org/wiki/Friis_formulas_for_noise
>

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Andy Walls]

On Wed, 2016-12-07 at 12:10 -0500, Andy Walls wrote:

> > From GDB I can see
> > 
> > 
> > d_filtnum = 0
> > count = -67108696
> > d_out_idx = 0
> > 
> 
> This is a garbage-in, garbage-out problem I've seen exactly before with
> other blocks and the PFB clock sync block.
> 
> 1. Check to make sure that your filter taps don't trace out a function
> that has discontinuities or flat spots (i.e. a square pulse), and the
> PFB clock sync algorithms can't handle that.

typo:  ... *as* the PFB clock sync algorithms can't handle that.

> 2. Add a tag_debug block before the PFB clock_sync and look for time_est
> tags with values outside the range [0.0, 1.0).
> 
> -Andy



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

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[Andy Walls]

>  From: 
> devin kelly
>   Subject: 
> Re: [Discuss-gnuradio] Segfault
> with
> volk_32fc_32f_dot_prod_32fc_a_avx
>  Date: 
> Wed, 7 Dec 2016 10:18:32 -0500
> 
> __


> I think I've found part of the problem:
> 
> 
> Looking here (on frame 2 in gdb):
> 
> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L465
> 
> 
> 
> This is the line where filter is called (which is where the segfault
> occurs):
> 
> 
> d_filters[d_filtnum]->filter([count+d_out_idx])
> 
> 
> From GDB I can see
> 
> 
> d_filtnum = 0
> count = -67108696
> d_out_idx = 0
> 

This is a garbage-in, garbage-out problem I've seen exactly before with
other blocks and the PFB clock sync block.

1. Check to make sure that your filter taps don't trace out a function
that has discontinuities or flat spots (i.e. a square pulse), and the
PFB clock sync algorithms can't handle that.

2. Add a tag_debug block before the PFB clock_sync and look for time_est
tags with values outside the range [0.0, 1.0).

-Andy


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

Re: [Discuss-gnuradio] Debugging ControlPort/Thrift problem (Re: costas ambiguity and correlate-and-sync block in qpsk)

[Andy Walls]

On Sun, 2016-04-03 at 13:01 -0400, Andy Walls wrote:
> >On April 3, 2016 11:31:02 AM EDT, Tom Rondeau wrote:
> >>On Sun, Apr 3, 2016 at 11:27 AM, Landsman, Arik wrote:

[snip]

> >>>> Here is some good info on how GRNURadio's control port works at a
> >>high
> >>>> level:
> >>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort
> >>>>
> >><http://redir.aspx?REF=azbe_GyxFRKBpOrbCXsEn87Wj8ET5GUm0QC3BOXvRTTOmAsr1FvTCAFodHRwczovL2dudXJhZGlvLm9yZy9yZWRtaW5lL3Byb2plY3RzL2dudXJhZGlvL3dpa2kvQ29udHJvbFBvcnQ.>
> >>>> https://gnuradio.org/doc/doxygen/page_ctrlport.html
> >>>>
> >><http://redir.aspx?REF=SxLIHILotdP8HOdDt_K6tXfxwQKnxOUFu1TiyaDWXwfOmAsr1FvTCAFodHRwczovL2dudXJhZGlvLm9yZy9kb2MvZG94eWdlbi9wYWdlX2N0cmxwb3J0Lmh0bWw.>
> >>>>
> >>>> From that second page, it appears that running two flowgraphs on
> >the
> >>>> same machine has a problem caused by Apache Thrift and GNURadio's
> >>>> configuration of the Control Port network port (default of 9090).
> >>>>
> >>https://gnuradio.org/doc/doxygen/page_ctrlport.html#ctrlport_thrift_issues
> >>>>
> >><http://redir.aspx?REF=PEreM48t5VngbsJ1nPZyY40coia_Ki9MnN28CfQhswzOmAsr1FvTCAFodHRwczovL2dudXJhZGlvLm9yZy9kb2MvZG94eWdlbi9wYWdlX2N0cmxwb3J0Lmh0bWwjY3RybHBvcnRfdGhyaWZ0X2lzc3Vlcw..>
> >>>>
> >>>> So please only run on flowgraph at a time, at first, to
> >troubleshoot
> >>>> this issue.
> >>>>
> >>>> Second, you may want to try setting the GR_CONF_THRIFT_PORT
> >>environment
> >>>> variable to something other than 9090, a port that you know is open
> >>on
> >>>> your machine, for each separate flowgraph that you run.
> >>>>
> >>>> FYI, the modulate_vector block runs a "mini"-flowgraph, before the
> >>main
> >>>> flowgraph actually runs:
> >>>>
> >>>>
> >>>>
> >>https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/modulate_vector.cc#L59
> >>>>
> >><http://redir.aspx?REF=rCyK29_HIPXb4AHqBP038K2B4o2SxURzlIzwumhDH6vOmAsr1FvTCAFodHRwczovL2dpdGh1Yi5jb20vZ251cmFkaW8vZ251cmFkaW8vYmxvYi9tYXN0ZXIvZ3ItZGlnaXRhbC9saWIvbW9kdWxhdGVfdmVjdG9yLmNjI0w1OQ..>
> >>>>
> >>>> Hopefully, there isn't some sort of weird race condition with the
> >>Thrift
> >>>> port being open for the modulate_vector block's mini-flowgraph and
> >>the
> >>>> main flowgraph.
> >>>>
> >>>>
> >>>> Hi Tom,
> >>>>
> >>>> Do you have any comments or insights on Arik's Thrift error message
> >>>> and/or the possibility of modulate_vector's mini-flowgraph causing
> >>>> problems with Thrift's network port and the main flowgraph?
> >>>>
> >>>> Regards,
> >>>> Andy
> >>>>
> >>>
> >>> Andy,
> >>>
> >>> I think you've got it on the Thrift issue. However, running the
> >>modulate
> >>> vector mini flowgraph first should kill itself immediately and free
> >>up the
> >>> port, so I don't think that's the problem. On the other hand, I've
> >>been
> >>> seeing issues recently where every time I launch GRC, it seems to
> >>cause a
> >>> conflict with whatever port I'm setting. Almost as though GRC is
> >>launching
> >>> something and holding on to the port specified in the thrift.conf
> >>file. I
> >>> thought this could just be a problem on my laptop (I've been
> >>traveling a
> >>> lot -- more than usual even -- and developing on my laptop can lead
> >>to me
> >>> doing a lot of crazy things), but I think I've since seen it on my
> >>office
> >>> workstation as well. That could be a problem here, too. We'll have
> >to
> >>track
> >>> that down.
> >>>
> >>> Using the GR_CONF_THRIFT_PORT variable is a good idea to set the
> >port
> >>per
> >>> flowgraph you're running. Another option is to set the port to 0 in
> >>> thrift.conf, which will cause Thrift to open an ephemeral port for
> >>each
> >>> server is creates. You'll just have to pay attention to the message
> >>output
> >>> that announces the ControlPort endpoint to find out what port it's
> >>running
> >&

Re: [Discuss-gnuradio] FSK demodulation questions

[Andy Walls]

On October 18, 2016 3:39:28 PM EDT, Andy Walls <a...@silverblocksystems.net> 
wrote:
>
>It works because the spectrum of a GMSK signal has two spectral peaks
>spaced equidistant from the center frequency.


Oops.  "... spectrum of a *squared* GMSK signal has two spectral peaks ..."

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

Re: [Discuss-gnuradio] FSK demodulation questions

[Andy Walls]

>  From: 
> Ellis, Duane
> 
> 
>  Date: 
> Tue, 18 Oct 2016 18:57:33 +
> 
> __
> Hi,
> 
> I've been working towards an FSK demodulator scheme using GNU radio (more 
> specifically, the signals are GFSK)
> I've read through this example: 
> https://nccgroup.github.io/RFTM/fsk_receiver.html
> 
> Specifically it talks about the "add_const" block, the value of which was 
> determined by trial and error for the specific data set in use.
> 
> This "constant" is actually the frequency error value
> 
> Here, in this slide deck (slide 2)
> http://www.qsl.net/kb9mwr/projects/dv/apco25/GnuradioFourLevelFSK.pdf
> 
> They show a frequency correction feed back loop from the FSK4 demodulator to 
> the front end, but uses a custom module.
> 
> I'm looking for a simpler way to do this using "stock components" that are 
> already in Gnu Radio.
> 
> I can of course - make this work for one specific transmitter, and one 
> specific 
> receiver. This solution does not work well when I have 50 different 
> transmitters, I need a solution that can adjust dynamically.
> 
> Any suggestions for stock components? Or another example?

So, if you want a "near" stock, open loop, coarse frequency estimation
and correction for GMSK (GFSK with h=1/2), then have a loog at gr-ais'
square_and_fft_sync_cc block, along with its freqest block:

https://github.com/bistromath/gr-ais/blob/master/python/gmsk_sync.py
https://github.com/bistromath/gr-ais/blob/master/lib/freqest_impl.cc

It works because the spectrum of a GMSK signal has two spectral peaks
spaced equidistant from the center frequency.

It works best with continuous, fairly evenly distributed, between mark
and space, data.  It can get fooled at the start or end of a burst, or
during a long run of mark or space.

-Andy

> Thanks.



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

Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

[Andy Walls]

>  From: 
> John Malsbury
>   Subject: 
> Re: [Discuss-gnuradio] Rectangular
> Pulse Shape w/ PFB Clock Sync
>  Date: 
> Thu, 29 Sep 2016 09:19:20 -0700
> 
> __
> Neil,
> 
> 
> Yes. It does lock and track with those taps.  But with about 0.2-0.3
> dB of added implementation loss. 
> 
> 
> -John

You may want to experiment with different Timing Error Detectors (TEDs),
aside from Gardner's, in your original flowgraph, to see if you can do
better.

This MatLab documentation page has a nice picture of where the TED sits
in a clock recovery block, and also has the math for some popular TEDs:
http://www.mathworks.com/help/comm/ref/comm.symbolsynchronizer-class.html


FWIW, I found this thesis paper, which has a short discussion of the
popular TEDs and measuring performance of TEDs:
http://www.ece.usu.edu/grad/reports_theses_disseratations/2010/Bage_Jayaraj_Nagendra/thesis.pdf

In that thesis, the author develops a Minimum Signal Error Rate TED
(MSERTED), that has as its objective criteria to minimize the the log of
the probability of error, log(Pe).  Similar to the PFB clock sync block,
MSERTED uses a derivative of the matched filter.  MSERTED's output
includes, as a multiplier, the output of the derivative matched filter,
which would have many 0's for a square pulse filter.  You would have to
use the Rx RC filter that Neil suggested, if you wanted to try MSERTED.

Regards,
Andy


> 
> On Wed, Sep 28, 2016 at 6:41 PM, Neil Schafer 
> wrote:
> I haven’t tried it myself, but wouldn’t using a raised
> cosine or Gaussian filter for your taps still provide
> some pulse shaping for the PFB clock sync to track?
> You’re essentially leap-frogging the RRC matched
> filters at transmitter and receiver, and placing the
> entire burden at the receiver, but at the decision
> point of the clock synch the end result should be the
> same.
> 
>  
> 
> Neil
> 
> 



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

Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

[Andy Walls]

>  From: 
> John Malsbury
>   Subject: 
> [Discuss-gnuradio] Rectangular
> Pulse Shape w/ PFB Clock Sync
>  Date: 
> Wed, 28 Sep 2016 00:07:46 -0700
> 
> __
> I'm struggling with something pretty basic.  I am trying to achieve
> near theoretical performance detection of a rectangular (no RRC) QPSK
> signal at 2 or 4 sps.  I have an existing  solution that uses a
> discrete FIR filter followed by a Gardner timing recovery loop.  The
> taps of the FIR filter are a box car function.  It works quite well
> and implementation loss is negligible.
> 
> 
> However, I'd like to achieve the same thing using the stock PFB clock
> sync.

It won't work.  The PFB clock recovery uses a derivative filter based on
the matched pulse filter, and relies on a peaked match pulse filter
shape. (Which has a derivative filter tap value of ideally 0 at the
center of the matched pulse filter taps.)

The derivative filter of a matched pulse filter for square pulses
doesn't have the properties the PFB clock sync block needs.

Regards,
Andy

>   For the life of me I can't figure out the proper specification of
> nfilts, and taps.
> 
> 
> Given a signal with rectangular pulse shape at 'sps', can someone
> spell out the taps and nfilt i need to enter into PFB clock sync for a
> properly matched filter bank?
> 
> 
> 
> -John
> 
> 
> __
> 



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

Re: [Discuss-gnuradio] Calculating additive noise power for known signal

[Andy Walls]

On Wed, 2016-08-24 at 13:55 -0400, Andy Walls wrote:
> On Wed, 2016-08-24 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> > Date: Tue, 23 Aug 2016 16:42:33 -0700 (MST)
> > From: Paul Creaser
> > To: Discuss-gnuradio@gnu.org
> 
> > In a real system the signal would be a preamble, which would normally be 
> > used
> > for synchronization purposes at the receiver end (For example PLC system).
> > 
> > "I'm not quite sure what you mean by "cyclic noise", but the example you
> > give is 50 Hz (or 60 Hz) hum, so a narrowband interference."
> > 
> > Cyclic noise, perhaps my understanding is incorrect. In a PLC system, the
> > noise rejection system uses a Zero Cross detection to detect the beginning
> > of a power cycle (50Hz/60Hz). During the cycle at the same phase point,
> > noise repeatedly occurs. So on a scope you would see a nice sine wave for
> > the power and noise which repeats at the same phase point in the power
> > cycle.
> 
> Ah, now I understand: a periodic noise impulse.  So definitely not an
> AWGN.
> 
> 
> > This is different from the 50 Hz noise I suggested previously. However the
> > idea/hope is that this noise is narrow band noise and because of its
> > repetitive behaviour,
> 
> Impulsive noise is usually broadband.  Signals that are concentrated in
> the time domain are spread out in the frequency domain, and vice versa
> (this falls out from the Fourier transform).
> 
> A periodic, broadband noise impulse is essentially going bump up the
> noise floor for a short time every 50th (or 60th) of a second.
> 
> 
> 
> > .i.e. occurring in the same point in the cycle, and
> > relatively stable amplitude, it should be possible to remove it from a known
> > signal.
> > 
> > I will take on board all the useful advice and continue my studies.
> > 

This paper on impulsive noise mitigation in PLC systems seems apropos:
https://arxiv.org/pdf/1303.1217.pdf

-Andy


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

Re: [Discuss-gnuradio] Calculating additive noise power for known signal

[Andy Walls]

On Wed, 2016-08-24 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Tue, 23 Aug 2016 16:42:33 -0700 (MST)
> From: Paul Creaser
> To: Discuss-gnuradio@gnu.org

> In a real system the signal would be a preamble, which would normally be used
> for synchronization purposes at the receiver end (For example PLC system).
> 
> "I'm not quite sure what you mean by "cyclic noise", but the example you
> give is 50 Hz (or 60 Hz) hum, so a narrowband interference."
> 
> Cyclic noise, perhaps my understanding is incorrect. In a PLC system, the
> noise rejection system uses a Zero Cross detection to detect the beginning
> of a power cycle (50Hz/60Hz). During the cycle at the same phase point,
> noise repeatedly occurs. So on a scope you would see a nice sine wave for
> the power and noise which repeats at the same phase point in the power
> cycle.

Ah, now I understand: a periodic noise impulse.  So definitely not an
AWGN.


> This is different from the 50 Hz noise I suggested previously. However the
> idea/hope is that this noise is narrow band noise and because of its
> repetitive behaviour,

Impulsive noise is usually broadband.  Signals that are concentrated in
the time domain are spread out in the frequency domain, and vice versa
(this falls out from the Fourier transform).

A periodic, broadband noise impulse is essentially going bump up the
noise floor for a short time every 50th (or 60th) of a second.



> .i.e. occurring in the same point in the cycle, and
> relatively stable amplitude, it should be possible to remove it from a known
> signal.
> 
> I will take on board all the useful advice and continue my studies.
> 

So I have a couple of thoughts:

1. The LMS adaptive filter I suggested earlier won't do much good in the
face of broadband periodic noise impulses.  It still may help with
equalizing a poor channel, since PLC transmission lines are usually of
uncontrolled and unknown quality.

2. Your communication system should still use appropriate channel
filters and pulse matched filters, to mitigate the effects of broadband
noise that shows up outside your channel of interest.

3. HF systems are the only other systems I'm familiar with that deal
with impulsive noise.  HF communications systems often employ FEC and
interleavers to combat impulsive noise.

4. Adaptive noise cancellation techniques may help here, but I'm no
expert on them.  A quick Google turns up some decent material.

5. If you track the timing of the impulsive noise bursts, is it feasible
to have your system schedule its communications between the bursts? (I
don't know your topology.)  Think of it as a TDMA timeslot clock. :)
1/60th of a second at 9600 symbols/second is 160 symbols.

-Andy 


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

Re: [Discuss-gnuradio] Calculating additive noise power for known signal

[Andy Walls]

On Tue, 2016-08-23 at 15:36 -0700, Richard Bell wrote:
> Great answer. I wish I could upvote it! 

Thank you! You're too kind, in light of my typos (e.g. your -> you're,
of -> on).  :) 


> There should be a GNU Radio Stack Exchange type thing. 

There is :)

http://stackoverflow.com/questions/tagged/gnuradio

Regards,
Andy



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

Re: [Discuss-gnuradio] Calculating additive noise power for known signal

[Andy Walls]

On Tue, 2016-08-23 at 12:00 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 7
> Date: Mon, 22 Aug 2016 18:14:29 -0700 (MST)
> From: Paul Creaser 
> 
> I've just started studying methods used to detect and then filter out/remove
> cyclic noise from known signals. 
> 
> I have a signal of 256 samples which repeats itself. I take this signal,
> attenuate it and add noise at a specific band (frequency band), for example
> 50 Hz Sine Wave. In the simplest case this is none varying. However in the
> future it will vary slowly over time. 

I'm not quite sure what you mean by "cyclic noise", but the example you
give is 50 Hz (or 60 Hz) hum, so a narrowband interference.


> What I would like to do is find the power level of the additive cyclic noise
> (, which should be the difference between the two signals) and where in the
> frequency spectrum this noise exists. Using this information, I would hope
> to use weighting to recover the original signal.

If the noise is always out of the channel of your signal of interest,
then a bandpass filter will do the job and your done.

If the noise is in the channel of your signal of interest, then it
sounds like what you really want in the end is an adaptive equalizer or
filter.

If you're not afraid of a lot of work:
Just dive into implementing a Least Mean Squares (LMS) adaptive
filter.  

You can either make it Data-Aided (DA), adapting the filter when it
detects and operates on a known preamble; or Decision Directed (DD),
adapting the filter every time it makes a decision about what a data bit
should be.

I prefer using a Data-Aided LMS adaptive filter, as I often work with
signals that have known preambles.
 
Such a system would look something like:

received samples source -> channel filter -> automatic gain control ->
correlator to detect and mark the preamble -> LMS DA adaptive filter
-> ...

Translating that to example GNURadio blocks:

USRP Source -> Freq Xlating FIR Filter -> Feed Forward AGC ->
Correlation Estimator -> (Your custom LMS DA filter block) -> ...


> *Steps*
> 
> 1 I take the original and modified signal and rescale the modified signal to
> match the original.
> 
> At the moment I use a very naive approach which is to take the absolute sum
> of the 256 samples for both signals and from this calculate a simple scale
> factor. I think this should be OK where I have narrow band noise, but it may
> fail badly in other cases where the noise levels are high.
> 
> 2 Next I take the FFT of the two signals (256 samples).
> 
> 3 Calculate the noise
> 
> Using the difference between the FFTs, I then calculate the noise power.
> 
> *Two questions?*
> 
> 1 The rescaling method is very basic, using absolute accumulated sums. Does
> GNU radio have any blocks, which could perform this auto-scaling more
> effectively?

GNURadio has several AGC blocks.  They all have their quirks.  Pick one
an try to make it work.


> 2 Using the basic difference between the FFT's, such as the absolute
> magnitude difference, should provide a starting point for calculating the
> noise power. Again is this naive?

Noise power and noise density have specific meanings which I don't think
match what you're thinking about here.  AFAICT, you want to know the
power of an in-channel narrowband interference (so that you can
ultimately filter it out).

Looking at FFT's will give you a feel for the situation, but it's kind
of a blunt instrument, if you plan of filtering by direct FFT bin
scaling or excision.

It really sounds like what you want is an adaptive equalizer (aka
adaptive filter).

There's lots of existing literature on equalizers.
This lecture is still a little too advanced for most folks, but it has
the basic concepts covered clearer than most others I could find on
Google: 
http://www.eecg.toronto.edu/~johns/nobots/courses/ece1392/equalization2.pdf


Section 14.6 of this book describes the LMS algorithm:
https://www.amazon.com/Mathematical-Methods-Algorithms-Signal-Processing/dp/0201361868

And here is a PDF copy I spotted on the internet (click at your own
risk):
https://www.u-cursos.cl/usuario/834c0e46b93fd72fd8408c492af56f8d/mi_blog/r/4%29_Todd_Moon_Mathematical_Methods_and_Algorithms_for_Signal_Processing.pdf

-Andy



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

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

[Andy Walls]

On Fri, 2016-07-29 at 11:49 -0400, Michael Dickens wrote:

> I'm looking for an OOT to do the REP /REQ way that GR does -not-
> provide, or will just create one myself. I don't anticipate adding it to
> the core gr-zeromq component. I agree that it would add unnecessary
> complexity to those already-existing blocks. - MLD

I don't care if new blocks are added to gr-zmq to cover the other
combinations.

I just think its a bad idea to code a super-flexible gr-zeromq block
with "multiple-personalities" into a single C++ block and have its
functionality change between REQ/REP/PUB/SUB/PUSH/PULL based on an input
parameter.

BTW, I know of no OOT that has the functionality you need.  Sorry.

Regards,
Andy 




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

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

[Andy Walls]

>  From: 
> Francisco Albani
>   Subject: 
> Re: [Discuss-gnuradio] ZMQ REQ /
> REP naming Swap?
>  Date: 
> Thu, 28 Jul 2016 23:21:25 -0300
> 
> __
> Michael, I found the need to do the same for some applications. I also
> needed to choose between bind and connect (I made this a parameter of
> my block).
> 
> 
> Wouldn't be better to have just one sink and one source with
> selectable options, like:
> * socket_type: REP/REQ/SUB/PUB/PUSH/PULL
> 
> * method: bind / connect
> 
> * interface: stream / message
> 

I think this would make the gr-zmq C++ block code unnecessarily complex
and harder to maintain.  The block requirements for each combination of
parameters grow in different directions.

Some things you'd have to deal with:
1. REP blocks have a receive then send main loop;
   REQ blocks have a send then receive main loop.

2.  REQ/REP can never drop messages/samples and so the tag propagation
code can be simple;
PUB/SUB can drop messages/samples and tag propagation code needs to
account for that in tag offsets

3. GNURadio messages are usually small enough that they can be handled
in one call to work().  GNURadio sample stream payloads can have a great
many samples that need to be handled across several calls to work().

It's just not worth it at the C++ level.  Maybe at the GRC block XML
file level, it might be worth it.

My $0.02

Regards,
Andy


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

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

[Andy Walls]

From:   Michael Dickens
Date:   Thu, 28 Jul 2016 20:23:36 -0400
> On Thu, Jul 28, 2016, at 06:44 PM, Johnathan Corgan wrote:
>> The ZMQ REQ/REP dataflow has the receiving end REQuest data from the
sending end when needed, which REPlies with a packet.  It's a form of
flow control.
>>
>> From the GNU Radio perspective, streams flow into GNU Radio sinks to
exit the flowgraph, and data is sourced into a flowgraph from a GNU
Radio source block.
>>
>> Thus, the correct model is GR Stream | GR REP Sink | ZMQ REP | ZMQ
Transport | ZMQ REQ |  GR REQ source | GR stream

[snip]

>My argument here is that it's equally valid to do the ZMQ REP/REQ
>transport either way, and if other projects are doing it the opposite
>way from GNU Radio, why aren't we providing an option to support that
>way?

[snip]

The ZMQ Guide is pretty clear that the core REQ/REP pattern is intended
to have the following usage:

   REQuests are sent by Clients 
   REPlies are sent by Servers

Likewise in GNURadio it is clear that

   Sinks send data out of a GNURadio instance
   Sources send data into a GNURadio instance

Server vs. client and Source vs. Sink are orthogonal. So any of the
following is valid:
   REQ source
   REQ sink
   REP source
   REP sink
   REQ msg source
   REQ msg sink
   REP msg source
   REP msg sink

But what you actually should use depends on the functional context.

In the context of using REQ/REP, here are some use cases where I would
likely use a GNURadio instance as a server or a client.  This is for
GNURadio instances communicating with programs which are not GNURadio
instances:

GNURadio as a client:
-
(C1) Accepting medium to high rate sample data from an external source
for RX processing (REQ source)
(C2) After Rx processing, providing medium to low rate PDUs/messages to
an external source. (REQ msg sink)
(C3) Providing low rate status messages (REQ msg sink)
(C4) Accepting low rate sample data from an external source for further
Tx processing (REQ source)

GNURadio as a server:
-
(S1) Tx processing output providing medium to high sample rate data to
an external source (REP sink)
(S2) Accepting medium to low rate PDUs/messages for Tx processing (REP
msg source)
(S3) Accepting low rate command and control messages (REP msg source)
(S4) After some Rx processing providing low rate sample data to an
external source (REP sink)

Of course other developers can have other design preferences than those
above.

In the above, I would actually never use REQ/REP for cases C1 and S1.
REQ/REP is too high overhead and provides a reliability guarantee way
beyond what is the norm for SDR.  (libuhd/USRP source will drop data on
the floor if your GNURadio instance can't keep up; REQ/REP will not.)

REQ/REP is not the right pattern to use for high rate data.  From the
ZeroMQ Guide:
"Request-reply, which connects a set of clients to a set of services.
This is a remote procedure call and task distribution pattern."


TL;DR:
REQ is for clients, REP is for servers.
ZeroMQ REP/REQ is orthogonal to GNURadio source/sink.
Some (REQ/REP, stream/msg, source/sink) block functional combinations
are missing from gr-zmq.
The current gr-zmq REQ/REP source/sink block combinations are not wrong
or incorrect, but they might not fit the usage pattern one may need or
envision in a particular context.
Don't use REQ/REP for medium to high sample rate sample streams.

Regards,
Andy


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

Re: [Discuss-gnuradio] FSK modulation/demodulation for Universal Access Transceiver

[Andy Walls]

On Thu, 2016-05-26 at 11:04 -0400, discuss-gnuradio-requ...@gnu.org
wrote:

> Date: Thu, 26 May 2016 11:03:55 -0400
> From: Olivier Goyette 

> Hi everyone,
> 
> I'm currently doing an internship at school and i'm working with USRP N210
> and GNUradio. It's been a month since I began working with these 2 tools,
> so excuse me if I may sound noob, but I really need some help. I've been
> asked to start thinking about developing an UAT for civil aviation. I've
> read a ton of standards and papers concerning this new technology, so I
> won't relate it all over here, but the main thing about it is that it uses
> FSK mod/demod for the information to be transmitted and received.
> 
> I'm currently stuck on a problem that's been haunting me for the last 2
> weeks and that's why i'm asking for your guidance. When I run the mod/demod
> on simulation(attached #1), everything works fine. I'm sending
> *abcdefghijklmopqr
> *and on the receiving side i got the same thing.

Isn't simulation great. ;)


>  Now the problem is that
> when i'm trying to send it via the USRP with a cable between RX and
> TX(attached #2), i only get gibberish on the receiving side !

The real-world always ruins things!

> What have I done wrong ? I don't get why it's not working.

Three things:

1. On Tx you only appear to be using 1 sample/symbol.  That doesn't let
you do any pulse shaping.

2. On Rx you appare to be using only 1 sample/symbol, which makes symbol
clock recovery nearly impossible.

3. On Rx you're not performing symbol clock recovery  (M clock
recovery block or PFB clock recovery block).

4. On RX you're performing neither coarse nor fine frequency
synchronization.

5. Your USRP is unhappy with your configuration of the USRP blocks:
"The hardware does not support the requested Tx sample rate:
Target sample rate: 0.01 Msps  (<- 1 sample per second?!)
Actual sample rate: 0.195312 Msps  (<- 195.312 ksps is the slowest the USRP can 
go apparently)"



> Thank you for your time, your help will be more than welcome

As Marcus said, yo can look at Nick Foster's gr-air-modes to see how he
handles Mode S/ADS-B (which is ASK/OOK).

You can also look at Nick's gr-ais, which is a GMSK receiver (GMSK is
GMSK with a modulation index of 0.5). 

This set of class notes talks about receiver timing synchronization:
http://www.cs.tut.fi/kurssit/TLT-5806/Synch.pdf

Also fred harris' article "Let's Assume the System is Synchronized" is
good reading about receiver synchronization (although not specifically
geared towards FSK):
https://www.researchgate.net/publication/278639495_Let%
27s_Assume_the_System_Is_Synchronized
http://eclass.uth.gr/eclass/modules/document/file.php/MHX302/Lecture12%
20-%20Wireless%20signal%20processing%20%28Synchronization%29.pdf

-Andy

> Olivier



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

Re: [Discuss-gnuradio] Syncronization issues, using a GPSDO

[Andy Walls]

On Tue, 2016-05-24 at 10:37 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Tue, 24 May 2016 17:37:35 +0300
> From: Meelis N?mm 

> Hello everyone,
> 
> 
> I have been working on a positioning implementation and for that I need
> very good time synchronization between the USRPs that are geographically
> not in the same location. Considered a few possibilities, but decided to
> test out the GPSDO modules for the time sync (also provides the needed 10
> MHz). In order to measure the time sync, I?m periodically feeding both
> USRPs with the same frequency sweep signal, storing the interesting
> sections and calculating the delay between them via correlation.
> 
> 
> Overall it seems to work, but I?m witnessing an interesting effect. As I
> start the program, within the first 4-5 minutes the time delay between the
> USRPs increases from (near) 0 to about 4-5 samples (400-500ns, with 10
> MSps). Once this phase is done, the delay between the USRPs stabilizes and
> the two seem to be quite well synchronized. I have attached delay plots
> from 2 different runs (this behavior I can reproduce every time).  If I
> restart the python program after the ?warmup? phase, the delay is very well
> restricted and clocks seem well synchronized (restart is denoted by the
> vertical line). It is also worth pointing out that the pause between the
> restarts is short (around 15 seconds), if I make the pause longer (more
> than 60 seconds or so) the results again exhibit a ?warmup? phase (figure
> "delays_result65_1"), but usually a bit less emphasized.

I've run into a similar effect with a host using NTP and the PPS and
$GPRMC sentence from X310 USRP.

I have a USRP-time vs. Host-time monitoring loop, and I see the USRP
time diverge from NTP time usually twice after startup: once immediately
after the streaming initialization (understandable), and then another
smaller jump some time later (I can't explain).

https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00326.html

> 
> Would like to know what causes this effect? It does not seem to come from
> the USRP clock sync python code (relevant code given below), as after the
> fast restart the effect is not present. Right now to me, it seems that in
> the GPSDO, or in the FPGA clock sync, a certain (lock) ?warmup? phase is
> done, once the FPGA starts to use the 10 MHz output. If the program is
> restarted fast enough, the clocks are still in sync, but if the pause is
> long enough the clock sync process(es) can be seen again?

>Any thoughts?

I was lucky enough to work up a fix with a USRP-time vs. Host-time
tracking loop, without knowing the root cause.

If you can find a solution for your problem without knowing the root
cause, you'll probably be OK.

> Meelis

-Andy


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

Re: [Discuss-gnuradio] UDP Source Error (on windows)

[Andy Walls]

On Thu, 2016-05-19 at 11:32 -0400, mle...@ripnet.com wrote:
> I'll comment that the Windows socket implementation isn't in
> compliance with the spirit of the robustness principle.  But, whatevs.
> Easy enough to just remove that option for the UDP case.
> 

I think it's a bit of a security failing of Linux to allow injection of
4 unused bytes into the kernel space from user-space for every locally
opened UDP socket.  I'm not sure how I could exploit it (perhaps coding
a jump instruction to a no-op sled somewhere nearby?),  but I'm not that
creative.

Meh.

-Andy


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

Re: [Discuss-gnuradio] UDP Source Error (on windows)

[Andy Walls]

> 
> OK, I was able to reproduce the issue, and it appears to me to a core
> GNURadio issue not specifically related to the installer
> 
> 
> udp_source_impl.cc is setting the SO_LINGER option on the UDP socket,
> which at least on Windows, causes a WSAENOPROTOOPT exception, because
> linger doesn't really mean anything for a UDP socket.  
> 
> 
> Perhaps the Linux folks can help here, but I'm guessing that this
> option must be simply ignored on Linux so there is no error for most
> users.  Looking at the man pages doesn't specify any particular
> behavior required.
> 
> 
> Geof


SO_LINGER gets processed by the Linux kernel generically here:

http://lxr.free-electrons.com/source/net/core/sock.c#L644

with no check against socket type.

The UDP socket handling doesn't use the resulting SOCK_LINGER flag
setting.
http://lxr.free-electrons.com/source/net/ipv4/udp.c
http://lxr.free-electrons.com/source/net/ipv6/udp.c

Only TCP and the Bluetooth SCO protocol in the Linux kernel care about
SO_LINGER.

Regards,
Andy


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

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

[Andy Walls]

On Wed, 2016-05-18 at 03:11 -0400, Anon Lister wrote:
> Andy, 
[snip]

> Since I'm replying in the pybombs thread, I did try it and it broke
> pretty badly. Missing deps and such, I'd be willing to try to help get
> with that after I get the build down by hand and know what I can use
> from yum and what I have to source build (which I expect is almost
> everything).

Building on SciLinux 6.x (and probably CentOS 6.x) with PyBOMBS is a
fool's errand.  Take it from a fool who tried.

PyBOMBS should *not* target RHEL/CentOS/SciLinux 6.x as the Python is
too old, and the old Qt4 version forces maximum versions for Qwt, SIP,
PyQwt, and maybe other libraries.  M4, autoconf and automake are too
old.  libcurses.so is also broken in a funny way, so libuhd examples
won't compile without fixing it.  A few items need patches to build.  It
goes on and on

A big nasty Bash script, a chroot-ed modern distro install, or a more
capable build system (like bitbake), is needed for GNURadio on those
distros.

 
> Did get el7 build without much issue, don't think I needed to source
> build GCC or anything, there were only a few packages that needed
> source build, boost I think was the only big one.

And since el7 *is* available to people, any hard work on el6 is
something I would not encourage.

Regards,
Andy



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

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

[Andy Walls]

On Tue, 2016-05-17 at 12:44 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Mon, 16 May 2016 22:51:45 +0200
> From: Marcus M?ller
> To: discuss-gnuradio@gnu.org
> 
> Hi Martin,
> 
> first of all: thanks for jumping through all these hoops to push
> PyBOMBS!
> 
> So, trying to make things (especially recipe fixes etc) easier to test
> for me, I've built myself a small set of script to log in to a set of
> VMs, install pip & git there, install pybombs in the vm, adding a test
> user, getting pyBOMBS and then install a package of my choice.
> That all's built atop of ansible and I hope the stuff one needs to do
> to
> test this on one's own VMs is documented well enough:
> 
> https://github.com/marcusmueller/ansible-pybombs-testing
> 
> I can only second the call for people to look at building thrift
> 0.9.3,
> especially on something that's not Ubuntu. As it is now, I really
> can't
> find a way to do so on CentOS7, and that's one of the platforms I'd
> really love to support.

Huh, that's one of the few things that built with no problems on
Scientific Linux 6.x, after I did this:

mkdir -p ${HOME}/target/share/aclocal
echo `/usr/bin/aclocal --print-ac-dir` >> ${HOME}/target/share/aclocal/dirlist
export 
LD_LIBRARY_PATH=${HOME}/target/lib64:${HOME}/target/lib:${LD_LIBRARY_PATH}
export LIBRARY_PATH=${HOME}/target/lib64:${HOME}/target/lib
export PATH=${HOME}/target/bin:/usr/lib64/qt4/bin:${PATH}
export PYTHONDOCS=${HOME}/target/share/doc/python-2.7.11
export 
PKG_CONFIG_PATH=${HOME}/target/lib64/pkgconfig:${HOME}/target/lib/pkgconfig:${HOME}/target/share/pkgconfig

and I installed the following from source or PIP:

binutils-2.26.tar.gz (source)
gcc-4.9.3.tar.gz (source)
   gmp-4.3.2.tar.bz2
   mpfr-2.4.2.tar.gz
   mpc-0.8.1.tar.gz
   isl-0.12.2.tar.bz2
   cloog-0.18.1.tar.gz
m4-1.4.17.tar.gz (source)
autoconf-2.69.tar.gz (source)
automake-1.15.tar.gz (source)
bison-3.0.4.tar.gz (source)
Python-2.7.11.tgz (source)
boost_1_53_0.tar.bz2 (source)
pip (using get-pip.py)
libevent-2.0.22-stable.tar.gz (source)
twisted (pip)

I can't recall the thrift deps that I installed with YUM, but they are
most certainly old and from the SciLinux or EPEL repos.

Then this thrift build process worked:

git clone https://github.com/apache/thrift.git
cd thrift
git checkout 0.9.3
./bootstrap.sh && ./configure --prefix=${HOME}/target \
  --with-c_glib --with-cpp --with-libevent --with-python \
  --without-csharp --without-d --without-erlang --without-go \
  --without-haskell --without-java --without-lua --without-nodejs \
  --without-perl --without-php --without-ruby --without-zlib \
  --without-qt4 --without-qt5 \
  --disable-tests --disable-tutorial \
  CC=gcc CXX=g++ PY_PREFIX=${HOME}/target CXXFLAGS="-DNDEBUG"
make -j 5
make install
cd ..

I recall a nagging dependency was the libevent 2.x stuff.  There's
headers for  or something like that, which thrift needs,
that is not in older versions of libevent.

FWIW, Thift lists its requirements here:
http://thrift.apache.org/docs/install/
http://thrift.apache.org/docs/install/centos

Regards,
Andy

> 
> Cheers,
> Marcus



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

Re: [Discuss-gnuradio] VOLK division between complexes

[Andy Walls]

On Thu, 2016-05-12 at 16:24 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Wed, 11 May 2016 16:09:56 -0300
> From: Federico Larroca
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] VOLK division between complexes

> Hello everyone,
> We are on the stage of optimizing our project (gr-isdbt). One of the
> most consuming blocks is OFDM synchronization, and in particular the
> equalization phase. This is simply the division between the input
> signal and the estimated channel gains (two modestly big arrays of
> ~5000 complexes for each OFDM symbol).
> Until now, this was performed by a for loop, so my plan was to change
> it for a volk function. However, there is no complex division in VOLK.
> So I've done a rather indirect operation using the property that a/b =
> a*conj(b)/|b|^2, resulting in six lines of code (a multiply conjugate,
> a magnitude squared, a deinterleave, a couple of float divisions and
> an interleave). Obviously the performance gain (measured with the
> Performance Monitor) is marginal (to be optimistic)...
> Does anyone has a better idea?

I have a different idea, but I doubt it is better.  The transformation

w = Log (z) = ln|z| + jArg(z)

transforms multiplication, division, power and root operations into
addition, subtraction, multiplication and division  operations
respectively.

So if c = Log(a), d = Log(b), then a/b = Exp(c-d) .

If along with your complex division, you also have a lot of additional
complex multiplcation, power, and/or (real) root operations to perform,
then the transform *might* give you a savings.  A savings would also be
more likely, if you don't need to invert the transformation at the end
(i.e. no need for z = Exp(w)). 

Regards,
Andy

>  Implementing a new kernel is simply out of my knowledge scope.
> Best
> Federico



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

Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk

[Andy Walls]

On Mon, 2016-04-18 at 00:44 +, Landsman, Arik wrote:
> So the generic_mod() shifts the expected output by 50 samples to the right, 
> thus dropping 50 samples off the end. with this in mind, generating *two* 
> modulated vectors should do the trick: 
> 
> - generate an untrimmed sequence 2 preambles long (seq1)
> - generate another sequence 3 preambles long (seq2)
> - samples_per_preamble = (preamble_length_bytes * [8*2/mod_order] * sps) 
> #[8*2/mod_order] is the symbols_per_byte  for a given mod_order
> - in seq2, start_of_preamble = len(seq1) + 
> - in seq2, end_of_preamble = len(seq1) + samples_per_preamble +  in generic_mod>
> - lost_samples = seq1 - 2 * samples_per_preamble   #remainder after 
> subtracting all preamble lengths from seq1
> 
> this works, at least manually, and should be generic enough to work for all 
> cases, e.g. mod orders, preamble lengths, etc and regardless of the inner 
> workings of generic_mod (which is good in case it gets changed). 

Hi Arik:

Glad you found a way to make things easier.  Be advised that other
modulators (e.g. GFSK_mod, GMSK_mod) probably have different properties,
so what you've come up with may only work for QAM and PSK modulations
using generic_mod. 

Regards,
Andy

> Just need to python it into the Rx in a neat way.


> 
> 
> 
> 
> 
> From: Landsman, Arik
> Sent: Sunday, April 17, 2016 7:44 PM
> To: Andy Walls
> Cc: discuss-gnuradio@gnu.org; t...@trondeau.com
> Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> Hi Andy,
> 
> Just a quick update - I changed sps from 10 to 5 to repeat your trimming 
> procedure. Works like a charm. Certainly clear why you picked the 2nd 
> preamble copy and not the 1st..
> 
> as expected correlation is not as strong with decreasing sps (assuming unmod 
> preamble stays same size).
> 
> Looks like it is possible to come up with an "auto-trimming" algorithm after 
> all. if the number of lost samples (distorted, nulled, etc) is a function of 
> sps, modulation order, and preamble length (and lost samples in 
> digital.generic_mod that I guess just don't get shifted out), then exact 
> placement can be calculated based on these parameters alone and some initial 
> experimentation.
> 
> i'll try experimenting, lets see if this holds :)
> 
> Best Regards,
> Arik
> 
> 
> 
> From: Landsman, Arik
> Sent: Sunday, April 10, 2016 4:25 PM
> To: Andy Walls
> Cc: discuss-gnuradio@gnu.org; t...@trondeau.com
> Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> Hi Andy,
> 
> Sorry for delayed response, the weekend finally arrived.. added some comments 
> inline below. Your comments on zero-IF receiving are well taken - going to 
> try a low-IF approach instead. This maybe the source of some phase noise 
> issues I had on the hardware last night. Using the USRP N210 btw.
> 
> Overall, the aim in this case, at least for now, is three-fold:
> 
> - design / fine tune a QPSK Rx capable of performance similar to a 
> diff-encoded Rx. Thus, at low SNR we could use non-diff and at higher SNR use 
> diff encoding. Or possibly just non-diff if the latter outperforms.
> - implement it as a testbed for encoding/networking algorithms for 
> heterogeneous networking (big topic for 5G). Not an expert in networking, but 
> we have RA's devoted to the topic. So ultimately the Tx-Rx network should 
> work reliably enough to allow performance testing their algorithms without 
> hardware bottlenecking the performance.
> - on the personal front I am here for the long howl, as the topic is of 
> personal interest. And contribute back into gnu-radio. Looks like this 
> flowgraph is going in the "psk mod" footsteps as a non diff-encoding 
> implementation. so if it appears feasible to create a python wrapper and a 
> block i'll certainly start there. the big hurdle is the hand-tuning the 
> corr_est block, which I'm going to contemplate a way to auto-cal it.
> 
> Best Regards,
> Arik
> 
> 
>  Andy Walls [a...@silverblocksystems.net]
> Sent: Tuesday, April 05, 2016 7:23 PM
> To: Landsman, Arik
> Cc: discuss-gnuradio@gnu.org; t...@trondeau.com
> Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> On Tue, 2016-04-05 at 00:00 +, Landsman, Arik wrote:
> > Hi Andy,
> >
> > Added a few comments inline (marked with "==" in lieu of a better email 
> > client)..
> >
> > But overall corr_est works very consistently. I did have a few observations:
> 
> Hi Arik:
> 
> For my responses to th