Plumbing in the Filters

Having made and tested my new I2C-controlled filters, it was time to plumb them into the rig and go multi-band...

I made up some little patch leads from RG58, so I could plug the filters into the sockets that held the plug-in filters. That way - I supposed - I wouldn't need to make any modifications to the rig to incorporate the new filters. I should be so lucky!

 Here is the rig with the new filter boards patched into the signal chain...

On trying the filters, I noticed an immediate problem on 80m. As soon as I pressed the PTT or the key to put the rig in Transmit, the LowPass filter board tripped out - none of the filters was selected and no amount of subsequent band changing (thereby forcing my ATmega328P to send new commands to the MCP23008 IO Expander) would rescue things. I needed to "power cycle" - the new name for turning things off and back on again, for those who prefer to call a spade a personal, horticultural entrenching tool.

This was fixed pretty quickly by adding some more decoupling to the IO Expander chip - I already had 470nF about 2cm from the chip, but another 100nF right near the VDD pin and similar on the collectors of the relay drivers (on the 80m band only) soon cured things.

This fixed the LPF. However, plumbing in the new BPF was causing much greater problems...

Everything worked FB with the rig driving a dummy load. However, when I worked into my antenna system, I was seeing all sorts of problems on the meter on my tuner.

Looking at the signals on the oscilloscope soon identified the problem - the rig was generating out-of-band signals (at LOWER frequency than the intended RF). This was causing the indicated SWR to be very poor (which it was not; the antenna was correctly tuned for the band in question, but NOT for the additional lower-frequency content).

Eventually, I figured that this was caused by some kind of feedback path from the antenna back into the rig - which was sitting there naked on the bench, without shielding its modesty in a nice enclosure. With this differential diagnosis in mind, I set about looking for the source of my woes.

The out-of-band stuff was bad when I spoke into the rig and was strongly triggered by low frequency content in my voice. Conversely, a high frequency whistle seemed to provoke much less out-of-band output. This made me wonder if the feedback was somehow getting into the AF path - but careful investigation and measurement showed it was contained within the final stages of the transmitter.

Eventually, I discovered that things were made very much better if I removed one particular segment of wire on transmit, seen here labelled accordingly...

The offending wire (in fact, a length of coax, some 10cm long) was driven at one end by the PA output during transmit, BUT WAS OPEN CIRCUIT AT THE OTHER END, due to the action of one of the Transmit / receive relays. 

Here's the relevant section of the schematic...

I decided that the quickest path to a solution would be to add another little relay close to the final transistor, in series with the one already there, such that the little piece of wire is automatically removed whenever the rig is in transmit. Here's the plan...

And here's the actual fix on the rig...

Strangest thing of all - I'd been supported and encouraged through some of this fight with the RF feedback by my friend, mentor and collaborator (watch this space!), Pete Juliano, n6qw. Turns out that he's had a VERY similar problem in his build of a BITX20 - which he solved by adding an extra relay too.

Now, the rig works on all four bands, without having to do anything more than drive the menu system on my "VFO". Of course, I still have to adjust my antenna and (of course) the g5rv is still little more than a dummy load on 17m but at least the rig is now genuinely multi-band.

As I admitted before, things are not yet "perfect"; I still see faint traces of the original problem (which TOTALLY disappear when firing into the dummy load) but I'm not going to do any more detective work to improve matters until the rig gets a properly shielded enclosure. It is entirely usable now.

Instead of wasting time chasing perfection, I'm off to explore four different bands at the "flick of a switch"!

...-.- de m0xpd

Farhan's New Transceiver

I'm excited to see that Farhan has used digital RF generation and (Arduino) micro-control in his new rig, the "Minima"...

I particularly like the under-stated name; I'm sure little Minima is going to generate a big noise in our hobby.

Congratulations, Farhan - you've fathered another beautiful child.

 ...-.- de m0xpd

Low- and Band-Pass Filters

I have just completed the new I2C controlled low-pass and band-pass filter boards for my multi-band rig...

Despite my experiments with the MCP23017 last week, I'm using the Mircochip MCP23008 I/O expander to control four filters, one of which is switched into circuit by relays. The switching is controlled by I2C messages from my RF Generator, which is in essence an Arduino.

I have used a common board layout for switching part of the system and inserted band-pass and "harmonic" filter networks, both of which are to standard G-QRP Club recipes...

There are jumpers to set the I2C address of each board - but in use they will share the same address, such that both MCP23008s respond simultaneously to the band-change request. The I2C input (which also supplies 5V power) is at the left of each board, whilst the relays are switched by 12V, supplied by an input on the opposite side. RF enters the boards stage right and leaves on the left.

The boards are only single-sided PCBs, made in my "back-yard PCB fab", so I had to add some additional wiring on the copper side to control the output relays...

In use, the boards will be stacked, in an attempt to save space - it worked for the Tokyo city planners. Here's the intended configuration...

I have built filters for 80,40,20 and 17m - the first three are my favourites on the new rig and the 17m band is an experiment.

The system works FB - but I haven't yet had chance to plumb it into the rig - I've run out of weekend, not helped by spending a couple of pleasant hours at the West Manchester Club's "Red Rose" Winter Rally earlier today, where I didn't do any significant damage to the bank account.

...-.- de m0xpd

Switching Band-Specific Elements

This post describes some initial experiments to add extra GPIO pins to the Arduino using a Microchip GPIO Expander.

My band-specific plug-in modules (as used on my multi-band BITX and Occam's Dagger rigs) are all very well...

But - let's face it - plugging and un-plugging is hardly in the spirit of the rest of the micro-controlled system.

With the Christmas and New Year festivities fading into memory, it is time to get back to the bench and play some games and the idea of switching band-specific functions (like low- and band-pass filtering) had bubbled up to the top of my list. It is a game I've played before - but this time I intend to have the filter board respond to I2C commands, rather than a parallel digital input.

In all my "Arduino" controlled rigs, I've already run out of Input/Output pins - so it was my intention to hang an input/output expander chip on the I2C bus. Whilst there are other devices available, I planned to use the Microchip parts and had ordered an MCP23017 device to play with a few weeks back.

There are good resources on the internet teaching you how to use this part - I used and recommend the excellent tutorial here.

Before I could do anything, I needed to be able to parallel the I2C lines with the LCD module - so I made up a little scrap of stripboard which allows me to hang three devices on the same "bus" (comprised of power, clock and data lines)...

The MCP23017 was plugged into a solderless breadboard, which also housed a single general-purpose NPN transistor (in my case a 2N3904) to switch a little relay. Here's the breadboard...

and here are the DPDT relays I intend to use when I get round to building permanent I2C-switched filter boards...

Coding for the GPIO expansion is very easy (see the tutorial in the link above).

I set up an array of "codes" which I want to write to the GPIO device...

This array will be used to assert one of the GPIO device's outputs for each band - the asserted output will turn on the transistor which will in turn turn on two relays to patch in the intended band-specific filter. One of these transistor / relay combinations was implemented on the breadboard (above) for my experiments.

My software (both for the "Occam's Dagger" CW rig and the subsequent BITX SSB rig) has an integer variable describing which band is in use - so this variable is used to index into the BandSwitch array to choose the appropriate code for the GPIO device. However, before the device can be used, it must first be initialised...

The GPIO device has three hardware address pins, which are tied to 0 or 5V to set the I2C address. My LCD is already on address 0x20 - so I had to select something different. Setting all three address lines high gives an address of 0x27 (you can learn about this in the tutorial if you're not au fait with I2C). With the address defined, initialisation is simplicity itself...

You use the Arduino "Wire" library to talk to the GPIO expander. You need first to specify if the ports are to be used as inputs or outputs - in our case they'll be outputs. I am only going to use up to 8 bits but in the following code, I set all 16 of the available pins on the MCP23017 as outputs.

This "initialisation" code should appear in the "setup" phase of the Arduino sketch - in my case I added it at the very end of "setup"

The code also sets the GPIO outputs to that appropriate for the initial band - in my code the band in use is described by the value of MenuOption[3], so BandSwitch[MenuOption[3]] is the code relevant to the starting band.

Subsequently, whenever the band is changed (i.e. when MenuOption[3] changes value), the following code should be called...

This can be added into the code that runs as a specific action on leaving menu mode after a band change.

Here's the whole shebang on the bench...

I found that one relay coil draws 18mA from the 12V supply - so I anticipate that the power consumption of the whole rig will go up by around 60mA when the bandswitching is fully automated.

Here's a schematic illustrating the "spirit" of my experiment - it uses an MCP23008 rather than the MCP23017, but that's what I plan to use eventually.

Now to design some filter boards.

.... -. -.-- de m0xpd

Hats off to China

As western science and ambition rests on its laurels / falls behind / looks on in in envy, China today successfully landed its "Chang'e 3" probe on the moon.

The image above is from the downward-facing camera on Chang'e 3, as distributed within China.org.cn's coverage.

Congratulations and kudos to The People's Republic - I, for one, am impressed!

...-.- de m0xpd

R(F)duino

I mentioned in an earlier post it was my intention that - "eventually - I'll be moving to just an AVR microcontroller on a board with the DDS modules".

Well - it is accomplished...

You see above the new board on the bench, with the familiar tuning knob and display, running my "double DDS RF Generator" code for my multi-band BITX rig.

I've called the new board the R(F)duino for obvious (but still inexcusable) reasons. It uses a simple single-sided PCB...

on which is hosted an ATmega328P and the two DDS modules.

I have set up the system so that it can run the Arduino bootloader and appear to the Arduino IDE as a UNO board, via a serial interface. I've also added an ISP interface, so that more advanced users can program directly from (e.g.) Atmel Studio, via an AVRISP II or a JTAGICE 3 (or any other AVR ISP programmer).

There's also an explicit I2C interface. At the moment, this drives only the LCD display - but I have plans for hanging more sub-systems off the I2C bus.

The programming and I2C interfaces and other features are seen in the following image...

There's lots of I/O, which can be re-configured by programming, but is arranged with my own tuning and control scheme in mind. It also supports some of my ideas for CW, including an iambic keyer.

The system was set up in "Arduino" mode, through the serial port...

I use a USB to serial adapter from 4tronix which has the very considerable advantage that it has been modified for use with "Arduino clones" by the addition of a 0.1uF capacitor from the "modem's" DTR line to the RST pin. Plug 'n play!

All this is going to be (or, at least, lead to) an open-source project, with code and hardware designs available for download (and - perhaps - with hardware available for purchase). It will take a little time so - please - be patient!

For the moment, I'm back to some more experiments operating voice and CW on my new rig with its even newer Digital RF Generation scheme running on the "R(F)duino".

...-.- de m0xpd

CW on the BITX

Having a microcontroller sit there controlling the DDS modules that make all the RF signals required for my BITX-inspired SSB rig tempts me to do more than just SSB - so today I tried some CW with great success...

I added straight key and iambic paddle inputs to the controlling Arduino and modified the code to read them (actually using software resources I'd developed on the "Occam's Microcontroller" project). When any key is pressed, the system generates a 600Hz signal for the CW and generates a logic output to key the transmitter (regular readers may recall I added a TTL input to my power switching scheme for just this purpose).

The key signal is controlled by a "QSK" timer, triggered by the operation of any of the morse key inputs. The 600Hz tone is generated using the Arduino's internal "tone( )" function - which makes an ugly 5V square wave - so I needed to build a filter to make it a closer approximation of a sinewave.

I first tried some simple passive filters - but these weren't up to the job - so I ended up making a second order filter with a couple of integrators and setting the whole thing up as a bandpass with a centre frerquency of 600 Hz and a Q of about 10. 

You can see (most of) the experimental set up smeared over the bench...

I ran the code on an Arduino MEGA for testing - the majority of the rig is still under the control of the ATMEGA328 in the RF Generator, with the MEGA generating the CW signals (as well as controlling "imaginary" DDS modules and interfacing to a real LCD and rotary encoder, visible in the photo above). It will eventually all run on the single chip (when I get round to re-programming it).

The low-pass filter that files the rough edges off the square wave is seen in close-up below...

It is implemented on a quad op-amp from the junk box (a TL074) and I'll be pleased to publish the schematic when I finalize it on something more permanent than the solderless breadboard.

Even though the system was in a terrible mess all over the bench, I couldn't resist having a shout - you know how it is!

I sat on 40m for a few minutes and couldn't understand why Win, dj2od, wouldn't come back to my answers to his CQ. Then it dawned on me - my rig was in LSB mode (as befits SSB voice on 40m). [On reflection, I see that this is immaterial - the far end wouldn't know / care if I was operating in upper or lower sideband]. I switched to 20m (and USB) and answered a CQ from George, kz1h.

He came straight back and gave my 4 Watts a 579 from near Boston (!!!) but he also told me that there was RF feeding back into my keying, such that I was sending a "carrier" as well as my CW. He could copy the CW well enough - but obviously it was no fun on the receiving end, so we said our goodbyes.

After the QSO, I looked at the meter on my Made From Junk "Deluxe" Versa Tuner and, sure enough, there was indicated power being radiated all the time.

A capacitor on the straight key input soon sorted that and I was back in action...

I answered Lars' CQ from his station oh6kd, near Vaasa. He gave me 599(!) and said "v nice sigs" before I'd even told him the rig was H/B (much less in a completely jury-rigged, experimental lash-up state).

I am delighted with the performance of this system which is (I argue) made all-the-more versatile by the presence of micro-control. All I need to do now is add a little more flexibility to the code (with an explicit CW mode), add in some niceties like sidetone, put all the code in the one little ATmega processor and neaten up the whole shebang - at least to the point where I'm not dogged by unwanted RF coupling!

...-.- de m0xpd