Adding FM to the mcHF SDR transceiver

This has been one of those "Rabbit Hole" features.

In the past I have stated several times on the Yahoo Group that I would not be adding FM to the mcHF (a completely stand-alone QRP SDR HF transceiver) any time soon, mostly because I was quite certain that there was simply not enough processor horsepower to do it properly, but quite recently I (sort of) got obsessed with making it work, going from "0 to 60" in just a few evenings of code "hacking".

While it took only an hour or so to get the FM demodulation and modulation working it ultimately took much longer than that to integrate the other features (subaudible tone encode/decode, etc.) and especially the GUI interface with everything!  By the time I was done I'd spent more time than I had hoped (not unexpected!) but at least had something to show for it!

FM on an HF transceiver:

First of all, FM is one of those modes that I have used on HF only a few dozen times in my 30+ years of being a ham - using it most often (albeit rarely) when 10 meters is open and I hear a repeater booming in, but other than that I haven't really had any reason to do so, particularly since there are no local 10 meter repeaters and local activity on "10 FM" is quite sparse.

Figure 1:
Reception of an FM signal as displayed on the waterfall (using the
"blue" palette) showing the sidebands from the 1 kHz tone
modulated onto the carrier being received.  The white background
on the "FM" indicator shows that the (noise) squelch is open.
Click on the image for a larger version.

What might be a practical reason to add FM to the mcHF other than for 10 meter openings or with a transverter (or a modified radio) on a higher band such as 6, 4 or 2 meters where FM is common?  I asked this question on the mcHF Yahoo group and several people noted that in various parts of Europe, FM repeaters and simplex operation on 10 meters is/are (apparently) more common than here in the U.S - not to mention the fact that I suspect that some mcHF users like to hang out on "CB" frequencies where FM is used in Europe.

Background:

As it turns out I was recently adding/fixing some of the current mcHF features, streamlining some code and I decided to look into what, exactly, it would take to demodulate FM.

Before I begin the description it should be noted that the mcHF, in FM receive mode, must utilize "frequency translation" which shifts the local oscillator by 6 kHz - this, to get away from the "0 Hz hole" intrinsic to many SDR implementations that down-convert the RF to baseband:  If we did not do this the FM carrier would land in this "hole" and hopelessly distort it!

With the signal to be received centered at 6 kHz at the input of the A/D converter, a software frequency conversion shifts it back to "0 Hz" where, in the digital domain, the hole does not exist.  True, the FM signal is now modulated +/- zero and includes "negative" frequencies, but since the signals are quadrature and it is just math at this point we can get away with it!

(Note:  The "0 Hz hole" still exists but is now 6 kHz removed from the center of the carrier so it has no effect at all on demodulated signals in receive bandwidths up to 12 kHz.)

The PLL method of demodulating FM:

The most common way to do this is via a PLL, implemented in software

Figure 2:  PLL implementation of an FM demodulator

Depicted in Figure 2 this works by "tracking" the variations of the input signal's frequency using the PLL:  Differences in instantaneous phase are detected, applied to the VCO's tuning line via the Loop Filter.  The loop filter is present to remove the energy from the original carrier frequency, effectively leaving only the audio modulation behind, a sample of which is high-pass filtered to remove the DC content and used to extract the demodulated audio.

In hardware this type of scheme is used in PLL ICs such as the NE564 and NE565, or even the good old 4046 PLL IC:  Many implementations of hardware-based FM demodulators may be found on the internet using these chips!  (Hint:  Google "NE565 SCA decoder").

In software this method would typically be applied in those instances where the "carrier" frequency was high, compared to the highest modulated frequency contained in the FM signal to be demodulated and the "VCO" would be an NCO (Numerically Controlled Oscillator) - essentially a software-based DDS (Direct Digital Synthesis) "oscillator."  In a typical SDR application the implementation would appear more complex than in the above block diagram, using both the I and Q channels as part of the phase detector (and to avoid ambiguity since both are needed to avoid the "frequency image" anyway) - but the intent is quite clear.

Out of curiosity I decided to implement this on the mcHF, but as expected it was to "expensive" in terms of processing power - plus, the "carrier" frequency (in software) was only 6 kHz - not too far above the highest modulated frequency.  I could hear the audio, but it was somewhat distorted.

The "arctangent" method of demodulating FM:

Applying another tactic I went for the "arctangent" method.  If you recall your trigonometry, the arctangent is that number that you get when you input the ratio between the two sides of a triangle to yield the angle.  Related to the arctangent is the "atan2" function that appeared in computer languages where not just the ratio is inputted to the function, but the actual lengths of the sides of the triangle (y, x) and the angle is computed from that.

If we consider the instantaneous amplitudes of our I and Q signals to be vectors, we can see how we can use this function to determine the angle between those two vectors at any given instant - and since FM consists of rapidly changing phases (angles) we can therefore derive about the frequency modulation:  The more the angle changes, the more deviation!  (More or less...)

Figure 3:  Speech-modulated audio being received and displayed
on the "Spectrum Scope" showing the width of a typical
voice-modulated, pre-emphasized FM signal.  The red "FM"
indicator shows that the subaudible tone is being received and
properly decoded.
Click on the image for a larger version.

In order to do this you must know how the vector has changed from one sample to the next, using previous information to do so, so a bit of math is first used to accomplish this as described in the following code snippet:

loop:
   y = Q * I_old - I * Q_old
   x = I * I_old + Q * Q_old
   audio = atan2(y, x)
   I_old = I
   Q_old = Q

