Phone !

After the frustrations of getting an analog oscillator under the closed-loop control of an Arduino, I had promised myself a rest. I decided a change would be just as good - so I took what is (for me) a very radical step. I thought about trying phone operation, rather than the habitual CW. Who says you can't teach an old dog new tricks?

The first challenge was finding a mic - such things have no place in the m0xpd shack! I ended up stealing one from the little FM bug transmitter I made (but NEVER operated - honestly Mr OFCOM) from Harry, SM0VPO's design back in the mists of time.

I decided that my restful change would see me revert to the comfort and convenience of DDS - so I planned a DSB transceiver using most of the bits already on the bench. I needed a pre-amplifier and modulator for my voice, so cooked up the following scheme, taking inspiration from the Wee Willy (amongst other sources)...

 

I found that too much Tx power was being wasted on low frequency content, so I added the 2nd order high-pass filter stage on the input. The output drives the ugly Sudden Tx, reported last week. For the receive side, I could have used the previous Rx stage, but decided to knock up a new SA612/LM386 combination, with oscillator input (to pin 6 of the 612) directly from the DDS.

The remainder of the expanded AF system from last week was still useful - so I made a common interface and just plugged 'n played! Rx/Tx switching is handled by a push-button DPDT switch, which operates the Tx "key" line and the Rx mute, as appropriate.

Here's the whole shooting match on the bench...

As you see, I didn't use the Arduino-based VFO (as its components were still hooked up to the Arduino-controlled Colpitts), using instead the pa0klt (Si570 based-) system from SDR-Kits...

I listened to the goings-on on 40m this morning with some trepidation; band conditions were reported as good by lots of ops with 400W to play with. How would my 1 Watt sneak past the big guns?

I needn't have worried - I answered the CQ from Chorley and District ARS' special event station mx0isn, operating the "Bunkers on the Air" event from Brinscall, in memory of the D-Day landings. Operator Dillon (m0ykb) made some generous remarks about my signal and gave me five and seven. Great!

 m0xpd operating phone - whatever next?
 ...-.- de "mike zero x-ray papa delta"

Arduino Controlled Colpitts Oscillator

A recent post closed in something of a "cliff-hanger" ...

"This puts me in the interesting position of being able to "close the loop" and making an automatic controller to regulate the frequency to a desired value."

Well - now I've scrambled over the top of the cliff to safety - although it certainly was a struggle.

I have assembled not only the SA612-based oscillator you've seen before, but a complete receiver and transmitter combination which - one day soon - will be a(nother) QRP rig. The Rx and Tx are improvisations on a theme established by George, g3rjv's famous "Sudden" designs, available in kit form through G-QRP sales.

The receiver section differs most strongly from the stock "Sudden" - partly because it hosts the VFO and partly because I've modified the AF section. With all due respect, I don't like the "wide open" audio response of the Sudden - so I've added a more complex audio-frequency path, including the ability to use my CW Filter. The Tx is in closer-to-stock condition, although it now is driven by the VFO in the receiver. 

Here's the whole shooting match on the bench...

 

The cliff-hanger suggestion of closed-loop control was of interest not only as a means to regulate the oscillator (so as to bring it near to the level of stability now so easily available from DDS oscillators). Also - and, perhaps, more importantly - I was interested in the controller idea in order to simplify the "calibration" of the oscillator. If I were able to run it in a closed-loop configuration, I wouldn't need to figure out what voltage to apply to my varicap tuning diode - it could figure it out for itself!

I measured the frequency output of the oscillator across the entire control range of my D-A converter, with the following encouraging result...

 

The frequency is seen to be almost a linear function of control voltage - in fact, a close-to-least-square linear fit (as shown by the dashed red line in the graph above) has equation of the form "y=mx+c" you'll remember from school...

 

I said "close-to-least-square" because it is an approximation I made by "squinting" at the data and finding a nice simple integer value for the "gradient" term, m=14. This will become important for us later when I add RiT (receive incremental tuning).

