2

I just started using GNU Radio, I must say I am quite a noob but I have some background on RF related stuff. Here's the thing: I recorded a file that I now want to repeat through my HackRF and GNU Radio.

GNU Radio WorkFlow

This is the exact settings for the filter: Filter settings

The settings you see are casual (since I cannot get it working I started testing with random values). This is the error I get:

Executing: /usr/bin/python3 -u /home/scare/LAB/RadioFrequencies/GNU Radio/reply_433.py

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.8.2.0
built-in sink types: uhd hackrf bladerf soapy redpitaya file 
[INFO] [UHD] linux; GNU C++ version 11.1.0; Boost_107600; UHD_4.0.0.0-0-unknown
Using HackRF One with firmware 2017.02.1
Traceback (most recent call last):
  File "/home/scare/LAB/RadioFrequencies/GNU Radio/reply_433.py", line 211, in <module>
    main()
  File "/home/scare/LAB/RadioFrequencies/GNU Radio/reply_433.py", line 187, in main
    tb = top_block_cls()
  File "/home/scare/LAB/RadioFrequencies/GNU Radio/reply_433.py", line 137, in __init__
    firdes.high_pass(
  File "/usr/lib/python3.9/site-packages/gnuradio/filter/filter_swig.py", line 124, in high_pass
    return _filter_swig.firdes_high_pass(*args, **kwargs)
RuntimeError: firdes check failed: 0 < fa <= sampling_freq / 2

Done (return code 1)

Where obviously the interesting part is the RuntimeError: firdes check failed: 0 < fa <= sampling_freq / 2

Unfortunately, I don't get what that 'fa' stands for.

Any idea?

Cheers

scarecrow
  • 31
  • 2
  • 5

2 Answers2

2

I just got done solving this same error. The error is caused by a filter's Cut-off and transition parameters being set incorrectly (in my case far too large). GNU radio handles the variable 'samp_rate' differently for each block and filters seem to interpret it was a point to center the filter on (that's my take on it so don't quote me).

I also looked in the source code and can't find anything helpful on 'fa'

So try adjusting your cutoff to be something below samp_rate and make your transition width something to the tune of 250e3. I used GUI sliders to set the filter how I liked and I will make these permanent in the final version.

Screen Cap of Settings Here Slider Settings For Both Sliders

Mike Ossmann's "SDR with HackRF One, Lesson 10 - Filters helped" me out here. Also just a great SDR lecture series for GNU radio if you haven't come across them yet. (just make sure to use the QT GUI).

I hope this helped. I am pretty new to GNU so sorry if the explanation is a little half-baked.

Andrew J
  • 21
  • 1
  • 1
    yep, correct in its core! remember this is discrete-time signals, so you can only represent things in [-f_s/2 ; +f_s/2] at all. Sampling something at 2 MHz and then trying to filter things out at a frequency higher than 1 MHz makes no sense. – Marcus Müller Sep 30 '22 at 17:57
2

fa is the cutoff_frequency in the function that is throwing the error message. The cutoff frequency has to be greater than 0 and no more than the Nyquist limit. There are some functions called sanity_check_xxx (xxx being whether one cutoff or 2, i.e. bandpass, and optionally c for complex) around line 750 in gr_filter/lib/firdes.cc in the GNU Radio repository on GitHub.

In the question the samp_rate would need to be at least 800MHz to support a high pass cutoff of 400Mhz. As far as I can tell sample rate is used the same way in these filter functions as anywhere else in GNU Radio.

I ran into the same error message because I used 'firdes.band_passinstead offirdes.complex_band_pass` and the low cutoff was negative, which it should be for the complex band pass filter.

Deepstop
  • 3,627
  • 2
  • 8
  • 21
  • Yep, "would need to be at least 800 MHz", but (as I think you were implying :-) ) most SDRs don't handle sample rates this high. However, they don't need to -- with the osmocom's frequency set to 433 MHz, the frequencies that you're transmitting will be at most 1 MHz (half the 2M sample rate) away from that center freq. The images in the [Negative Frequencies section on Py SDR](https://pysdr.org/content/frequency_domain.html#negative-frequencies) show this idea of shifting the frequency. – pianoJames Oct 07 '22 at 20:42
  • 1
    All I was saying was I see the high pass filter block's cutoff frequency as 400M, but the sample rate is 2M. With a sample rate of 2M the cutoff frequency cannot be more than 1M. The Osmocom block doesn't factor into the error message. I agree that as the Osmocom has a local oscillator that it doesn't need a sample rate that high. – Deepstop Oct 08 '22 at 21:45