Where:
   "I" and "Q" are our quadrature input signals
   "audio" is the demodulated output, prior to de-emphasis (see below.)

Because we supply it with both x and y, "atan2" function has the convenient feature of knowing, without ambiguity, the quadrant from which the two sides of the triangle are derived - something not possible from the normal "atan" function.  For example if our vector is +1, +1 - a ratio of 1 - we know that our angle is 45 degrees in the first quadrant, but if our vector is -1, -1 - our ratio is still 1, but clearly this angle is in the fourth quadrant and the normal "atan" function would give us a completely bogus answer - but "atan2" would faithfully yield the correct answer of 315 (-45, actually) degrees.

If you are coming from the analog world you know that one of the necessary steps in properly demodulating an FM signal is to apply limiting after bandpass filtering, but before the actual FM demodulation - this being a process where incoming signal is typically amplified and then strongly clipped - often several times - to assure that the amplitude of the resulting signal is constant regardless of the strength of the original signal.  The reason for this is that most analog FM schemes are either amplitude sensitive to a degree (e.g. slope detection, the "Foster-Seeley" discriminator - link, or even the so-called "ratio detector" - link) or can operate over only a somewhat limited amplitude range and still maintain "linearity" in their frequency-dependent demodulation.

As it turns out the while both of the aforementioned schemes are amplitude-insensitive with this limiting applied, the "atan2" method can be considered to be the ultimate "ratio detector" in that all it really cares about is the ratio of the vectors from the I and Q channels and not a whit about their amplitudes!  If the signal is reasonably strong, both channels (I and Q) will reflect the instantaneous angle-change of the received signal with respect to the previous sample.  As with any other method of detection of frequency modulation as signals get weaker, noise begins to intrude, causing uncertainty and the calculation of the instantaneous angle begins to be contaminated with random bursts of energy which naturally shows up as "popcorn" and/or "hiss" in the recovered audio.

Rather than using the compiler's rather slow, built-in floating-point "atan2()" function I decided to use the "Fixed point Atan2 with Self-Normalization" function (in the public domain) attributed to Jim Shima posted (among other places) on the DSP Guru Site (link here).  Actually, this algorithm was quite familiar to me as I'd unwittingly derived a very similar method many years ago on a PIC-based project in which I needed to do an ATAN2-like function using integer math to derive the bearing on a direction-finding (DF) system. (The DF system is described here - link)

Needless to say, this algorithm is blazing fast compared to the built-in, floating-point "atan2" function and demodulating FM with this much horsepower simply would not be possible without its "cost savings" and the accuracy of the result easily yields sub 1% THD (distortion) - more than adequate for communications-grade FM.

De-emphasizing the demodulated audio:

The audio that spits out of the "atan2" function is proportional to the magnitude of the frequency deviation at any modulated frequency (within reason, of course!) - but in amateur radio, at least for voice communications, we do not use "FM" per se, but rather "Phase" modulation (PM).  Without going into the math, the only thing that you need to know is that in order to use an FM modulator to generate a PM-compatible signal one must "pre-emphasize" the frequency response of the audio at a rate of 6 dB/octave.  In other words, if you were set a signal generator to produce +/- 2 kHz of deviation with an audio signal of 1 kHz, if you change that audio signal to 2 kHz - but kept the audio level the same - the deviation would increase to +/- 4 kHz of deviation when you are using PM.

If you did not do this pre-emphasis, your audio would sound muffled on an ordinary amateur "FM" receiver.  Conversely, if you use an "FM" receiver for the reception of PM you must apply a 6 dB/octave de-emphasis to it:  Without this the audio tends to sound a bit "sharp" and tinny.

There is a practical reason for doing this and it is in the form of "triangle noise" - that is, as an FM signal gets weaker, the recovered audio does not get quieter, but it gets noisier, instead, with the noise appearing in the high frequencies first as high-pitched hiss.  By using "PM" (or more typically, "true" FM with pre-emphasis on transmit and de-emphasis on receive) we reduce the intensity of this high-pitched noise on weaker signals:  Since we are boosting the "highs" on transmit and then reducing them back to normal on receive, those audio frequencies that would be first affected by noise as the signal weakens are maintained at higher levels while at the same time reducing the amplitude of the high frequencies in which the noise will first appear, preventing the phenomenon by which the high frequency component would otherwise be the first to disappear into the noise with weak signal.  The end result is that with PM, the signal can be weaker - and seem to be noise free - more than is possible with "straight FM".

For an explanation of noise in FM signals, in general, read the page "Pre-Emphasis (FM) Explained" - link.

In an analog circuit this de-emphasis is as simple as an "R/C" (resistor-capacitor) low-pass filter (series resistor followed by a capacitor to ground) and it may be simulated in code as follows:

loop:

  output = old + α * (input - old)

  old = input

Where:
   "α" is the "smoothing" parameter
  "input" is the new audio sample

  "output" is the low-pass (integrated) audio data

In the above, the output data is proportional to the previous output and the next input which means that as the rate-of-change increases, the output decreases - effectively forming a single-pole low-pass filter of 6 dB/octave.

If you were to implement this with real components (resistor, capacitor) you would not select them for really low frequency as this would mean that by the time you got to speech frequencies (1-2 kHz) your audio would rolled of by many dB - but this would also mean that low-frequency components (subaudible tones, AC hum, even the low-frequency components of noise) would seem to be artificially amplified and could "blast" the speaker/amplifier.  Instead, one would select a "knee" frequency above which one would start to roll off the audio - typically just below the bottom end of the "speech" range of 300 Hz or so and by doing this the low frequencies are not as (seemingly) amplified as they would by otherwise.  As it turns out, with an "α" setting of 0.05 or so we can achieve a reasonable (low frequency) "knee" frequency at a sample rate of 48 kHz.