You'll see that I cover the entire 40m band (except for that "phone" stuff of which I've heard rumors somewhere above 7.040 HI HI). This isn't luck - rather it is the outcome of careful selection of the range of control voltages supplied to the varicap diode (which, in the present system, is just a Zener).

I now have arranged one of the channels of my (MCP4922) digital-to-analog converter to serve as reference voltage generator for the other channel, so I can "scale" the output voltage range to a fraction of the original 0 to 5V. 

Here's the schematic...

I'm currently using a value of 1000 as the channel B "reference value", such that the channel A reference voltage (supplied by the channel B output - see the red link in the schematic) is a little under a quarter of the 5V supply rail - my control voltages for the varicap run from zero to 1.22 volts.

The "encouragement" of the almost linear mapping between DAC arises from the fact that - for any desired frequency we would like the oscillator to produce - the squared deviation between that desired frequency and the oscillator frequency (the "squared frequency error") is a quadratic function of the DAC Code. This is shown for our "favourite" frequency of 7.030 MHz in the following graph...

As before, the dashed red line shows the result associated with my linear fit - which, when squared, gives a perfect quadratic. The blue line is real data from the oscillator - almost quadratic.

You may well wonder what is so good about a quadratic error function.

It turns out that it is easy to find the lowest value of squared frequency error (i.e. to find the DAC Code which gives the correct frequency) in the presence of this quadratic form, using simple "gradient search" methods.

Think of the shape above as a cross-section through a valley. All we need to do to find the bottom is walk downhill (as all those energetic SOTA and WOTA enthusiasts will know). For the quadratic, the gradient is a linear function of the DAC Code so, to "walk downhill" all we do is subtract an amount from the value of the DAC Code proportional to the frequency error.

We subtract to walk downhill.

Here's the code required on the Arduino to implement this "gradient search"...

 

