A common situation is a flow graph that was developed in one version of GRC, say GRC 3.6, will show flow graph error and not load on GRC 3.7, or a flow graph developed on the latest GRC version will not load on an earlier version of GRC 3.7. This situation can be expected from the GRC flow graphs presented as SDR Projects: SDR Projects and DSP Projects: DSP Projects The solution to this problem is often quite simple and will be described here.
The basis of the problem are changes in the algorithms of the DSP blocks. In the case of a change in the version library DSP block, the DSP block or blocks that will not load cause the red ‘flow graph error’ indicator to illuminate and the blocks are displayed in the work space with a skeletal appearance, different in appearance from the other blocks. All that is necessary to fix the problem is to replace that block, say a filter block, with an equivalent filter block from the library that you are using and enter the relevant filter parameters. One other loading problem, relates to changes in the parameters unique to the USRP Source block (receiver block). The USRP Sink block will appear normally in the work space, the red ‘flow graph error’ button will not be illuminated, but the flow graph will not load. One solution is to substitute the USRP Source block with the equivalent block from the library. Another approach is to edit the USRP Source parameters. Do follow this approach, open the ‘Properties’ window of the USRP Source, open the ‘FE Corrections’ tab.and change the parameters to those depicted below:
GNU Radio is in a state of constant development, read “change”. A massive change occurred at the time when GRC transitioned from version 3.6 to version 3.7. There are still DSP algorithm revisions in the GRC 3.7 era. Flow graphs developed under GRC 3.6 or early GRC 3.7 will not run under later versions of GRC 3.7.
]]>Frequency band

76.1 GHz  121.25 GHz 
LO frequency  12.6 GHz x 6