Even if we appropriately select a "knee" frequency as above our audio amplifier/speaker will still get blasted by low-frequency noise since we must still amplify the signal by well over 10 dB to get reasonable amplitudes at speech frequencies, but we can - with a "differentiator" - the inverse of (but similar to) the integrator described above, knock off these low-end components.  In software this differentiator function (which, in the analog world, is a series capacitor followed by a resistor to ground) is performed as demonstrated below:

loop:

  filtered = α * (old_input + input - old_filtered)

  old_filtered = filtered

  old_input = input

Where:
  "α" is the the equivalent of the time constant in that a "small" α implies an R/C circuit with a fast time-constant strongly affecting "low" frequencies.
  "input" is the new audio sample.
  "filtered" is the high-pass filtered (differentiated) audio

Setting "α" to 0.96 (with a sample rate of 48kHz) put the "knee" roughly in the area of 300-ish Hz and with the "low-pass" (integrator) and "high-pass" (differentiator) cascaded the low-frequency speech components were minimally affected, but the combination of the "knee" frequency of the integrator and the nature of the differentiator meant that the very low components (below approximately 200 Hz) were being attenuated at a rate of around 12dB/octave - all by using simple filtering algorithms that take little processing power!  Again, it is important that we do this or else the very low frequencies (subaudible tones, the "rumble" of open-squelch noise) would be of very high amplitude and easily saturate both the audio amplifier and speaker, causing clipping/distortion at even low audio levels.

At some point I may attempt to design an FIR or IIR filter that will both de-emphasize the audio at 6dB/octave and filter out the low frequencies used by subaudible tones but I wanted to at least try the above method which was pretty quick, easy to do, and had a fairly low processor burden.

Pre-filtering:

One factor not mentioned up to this point, but extremely important - especially with FM - is that one must bandwidth-limit the I and Q channels before demodulation.  More than in the case of AM, off-frequency signals will contribute to noise and nonlinearity in the demodulation process and it is easy to see why:  If we are simply using vectors with our "atan2" function to recover the frequency modulator, anything that contaminated that information would distort and/or add noise to the resulting audio so it is important that we feed only enough bandwidth to the demodulator to pass "enough" of the signal.

Defining the bandwidth of a modulated FM signal is rather tricky because it is, in theory, infinitely wide. In practice, the energy drops off rather quickly so the "far out" sidebands soon disappear into the noise, but how quickly can we "clip off" the "close in" sidebands?  Clearly, we must have at least enough bandwidth to pass all of our audio, and since the FM signal is symmetrical about its center, it's twice as wide as that.  There is also the issue of the amount of frequency deviation that is used.  If we take our example of +/- 2.5 kHz deviation in "narrow" mode we know that just because of that, alone, our signal must be at least 5 kHz wide!  It would make sense, therefore, that the actual bandwidth of the signal is related to both the amount of deviation and the audio imposed on it - and it does, and this is called "Carson's Rule" and you can read about it here - link.  This rule is:

 occupied bandwidth = 2 * (highest audio frequency) + 2 * (deviation)

If we have +/-2.5 kHz deviation and our audio is limited to 2.6 kHz the calculated bandwidth would be 10.2 kHz.  It should be remembered that this is considered to be the occupied bandwidth of the signal and generally indicates the minimum spacing between similar signal, but it turns out that if we are willing to put up with minor amounts of signal degradation our receive bandwidth may be narrower.  By cutting off a few extra sidebands the result is a bit of added distortion since part of signal that represents the vectors presented to the "atan2" function have been removed and the representation is understandably less-precise.

In the case of the mcHF, filtering for the FM demodulator is done by the same Hilbert transformers that are already present for "wide" SSB and AM demodulation where they can also be configured to provide a low-pass function.  For example, there exist 3.6, 5 and 6 kHz low-pass versions of the Hilbert transformers that provide the 90 degree I/Q phase shift and coupled with the fact that these would operate both above and below center frequency, they yield approximate detection bandwidths of 7.2, 10 and 12 kHz, respectively.  Using a filter wider than 12 kHz (+/- 6 kHz) is problematic in this implementation because, as noted earlier, we are shifting our signal by 6 kHz and with a 12 kHz bandwidth, one edge of the filter actually falls in the "zero Hz hole" of the hardware.  This is not a problem at the 12 kHz bandwidth, but it is a problem at wider bandwidths and can result in significant distortion.

While receive bandwidths more than 12 kHz could be obtained using a shift greater than 6 kHz, testing (both on-the-bench and on-air) has shown that "wide" +/- 5 kHz deviation signals may be received with little/no obvious distortion with the 12 kHz bandwidth setting - and even the 10 kHz setting is very "listenable".

Surprisingly, if you cram a +/- 5 kHz deviation signal through the 7.2 kHz filter, the results are generally quite usable although distortion and frequency restriction are becoming evident and there may be the risk of clamping if the squelch is set too tight.  One advantage of a 7.2 kHz filter over a 12 kHz filter is that the former, being only 60% as wide, will intercept commensurately less noise on a weaker signal which means that it may be possible to gain an extra dB or two of receiver sensitivity by switching to the narrower bandwidth - if one is willing to accept the trade-off of lower fidelity!

In a later posting I'll talk about the squelch "circuit", subaudible tone detection as well as frequency modulation.

[End]

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

