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