Last week's fun and games with an
Arduino Software-Defined Receiver were just initial feasibility studies - stretching exercises before the competition began. Here's the real deal...
Sure, it looks the same. But things have changed - significantly.
Last week's system was a direct implementation of a conventional superhet receiver - only with everything from IF to AF output implemented in DSP on the
Arduino DUE.
Superhets are great - but they have a known problem - the "
image frequency". The image frequency is that point on the spectrum twice the BFO frequency away from the frequency to which we intend to tune the radio. If there happens to be a strong station at the image frequency it will mask anything at the intended frequency - it is, in effect, a noise source. Usually, in modern receivers, the BFO will be at a few MHz and the image is a long way out-of-band. Its influence can be avoided by filtering.
However, software-defined-radios have a very low BFO frequency - in the kHz range. This means that the image is in band and entirely audible. It is so close to the intended frequency that conventional filtering cannot block it. Something fancy needs to be done...
My new SDR implementaton may look similar to the old one on the bench - but a close-up reveals a different front-end...
Now, instead of using one of the sine wave outputs from the
Kanga/m0xpd DDS Shield sitting on top of the Arduino MEGA at stage right, I'm using the pair of quadrature square waves. Despite the tuning indicated on the LCD, these square waves are at a frequency of four times that of the conventional VFO. The addition of IF offset and the four times multiplication is achieved in the controlling MEGA with some trivial changes to the
standard VFO code you've seen so many times before.
The square waves make their way down the plaited wires to a 74CBT3253 multiplexer, running as a Tayloe detector, which
you've seen before. This mixes the RF from the antenna, after it passes the same
40m bandpass used last week, to produce TWO intermediate frequency signals which are in quadrature relationship (meaning that one is 90 degrees of phase away from the other). This is important - it gives us some extra information about the one incoming RF signal, which will allow us (in software) to discriminate between upper and lower sidebands. The intended and image frequencies are - in one sense - the "upper and lower sidebands" and this ability to discriminate between them will allow us to reject the image from our receiver's output.
The two IF signals pass through amplification and filtering which must be as closely matched as possible - we want our two IFs to differ ONLY in phase and any difference in the front end responses would spoil this. The IF processing happens in the same TL074 quad op-amp as was used last week - but (since we have two IF signals) the circuit has changed considerably.
There is now 40 dB of gain in a first stage and the anti-aliasing filter has now been reduced to 3rd order (
as it is only implemented in one stage) PLUS it provides a further 40 dB of gain.
The in-phase ("I") and quadrature ("Q") IF signals are sampled by two inputs to the Adruino DUE's analog multiplexer. I am using the analog to digital converter of the Arduino in standard gain setting, so I need analog input signals of order Volts - that's why I needed the 80 dB of gain.
Once inside the Arduino, the signals are filtered by the intended RF response (a bandpass, with bandwidth appropriate to the mode and centre frequency above or below the BFO, as appropriate to the sideband). The filters for each channel have the same magnitude response, but one is "shifted" by the "
Hilbert Transform" response, which advances the phase by 90 degrees for positive frequencies and retards it by 90 degrees for negative frequencies (
if the idea of "negative frequency" is new to you don't worry - it is part of the baggage of Digital Signal Processing). All this fancy filter design is achieved inside the Arduino.
Adding the two filtered IF signals rejects the image frequency (subtracting one from the other would keep the image and reject the "intended frequency"). This is the method employed in a "phasing receiver" - only I'm using it just for image rejection - a phasing receiver might use it to select between LSB and USB mode (
which my new SDR receiver is still doing using the conventional method).
All this processing is done in the frequency domain, with 1024-point FFTs, so a further inverse Fourier Transform is required to get back to the time domain - still at IF.
Mixing down to baseband is then implemented in the usual way - with upper or lower sideband selected by the design of our IF filter relative to the "BFO".
It works - boy, does it work!
Along the way, I'm ashamed to tell you that I killed an innocent 74CBT3253. It was mounted on one of my
SOIC Carriers, like this one...
(the photo above is of a different chip - a digital potentiometer).
Fortunately I had some spares - not just of the 74CBT3253 (thanks Dennis) but also of my carrier PCB. Unfortunately, my eyesight has been defective since birth and is deteriorating as I mature! But I'd seen how the big boys do hand re-working of invisible surface mount components under fancy microscopes costing thousands of pounds. So...
A few weeks back, I got a USB microscope for pennies (well, a thousand and some pennies) on eBay. Here it is, set up to solder the new 74CBT3253 onto the carrier PCB...
I hold the PCB down with a couple of blobs of BluTack - but the chip itself is pretty much invisible in the photo above - which is just what I (don't) see when sat at the bench. However, if I look up, I see all the action in close-up on the screen - here's the chip during soldering...
Brilliant ! Even I can see that! If you have to play with SMD components and have less-than-perfect vision, get yourself a cheap USB microscope - they work a treat!
Over the next few weeks, I shall be moving the VFO and its user interface from the MEGA onto the DUE, using the few spare cycles the DUE has in between its hefty DSP tasks. I know it will fit - but if it doesn't, I've already got the core code running on an
STM32F407 device which clocks at twice the speed of the SAM3X on the DUE and is a fancier processor (an AMR M4 rather than an M3), so if things get too tight I have a fall-back position.
I'll also be thinking about generating rather than just consuming RF - this is going to be a transceiver!
...-.- de m0xpd