Adding a waterfall display to the mcHF transceiver

Figure 1:
The "Grey" waterfall mode of the mcHF self-contained SDR transceiver
in "Magnify" mode which shows only 24 kHz total bandwidth.
Three - possibly four SSB QSOs are visible in this picture.  This picture
was taken before I added windowing to the FFT, improving the "look".

One of the things that the mcHF SDR transceiver has been missing from the beginning was a type of spectral display often referred to as a "Waterfall" display.

It seems that all "good" SDR rigs have them these days - so why not this one?  When I first started working with the mcHF and contemplated this question I thought, "there's plenty of processor horsepower for this... I think..."

Actually, it was more complicated than that.

Two types of LCDs and interfaces:

There are two "flavors" of the mcHF:  The early units used LCDs with "SPI" (high speed Serial) interfaces while the current crop (and by far the majority) use a parallel interface that physically maps the display's RAM to the processor's I/O controller so that it sees it as RAM - plus, it can access the display's normal commands with 16 bit-wide parallel data - either method being orders of magnitude faster than the SPI.

Now, as new features are developed for the mcHF, it is strongly desired that they all be compatible with both the SPI and Parallel version.  To that end Chris, M0NKA kindly sent me an older "Rev 0.2" UI board with an SPI interface-type LCD so that I could spend some time improving the SPI-based routines that work with the display - plus it gave an opportunity to test both types prior to releasing software to make sure that I'd not "broken" anything on one or the other version of hardware.

Fortunately, after a bit of studying of the data sheets for the LCD unit I was able to discern that there was a hitherto un-utilized hardware feature that allowed bulk-writing to a defined area of display RAM and with this - and a few other tweaks - was able to speed the "user experience" of those with SPI interface mcHF transceivers by a factor of 4-10 or so, depending on what they were doing.  To be sure, the display updates on SPI-interface radios are still significantly slower than the Parallel-interface radios, but the former are very usable.

Rewriting the "Spectrum Scope":

Figure 2:
Rewritten spectrum Scope showing multiple SSB signals on
40 meters.  Signal-noise (band) conditions were rather poor, but
at least 3 QSOs (and possibly 5) are visible in this shot.
The 'scope is set to display the full 48 kHz mode and 10dB/division.
Note also that the transceiver is set to "LO Low Frequency Translate
mode which moves its demodulation +6 kHz from "zero", eliminating
the majority of issues that are encountered near "DC" with
typical "audio" SDR implementations that use
direct-conversion and/or sound cards.

This brought back another thing that I'd wanted to do from the beginning:  A complete rewrite of the Spectrum Scope (e.g. "Spectrum Analyzer").  I'd reworked it early on, adding some IIR low-pass filtering to "smooth" the display and adding a bit of non-linear display function so that its dynamics were improved, by the vertical scale meant absolutely nothing at all - in fact, its dB/division scaling varied depending on what else was on in the display's passband:  It looked "OK" aesthetically if viewed from a sufficiently long distance, but it did not stand up to close, technical scrutiny.

So, I completely scrapped the Spectrum Scope function save for the original RFFT written by Chris, the somewhat hairy and efficient display functions originally written by Chris and hacked on by me (this is open-source!) and I kept my IIR low-pass filter which seemed to be just fine.

When I was done I had a "proper" spectrum scope with the vertical scale adjustable from 5dB/division to 20dB/division and even 1, 2 and 3 S-Units/Division (because I could...)  There was even an AGC function so that the strongest signal was adjusted to be at the top of the scope, but at the same time it would detect the peak/average of the signals on the scope and prevent an "empty" span from rising up and simply filling the display with noise!

Not wanting to stop there, I put some thought into the waterfall display.

Adding a "Waterfall" display:

The waterfall display is the same as the spectrum scope, except that it adds the dimension of time:  While the frequency is represented horizontally along the "X" axis as with the spectrum scope, with a waterfall display the strength of the signal is represented by the color or intensity of what is on the display rather than the height.  The newest signal is "painted" along the bottom of the display and when the next scan is complete, the "old" information is scrolled upwards and the new information takes its place.  In this way, one has a brief history of signals - both on and nearby the center frequency.

There was a problem:  How do I do this without taking up massive amounts of processor power and/or memory?

