> You can do that (obviously, it works!), but I'd recommend you just use
> a channelizer with N=125 instead of 117! Your channel map can be used
> to ignore the channels you don't need (which seem to be the 4 upper and
> lower "edge" ones), and by only increasing the workload of the PFB ever
> so slightly (probably even actually decreasing it, because an 125=5³-
> FFT is likely to be much more efficient than an 117=3²·13-FFT), you get
> rid of the rational resampler, which not only brings more CPU load, but
> also a resampling filter response that might have ripple and aliases.
Highmesh Product Page
Highmesh contains other products and information you need, so please check it out.
Thanks for that suggestion, Marcus! I have the resampler version
running right now but will change to use the channel count idea instead.
John
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 = kHz).
I did an experiment using a signal generator feeding the Red Pitaya
receiver and testing various channels. I started at the center channel,
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:
+2.05 kHz
+1.37 kHz
+0.68 kHz
0.00 kHz
-0.68 kHz
-1.37 kHz
-2.05 kHz
For more information, please visit HM USRP E Series.
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/ 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 / 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,,,
> 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, -11-29 at 10:34 -, John Ackermann N8UR wrote:
>> I'm building a ridiculous flowgraph that breaks the AM broadcast band
>> (540 - 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....... 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 pixels
>> tall, so the flowgraph is smaller than the screenshot. :-)
>> _______________________________________________
>> Discuss-gnuradio mailing list
>>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Want more information on Universal Software Radio Peripheral USRP? Feel free to contact us.
_______________________________________________
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Make sure that your kit contains all the items listed above. If any items are missing, please contact your sales agent or Ettus Research Technical support immediately.
All Ettus Research products are individually tested before shipment. The USRP™ is guaranteed to be functional at the time it is received by the customer. Improper use or handling of the USRP™ can easily cause the device to become non-functional. Listed below are some examples of actions which can prevent damage to the unit:
In order to use your Universal Software Radio Peripheral (USRP™), you must have the software tools correctly installed and configured on your host computer. A step-by-step guide for doing this is available at the Building and Installing the USRP Open-Source Toolchain (UHD and GNU Radio) on Linux, OS X and Windows Application Notes. Release 3.8.4 or later of the USRP Hardware Driver, UHD, is required. It is recommended to use the latest stable version of UHD that is available.
If you have a USB stick with the Live SDR Environment installed on it, then you may boot your host computer from that. The LiveUSB SDR Environment does not require anything to be installed on your host computer, and contains a Linux-based environment with the UHD software and the GNU Radio framework already installed. More information about the Live SDR Environment is available at the Live SDR Environment Getting Started Guides page.
The included USB 3.0 cable provides power and data connectivity for the USRP Bus Series. The host-side of the cable must be plugged into either a USB 2.0 or 3.0 port. Note that the USB 2.0 link provides less bandwidth than the USB 3.0 link. Also note that an external DC power supply must be connected if using a GPSDO (B200/B210 only).
Once the software tools are installed on the host computer, or using the Live SDR Environment, verify the correct operation of the USRP by running the utility programs on the host computer. More information is available at the Verifying the Operation of the USRP Using UHD and GNU Radio Application Note.
Technical support for USRP hardware is available through only. If the product arrived in a nonfunctional state or you require technical assistance, please contact . Please allow 24 to 48 hours for response by , depending on holidays and weekends, although we are often able to reply more quickly than that.
We also recommend that you subscribe to the community mailing lists. The mailing lists have a responsive and knowledgeable community of hundreds of developers and technical users who are located around the world. When you join the community, you will be connected to this group of people who can help you learn about SDR and respond to your technical and specific questions. Often your question can be answered quickly on the mailing lists. Each mailing list also provides an archive of all past conversations and discussions going back many years. Your question or problem may have already been addressed before, and a relevant or helpful solution may already exist in the archive.
Discussions involving the USRP hardware and the UHD software itself are best addressed through the usrp-users mailing list at http://usrp-users.ettus.com.
Discussions involving the use of GNU Radio with USRP hardware and UHD software are best addressed through the discuss-gnuradio mailing list at https://lists.gnu.org/mailman/listinfo/discussgnuradio.
Discussions involving the use of OpenBTS® with USRP hardware and UHD software are best addressed through the openbts-discuss mailing list at https://lists.sourceforge.net/lists/listinfo/openbtsdiscuss.
The support page on our website is located at https://www.ettus.com/support. The Knowledge Base is located at https://kb.ettus.com.
Every country has laws governing the transmission and reception of radio signals. Users are solely responsible for insuring they use their USRP system in compliance with all applicable laws and regulations. Before attempting to transmit and/or receive on any frequency, we recommend that you determine what licenses may be required and what restrictions may apply.
If you have any non-technical questions related to your order, then please contact us by at , or by at +1408610 (Monday-Friday, 8 AM - 5 PM, Pacific Time). Please be sure to include your order number and the serial number of your USRP.
If you want to learn more, please visit our website SDR for IoT Applications.