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

Using the Arduino VFO

I've been playing with the Arduino VFO system, after she made her brief appearance as a blushing debutante in the sumptuous elegance of the Norbreck Castle Hotel. Regular readers will remember the special affection I have for this "magnificent" location.

First experiment was to convert George, g3rjv's classic "Sudden" receiver to digital VFO operation, which was achieved with what HF used to call "laughable ease"...

   

(details of this conversion will be published later).

Readers may recall that I used up some of the free space on the Arduino DDS shield by deriving a pair of quadrature squarewave signals, à la software defined radio, intending to play with Tayloe detectors. Well - yesterday I started to uphold the intention, brewing up a simple circuit with a 74BCT3253 and a 5532 double op-amp...

   

It works quite well, with the Arduino VFO liberating the receiver from the rock-bound limitations of simple SDR receivers, like the Softrock I cut my teeth on back in 2008...

   

 Here's a closer look at the board (where you'll see that I left the Sudden experiment in place)... 

 

RF from the antenna and the pair of quadrature squarewaves from the VFO system enter stage left, after which there's a filter and a transformer (essentially a Balun to convert the unbalanced feed to a balanced input to the detector). Then the 74BCT3253 sits on one of my SOIC - DIL modules, where it switches the RF to generate two signals which, after amplification by an NE5532, form the I and Q input to an SDR program.

I tried Winrad - but then switched to HDSDR.

Here's a screenshot of me listening to m0roa early this afternoon...

 

as you see, I set the "offset" between HDSDR's "local oscillator" and "VFO tuning" at 10kHz and tuned using the rotary encoder on the Arduino VFO, which makes the whole experience feel more like radio!

I changed the display on the Arduino VFO to add the 10kHz offset - so the LCD shows the correct frequency my receiver is "hearing" - even though the DDS is generating a signal of four times this (minus the offset). A vivid demonstration of the flexibility of the Arduino-based VFO.

I also experimented with generating some CAT controls for HDSDR in the Arduino - I can change the VFO tuning, but not the local oscillator setting - ironic, given that the Arduino is generating the LO signal! If anybody knows if CAT control of the LO setting in HDSDR is possible, I'd like to hear from them. OK - after a few more minutes playing around, I found how to set the Tune fixed to 'LO<->Tune-Offset' option - now I have the screen on the computer displaying the same as the VFO's LCD screen (by sending the appropriate CAT command to HDSDR).

All of which reminds me of just how much I dislike software defined radio. Never mind - next Sunday its G-QRP Valve day!

 ...-.- de m0xpd

Arduino VFO

The m0xpd wallet has been dusted off - to the extent that I actually invested in a genuine Arduino (!!!) 

Nothing against the penny-pinching Wotduino^TM - but I need to be able to show true compatibility for some "public appearances" in the future and there's nothing more convincing than hearing the tune played on a genuine Stradivarius fiddle.

As opening application for the kosher Arduino, I rustled up a VFO system - much in the style of the excellent pa0klt VFO I got from Jan at SDR-Kits a few years back.

I took another of my Arduino DDS shields (this time made up with a socket for the DDS module, as I wanted to be able to plug different units in for testing). Then I took my code for driving the DDS module and mixed in some rotary encoder interfacing and some calls to the Arduino LiquidCrystal library to drive a 16*4 LCD.

Here's the finished result...

 Like my Arduino QRP rig, the VFO currently jumps the gaps between the amateur bands - although there's nothing to stop me having a continuously-variable frequency, with no inter-band gaps if I choose. That's the beauty of this approach - it is flexible and entirely configurable. Something other VFOs can't match.

It's also inexpensive - even if you insist on buying a pukka Arduino, you still might get change from £25.

Cheap chips!

...-.- de m0xpd

Arduino Honeymoon Over

After a long and enjoyable honeymoon period with the Wotduino, in which she could do no wrong, I woke up this morning to see her for what she is - warts and all...

The problem was that I had made some modifications to the code (what the Arduino community call the "sketch") for my little QRP Rig and I had committed the ultimate sin - I hadn't saved it!

 

Go ahead - laugh at me. Call me all sorts of names. Tell me I should never do that.

Fact is - any other IDE for a micro-controller I've ever worked with (as far as I can remember) saves the code when it is built. So, naively, I expected Arduino would do the same. The sort of assumption you are likely to make in the first flush of romance!

No sir! Not the Arduino!

Turns out that this is a weakness which trips up many newcomers - a quick search on the net returns reassuring comments like "Lots of people ask this. Quick answer - no." (on the Arduino forum, no less). Fortunately, the quick answer is that its IS possible to recover code that has been uploaded to the Arduino, even when you didn't go through the stone-age step of saving the sketch at the time (or even when you closed the Arduino IDE).

I was put onto the scent by Robert's useful post, which had me searching for a folder of the form "buildxxxxxxxxxx.tmp" and which, in my case turned out to be:

C:\Users\Paul\AppData\Local\Temp\build6490475155612533273.tmp.

You need to remember the (approximate) date at which it was created / modified to find out which is the correct folder.

Then you look for the file with the same name as your sketch and a C++ extension - in this case, the file highlighted...

 

Opening this file (in Notepad, if on a windows machine) will reassure you that you're on the right track...

 

Then, it can simply be copied and pasted back into the Arduino editor window where it belongs...

   

Here I changed the name of the sketch and made damned sure to save it - I won't be going through this fiasco again!

So - there IS a way to rescue all your typing and escape the disappointments and inadequacies of the Arduino "Development Environment". Perhaps she's worth sticking with for a little while longer!

...-.- de m0xpd