Hi Marcus --
First, thanks for catching the typo in the channel map. There was no
plan to skip any channels; the goal is to get each channel in frequency
order (out0 = 540 kHz; out116 = 1700 kHz).
I did an experiment using a signal generator feeding the Red Pitaya
receiver and testing various channels. I started at the center channel,
1120 kHz, and found there was zero offset from nominal. I then went 1,
2, and 3 channels both lower and higher and came up with this map:
1090 +2.05 kHz
1100 +1.37 kHz
1110 +0.68 kHz
1120 0.00 kHz
1130 -0.68 kHz
1140 -1.37 kHz
1150 -2.05 kHz
Now, the sample rate coming out of the channelizer (hardware sample rate
of 1.25 msps divided by 117) is ~10.683 ksps. Gee, that 683 is pretty
close to the per-channel offset.
I didn't test further, but I strongly suspect this offset of ~680
Hz/channel continues in both directions, so that the signal has moved
far from the expected point as you get further away.
So, I think this tells me that the sample rate going into the PFB,
divided by the number of channels, needs to match the channel spacing.
That means a rational resampler going into the PFB to change 1.25 msps
to 1.17 msps.
I don't think I've ever read anything before that the sample_in rate has
to equal (channel_num x channel_spacing). It makes perfect sense when
you think about it, though. Your reference to the "channel raster" was
enough to make the light bulb turn on for me, and thanks very much for that!
Now to test with the resampler... Thanks much for helping me work
through this!
John
----
On 11/29/2017 01:20 PM, Müller, Marcus (CEL) wrote:
Hi John,
given the fact that the frequency shifting of the individual sub-
filters is actually done via a DFT implemented by an FFT, and that
should have negligible phase accumulation error for benign FFT length
(i.e. channel numbers, let's say <1e6), hm.
First gut feeling, and easiest to check:
The output channels seem to have an offset in the range > of 400 to
700 Hz versus the unchannelized input.
Make double sure that (sampling rate going into the channelizer) / 117
is actually exactly the raster you want.
If I interpret your file correctly, there's 1.25 MHz going into the
channelizer, so channel raster is 1250 / 117 kHz = 10.684 kHz. Hope
that's right!
What I could imagine are artifacts due to the non-perfect filter phase
linearity; but that would actually be a pretty intense speculation;
unless we're leaving the areas where our floating point numbers are
accurate enough, there shouldn't be non-linear (i.e. frequency-
shifting) behaviour.
I just threw together this:
from gnuradio.filter import firdes
file_sample_rate = 2.5e6
decimation = 2
pfb_taps = firdes.low_pass(2.0, file_sample_rate/decimation,10000,5000,
firdes.WIN_HAMMING, 6.76)
(pretty much lifted straight from your GRC)
Inspecting pfb_taps yielded a length of 603 taps, which we'll "evenly
as possible" have to distribute across the channels (117 of which
exist, as your channelizer map has length 116, but is missing the 56).
You could build a simple "unit test": Use a Vector source that pushes
[1 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 4 … 0 0 0 0 0 0 0 117
0 0 0 0 0 0 0 ]
through a length=117*8 IFFT, and push the result (after a vector-to-
stream) through your channelizer. You should see single tones in all
your channels. (The different amplitudes might help telling them
apart). Do they end up in the center of your bins?
Best regards,
Marcus
On Wed, 2017-11-29 at 10:34 -0500, John Ackermann N8UR wrote:
I'm building a ridiculous flowgraph that breaks the AM broadcast band
(540 - 1700 kHz in the U.S.) into 117 10 kHz wide channels and measures
the energy in each. The thing is working but I see a frequency offset
in the output channels that is not present in the data before
channelizing. The output channels seem to have an offset in the range
of 400 to 700 Hz versus the unchannelized input.
The signal chain is:
2.5 msps recording centered at 1.4e6 Hz -> xlating filter, decimation 2,
output centered at 1.12e6 -> PFB channelizer with 117 channels, yielding
a channel rate of 10,683.760683...... samples per second.
Looking at the spectrum at the output of the xlating filter, the carrier
frequencies are correct. Looking at the output of a channel, the
carriers are offset by several hundred Hertz, always high. (Given the
absolute frequency is in the 1 MHz range, these offsets are parts in
1e3, a pretty large amount.)
I wonder if the large number of PFB channels is causing a rounding error
that results in these frequency offsets. Or is there something else
going on?
I can probably fudge the xlating filter frequency a bit to move the
carriers closer to nominal, but would like to understand what's happening.
I'm attaching the (absurdly huge) .grc file. The canvas is 4192 pixels
tall, so the flowgraph is smaller than the screenshot. :-)
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio