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
>> 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
No comments:
Post a Comment