It is - as you see - easy. The only trick is that we have to scale our updates appropriately (otherwise we'll run downhill, not be able to stop at the bottom and keep going up the other side). The parameter "alpha" in the code segment above currently has value 0.07 in my code, giving a nice compromise between update speed and no tendency to "run up the opposite side" (under-damping).

If we ask the system to "search" for a frequency outside the available range or choose too large a value for alpha, in which case we run all the way up the opposite side into the next valley (instability), the code will try to push the DAC Code value outside the 12-bit limits available on the MCP4922. To prevent this, the "constrain" function in the code above keeps the DAC fed with meaningful numbers (although it would already be a failure at this point, so the error trap is somewhat futile).

The whole Arduino-controlled Colpitts oscillator works rather well.

It has been working well with the receiver for a couple of weeks now - but when I added the Tx last weekend, all hell broke loose.

I began to wonder if it would have been better just to let go of my tenuous grip on the cliff on which we were hanging and fall to a merciful release. But I soldiered on and - this morning - finally prevailed.

I had found, you see, that the act of transmitting pulled my VFO way out-of-tune. I started the remedial treatments by putting the VFO and receiver (along with the DAC and a buffer amp) inside a metal enclosure (seen more clearly in the bench shot when the enclosure lid is on)...

 

This presented the challenge of how to make the myriad connections to my ugly development boards (preferably without opening the notoriously empty m0xpd wallet). I came up with a solution of which I'm quite proud...

A simple 3mm slot, cut in the appropriate place on the "end" of the enclosure with a slot drill in my "trusty rusty" milling machine, allows the 0.1 inch sockets already used to hook up to the boards, to protrude to the outside world for onward connections...

   

That improved things - but I still had to spend too many hours of my precious leisure time clinging to the perilous cliff, working through all sorts of boring ground and coupling issues. Eventually, early this morning, it paid off...

Now I have less than 10Hz "glitches" in the VFO output when keying the Tx and a transceiver which - unlike the Sudden - is freed from the rock-bound fetters of VXO operation. I swell with pride - but the sense of achievement is tempered by knowledge that it is SO MUCH EASIER using the DDS.

Now I need to sort out RiT before I can try for a QSO, but I'm going to take a break first - I'm exhausted from all that cliff-hanging.

...-.- de m0xpd

Octals and Octuples

Younger readers will be amused to hear that bits once were so precious that we did't group them profligately in fours. Rather, we arranged them sparingly in threes.

The four-bit groups conveniently were abbreviated into hexadecimal numbers, now widely used in computing. The three-bit groups didn't require counting to use the rather unnatural "numbers" A : F evoked in hexadecimal, as three binary digits could simply be written in base 8, using the familiar symbols 0 : 7. We called that numerical system "octal".

Way back then, computers were often using word lengths and internal architectures which were multiples of three - so the base 8 octal system was great. Today, our digital machines usually are built around parallel groups of bits of length divisible by four and NOT by three - so octal has fallen into a dusty corner of the dictionary. Pity.

All this talk of 8 arises because I have just made what the world calls an "octal" bi-directional level converter, extending my earlier "quad" level converter (as was mentioned here). The world shouldn't call it this - it should call it an "octuple level converter", but we all know how dumb the world is!

For those wishing to brush up on the correct names of things, take a look here. 

Enough pedantry - let's look at the new gadget.

It is built as an n-tuple extension (pedant !) of the circuit originally used in the development of my Si570 DDS module . I previously had made up a plug-in module (regular readers know I have a passion for these) hosting quadruple converters but there are times when four simply isn't enough. [There is nothing to forgive when the world calls this a "quad converter", as "quad" is an abbreviation of "quadruple" - not a misunderstanding of "quartal". Pedant !]

 Here's the copper layout, for a single-sided, homebrewed, octuple converter...

 

The two lines of 0.1 inch pitch pins are 0.6 inches apart (making the plug-in module like a "wide" DIP) but the overall board width isn't nearly as attractive as the commercial equivalents of this device, due to the constraints imposed by my clumsy, single-sided PCB. That's the price you have to pay for being a cheapskate! (Note, if you followed that "commercial equivalents" link, that Lady Ada doesn't fall into the "octal" misnomer trap, staying safe with "8-channel".) 

Here's the finished module, along with its quadruple smaller sibling...

 

You might be able to see from the photo above that my new octuple module is less than twice the "length" of the quad, which is why I made the 8-channel version. I've already made three quads (hard for me to say as the father of twin daughters), but they're wasteful of breadboard area (the modules - not the twins!). The new octuple squeezes more into less.

Note also there are a couple of unpopulated boards lurking in the background, waiting for the next time I feel strong enough to engage in some microscopic work. That work has been greatly eased by the purchase of some Xcelite 412 "anti-tweezers" (as Tom and I call them), which give me some chance of holding the tiny devices for long enough to solder them in place. Get yourself a pair - they work well.

The imminent arrival of new spectacles (currently being made up at the opticians) might even allow me to see the objects I'm trying to solder too!

 ...-.- de m0xpd

VFO Pulls No More!

My troubles with the SA602/612-based VFO are over - now she is completely oblivious to large signals, keeping on oscillating at just the same rate as when tickled by weak signals or nothing at all!

The "fix" was motivated by various correspondents (particularly members of the G-QRP Yahoo Group) who pointed to the varicap diode as the most likely origin of my problems. I tried replacing it with a conventional capacitor and - sure enough - the "pull" was gone.

Now - there's nothing intrinsically wrong with varactor / varicap diodes; they have been seen to work as tuning capacitors in many radios before. What was wrong with my experiment turned out to be the physical separation between the diode, the (trimmer) potentiometer used to derive its tuning "bias" voltage and the regulated power supply providing the input to this voltage divider, as seen in the photo below...

I tried generating the control voltage local to the varactor and - sure enough - the oscillator was as solid as when controlled by the "real" capacitor.

I don't know exactly what was causing the problem when the control voltage was remotely generated - John, g8ozh, had suggested ground impedance problems and I'm inclined to agree with his explanation. Whatever the precise cause, I now had a resolution of the issue, which prompted me to modify the ugly circuit close to the tank, adding a socket into which I could plug various capacitors and their tuning means, close to the coil. I also provided a local voltage regulator...

   

With this simple interface socket I could confirm the stability of a "pukka" trimmer and the viability of a locally-controlled varactor. I could also move in my intended direction, adding a digital-to-analog converter to achieve digital control of the oscillator...

The most "complex" of the tuning plug-ins includes an MCP922 12-bit DAC, which is controlled over a serial interface. You can see the whole shebang in action on the bench...

 

The Arduino seen above is running code to generate d.c. voltages on the MCP4922, used as control voltages for the varactor, in response to my inputs on a rotary encoder. I also took the opportunity to add a frequency counter to monitor the oscillator, using the Frequency Counter library provided by Martin Nawrath (whose excellent FFT library I have also used). This allows direct monitoring of the oscillator on 40m (higher bands will need a divider / pre-scaler to operate correctly).

The LCD screen now displays not only the varicap control voltage but also the resulting frequency...

This puts me in the interesting position of being able to "close the loop" and making an automatic controller to regulate the frequency to a desired value.

Can I be bothered - or will I remain seduced by the simplicity of the DDS ?

...-.- de m0xpd

VFO Pull

Now here's a pretty problem. Actually, it has been a living nightmare, spoiling my "playtime" these past few weekends!

Having been in raptures over the elegance and efficiency of the DDS synth module recently, I decided that I ought to investigate alternatives. Both for the sake of "balance" and to demonstrate (not least to myself) that I'm no one-trick pony.

The alternative means of frequency-generation was to be a simple VFO of the sort that can be implemented on the near-ubiquitous SA602/612.

I took as my starting point George, g3rjv's "Sudden" direct-conversion receiver, made for 40m.

Now - before we go any further - let me be careful to explain that none of what follows is, in any sense, a criticism of the Sudden, the SA602/612, or anything else. It is just a story about my self-education and recreation.

Here's my (very) ugly experimental system...

   

It is a fairly conventional embodiment of the "Sudden" - with the only exception being the fact that it is tuned using an MVAM109, ultimately to be controlled by a DAC (as described in this earlier post) but here controlled by a stable d.c. source. Not seen in the photo above is the input RF network (more of which later).

I was surprised (/shocked / intrigued / startled / depressed - call it what you will) by an unexpected aspect of the performance of the system, which has become the subject of the "living nightmare" I refer to above. The receiver was found to "chirp" very badly on receiving strong signals - CW, of course (I have heard rumor there are other modes).

Some investigation with my old Racal-Dana Universal Counter Timer revealed that the VFO was being pulled by such strong signals. I didn't expect that!

I contacted George, who told me that he had "not heard of VFO pulling as a common problem" - and suggested that "The best route is probably the input attenuator".

A quick experiment confirmed that reducing the signal level did indeed stop the pulling - but I wanted to try to understand what was causing this unexpected behaviour - partly because I believe it must be one of the limitations on such a receiver's ultimate performance in dealing with weak signals on an overcrowded band, where consideration for not treading on the dainty toes of QRP signals isn't at the top of everybody's agenda.

I made a few experiments and arrived at what remains (for me) a rather surprising conclusion.

I started with a "vanilla" Sudden...

This system displayed the "chirp" on receiving strong signals and acted as a reference.

Next, I started to wonder what might be the mechanism behind disturbance of the VFO's action. The first thing I tried was to produce a stabilized power supply for the mixer / oscillator - as has been done with the "Sudden 2"...

 

This made no significant difference - so I sought to increase the decoupling between the oscillator and the remainder of the receiver as much as possible.

To achieve this, I buffered and amplified the oscillator signal (derived from the unused winding on the transformer, the other side of which was used as the oscillator coil) using my popcorn buffer module and used this to drive a second SA612, working only as mixer...

 

 In this test, I also used a second LM386, distant from the SA612 used as oscillator, as seen in this photo...

This functional separation of oscillator and mixer between two SA612s and the physical separation between the oscillator '612 and the LM386 also persuaded me that the ability of strong input signals to pull the VFO - STILL PRESENT IN THIS TEST - was not caused by consequences of the "layout" of my circuit. I was baffled.

At this point, I speculated that there might be some coupling between the RF and AF stages - perhaps caused by the rather long speaker leads. So I replaced the speaker and its long lead with a 15 Ohm resistor, right on the LM386 output - with no change - the VFO was still pulled.

The system was being powered by a nice old Farnell linear power supply, with a big analog meter to monitor output current. I could see that the current increased (from around 50 to 55 mA) on receiving a large signal. I disconnected the loudspeaker (such that there was no increase in current - the additional current was all associated with driving the audio frequency load) AND THE VFO PULL DISAPPEARED!

The same - not surprisingly - was true if I powered down the LM386.

This really was odd - I could not measure ANY change in power supply conditions at the oscillator - the voltage was constant to better than 100 microvolts (i.e. better than one part in 50000), given the locally regulated 5V supply.

Then I tried provoking the same outcome (a change in VFO frequency) by changing not the input signal - but the AF signal. Previously, the increase in the AF power was caused by an associated increase in RF signal. Now, I tried driving the LM386 input with an AF signal, to dissipate the same AF power in the speaker.

I COULD GENERATE THE VFO PULL !!!

I have no idea how/why this is happening - there is no measurable change at the oscillator's local power supply. It is driven by the same RF input. It is loaded by the same load impedance presented by a (powered but unloaded) LM386 - but it is still pulled when I apply AF from a separate signal source to the input of the other LM386.

[Note: whilst ordinary linear concepts like correlation and coherence don't have any meaning in the context of the non-linear operation of "mixing", bear in mind that the AF oscillator is independent of the SA612 oscillator and any RF going into it {I hope!}]

So - a living nightmare. The sense that reason is power-less. The frustration and futility of banging one's head against a hard object for too long.

All I can hope to do is present some evidence, in a form capable of independent verification (by YOU) and hope that you'll be able to shake me out of my bad dream. Here's the evidence...

I'll set up the vanilla Sudden once again - but with a 50 Ohm attenuator on the input, rather than the stock 10k potentiometer (we're trying to deal with too many variables already here - I don't want the potentiometer changing the source impedance of the RF).

Here's my input arrangement - signals derived from the Norcal S9 Generator (or, rather, my "sincerest form of flattery" version), going through a switchable attenuator...

 

We'll tune the receiver and switch the input through 20dB - first with the speaker loading the LM386, as per normal use. The audio is monitored on Spectran...

 

You can see where I switch the level. You can see the consequence of the change (the VFO frequency goes DOWN with increasing signal amplitude). The frequency change is about 30Hz, which assuming a reference of 650Hz, is a ratio of 4.6% which, for the musically literate amongst you, is close to a semitone (2^(1/12) is approximately 5.9%). In more extreme cases, I have observed frequency pulls exceeding 90Hz (greater than a whole-tone).

 Now, if we disconnect the speaker (leaving only the fairly high-Z load from direct connection to the computer soundcard) and make the same test...

 

Sure, the charming analog VFO is doing its wonderful slow "drift" thing - but it is completely agnostic to input level.

So - tell me - what does your Sudden do when you've got the input attenuator set too high?

Of course it distorts - but does its VFO get dragged around too? 

I'd like to know - but I'd LOVE to understand WHY!

 ...-.- de m0xpd

Post Scriptum:

In the course of the above, I started to use the 10mm "Toko 10k replacement" coils produced by Spectrum Communications and available (to members) from the G-QRP club.

I couldn't find these as an Eagle part - so I built one from scratch.

This allowed me to make up a PCB for a generic band-pass filter (see George's recipe in the current number of SPRAT, vol. 154, p. 25).

Here's one made up for 40m...

I'll be pleased to share the library with anybody that needs it - only Cadsoft still haven't remembered me (despite an email request sent over a week ago), so I can't post on the official download page (along with my Toroid library for inductors and transformers wound on toroidal cores).

Get in contact directly if you want an early copy of my new "inductor-spectrum.lbr" library.

More Analog and the RBN

In the midst of yesterday's fun-and-games with the VFO, I was trying to engage in the G-QRP valve day with my (replica) Paraset. It was an almost complete failure!

 Unfortunately, I had greater than S8 noise around 3560kHz all day (I'm rock-bound on the Paraset to 3.56MHz or 3.579MHz) and the receiver isn't really usable on 40m in typical conditions.

Still, I plugged away in between playing with coils and SA612s and varactor diodes.

Here's the Paraset, squeezed onto the bench...

 

I didn't hear anything beside the aforementioned noise all day - but I do know that my signal was getting out there - thanks to the brilliant "Reverse Beacon Network"...

 

When I say "getting out there" it was - at least - getting the 287 miles to Brendan, ei6iz. Thanks Brendan!

I've never used the RBN before - but now I'm a convert and I'm sure it will feature heavily in all my working.

I'm fast coming to the conclusion that weekends are a wash-out for radio - and certainly a bad day to operate QRP with the additional handicap of a pre-historic rig! There's much more noise at my QTH on the w/e (presumably due to more electronics being used in residential areas when folk aren't at work). Then - of course - there's all that awful  "_ . ... _" QRM.

I had to give up in the late afternoon to tighten my trousers and QSY my Baritone voice up to Tenor to sing in a SATB context, before enjoying some more Morse in the evening.

All in all, a nice day - albeit a frustrating one.

 ...-.- de m0xpd

Analog Nostalgia

Having sold my soul to the devil (as some would see it) by playing with a digital synthesized VFO (Blogs passim), I decided it would be fun to take a walk down memory lane and look at a traditional (Colpitts) VFO.

I still wanted to keep things under the control of the Arduino (or a similar micro-controller), so I looked at varying the frequency of a conventional SA612-based oscillator using a varicap diode.

Here's my basic scheme, which contains no novelty...

I started by making the oscillator sans varicap and soon was strolling down memory lane and meeting drift, temperature sensitivity and all the other quirks that make analog such fun! I could easily control the frequency of the oscillator by deriving a control voltage from a pot - so I was ready for the next step...

I made a controllable voltage source on the Arduino, using the same LCD display and rotary encoder interface that formed the basis of the simple DDS-based VFO. Instead of controlling a DDS, I now generated "d.c." voltages using PWM methods with the inbuilt "Analog Write" function. This voltage was fed to the control input of the system above.

It wasn't a great success, for two reasons...

Firstly, the analogWrite function accepts an 8-bit argument, giving only 256 different voltages on the output - this isn't really enough to give both range and resolution in a VFO.

Secondly - and more of a show stopper - the PWM signal was very difficult to smooth to a d.c. value, suitable for driving the varicap diode. To try to make things easier, I upped the PWM rate from Arduino's standard, pathetic 490Hz to 32 kHz, to give the low-pass filter more "room" to isolate the non-zero frequency components from the wanted d.c. component. I also experimented with various types of low-pass filter (as shown in the rectangular box in the schematic above) but got bored (especially as the 256 control levels wasn't enough) and jumped ship on PWM. It might be good enough for motor speed applications, but that's about it!

Fortunately, the junk box offered up a 12-bit DAC (a Microchip MCP4922), which has an SPI interface. There is an Arduino SPI library - but it uses pins I had already assigned to my (parallel) Hitachi LCD interface. It was easier to write some bit-banging SPI code to get the MCP4922 putting out REAL d.c. than to re-work the LCD (by pulling out wires and re-assigning pins).

Here's the complete system on the bench...

   

The oscillator is seen at top right, with the control voltage arriving on the white crocodile clip. This is generated by the MCP4922 nestling in the little solderless breadboard, under the control of the Arduino.

The display tells me what's going on - translation between the 12-bit numeric code and the actual voltage is just a linear scaling exercise.

Now, with clean d.c. control voltages, the VFO is running as sweetly with digital input from the Arduino as it did with control voltage derived from a pot. Only there is all the flexibility conferred by the digital system. I could, for example, now make an Arduino-based CW transceiver without the DDS module - with all the frequency offsets and incremental tuning etc under digital control.

I could also wear a hair shirt, become a vegetarian and subject myself to other mortifications.

No thanks - I'm happy with the DDS.

QED

 ...-.- de m0xpd