And the resampler did the trick. Carriers are now nicely aligned. Thanks again!
On Nov 29, 2017, 4:48 PM, at 4:48 PM, John Ackermann N8UR <j...@febo.com> wrote: >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 >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >_______________________________________________ >Discuss-gnuradio mailing list >Discuss-gnuradio@gnu.org >https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
