Tuesday, March 10, 2015

Update on the mcHF - Adding more features (Part 2) - Implementing audio filters and fractional I/Q phase adjustments

The front panel display of the mcHF SDR transceiver, an entirely
self-contained all-mode HF transceiver based on open-source software.
This is shown not in its 3D-printed case - which is open-source, too...
(No, you don't need a computer for this transceiver to work!)
Last time (See the January 27, 2015 entry - LINK) the addition of AGC and a gain control to maximize receiver dynamic range was discussed.

This time:  A discussion on the addition of adding audio filtering, decimation/interpolation and fractional I/Q phase adjustments for both receive and transmit.


Doing audio processing with limited resources:

Being that the mcHF is entirely self-contained and has a reasonably powerful, yet modest processor (the STM32F405 or '407 processor running at 168 MHz - a device with an ARM Cortex M4 core that includes hardware floating-point support) there are practical restrictions on how much number-crunching one can get away with when performing various tasks.  As you might expect, the most time-critical task is the "real time" processing of the receive data from the dual A/D converters as I/Q channels into demodulated audio.

If one goes through the literature on typical SDRs in the amateur world it quickly becomes apparent that limited processing power is often not a prime consideration.  This is not too surprising considering the fact that multi-GHz, multimedia processors in desktop computers are ubiquitous, so processing power is considered to be "cheap" and very often a lot of processing is thrown at a problem simply because it is available!

For example, one might implement an FIR (Finite Impulse Response) audio filter with 512 or even as many as 2048 taps without batting an eye on a PC and still have resources to burn, but try that on the processor in the mcHF and you'll have suddenly used up the vast majority of processor power (if not all of it - and more!) on that one task!

So, one starts to ask various questions like:
  • How can I do something while using less processor horsepower?
  • How "good" is "good enough"?
  • If I cut a corner somewhere, how detrimental will it really be in practical, real-world situations?

Receive signal processing:

The mcHF uses a standard, inexpensive "sound card" type codec (a Wolfson WM8731 or the compatible TLV320AIC23) for all A/D and D/A.  This is a 16 bit device capable of a number of sample rates from 8 to 96 ksps (KiloSamples Per Second), but in the mcHF it is typically operated at 48 ksps, this to allow the visualization of the spectrum +/- 24 kHz from the center as can be seen in the picture at the top of the page.

Being a typical SDR one of the first steps in signal processing is the same as that of any typical "phasing" rig - analog or digital - and that is to impart a differential 90 degree phase shift on the audio channels, a task that is, in this case, accomplished with a "Hilbert" transform.

Now, at the beginning the mcHF's audio path was "baseband" based, which is a confusing way to say that all demodulation was done around "zero Hz" or "near DC":  A demodulated CW tone tuned to yield 700 Hz was, in fact, 700 Hz away from the local oscillator frequency.  This is not an ideal situation for a number of reasons (which will be covered in a later installment!) but it was, from the beginning, the easiest thing to do.

Because the demodulation was done "near DC" this meant that the Hilbert transformer had to be of the "0 degree/90 degree" types rather than the more typical "-45 and +45" degree type:  While the former can be made to behave fairly well at low audio frequencies with a reasonable number of FIR taps, the latter cannot!  An 81-tap FIR-based Hibert transformer is used to provide the audio phase shift, providing reasonable performance down to a couple hundred Hz - as low as we need to go for SSB!

Once the two audio channels are set 0/90 degrees from each other one can then do the math to convert the two channels into USB and LSB - which is just addition or subtraction of these channels:  Which does which depends on which phase happens to have been assigned where in the hardware.  This demodulation converts the separate I/Q channels into just ONE audio channel, but it is not yet bandpass-filtered!

Working with limited resources:

IIR instead of FIR audio filtering:


Originally the code used a combination of FIR low-pass and bandpass filters with 48 taps to provide the receive audio filtering but because the receiver sample rate was 48 ksps this meant that with so few taps that it was not practical to define a very "sharp" audio filter.  To get a "properly sharp" FIR audio filter at 48 ksps would require, perhaps, 3-4 times as many taps as that and commensurately larger audio buffers and an increased amount of processor overhead, so I decided to take a different approach.

Most of my embedded programming has been using fairly low-end PIC microcontrollers (the PIC16 and PIC18 families) and I have used both FIR and IIR filters on these devices of rather low complexity since the resource of these processors are extremely limited.  Having cut my teeth on these types of filters I was comfortable enough with IIR filters that I was not scared of their (somewhat undeserved!) reputation of being "inherently unstable" and I also knew from experience that IIR filters could, when properly finessed, offer superior performance to FIR filters in situations where one needed to severely limit the amount of processor overhead, particularly when one has floating point math available.

Having access to MatLab and its filter design/simulation tools I soon had working some fairly low-complexity IIR filters thanks to the built-in support of the CMSIS DSP library (link) that offered performance that was far superior to the original FIR filters with reasonable "Shape Factors" (e.g. the ratio between the passband and attenuation response).

Decimation to reduce processor loading:

So it remained like this for several versions of code:  All of the audio processing was being done at 48 ksps but I had not yet taken advantage of another trick available to reduce processor overhead:  Decimation.

At this point I was still crunching numbers at 48 ksps - this, to produce audio that had no components higher than 4 kHz or so!  Nyquist tells us that to process such signals we need not sample at any higher than 8 kHz, so running at many times that sample rate was simply wasting CPU power!

The term "decimation" in DSP terms simply means keeping 1 out of N samples and throwing the rest away, and if you have fewer samples, there are fewer numbers to crunch.  For practical reasons - sometimes those dictated by available library functions and/or the sizes of buffers - it is usually best to pick "N" as a power-of-two (e.g. 2, 4, 8, 16, etc.) For the second of these reasons (e.g. the audio "chunk" size was 64 samples - a number that was NOT evenly divisible by 6!) my best choice was to decimate-by-four to reduce my sample rate from 48 ksps to 12 ksps.

If you throw away samples you must still do something about the audio spectral content that would be above the Nyquist limit at the new sample frequency, so one must first low-pass filter and remove those signals and that meant that I had to get rid of those signals that would be at 6 kHz and above!

Comments:
  • In theory, a decimation-by-8 to yield a sample rate of 6 ksps would have worked since, for normal SSB, my maximum audio frequency could be less than 3 kHz.  The problem is that this would have placed my Nyquist limit very near my desired maximum frequency of 2700 Hz or so - and in the audible range - requiring pretty tight filtering.  The added complexity of such filtering may have countered any gains afforded by the reduction in sample rate, plus it would have precluded the use of "wide" audio filters (such as the 3.6 kHz filter) for SSB and AM unless I were to have added yet another decimation rate!  (For CW or Digital-mode filters this would probably be fine...)

The CMSIS library for the ARM M4 processor contains a handy decimation function with a built-in FIR low-pass filter, but number-crunching (with the aid of MatLab) showed that I'd need quite a few FIR taps - and additional processor overhead - to get the needed 60dB or so low-pass filtering that was required!

Fortunately, I already had a low-pass filter at hand:  The Hilbert transformer!

Using the free "Iowa Hills" filter design tools I designed a new Hilbert Transformer that was identical to what was already in there, except that it had a low-pass cut off starting at about 3.6 kHz or so - just about right for the 3.6 kHz audio filter in the radio - and with 81 taps it provided reasonable (>=55dB) worst-case low-pass filtering to prevent aliasing at and above 3.6-ish kHz, the highest audio frequency that my audio filters would pass.

At this point I'll say a few words about "appropriate" audio filtering.  I really didn't care too much if the filtering above this frequency was insufficient to prevent "audible" aliasing since it was going to be removed by the SSB filters anyway.

For example, if one picked, say, 4 kHz has the highest-frequency signal that was going to get through the 3.6 kHz audio filter (e.g. a strong CW signal down on the "skirts" of that filter) we know via math that its alias would be at 12 - 4 = 8 kHz.  What that means is that worst case, our strongest alias signal - and the "closest" to our audio passband - would be at 8 kHz, so our filter must attenuate adequately - by some 60dB or so - between the 3.6 kHz representing the "top" of our widest filter and 8 kHz.

On this point I actually "fudged" a bit:  The filtering was adequate to knock it down only by 50 dB or so, but since the 3.6 kHz filter was not going to be used very often I looked, instead, at the numbers for the "2.3 kHz" filter - which actually passes audio between about 300Hz and 2600 Hz, and its steep skirt is around 3100 Hz or so.  Taking 3100 Hz as our "new" highest frequency the alias would be at 12 - 3.1 = 8.9 kHz and this extra (almost) 1 kHz of roll-off provided another 10 dB or so on our low-pass filter.

Because the CMSIS decimation function required that I put some FIR low-pass filtering in place - that is, I could not use the function without it - I used as few as FIR taps as practical, finessing them with MatLab so that they, too, did as much filtering as they could with those few taps and achieved something in the 10-20dB area (depending on frequency) on top that achieved with the Hilbert transform, so we now had our target of at least 60 dB!

At the output of the decimator I now had to work at 12 ksps rather than 48 ksps which meant that I had to redesign all of my audio filters, but by keeping them as complex as they had been before - even though the sample rate was now lower - meant that they could now be made to be made "sharper" than before and thus offer higher-performance!

Since I had one forth as much audio data to crunch, more processor horsepower was now available to do other things, allowing to add additional features in the future!

Interpolating back to 48 ksps:

At the end of the audio filtering and AGC processing I had another problem:  The D/A converter still operated at 48 ksps so I had to do an "interpolation" step to up-convert from 12ksps.  Here, too, one must do a bit of low-pass filtering, but for a different reason:  The raw 12 ksps audio would contain aliased audio if upconverted directly to 48 ksps and this can be heard (if your ears are good enough) and could be extremely annoying!

As with the decimation, there is a CMSIS library interpolation function and it has a built-in FIR low-pass function, but there is no real need to make this filtering particularly strong.

In the worst case scenario with the 3.6 kHz audio filter selected, there will be audio content at (12kHz - 3.6 kHz = ) 8.4 kHz - but nothing below that, so a fairly weak low-pass filter with relatively few FIR taps (to minimize processor loading!) was designed in MatLab.  This filter was designed to start rolling off above 3.6 kHz and by the time it got to 8.4 kHz it was attenuating by 25dB or so and was down by 30-40 dB the time it got to 9-10 kHz, where the vast majority of the aliasing energy would be when one operated the most-used 2.3 kHz audio filter:  Because of the way that the human ear works, the "clutter" at the high audio frequencies, knocked down by 25+ dB would probably not even be noticed by someone with even the most acute hearing!

Upon getting this code operational, I fed the LINE OUT from the receiver into the Spectrum Lab program with a sound card running at 192 kHz and verified that the low-pass filtering did, in fact, reduce the aliased signals by the predicted amount.  I then routed the audio into full-range speakers and, with a graphic equalizer, intentionally boosted the highs by 10-15dB in an effort to accentuate the aliasing signal but even in a worst-case scenario with single tones the aliasing was pretty much inaudible.

Comments:
  • For the 10 kHz audio filter mode, decimation/interpolation-by-2 was used and similar tricks were used with the Hilbert transformer to minimize processor loading.  In this case the interpolation's low-pass filtering was far less effective since the Nyquist frequency is 12 kHz so the output contains aliasing components that are only 6-15dB down, worst-case.  Even in this case, with a 9.8 kHz tone - with the alias at 24 - 9.8 = 14.2 kHz - the psychoacoustical properties of human hearing make it somewhat difficult to hear this tone.
  • The codec chip is also capable of operating at 8 ksps, both for A/D and D/A operations.  While this would greatly reduce processor overhead, it would limit the view on the spectrum scope to just +/- 8 kHz!  If there had not been enough processing power to do what was needed to be done this may have been a necessary strategy to take, but with voice modes, it turned out not to be needed.  In the future when digital modes are contemplated and additional processing power may be needed - but a wide "spectrum scope" is not - the use of an 8 ksps rate will be considered.
Fractional I/Q phase adjustments:

One of the problems with real-world hardware is that there will inevitably be variations in the I/Q phasing and amplitude of the audio as it is processed by the two audio A/D converters.  This phase difference could be from a slight shift in the local oscillator signal or, more likely, it could be due to component variations in the analog circuitry comprising the mixer and filtering that precedes the A/D converter.  Whatever causes this problem, it must be addressed to maximize the opposite-sideband rejection.

Addressing the amplitude imbalance is pretty easy:  One simply multiplies the amplitude of the I/Q channels by a small, fractional number made adjustable by the user.   Typically both channels are multiplied by equal and opposite amounts so that the total amplitude remains generally constant.

Phase adjustment, on the other hand, is trickier!

In my researching how this is done on PC-based SDR implementations I saw that there appeared to be handy, on-the-fly calculations phase adjustments that could be done using various library functions that would transform the I/Q signals.  While such functions may have existed somewhere in the bowels of the libraries available to me, real-time calculation of the phase for each sample that came in would represent a prohibitive cost in terms of processor power!

So, how would one take care of this problem with a minimum of overhead, preferably with a one-time calculation?

It struck me that if I could modify the Hilbert transformer in a "fractional" manner I might be able to effect a fractional phase adjustment.  Since calculating the 81 coefficients internally was out of the question (I didn't want to figure out how to do that from scratch, plus it would have been a pain if I needed to modify the Hibert transformer in the future if I wanted to modify its parameters!) I wondered if I could "tweak" a fixed set of coefficients and not "break" the transformation to a significant degree?

Using the Iowa Hills program I calculated four sets of Hilbert coefficients:  0 degrees, 90 degrees, 89.5 degrees and 90.5 degrees.  In the mcHF, the 0 degree set (the "I" channel) would remain constant, but if the I/Q phase needed to be adjusted, the data from the nearest "alternate" set of coefficients for the "Q" channel would be proportionally blended.  For example, if 89.95 degrees was needed, it would use 10% of the 89.5 degree set and 90% of the 90.0 degree coefficients and this new data would be input to the Hilbert transformer.

Putting this new code into the receiver, using a signal generator, and making very careful measurements at the "worst case" settings of 89.75 and 90.25 degrees (and a few points in between) I measured only very minor amplitude (for which I could compensate!) and phase degradation in the performance of the Hilbert transformer due to these "straight line" approximations and called it good!

This method of phase adjustment is applied for both receive and transmit, but in practice it has been observed that far more amplitude adjustment is typically required than phase adjustment to effect optimal opposite-sideband rejection, at least if good-tolerance components - especially capacitors - are used in the receive and transmit paths!

Comment:
  • On my mcHF transceiver I have typically required well under 1/10th of a degree of phase adjustment, so the available range of +/- 0.5 degrees is probably overkill!

What about transmit?

All of the above tricks could be applied to transmit, but thusfar, there has been no need to do any decimation/interpolation - just the Hilbert transformations, amplitude and phase adjustments, some audio processing and filtering - topics for later discussion.

For transmitting, since fewer operations need to be accomplished than in receive, everything still operates at 48 ksps with processing power to spare.  If it does become necessary in the future, I could decimate/interpolate within the transmit function and "regain" a significant number of CPU cycles!


How does the receiver sound "on the air"?

In tuning around with this receiver, the result of this processing - which is all done with floating-point arithmetic - is at least comparable to any of my other all-analog radios in terms of filter performance, adjacent channel rejection and opposite-sideband rejection:  Even under "contest" conditions with a very strong signal "next door" the receiver seems to be perfectly capable of holding its own!

While a few shortcuts had to be taken to reduce the amount of processing to an amount that could be handled by this radio, it does not seem to have demonstrably compromised its receive performance in actual, real-world conditions!



[End]

This page stolen from "ka7oei.blogspot.com".

Saturday, March 7, 2015

Using the "RTS.SDR" dongle (with HF port) as found on Ebay

Some months ago I was perusing the wares of a seller on EvilBay and having decided to purchase one of those all-purpose component testers, I was tempting myself with other items on sale.  One of the items that I could not resist was the "RTL.SDR" that was billed as having an onboard frequency upconverter to allow HF operation (it actually doesn't - see below) plus a more stable reference oscillator.

Figure 1: 
The EvilBay "RTL.SDR" with extra connector
for HF reception.
According to the pictures on EvilBay, the units
currently sold host different picture, with
 a graphical representation of the schematic
diagram showing the mixer.
Click on the image for a larger version.
"What are these 'dongles' of which you speak?"

Stepping back for a moment, the "RTL" SDR dongles have been around for a few years, so-called because they typically contain as one of their active devices the Realtek RTL2832U.  These devices - costing roughly $10 (more or less) also contain a device (a Rafael Micro R820T in the case of the one pictured) with an onboard frequency synthesizer, I/Q mixer and (8 bit) A/D converter that allows one to receive signals from 50 MHz (or lower) to well above 700 MHz - sometimes way above 700 MHz, just using a computer with reasonable horsepower and FREE software!

While the thought of an 8 bit A/D converter and its rather limited dynamic range (40-ish dB) might make it sound like these devices may be useless when connected to an antenna, the fact that they convert only a limited range of frequencies (approximately +/- 2.4 MHz at most) around the tuned frequency - plus the "oversampling" nature of the raw A/D sampling rate of the 8 bit converter means that relatively narrowband signals can have quite good ultimate quantization range.  What can suffer is when, within the sample-rate passband there are signals that range widely in signal strength:  Under such conditions it is recommended that one "finesse" the gain controls for optimum input signal levels to the A/D converter.  Another deficiency from which they suffer is quantization noise - that is, the inability to "see" weak signal that are down in the mud, plus the tendency for this noise to somewhat "spread" the energy of nearby, stronger signals around and raise that noise floor.

Perhaps the most popular software to do this is "SDR#" (a.k.a. "SDR-'Sharp'").  Easily found via a web search, this software is compatible with many software defined radio packages and it supports many modes and features, also offering many optional plug-ins.

These low-cost USB dongles were intended to allow the reception of digital TV and FM/Digital Audio broadcast (but not the sort of TV or digital audio broadcast that is used in North America) on a computer so they were designed to tune from something around the low-medium VHF range - say, 20's to 50's of MHz and up, almost completely leaving out the HF frequency bands.

Several schemes have been devised to allow the use of these handy devices to receive HF and these typically involve the use of some sort of upconverter to translate the HF frequencies from as low as the AM broadcast band up to a range that these devices will tune.  Another scheme - used here - is to feed HF directly into the "Q" input of the RTL chip - this input not normally being used with its frequency converter.

So, I soon found myself with the device pictured in Figure 1 in my hands.  Getting busy with life and other things, it was a few months before I got around to playing with it and while I quite easily got it working on the "UV" input which, on this particular unit tunes from just below 25 MHz to over 1 GHz (although I'm not sure exactly how far above 1 GHz...) but I was puzzled as to how to configure it operate at HF.

How to make it work on HF:

Back then, a web search didn't help as there was a plethora of hits on "RTL SDR Upconverter" so I removed the unit from its case and found the callsign "BA5SBA" on the board that you see in Figure 2 and got a hit with Google on a German page (this one - LINK - you may need to run it through a translator, so try THIS LINK which may or may not work...)  While this web page didn't describe exactly what I needed to do, it did provide enough clues to get it working!

Comment:
  • More recently, the some of the sellers on EvilBay are including in their postings some basic instructions on how to get these devices to work on their "HF" ports, but what follows below contains more information - and is hopefully easier to find and more permanent - than an EvilBay posting!

Figure 2: 
Inside the BA5SBA "RTL.SDR" with the "HF" port.
The jumper in the upper-left corner marked "A" and
"P" appears to be intended for putting 5 volts on
the "UV" antenna connector to power an external
RF amplifier.  ("A" = active, "P" = passive).
Click on the image for a larger version.
With a bit of reverse engineering I determined that the "HF" input was connected, via a transformer, some low-pass filtering and some protection, to one of the inputs of the RTL chip - specifically, the "Q" input - which not used in its normal role when converting from higher (VHF/UHF) frequencies.

Using a signal generator set to 5 MHz I connected it to the "HF" input of the device and, just for kicks, tuned SDR# to 5.000 MHz as well.  After a bit of fiddling about, I finally found how to configure the unit to receive at HF.

  • STOP the SDR receiver first by hitting the square "stop" button at the top.
  • Bring up "RTL-SDR Controller" window (accessible by clicking on the "gear" symbol)
  • Under "Sampling Mode" set it to "Direct Sampling (Q Branch)".  Note:  You cannot change the sampling mode without first STOPPING the SDR.
  • Restart the SDR by pressing the "start" button (the right-pointing triangle resembling a "PLAY" button)

Once I had done this I saw the 5 MHz signal on the display!


Comments: 
  • By default, SDR# will set the "RF Gain" setting in this same "RTL-SDR Controller" window (see Figure 6) to minimum gain (all the way to the left.)  If you leave it there, the SDR dongle will be EXTREMELY DEAF when it is in the normal "Quadrature Sampling" mode.  When you have it in either "Direct Sampling" mode this control is disabled.
  • I would suggest checking the box that says "RTL AGC" and moving the RF Gain control in either "Quadrature Sampling" or "Direct Sampling" modes:  If you do not do this your receiver may be very deaf!
  • I experimented with using this device with the "HDSDR" program and found that at HF, its sensitivity was noticeably worse than that obtained when using it with SDR#.  I'm not sure why this might be, but it seems to have something to do with the way the "ExtIO" driver - or HDSDR itself - handled the internal gain settings of the dongle.
Figure 3: 
A screenshot of SDR# showing the configured "Shift" for the mixer.
Click on the image for a larger version.

Now I am very surprised that I can tune SDR# to "5.0" MHz and see the 5 MHz signal that I am inputting as the chip on this dongle should not function at that frequency!  What I expected to have to do was as follows as shown in Figure 3:
  • Knowing that the onboard mixer uses the 28.8 reference oscillator, check the "Shift" button on SDR#.
  • Enter a frequency of "-28800000" (yes, negative 28.8 million) into the box as shown in Figure 3.
  • Note:  There is a bug in some versions of SDR# that, if you are already tuned to a frequency lower than the "shift" frequency, the tuning may not work properly until one sets a much higher frequency with the 100 MHz digit and tunes back down.
  • Having done this, one need not mentally add the desired HF receive frequency to 28.8 MHz:  The receive frequency is simply input to the main frequency tuning as one would any other frequency!
  • If the 28.8 MHz frequency reference oscillator is somewhat off frequency one must first set the frequency using the "normal" VHF/UHF mode and calibrate it in the "RTL-SDR Controller" window and THEN, after switching to HF mode as described above, one can input a frequency that is slightly different from 28.8 MHz as needed to correct the offset.  I did not have to make any correction at all!
Comments: 
  • The 28.8 MHz reference oscillator supplied with this unit appears to be quite good and stable and was only off a few PPM:  Your mileage may vary.
  • If you want to use the VHF/UHF input again, remember to reset the "Sampling Mode" back to "Quadrature Sampling" and UN-CHECK the "Shift" box that is visible in Figure 3.
Does it matter whether one uses the "0 MHz" method or the "-28.8 MHz" method with the offset?  Not really:  I could see no difference in the sensitivity of the SDR - but it is good to be aware of both methods just in case the "0 MHz" method doesn't work!


Comments on the design of the HF mixer and its limitations:

Sensitivity (or the lack of...)

Figure 4:
The low-pass filter in front of the mixer.
Click on the image for a larger version.
The very simple mixer on this SDR Dongle has its limitations, the first of which is that being entirely passive, the ultimate sensitivity at HF is not particularly good:  Using SSB (2400 Hz) bandwidth, signals down to around -90dBm were audible, but that was about it.  While this represents a signal of around 7 microvolts and may seem horrible (and it is, compared to modern HF receivers!) it should be remembered that if this is connected to anything resembling a full-sized HF antenna, it "hears" just fine since the background noise on HF bands - and thus the signals - will typically be above this level - at least on the "lower" bands of 10 MHz and below.

Nyquist rules!

The other problem is that the sampling rate on this input is 28.8 MHz.  What this means is that there is a Nyquist limit of 14.4 MHz - and that means that any signal above 14.4 MHz will reappear again as an "image" at a lower frequency, approaching Zero Hz as it approached 28.8 MHz.  In other words, if you were tuned to 7.1 MHz in the 40 meter band, you would also hear a signal at 7.1 MHz below 28.8 MHz, or 21.7 MHz!  This also means that if you were trying to listen on 21.1 MHz in the 15 meter band, you would hear a signal at its 7.7 MHz image!  The situation is worse on 10 meters since the 28.8 MHz local oscillator is nearly in the middle of this band:  An FM signal on 29.5 MHz would also appear on 28.1 MHz!
Figure 5:
The response of the low-pass filter depicted in Figure 4.
The bandpass response is the solid line.
Click on the image for a larger version.

If you look at the circuit board in Figure 2 you'll notice several components in the foreground, namely a number of inductors and surface-mount capacitors, all with the values marked on the silkscreen.  Presuming that the values of these components are as-marked, I drew the schematic in LT Spice that is shown in Figure 4 and simulated it with the result in Figure 5.  As can be seen, this low-pass filter effectively blocks signals much above 40 MHz or so, offering more than 40 dB of attenuation above 60 MHz.

Other than keeping signals from low-band TV and FM broadcast out of the "HF" input, this filter does not help us at all in our image problem.  Because this filter does not block signals immediately above 28.8 MHz, we have another set of images that occur which means that a signal that is at 33.8 MHz - 5 MHz above 28.8 MHz - will also show up at 5 MHz! 

If there are no signals (or noise!) on these "image" frequencies, there should be no problem, but this is likely not to be the case during the daytime on a large wire antenna - which means that if you really want to use this dongle for serious HF reception, you need some sort of filter in front of it, either a separate Low Pass (below 14.4 MHz) and High Pass (above 14.4 MHz) to be used individually, or you could use a tunable preselector to pass only the frequencies of interest.  (There would be a problem with 10 and 20 meters as these bands are close to or include the Nyquist frequency!)


Possible modifications:

If you look at Figure 2 you'll note that there are several small "prototype" areas on the circuit board.  These are large enough to allow the construction of some simple circuits, namely a bit of additional gain (amplifiers, filters) to improve the sensitivity of the receiver.

As mentioned before another useful modification - one external to this box - would be the addition of a preselector to filter a narrower range of frequencies.  Another would be to simply add another oscillator of a much higher frequency (say, 100-150 MHz) and feed it into the mixer to put the Nyquist limit completely above the HF band.

Is this "HF" input useful as-is?

In general, yes, with a good antenna.  Despite its flaws, when one casually tunes around the HF bands its problems do not immediately jump out, at least on the lower bands.

The biggest advantage of this particular SDR Dongle is that it seems to have quite a stable oscillator on board - much better than the $8 USB "stick" that I have experimented with previously:  This one seems to move only a few 100 Hz from cold start even at UHF frequencies whereas the very cheap ones seemed to move all over the place with temperature!

To be sure, one could probably get better HF performance by building (or buying) an upconverter for this sort of SDR that uses a much higher local oscillator frequency - say, 100 MHz -  but if one upconverts all of the HF frequencies en-masse, there are a few things that one must remember:
  • If you use a chip like the NE602, it may simply overload when connected to a full sized HF antenna unless you are prepared to add switchable attenuation to it and/or a preselector!
  • On a full-sized antenna, intercepting and converting the entire HF spectrum can represent quite a bit of signal energy.  If the HF upconverter that you are using does not, itself, overload, there is a good change the the converter chip in the RTL-SDR itself will overload with so much energy from such a wide variety of frequencies!  Remember:  The receiver chips in these dongles were intended to work with the relatively weak and sparse broadcast signals intercepted on small, indoor antennas, not the entirety of the HF spectrum when the bands are open!
  • If you use a separate upconverter circuit - say, to 100 MHz - the frequency stability will be dependent on that 100 MHz local oscillator and the reference used by the dongle itself for its normal operation.  With two oscillators, there is the greater potential for drift, a fact exacerbated by these oscillators effectively operating at rather high frequencies.
Figure 6: 
The screen for configuring the dongle's
hardware.
Click on the image for a larger version.

A few brief comments on using it at VHF/UHF:

Remembering to set it to the "Quadrature Sampling" mode when using the "U/V" input, there are a few things to know when using this device - and possibly others like it - with SDR#.

Clicking on the "gear" symbol will open a screen such as that depicted in Figure 6 that allows modification of settings related to the dongle's hardware.  In particular, note the check in the box for RTL AGC and the lack of a check in the Tuner AGC box:  The RTL AGC box is necessary in both the Quadrature Sampling mode to get the most gain out of the device.

The Tuner AGC box - which is only available when Quadrature Sampling mode is active - if checked, does not seem to work properly in the the version of driver and/or SDR# at the time of initial posting of this blog entry (March, 2015) as it seems to increase the gain too much, causing overload of the A/D converter and actually reducing performance - particularly if a decent antenna is connected!  (This is really where the deficiencies related to just having 8 bits of A/D conversion start to show up:  With higher resolution - and higher dynamic range - the "sweet spot" in which the performance would be good would be wider.)
Figure 7: 
 Top:  Properly adjusted RF gain setting
Bottom:  The degradation from too much RF gain!
Click on the image for a larger version.

Figure 7 demonstrates the problem.  The top half of the image shows an optimally adjusted amount of gain - a setting of 12.5 dB for this particular antenna (yours will vary!) while the bottom shows a gain setting of 37.0 dB.

Even though more signal is reaching the A/D converter in the bottom example, it is way too much and the converter is being badly overloaded, causing the noise floor to rise from below, submerging weaker signals!  If the RF gain is sett too low, degradation can also occur, but this time from too little signal.

The idea is to adjust the RF gain so that there is there is the maximum difference between the highest signal and the noise floor seen between stations - even if the absolute level of the signals may be lower, overall!



[End]

This page stolen from "ka7oei.blogspot.com".