Normal view

There are new articles available, click to refresh the page.
Before yesterdayAMATEUR RADIO – HOMEBREW SDR

What To Do If Flow Graphs Do Not Load

By: w7fuw7fu
6 February 2020 at 15:55

Revised: February 5, 2020

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:

USRP Source Parameter FE Corrections

 

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.

Home made mmWave mixer experiments

By: w7fuw7fu
11 February 2019 at 18:00

The early January 2019 discussion on the WA1MBA Microwave Reflector of diode package capacitance and the impact on mmWave mixer performance prompted me to compare diodes for 76 and 121 GHz mixers.   I built two identical home made transmit mixers and compared the conversion efficiency of the BAT-15 diode, with a package capacitance of 0.23 pf, with the HSCH-9201 diode, with a package capacitance of 0.040 pf.  The measurements are ‘ham measurements’ taken with a Tek 494 SA and a homemade harmonic mixer. The LO drive is derived from a homemade synthesizer and a CMA tripler.  The IF frequency is 432.2 MHz.  LO and IF drive were optimized for each measurement.  All measurements are relative rather than absolute.  Below is a table of my results.

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 BAT-15 -36 dBm -55 dBm
SHM HSCH-9201 -25 dBm -33 dBm
     

 

The HSCH-9201 mmWave diode clearly outperforms the classic BAT-15 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

Direct RFIC Synthesizer and FPGA NCO Offset Tuning

By: w7fuw7fu
1 July 2018 at 19:00

SDR Offset tuning can be implemented with differential shifts of the RF and baseband frequency parameters.  One method to achieve receiver only offset tuning is what I call ‘indirect’ offset control.  This approach implements an offset with a baseband DSP tuning option feature of a Frequency Xlating FFT Filter in a receiver DSP flow graph: Zero Frequency Receiver Artifact  This approach to offset tuning is useful but limited to receiver only applications with a Frequency Xlating FFT filter in the flow graph.

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.

Basic Python tuning commands for offset tuning.  The intended RF output frequency is 144.200 MHz.  The RFIC synthesizer is commanded to output at 144,210 MHz (up 10 kHz).  The FPGA NCO is commanded to output -10 kHz (down 10 kHz)
Output spectrum of the offset configuration. The LO leakage is seen at -10 kHz and the intended frequency is centered at “0” on the FFT display
Offset Tuning with optional RFIC synthesizer frequency tuning.  The command ‘tune’ is the ID of an onscreen tuning widget block that provides tuning values for the RFIC synthesizer.

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

 

“Why” and “How” of I and Q

By: w7fuw7fu
29 June 2018 at 23:28

Why “I” and “Q”?

“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. SDR-1000, 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

 

 

‘Click Tune’ Frequency Changes with the FFT GUI

By: w7fuw7fu
27 June 2018 at 16:31

A useful SDR operating aid with a GNU Radio DSP is the ‘click tune’ function.  ‘Click Tune’ means that the user can left click the FFT GUI to center the desired signal in the passband.  In other words, when monitoring a band of frequencies, the desired signal can be selected simply by left clicking on that signal in the FFT display.

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 re-initialize 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.

WX GUI Slider Properties with the ID field parameter ‘tune’.  This slider adjusts the frequency from the Operating GUI.
GUI FFT Sink Properties with ‘tune’ entered in the Freq Set Varname field.  This command makes it possible to select frequencies by left clicking on the FFT Sink GUI.

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

DSP Frequency Memory with Preset Frequency Variables

By: w7fuw7fu
26 June 2018 at 01:05

A very useful feature of an operating GUI is the ability to program Preset Frequencies without editing the basic frequency selection menu of the overall DSP.  Preset Frequency capability is one approach to implement frequency memory into a GNU Radio DSP.  Frequency changes with the GNU Radio sliders and knob style tuning widgets can be tedious and not always 100% satisfying.  I include the Preset Frequency memory into all of my DSP’s, whether HF or microwave.  Any frequency can be quickly programmed into memory, to allow frequency changes easy and less fraught.

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.

Preset Frequency Flow Graph blocks

 

Let’s look at the Parameters for each flow graph block to implement a Preset Frequency of 3.818 MHz

Variable block Properties with the desired 3.818 MHz is entered in the Value field
Static Text block Properties with ‘pre_set_freq’ entered in the Default Value field and ‘PRESET FREQUENCY’ entered into the Label field
GUI Chooser block Properties with the 3.818 MHz ‘PRESET FREQUENCY’ as entry 14 in the Choice field and ‘PRESET FREQUENCY’ entered in the Labels field.

Link to Terms and Abbreviations Page: Terms and Abbreviations

Home Page link: Home Page

 

 

 

Zero frequency receiver artifact

By: w7fuw7fu
25 June 2018 at 19:25

A typical situation with SDR receivers is the presence of the zero frequency or ‘DC’ artifact in the receiver output.  The artifact shows up as a zero frequency spike in the FFT, a zero frequency line on the waterfall, or an audible heterodyne on the received carrier.  This artifact can be removed from the receive passband by implementing frequency offsets into the receiver front end.    A typical SDR receiver flow graph consists of a Source followed by a Freq Xlating FFT Filter.  Large frequency changes are usually made by center frequency parameters in the Source Properties box and small ‘tuning’ changes by center frequency parameters in the Frequency Xlating FFT Filter Properties box.

Typical SDR Receiver front end

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.

Zero offset FFT GUI showing artifact
Source Properties for zero offset
FFT Filter Properties zero offset

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

Source Properties for 10 kHz offset
FFT Filter Properties 10 kHz offset

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

 

 

❌
❌