As it turns out, all I really needed to store at any given time was the magnitudes and signals in the passband.  In "normal size" mode, the waterfall display is 70 pixels high and since it used a 512 point FFT (sort of...) I had 256 frequency bins, so I represented 48 kHz of bandwidth with 256 pixels horizontally with each pixel representing 187.5 Hz, nominally.  (Note:  It really doesn't work that way - read about FFT and windowing if you are interested...)   If all I wanted to do was store that information, I needed only 17920 bytes of storage since all I was actually storing was the same sort of data that the Spectrum Scope produced:  A signal that went from 0 for the weakest signal to 63 for the strongest - which would fit in a byte!  Making this a circular buffer with a pointer for each line, I could easily keep track of where I was in "time".

Figure 3:
Several CW signals (at least 5) shown with the Waterfall display
in "Rainbow" mode.  In this mode weak signals start at the "blue"
and of the rainbow and progress to red for the strongest.
(Pardon the garish colors and poor contrast - it's difficult to take a good
picture of an LCD screen with a cell-phone camera!)

For the color palette I did the obvious:  A 65 entry RGB palette that matched that 0-63 amplitude range:  That extra color?  I'll get to that in a moment...

The LCD actually uses a 16 bit RGB (5,6,5) color scheme, so it was easy to make another array into which I could simply load my color palette of choice.

Updating the display:

Updating the display was the slightly tricky bit.

Remembering that I'd implemented some "block write" functions when optimizing the SPI interface functions, I wrote some additional, minimalist functions to perform the needed tasks:  One to set up the area on the screen for the block write, another to accept data and another to "close" the block write and return the LCD to "normal" operation.

To display the waterfall, one simply defines the area of the screen defining the extent of the waterfall, enables the "write" command and then blindly throws the exact number of bytes of 16 bit RGB data at it constituting the size of the waterfall display.  It was a simple matter to use the stored amplitude data from the 17920 byte circular buffer to index the color palette and send that data to the LCD - I just had to make absolutely sure that I sent exactly the amount of data that conformed to the expected column and row sizes.

Since this was a "blind" write to the LCD it took an absolute minimum of I/O and even on an SPI interface LCD - while significantly slower than on a Parallel-interface LCD - it is still very usable!  Better yet, it doesn't take oodles, gobs and tons of processor power.

It does take more processor power to update the display than does the spectrum scope, particularly if one has it set to its highest speed, but in actual use one would have it set so that it would take 10-20 seconds for a signal to disappear from the display, and that really doesn't load the processor too much.  (Audio processing always takes precedence, so if one turns on all of the DSP modes with the waterfall set to its fastest mode, you will see it slow down significantly!)

About that "65th" color?  If you look carefully at Figure 3, above, you'll note a blue (cyan, actually) vertical line aligned with the "7035" graticule on the bottom of the screen to indicate the "tuned" frequency:  It's used for that!

Other modes:

In Figures 1 and 3 the waterfall is shown in the "Magnify" mode in which only 24 kHz is actually being displayed instead of the possible 48 kHz (I need to add a picture to show this...) and there is also a mode of the waterfall display that takes up more of the screen, covering the word "Waterfall Display".  There is also a "HotCold" palette in which weak signals are blue and strong are red - and it would be an easy matter to add even more palettes - if someone wants to go through and derive all 64 colors.

Note:  As of version 0.0.219.18, eight types of FFT windowing are available, significantly improving the "look" of both the spectrum scope and waterfall display! - For more information about this read the article on Wikipedia about Window Functions.  If one chooses the appropriate window function the waterfall display and spectrum scope's response to signals is much "tighter" as spillover energy from one "bin" to another on the screen can be minimized.

[End]

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

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".

Update on the mcHF transceiver - Adding features to the original code

For an follow-up article, see this link.

It has been a few months since I have posted anything on the mcHF transceiver  (my previous post may be found here - link) so unless you have been following the mcHF Yahoo group (link - membership required) you would be forgiven for thinking that I had abandoned work on it.

Figure 1:
The mcHF transceiver in operation, showing signals on 10 meters.
Click on the image for a larger version

Quite the contrary, a lot of features have been added to the code, starting with the fine foundation written by Chris, M0NKA based on version 0.0.181.  Considering that he pulled the disparate pieces together pretty much single-handedly, it is quite amazing what was there when I started!

Of course, this is open-source and the whole idea behind it is to allow multiple contributors:  It would be the height of hubris to think that just one person had a monopoly on good ideas, let alone the time to implement a fraction of them, so a group effort is key here.  Even if the majority of the group does not actually contribute directly to writing code, getting user-feedback is absolutely vital to knowing if one is going down the proper path and the detection and fixing of the inevitable bugs that creep in when work is done!

What is the mcHF?

I've had a few people ask me about this transceiver, wondering what it is, some apparently under the mistaken impression that it connects to a computer somehow like many SDR products.

This is, in fact, a completely stand-alone SDR transceiver capable of operating on all bands from 80 through 10 meters. *


RF goes in/out through a BNC connector, DC is applied, one listens to audio on a speaker or headphone, and "talks" with a microphone or an attached CW key/paddle/bug.  If so-desired, you can even connect it to a computer (or smart phone) and run some "sound card" digital modes like PSK31, RTTY, Olivia, WSPR, DV2 or SSTV if you like via its Line in/Line out jacks. **

The "heart" of this transceiver is the ARM Cortex M4 processor (made by ST) running at something under 200 MHz, a reasonably-powerful device, but not super powerful, which makes for some interesting challenges when one is trying to squeeze in various features - more on that in later posts.

* 160 meters is possible too, with just a bit of "hacking" - maybe just as simple as adding an outboard 160 meter low-pass filter.
** Because it is an SDR it should, in theory, be possible for the mcHF to run some digital modes stand-alone as well, but there is the problem of "too many desired features and too little time"!

Why did I do this?

You might think that I started this project knowing all about SDR and DSP.

You would be wrong.

The reason that I tackled this project was that I DID NOT  know all that much about SDR and DSP.  To be honest, I do have a programming and electronics background (but almost entirely self-taught) and I "knew" how SDR radios and DSP worked at the high level, but I'd really never gotten my hands dirty - so this was my chance to get myself drenched, not just my feet!

Not having worked with the Cortex M4 processor before or the CooCox programming environment, but being familiar with the "C" programming language in general (I've used it for many years in programming PICs and other things) I found Chris' source code to be fairly easy to follow, fairly well documented, and the programming software pretty easy to use and I was soon able compile my own code successfully - so I started adding features.

In the next few posts I'll describe the "behind the scenes" of a few of the features that I added.

* * * * *

Adding features - AGC:

As it happened, just as I got started with this project, Chris had other obligations that diverted his attention for a while, but he was happy to see progress being made:  He did make it open source, after all!

The first major change that I made was the implementation of an AGC in the receiver - something that had been missing from the beginning.

Admittedly, I had no pre-conceived notion as to how to do this in code and I purposely did not look at other open-source implementations, but since I knew exactly how an AGC circuit worked, so I simply wrote some code that emulated the rapid charging of a capacitor in the presence of a signal and the slow discharge in its absence and adjusted the "gain" of the audio path in the process simply by multiplying the "live" audio by the floating point number on-the-fly.

In a nutshell, it works like this.

In a loop, operating on each audio sample:

• Take the absolute value of the pre-AGC, post-filter audio signal.
• Multiply it by the current AGC value.
• If the resulting value is above the AGC "knee" value, reduce the AGC value quickly (e.g. the AGC "attack") by an amount proportional to the current AGC value, but if it is below the AGC "knee" (e.g. the AGC "decay") increase the AGC value comparatively slowly by a proportional amount.   The rate of the "decay" is the AGC "hang" time.
• Enforce limits to minimum and maximum AGC values.
• Multiply the audio signal by the AGC value.
• Use the linear AGC value to calculate the logarithmic S-Meter reading.

To my amazement, it actually worked the first time!

Not mentioned above is the fact that a bit of delay is added to the audio path, allowing the AGC correction to be applied "before" the signal was too high:  Doing this "look ahead" properly can completely prevent AGC overshoot when there is a (suddenly) strong signal in the passband.

Signal path gain control:

As often happens, tweaking the software leads to tweaking the hardware - which leads back to more tweaking the software.  Originally there had been an N-channel JFET across the RF signal path ("Q2" on the RF board) to provide a manual attenuation control.  The problem was that, due to an oversight it was not possible to completely bias this JFET to an OFF state as there was no way to apply a negative gate bias, so it was always causing a bit of signal attenuation (typically 6 dB) even when the attenuation control (and gate voltage) was set to "zero."

I'd also noticed that, while tuning around the bands, particularly 40 and 80, that some strong signals would cause terrible distortion so I put the transceiver on my service monitor and observed that its receiver would overload badly, with clipping of the A/D converter occurring at around -55dBm!

Ouch!

This transceiver uses a Wolfson WP8371 (which is very similar to the pin-compatible TI TLV320AIC23) which contains both a 16 stereo A/D and D/A converters.  In receive mode, the A/D converter takes the quadrature I and Q channels from the receive mixers and digitizes them, sends them to the MCU (processor) and then the D/A converter produces the receive audio.  In transmit, the A/D converter takes the transmit audio which is processed by the MCU and the I and Q channels are sent out via the D/A converter to the transmit mixers.

Upon inspecting the code I noted that the internal gain control of the codec was set to maximum which made me wonder if I could extend the dynamic range of the receiver with the codec's own gain control.

A bit of quick experimentation showed that by setting the codec gain to minimum the signal overload point of the receiver was raised from about -55dBm to around -19dBm - a significant improvement!

Note:  This "overload" level applied to signals within the A/D passband, +/- 24 kHz of center.  The "overload" level of signals beyond this range is approximately -5 dBm or so, the level at which the mixer, RF amplifiers and operational amplifiers started to compress/clip.  This is possible due to hardware-based "brick-wall" filtering within the codec chip that removes out-of-band signals beyond this +/- 24 kHz range plus the intrinsic low-pass filtering of the signal chain that attenuates signals that are much farther removed than that.

A bit more "hacking" at the code yielded the final result - an additional "AGC" loop wrapped around the main AGC loop:

• The output of the A/D converter is monitored.  If the output exceeds 1/8th full-scale, the codec gain is reduced by one "step" ("several" dB) immediately.  At this same instant other places in the receive signal chain (e.g. audio, S-meter) are rescaled by the same amount to compensate.
• If the output of the A/D converter never exceeds 1/16th full scale for "a little while" the gain is increased by one step.  In other words, when the strong signal(s) disappear, the gain is increased relatively slowly.  A lower threshold is used for the gain increase to add hysteresis and reduce the likelihood of constant "hunting".
• If the output of the A/D converter is higher than 1/4 full scale, the bottom portion of the S-meter scale - which is normally white - is displayed in red to indicate a possible overload condition.  This does not indicate a malfunction, but is mostly for informational purposes and it could be useful if one decides to override the "Automatic" codec gain control and use the "manual" codec gain control instead.
• Internally, the "front end" gain of the codec is tracked and this value is used to compensate, on the fly, those other values that require the input level to always be properly scaled with respect to the RF signal's input level.  Such parameters include the S-meter, spectrum scope/waterfall and the digitized audio from the A/D converter itself.  Where this not done the aforementioned items would "jump" as the codec's gain was adjusted, affecting their operation!

The upshot of the above is that on a "busy" band with strong signals one will occasionally see the bottom portion of the S-meter flash red, but it is extremely rare for the receiver to overload.  Even though reducing the gain of the A/D converter does reduce the ultimate sensitivity of the receiver, in practice this is almost never noticed since, on a very busy band where there are very strong signals, one would probably not "miss" an S-unit or two of sensitivity at the bottom end of sensitivity, anyway!  In other words, we are more prudently using our limited, available dynamic range!

This also meant that by changing the code and taking advantage of the hardware gain control built into the codec, the "iffy" JFET attenuator circuit could be completely eliminated as this new method of "attenuation" was much more effective, anyway!



The next time I write about the mcHF:  Implementing audio filters and fractional I/Q phase adjustments with limited processor horsepower - follow this LINK.

[End]

This page stolen from ka7oei.blogspot.com

Assembling the mcHF transceiver boards - getting ready.

If you remember last time, a few of the parts were still on their way - but since then, all have arrived and I have assembled one set of boards and gotten the transceiver operational.

But I'm getting ahead of myself.

Starting the build:

As noted before, there are 480-ish parts - most of them being 0805-sized surface-mount resistors and capacitors - these being somewhat smaller than grains of rice - so I set about putting together my assembly area by buying a shallow baking pan.

The thing about these tiny parts is that no matter how cheap or expensive they are, they are equally invisible when they fly away accidentally -  or just fall off the board, and even if the part costs less than a cent, if you don't have any more, it will then cost you several dollars to get more of them.  (For the really inexpensive parts, you should just get several times the quantity that you need!)

I lined the bottom of the baking pan with white paper for both electrical and thermal insulation and started putting parts on the UI (User Interface) board.

At this point I should say that having put it together, I learned something that anyone putting one of these together should consider:

A few mistakes - and lessons learned:

Assemble the RF Board FIRST, then assemble the UI board!

The reason for this is quite simple:  There are no really tricky parts on the RF board and by the time you finish it, your SMD soldering skills - whatever state they might have been in when you started - will be much improved - and this will come in handy when you solder the fine-pitched 100 pin microcontroller on that main board to it!


I didn't do that.

In following the recommendation of someone else who'd put one of these together, one of the first things that I'd put on the board was, in fact, the microcontroller.  Although I have soldered a fair amount of SMD before, it had been several months since I'd done it and I was a bit rusty.

Also, when I started soldering the microcontroller, I'd not noticed that the PC board was somewhat warped, probably a result of having been through the post from the UK, and that after I'd finished soldering the pins down a large percentage of them did not actually make contact to their pads because of the warpage!  Had I my wits about me I would have removed the microcontroller, clamped the board down to flatten it and done it again, but I didn't do that:  Instead, I went around, pin-by-pin with an extremely fine-tipped iron and tacked each one down, laboriously checking it and its destination for continuity until I'd finally gotten them all - a process that took over an hour and actually resulted in my ripping one of the pads off and a bit of microsurgery on the board to make the connection.

To reiterate:

1) Build the RF board first to get practice at soldering SMD components
2) Before soldering the microcontoller, clamp the board down to assure that it is perfectly flat!