13.5 GHz x9 and
10.15 GHz x 12 
SHM BAT15  36 dBm  55 dBm 
SHM HSCH9201  25 dBm  33 dBm 
The HSCH9201 mmWave diode clearly outperforms the classic BAT15 diode in this test, increasingly so at the highest frequency. Of interest to me is that for 121 GHz operation, the LO multiplication, x9 vs. x12, resulted in identical output amplitude. This could be explained by the tradeoff between LO multiplication number and the doubling efficiency of SHM mixers. The output amplitude with the HSCH diode in the home made mixer assembly encourages me to ask how these measurements compare to more professionally constructed SHM’s at these frequencies. Maybe this mixer configuration will be useful as a bare mixer transverter.
Integrated mmWave mixer assembly and circular waveguide transition
]]>It is possible to directly and separately tune the RFIC synthesizer and the FPGA NCO for both receiving and transmitting. This capability for offset tuning is useful for some applications: removing baseband artifacts, split frequency, and dual transceiver operation: Dual Transceiver Application This technique provides simplified direct control of the frequency offset and avoids the need for ‘indirect’ control via DSP flow graph adjustment. All of the tuning occurs directly at the RF synthesizer and FPGA level with Python commands in the Source and Sink Center Freq parameter fields..
To get started, it is useful review modern SDR architecture: Modern SDR Architecture and focus on the special purpose RFIC and the FPGA. The RFIC contains an independent RF frequency synthesizer. The FPGA contains it’s own synthesizer termed a ‘Numerically Controlled Oscillator’ (NCO). Each synthesizer can be tuned directly and separately with the proper frequency commands. The RFIC synthesizer outputs at RF. The NCO only outputs baseband frequencies which limits potential offsets to less than 1/2 the SDR clock frequency.
Below are a series of USRP Sink Properties boxes that illustrate the Python command syntax and supplementary tuning control functionality for a SDR transmitter.
Note: The location of the ‘tune’ command in the Sink Center Freq parameter field determines whether the ‘tune’ command in the Sink Center Freq parameter field determines the RFIC synthesizer frequency. The FPGA NCO cannot be tuned with a variable parameter.
Link to Terms and Abbreviations: Terms and Abbreviations
Link to Home Page: Home Page
]]>
“I” and “Q” processing is a prominent concept in discussions of Digital Signal Processing (DSP). Why? “I” and “Q”, as such don’t exist in nature. “I” and “Q” are mathematical creations for DSP. I’ll explain why and offer you a chance to create “I” and “Q” using GNU Radio in a modeling mode.
Digital Signal Processing, the heart of SDR, is entirely mathematically determined. A key mathematical function of DSP is Euhler’s Complex Exponential. The mathematics of Euhler’s Complex Exponential make it possible to analyze and understand “sinusoids”, that is all signals with all modulations. Terms and Abbreviations Conversely, these mathematics can be used to mathematically filter, mix, amplify, or what have you, any sinusoid. In other words, Euhlers Complex Exponential is used to perform any and all signal processing functions for DSP. An essential construct for this math function is that it process two signals, reliably 90 degrees out of phase relative to one another.
The stable 90 degree phase relationship of the two signals allows the analysis of signals and modulations. Hence the “I” and “Q”. In the end, “I” samples and “Q” samples designate two digital streams: one signal sampled “in phase” and the other signal sampled in “quadrature phase” or 90 degrees out of phase relative to “I”. The two sampled signals are at the same frequency, but not sampled with the same phase. Hence “I” and “Q”. No “I”, no “Q”, no DSP. For state of the art SDR, “I” and “Q” signals are synthesized immediately following signal digitization and become the digital input for DSP.
How to synthesize I and Q?
Synthesizing digital “I” and “Q” data for DSP is typically accomplished using a pair of Multipliers configured as a Quadrature Multiplier. One Multiplier multiplies the sample stream by the “I” component of the down conversion oscillator. The other Multiplier multiplies the “Q” component of the down conversion oscillator. This process is simpler than you might imagine. The following GNU Radio flow graph illustrates this process: Quadrature Multiplier demo
NOTE: The “I” and “Q” concepts are shared in the analog and digital realms. The somewhat confusing relm specific descriptive terminology deserves some comment. The preceding “I” and “Q” discussion uses terminology specific to the digital realm, the processing of digital data streams from sampled signals, in other words DSP. In the case of analog “I” and “Q” based signal processing, the terminology differs but the concept is the same. The analog system input is a “signal”, not a “data stream”. Analog “I” and “Q” signals are created in a Quadrature Mixer. The digital system input is a “data stream” not a “signal”. Digital “I” and “Q” data are created in a Quadrature Multiplier. A further example of the complexity of language verses the realities of implementation is first generation SDR. These early SDR implementations, e.g. SDR1000, Softrock, were implemented using Quadrature Mixers to produce analog “I” and “Q” signal outputs prior to digitization and subsequent digital signal processing. Second generation SDR, so called “advanced SDR”, employ Quadrature Multipliers to digitally generated “I” and “Q” data streams following digitization.
Link to Terms and Abbreviations: Terms and Abbreviations
Link to Home Page: Home Page
]]>
Implementation of the built in ‘click tune’ function is simple. That said, a downside of this simple, basic functionality, is every selection from the FFT simply adds or subtract baseband frequency tuning data for the tuning buffer. In order to select a specific second signal and center it in the passband, it is necessary to return the buffer data to “0”. In practice, after a initial signal has been selected, it is necessary to select “0” on the FFT display to reinitialize the frequency shift buffer, in order to select and center a second signal.
If a Tune WX GUI Slider widget has been included in the flow graph, a simple command in the GUI FFT Sink Properties box implements click tune. The two Properties boxes below illustrate the complete process. To get full functionality of ‘click tune’ make the frequency range of the Tune widget equals or exceeds the FFT display range.
NOTE; The ‘click tune’ function does not appear to work with the GUI Waterfall Sink with my version of GNU Radio. And, I am uncertain whether ‘click tune’ can be implemented with the QT GUI widgets.
Link to Terms and Abbreviations Page: Terms and Abbreviations
Home Page link: Home Page
]]>Examples are easy to imagine. Here are a few examples from my station. The 2 meter weak signal calling frequency in our area is 144.2 MHz. Sometimes we meet on the calling frequency and agree to QSY to another frequency for rag chews, say 144.240 MHz. It is easy to enter the 144.240 MHz rag chew frequency into the Preset Frequency Variable field and QSY simply by selecting the Preset Frequency from the Operating GUI. As a result there is no ‘tuning’ up to 144.240 MHz. It is easy to toggle back and forth from the Preset Frequency to the calling frequency and check for friends who might not be aware of the rag chew QSY. And, for rover operation, an aid to confirm that the rig is working while listening on an otherwise quiet band, is to set the frequency of a local beacon signal as a Preset Frequency. How do you set up a Preset Frequency?
To implement the Preset Frequency capability add 2 DSP blocks into your flow graph: a Variable block in which the desired preset frequency is entered, and a Static Text block which will display the preset frequency in the Operating GUI. The choice ‘Preset Frequency’ links the Static Text block to the GUI Chooser frequency selection block. The strategy is to identify a Variable block with a preset frequency in the Value field and a block ID of ‘pre_set_freq’, link that Variable block to the Static Text block with the ‘pre_set_freq’ ID, and link the Static Text block to the GUI Chooser block with the ‘PRESET FREQUENCY’ label. Let me illustrate with a flow graph the Preset Frequency function for an HF SDR DSP.
Let’s look at the Parameters for each flow graph block to implement a Preset Frequency of 3.818 MHz
Link to Terms and Abbreviations Page: Terms and Abbreviations
Home Page link: Home Page
]]>
The zero frequency artifact is removed with identical differential offsets to the RF frequency of the Source and the baseband frequency of the Frequency Xlating FFT Filter. In this manner the zero frequency is offset by an arbitrary amount and yet the received signal remains in the center of the receive passband. The following series of FFT GUI’s and Properties boxes will illustrate the solution.
Note the ‘Center Frequency’ text boxes with the notation ‘0’ included in each of the Parameter boxes. Both the Source and the FFT Filter are not offset. The artifact appears in the passband output.
FFT GUI that illustrates the 10 kHz offset achieved by equal and opposite frequency inputs to the RF and baseband SDR front end
Note the ‘Center Frequency’ text boxes with the notation ’10e3′ included in each of the Parameter boxes. These Center Frequency parameters determine the 10 kHz offset. In this case, the Source is offset 10 kHz, and the FFT Filter is offset +10 kHz. These frequency values and the sign of the offset can be varied to suit the application.
Link to Terms and Abbreviations Page: Terms and Abbreviations
Home Page link: Home Page
]]>