Additionally, be very careful when handling the microcontroller:  DO NOT handle it by the pins - not because of the static, but because they are very easy to bend and once you bend them, they can be extremely difficult to get back into their required sub-millimeter, precise (in all three axes!) position - so just DON'T BEND THEM!

Figure 1:
The UI (User Interface) board - the side with the MCU on it, before adding the connectors, switches and the connector along the top edge.
You might notice that I installed both U5 and Y1 along with C93 asnd C94 as I wasn't watching what I was doing:  You need only purchase either Y1 or U5 (U5 gives a bit better sample rate accuracy and stability, but Y1 is probably perfectly adequate).   If you use U5, you do not need to get Y1 or C93/C94.
Click on the image for a larger version.

Equipment:

I employed several methods in populating the boards.

The first thing that I did was to wash the boards in soap and water, scrubbing fairly vigorously then patting them dry, followed by wiping them down with denatured alcohol to remove adhesive tape residue from the packing and residual oils - followed by another wash with soap and water and a good rinse and dry.

For soldering equipment, I would recommend, at a very minimum,  the following:

1. A TEMPERATURE-CONTROLLED iron.  The iron should have a closed-loop feedback in it to maintain a constant temperature and not merely a dial to make it hotter or colder.  DO NOT attempt to solder this sort of thing if your iron does not have the ability to maintain its temperature to within 10 degrees C (about 20 degrees F) or so of its setpoint or you can damage the board.  Such irons are pretty cheap and plentiful these days so there's really no excuse for not having one if you are building these sorts of projects!
2. A TEMPERATURE-CONTROLLED iron.  This is so important that I thought that I'd say it twice!
3. A really fine tip for your soldering iron.  This tip should be almost needle-thin at its point - and that is no exaggeration!  This tip would not be used for soldering many of the larger components - for that you would be using just a "small" tip:  You would change to this really fine tip when you need to do a bit of re-work, such as tack down a single pin (or two) that didn't flow properly, or use it to "wick up" a bit of solder that might have bridged some pins.
4. Fine (small) solder braid.  This is the small, thin solder braid (the trade name being "Solder Wick") that is roughly 2.5mm (1/8") or so wide or smaller.  It really needs to be this small in order to fit between pins of SMD devices to suck up extra solder.
5. Small-diameter solder.  This would be the solder that is anywhere from the diameter of a hair to the diameter of #24 AWG wire.  In the U.S. you can still get the 60/40 or 63/37 Tin/Lead solder - which melts at a lower temperature and has better longevity and chemical stability - but good-quality lead-free solder will also work.  If you do not use rosin core solder, read the instructions with the solder carefully as some of the "organic" fluxes MUST be immediately washed off after soldering to prevent electrically conductive residue and/or corrosion from occurring!
6. Good-quality tweezers.  I have both metal and bamboo tweezers that are helpful for both picking up parts and holding them down during soldering.  The bamboo tweezers, bought for less than $1.00 on EvilBay (including shipping), are nice in that they are insulating both electrically and heat-wise, the latter making it easier to solder down parts.  Flat toothpicks also work very nicely for holding down components for soldering.
7. Magnifiers!  Unless you have extraordinarily good close-up vision, you will want some good magnifiers.  These can be in the form of very strong glasses or binocular goggles - some of which have extra flip-down lenses to change magnification - for hands-free use as well as jeweler's loupes and strong magnifying glasses for extreme close-up examination of solder joints and circuit board traces.
8. Volt-Ohm Meter.  An absolute must for troubleshooting, measuring voltages and resistance to determine if something is amiss.  It need not be fancy, but a cheap, $5 digital meter is probably better than a $10 automotive-type analog meter!

You SHOULD NOT start construction until you have ALL of the items above!

Figure 2:
 One side of the the partially assembled RF board.
Click on the image for a larger version.

A few very nice things to have:

1. Solder Paste.  Using a dispenser - often in a small, hypodermic syringe with a large-ish gauge needle, this contains both paste and flux.  This is applied to the pads and then the part applied into the paste and then heated with hot air - see below.  If you are in the U.S. you can get a small amount (but more than you need for this project) for a reasonable price from Cash Olsen, KD5SSJ.  (Google him for more info, or see the link below.)
2. Hot air rework tool.  These are essentially a miniature heat gun, but with fairly precise temperature control and the ability to be fitted with different tips to heat various areas and shapes.  If you need to remove a multi-pin chip such as the 100 pin microcontroller, this is going to be the ONLY way that you going to be able to do it without damaging either the chip or the board!  This also allows you to solder many components at once if paste has been applied to their pads and then the components applied to them.  These units are not terribly expensive, available for much less than $100 U.S. for a decent one if you look around.  I paid about $90 for one about 10 years ago from Circuit Specialists and they have become cheaper and better since then, with many different types available from both Circuit Specialists, EvilBay and many other places.
3. Flux pen.  This looks like a felt-tip pen, but filled with liquid solder flux.  It is a good idea to apply this to each solder pad on the board to make it easier to solder, making better and more-reliable joints.

 Methods:

There are (literally) hundreds of web pages and YouTube videos on how to solder - specifically, how to do surface-mount soldering, so I won't explain the exact methods - just name them.

 The "dab, place and solder" method:

For the individual, small, passive components such as resistors, capacitors and inductors I generally did the "dab, place and solder" method in which I would apply the solder paste to the pads of 4-8 components, place the components on those pads, and then, with the fine-tipped iron and either a toothpick or the bamboo tweezers, hold the component down while soldering.

When doing this it important to only place 4-8 components at a time because:

• It is best to place the component in paste when it is still "wet" so that it sticks the component to the board better.
• Doing a batch of 4-8 components is more efficient than doing one at a time, but not so many that you are likely to forget where each component that you just place is!

This last point is actually quite important because one tends to place all of the same types of components at a time.  For example, say your project has 25 0.1uF capacitors in it, scattered all over the board:  If you just place 4-8 of them (I would always place 6 components - an easy number to remember) then those 6 components are easier to find, particularly when a lot of components have already been placed on the board and it is getting harder to tell, at a glance, one that is soldered from one that has not been soldered!  By counting exactly 6 each time (or fewer, if you didn't have 6 of whatever it is to solder) you can be sure that you found them all!

After soldering them down, I would then run my finger over the board to discover any "loose" components - that is, ones that were stuck to the board with paste, but not soldered, and hopefully I'd be able to quickly discover where it was supposed to go!

For soldering multi-pin ICs, there are many methods using soldering irons.  Most of these involve tacking a corner pin or two and going from there, sometimes soldering each pin at a time if the pin pitch isn't too small.

One of the more popular methods involves "flooding" the pins with solder, often by dragging the tip across them all to distribute it to all of the connections and then sucking up the excess with solder braid:  You can find web pages and YouTube video describing this "Drag" method in detail.

Of course, if you don't have solder paste, the use of very fine wire solder works fine as well with the appropriate adaptations of the above techniques.

The hot air method:

The above method works well if you are soldering same-value components scattered all over the board, or if you are attaching components with larger pin counts.  If, however, you are able to populate a lot of components in a small area of a board it will be quicker and easier if you were to use the hot-air tool.

In that case, you would apply paste to the pads and then place the components into the paste - this time, for (possibly) many more components.  Then, very gradually, heat up the area with the components until the solder flowed completely.  In this case, with the components concentrated in one small area rather than all over the board, it makes sense to spend the time to bring up the temperature gradually.

One point of concern with the paste - particularly if it is heated too quickly - is that the liquids within it can flash-vaporize and bubble within:  When these bubbles pop, it can cause the part being heated to jump off the board, or at least out of position, requiring you to stop what you are doing and relocate the part.  If you are finding that the parts jump around when you are heating them, you are probably heating them too quickly!

For soldering larger devices such as multi-pin ICs, the typical methods include laying a thin line of solder paste along the line of pads rather than a dot on each pad:  Methods for doing this may be found on many web pages and YouTube, and you can look at the page of Cash Olsen, KD5SSJ - http://www.kd5ssj.com/   (Note:  I have not pecuniary interest in Mr. Olsen's web page or offerings other than I did buy some solder paste from him several years ago and was satified with his product.)

Figure 3:
 The "other" side of the RF board, also partially assembled.
Click on the image for a larger version.

One advantage of having a hot air gun is that even if you do use a soldering iron, if the solder masks were applied properly, reheating components that were previously soldered with an iron will often make them re-align and straighten up and make their joints look more uniform.  It also has the advantage that if you happened to miss soldering a joint to which you'd applied paste, it will now be soldered!


Next time on this topic:  A few pictures and comments on the actual assembly!

[End]

This page stolen from ka7oei.blogspot.com