Tuesday, July 25, 2017

Discreet Transistor Keyer - Part 2 - Refinements.


After building a prototype of the first circuit, I found a few things that weren't very good:  First, the speed and weight pots interacted significantly due to a flaw in my design.  I'll call it a brain fart.  The adjustment range was pretty much unusable as well, and the output waveform was pretty funky.

 Since it kind of worked, I did some further noodling and came up with the tweaks shown in the circuit above.  While I haven't built it in the physical world yet, I've modeled it in LT Spice and it looks pretty good.  The adjustment range for the speed control doesn't go as slowly as I'd like (about 13 WPM), but I seldom send any slower than that anyway, and the mid-scale speed of about 25 WPM suits me just fine. If I find that I need it to go slower, I can always add a "range" switch to add more R or C to the circuit - not a big deal.

With any luck, I'll have time to build this tomorrow and see if it works as designed.  Stay tuned!

Sunday, July 23, 2017

Mini-Project: Discreet Transistor CW Keyer; Part 1


Summertime in SE Michigan is painfully short, so I try to make the most of it while it lasts, reserving my hibernation-in-the-shack time for the seemingly endless winter months.  There are days, though, when the humidity and, here in swamp country, the mosquitoes make outdoor activities somewhat unpleasant.  So, I like to keep a few short-term projects in the queue for those occasions where I need to spend some time in the air conditioning.

My favorite mode is CW, and even though I'm a proud member of the SKCC (#3173), I don't mind admitting that I prefer using an electronic keyer.  And, while I love my old AEA "Morse Machine", there's something inappropriate about using it with my homebrew rigs.  I mean, if I can design and build my own SSB/CW transceivers, I damned well ought to be able to build a decent keyer, right?

Actually, I've done it before, but that one uses a microcontroller.  It works fine, but I want to do something "Old School", using no ICs.

When I first started "noodling", my thought was to, basically, build a solid-state version of the old Hallicrafters HA-1 "TO Keyer", so I immersed myself in the manual until I understood what made it tick.

The concept is incredibly simple: The DITs are formed by an astable multivibrator, and the DAH's formed by "ORing" the output of the DIT circuit with that of a bistable multivibrator.  Cool.  That gives me a starting point, now to make it happen in silicon.

Actually, it's been done - Hallicrafters had their HA-4 and Heath had their HD-10, but I want to come up with my own circuit rather than copy someone else's.  I also want to run this thing from a 9V battery, and both of the aforementioned designs require "split" positive and negative supplies.  So, while there is going to be some similarity to these earlier designs -  there's only so many ways to make a transistor multivibrator - this project won't be a clone.

I'm going to do something a bit different than I have in the past in that I'll post to this blog as I go, rather than waiting until the project is complete to do a "wrap-up" series.  Because of this, there are bound to be some mistakes along the way, but that's part of the fun, right?

Anyway, might as well start with the easy part: the DIT circuit:


Transistors Q1 and Q2 form the astable multivibrator, which is essentially a free running oscillator that produces square waves by feeding the output of each transistor to the input of the other.  The frequency and duty cycle are determined by C1, C2 and R1, R2 and R3.  By using variable resistors for R2 and R3, we're able to vary the speed and weight (element to space ratio) from the front panel.

When the DIT key is open, transistor Q3 is turned-on through R8, which forces Q2 off by forcing it's base low.  When the key is closed, Q3 is turned off, allowing Q2 to be turned on by Q1 and allowing the multivibrator to multivibrate.

R7's purpose in life is to create the "self-completing" dits by creating something of a "Wire OR" with the key input: If either the key OR the collector of Q2 are LOW, Q3 is turned on.  So, if the key is opened halfway through a dit, Q2 will keep Q3 on until the dit is complete.  Cool stuff, no?

This is what's running on the solderless breadboard pictured earlier - I'll be tweaking the timing resistor values as I move along, but this is a start...

73!

Thursday, July 20, 2017

Knowing Enough to be Dangerous

In my last post, I mentioned that, even though I'm not wild about computers, they do sometimes make for decent tools, so I try to know enough about using them to be dangerous.

Now that I'm "officially" finished with the SR-16 project, I'm working on ideas for the next one, which will be an even more ambitious attempt at a "contest grade" multi-band HF transceiver.

In building the 30m rig, I initially made a bad choice of IF frequency - 13.51 Mhz - which placed the 2nd harmonic of the VFO smack in the middle of the band.  The easy fix was to move the IF to 13.56 so that the harmonic of the VFO fell outside of the band, but that also required additional bandpass filtering to manage the now out-of-band spur.  Moving forward, I'm determined to avoid that by analyzing my choice of frequencies and avoiding those that interact unpleasantly.

This requires repeated calculations, something I hate doing but also something computers are pretty good at.  So, knowing enough to be dangerous, I wrote a little C++ program to crunch the numbers:

#include <iostream>
using namespace std;
int main ()
{
  float lo;
  float lowend;
  float highend;
  float step;
  float rf;
  int harmonic= 1;
  float spur;
  float range;
  int harmonicNumber;
  cout << "Please enter the LOWEST receive/transmit frequency in MHz: ";
  cin >> lowend;
  cout << "Please enter the HIGHEST receive/transmit frequency in MHz: ";
  cin >> highend;
  cout << "Please enter the STEP in MHz ";
  cin >> step;
  cout << "Please enter the IF frequency in MHz: ";
  cin >> rf;
  cout << "Please enter the number of harmonics to extend to ";
  cin >> harmonicNumber;
  cout << "The tuning range you entered is " << lowend <<" to"<<" MHz.\n";
  cout << "The IF you entered is " << rf <<".\n";
  cout << "Analyzing to the " <<harmonicNumber << "th Harmonics... \n";
  for(range = lowend; range <= highend; range = range + step)
  {
    //lo = rf - range; // low side injection
    lo = rf + range; //high side injection
    for(harmonic=1;harmonic <=harmonicNumber;harmonic ++)
    {
        spur = lo * harmonic;
        if ((harmonic > 1) && (spur > (lowend*.9)) && (spur < (highend*1.1)))
        {
            cout<<"Warning!!! When tuned to " << range <<"; the " << harmonic  <<" harmonic of the LO ("<<lo<<") is: " << spur << ".\n";
        }
        spur = rf * harmonic;
        if ((harmonic > 1) && (spur > (lowend * .9)) && (spur < (highend * 1.1)))
        {
            cout<<"Warning!!! When tuned to " << range <<"; the " << harmonic  <<" harmonic of the IF ("<<rf<<") is: " << spur << ".\n";
        }
        spur=lo*harmonic+rf;
        if ((harmonic > 1) && (spur > (lowend*.9)) && (spur < (highend*1.1)))
        {
            cout<<"Warning!!! When tuned to " << range <<"; the " << harmonic  <<" harmonic of the LO ("<<lo<<") + the IF ("<<rf<<") is: " << spur << ".\n";
        }
        spur = lo*harmonic - rf;

       if ((harmonic > 1) && (spur > (lowend*.9)) && (spur < (highend*1.1)))
        {
            if (spur>0)
            {
                cout<<"Warning!!! When tuned to " << range <<"; the "<<harmonic <<" harmonic of the LO ("<<lo<<")- the IF ("<<rf<<") is: "<<spur<<".\n";
            }
        }
        spur=rf*harmonic+lo;
       if ((harmonic > 1) && (spur > (lowend*.9)) && (spur < (highend*1.1)))
        {
            cout<<"Warning!!! When tuned to " << range <<"; the "<<harmonic <<" harmonic of the IF ("<<rf<<") + the LO ("<<lo<<") is: "<<spur<<".\n";
        }
        spur=rf*harmonic-lo;
      if ((harmonic > 1) && (spur > (lowend*.9)) && (spur < (highend*1.1)))
        {
            if (spur>0)
            {
                cout<<"Warning!!! When tuned to " << range <<"; the "<<harmonic <<" harmonic of the IF ("<<rf<<") - the LO ("<<lo<<") is: "<<spur<<".\n";
            }
        }
    }
  }
  main();
  return 0;
}
If this looks like gibberish, here's something that I hope will be encouraging: I'm not a programmer, not terribly bright, and figured out how to do this in a couple of hours.  If I can do it, anyone can!

Anyway, this program runs in the Linux terminal and will prompt you for the low and high ends of the band of interest, how many points within the band to analyse, the IF (BFO) frequency and the number of harmonics that you want the analysis to look at.  Then it crunches the numbers, and displays any "hits" that occur within 10% of the band edges.  If there are no hits, it dumps you back to the beginning (exit with "control-C".)

Here's a screen shot of running an analysis of the 40m band (in 1 Hz increments) and an IF of 6.144 MHz, running out to the 100th harmonics.  This took about 2 seconds for the computer to crunch the numbers and give an "all clear".

Here's one where I chose a bad IF frequency so that it'll show some "hits":


I literally had this written within a couple of hours of writing my first "Hello World" in C++.  It helped that I understood the math and some basic programming concepts, but yeah - this is something anyone can do, so there's no reason to be intimidated by it.

I promise, I'll get back to the Real Radio Stuff in my next post; I just wanted to write this one to show an example of how a computer and **very little** knowledge of programming can be a useful weapon in the homebrewer's arsenal.

73 Steve N8NM


Tuesday, July 11, 2017

SR-16 Arduino Sketch "Module" - Simple Interrupt Service Routine to Generate CW Side Tone.

I'm going to start this post with a proclamation: I am not a programmer.  Truth be told, I'm not all that wild about computers, but, like any other tool, they've got their purpose, so I try to get along with them when it suits me.

I've got some friends for whom the computer is the means and the end - it's the computer itself that provides the entertainment.  Me, not so much, but, being a guy who spends his free time building ham radios in his basement, I don't think it's my place to judge.  Different strokes.

That being said, computers are usually good at doing things that are mind numbingly routine and stupidly boring, and they do them at lightning speed and with consistent results - something I couldn't do if I wanted to. But, enough about my personality quirks, let's get on to the good stuff.

The Arduino has the tone command that Farhan and others (including me) use to generate the CW sidetone that is (after filtering - it's a square wave) sent to the audio chain for monitoring and the balanced modulator for transmission. 
So, in the code, you're monitoring the input connected to your key and, when it's closed, sending a tone to the appropriate output.  Once you've defined the input and output pins, the code to do this is alarmingly simple:

int buttonState = digitalRead(KEY_IN);  // read "KEY_IN", save value in "buttonState"
  if (buttonState==LOW)                         // is the key closed?
    {
      tone(TONE_OUT,750);    }                // if yes, send 750 HZ tone on "TONE_OUT"
    else                                                     // Otherwise
    {
      noTone(TONE_OUT);                      // send no tone on "Tone_OUT"
    }

Looking at the Raduino sketch, I see where Farhan's got similar code already written to accomplish this, but it looks like he never calls it - actually, he's commented out the lines in the loop() that would call this function - and I think I know why:  The transmitted CW would sound like my fist after a few too many visits to the Guinness low-gravity draught head. 

The loop() function executes it's instructions sequentially, over and over until the cows come home.  So, before it gets to the instruction telling it to check and see if the key's closed, it's gotta finish all the prior instructions.  If you have a very short loop(), this is probably OK - the Arduino is pretty speedy.  On the other hand, if you're doing a lot of things in the loop(), it can be a problem.

A better way to do it would be to use a pin change interrupt. Then, the moment that the key input goes from high to low, the Arduino will stop whatever it was doing (loop())  and execute the commands in the interrupt service routine (ISR).

I've been in the habit of avoiding using interrupts because, truth be told, I didn't know how.  Then, I found this website (https://thewanderingengineer.com/2014/08/11/arduino-pin-change-interrupts/). Print it, study it, learn it, it'll change your life; it's certainly changed mine!

Basically, I just followed the three steps outlined in that blog:

Step 1 - Turn on pin change interrupts:

OK, I'm using input D11.  The Arduino data sheet shows that  will be one of    the inputs on "Port B", so I'll turn that on:
PCICR |= 0b00000001;

Step 2 - Choose which pins to interrupt:

Again referring to the data sheet, D11 is Pin 3 on Port B, so I'll create a "mask" so that we only look at that pin:
PCMSK0 |=0b00001000;

Step 3 - Write the ISR:


/***************************************/
/* Interrupt service routine to       */
/* generate CW tone on keydown  */
/* Version 1                                  */
/**************************************/

ISR(PCINT0_vect) {
//Generate CW:
     int buttonState = digitalRead(KEY_IN);
  if (buttonState==LOW)
    {
      tone(TONE_OUT,750);    }
    else
    {
      noTone(TONE_OUT);
    }
}


And, by golly, that's it!  Loaded it into my rig and it works like nobody's business.

Now, if you cut and paste this into your sketch, I guarantee it's not going to work because I've deliberately left out a few things.  I'm silly that way. But, my intent isn't to write a how-to, but to encourage anyone who, like me, was intimidated by the concept of using interrupts to just go out there and grab 'em by the cajones.  Like most things technical, it's not hard to understand once you find an explanation that "clicks" with you.

73 - Steve N8NM

Friday, July 7, 2017

SR-16: Let's Get Modular

In my last post, I mentioned that the only way to eat an elephant is one bite at a time.  Building anything with any degree of complexity is the same way; you have to break it into manageable chunks, otherwise you're invariably going to find yourself overwhelmed.  In an electronics project containing more than a single stage, I will divide the overall project into a series of modules, each with a defined function (eg: IF amplifier stage) and parameters (input/output levels, impedances, gain).  Modularity allows each element to be developed, tested and refined individually, which is important because, realistically, at the amateur level (where I proudly reside) things seldom work right the first time.  It's much less frustrating to have to scrap a single module than it is an entire project.

The photo above shows the modules on the underside of the SR-16. Each module is on it's own circuit board and wired such that it can be removed independent from all other modules (with the exception of the power and TR switching, for obvious reasons.) 

The large, shielded enclosure to the left contains the Hayward/Damm HyCas IF/AGC circuit, which I'd built some time before conceiving of this project.  Since I knew the function and I/O parameters of HyCas module, designing and building a rig around it was straightforward:  I drew-up the block diagram to use as a road map and went to town.

Like Master Homebrewer Pete, N6QW, I have a number of favorite circuit modules that I use in my rigs.  An example of this is the mic and audio preamp module; I've got a design based around a single LM324 that works well, so rather than reinvent the wheel, I've used the same circuit in my last three rigs.  But, since it's built as a module, if I find something that I like better, swapping it out will be a snap.

Modularity isn't limited to the hardware side of the project, but extends also into the Arduino sketch that runs the bloody thing.   Since I'm using an SI5351 to provide the LO and BFO signals, much of the work has already been done for me byJason Mildrum, NT7S, Przemek Sadowski, SQ9NJE and Tom Hall, AK2B, so I used their code as a starting point.  Not being a programmer, it took a lot of studying before I understood how their sketch worked and was able to modify it to perform the additional functions required by this project. 

In the same manner that the block diagram served as a road map for the rig's hardware, I sketched (pencil and paper - too ugly to post!) a flow-chart for the sketch and wrote modular "functions" for each, well, function of the software. Each function is analogous to a hardware module - they can be developed independent of the main program, and subsequently refined individually without disrupting other parts of the code.

While I don't want to share my ugly flow-chart for the entire sketch, here's how I keep the functions organized on my hard drive:

Here's a drill-down into the folder containing the function to load the VFO frequencies and status from EEProm when the rig's fired up.  Notice that it took me several attempts to get it right!

Notice that I keep to a standard that I've developed for myself to maintain version control - this becomes increasingly important as the code grows longer.  I think that'll be the next entry into this crazy blog - it's absolutely essential to keep track of where you've been in order to get where you want to go.

I can't imagine successfully homebrewing anything more complicated than perhaps a Michigan Mighty Mite without using the modular approach. 

73 de N8NM

Top view of the SR-16 outside of it's cabinet.  The circuit modules occupy space on four subchassis.  Each subchassis is also modular in that it can be removed, tested and refined independent of the others.  Modules containing modules. It's module madness!

 

Sunday, July 2, 2017

SR-16: The Beginning.


Let's face it: The minimalist rigs so popular with the QRP crowd can be a lot of fun to use occasionally, but I know of only a few hardcore individuals who limit their operating to that type of station.  I think that I'm fairly typical in that, once the construction's over, I've tended to lose interest fairly quickly and revert back to using commercial equipment. 

That's actually been bothering me for the past few years.  Sure, I've rationalized this behavior by limiting myself to using only vintage equipment (while my IC-765s languish in disrepair), but I've slowly descended into feeling deeply inadequate and ashamed that, as a red-blooded amateur, I wasn't able to build something suitable for day to day usage.  Then it hit me: Why the hell not?

There's an old saying that compares completing a complex project to eating an elephant - it's possible if consumed one bite at a time.  Designing and building a rig that'll perform comparably, if not favorably, with commercial products is no different.  Before we sit down with fork and knife, we've got to come up with a plan as to how we're going to devour the beast.  Pete, N6QW, calls the planning process "noodling".  I figure that, at this point in the project, I've done enough noodling to open a pasta factory. 

Where to start?  The beginning is as good a place as any, so I sat down and thought about what I wanted this rig to do.  It was, at this point, where the SR-150 came to mind.  I owned one years ago, and have ever since believed that it was the most practical, user friendly rig of the tube era.  Now, the SR-150 was a five-band dual conversion transceiver, and with the bottom of the solar cycle looming, I figured it'd be a bit of a waste to spend time building circuitry for bands that will likely be dead for the next few years.  The SR-160, on the other hand, was Hallicrafters' "stripped down" version: Single conversion and covering only 80,40 and 20. 

Features?  Thinking about how I operate, I tend to use very few "bells and whistles".  The SR series had RIT, which is essential, but required an outboard VFO to operate splits beyond a few KHz.  One of the beauties of modern, microprocessor control is that you're able to implement multiple VFOs via software - so that was a must.  Manual and decent AGC were also deemed necessary, as was front panel control over mic gain and metering of the PA current and forward and reflected power.

I debated with myself over adding a notch filter, but nixed the idea after thinking about how little I actually used the ones on my commercial rigs.  But, at the same time, determined that fairly broad but decent CW and SSB filters were something I absolutely needed.

So, one night in January, I took my list of features, sat down at the computer and drew-up what I envisioned the front panel of a modern-day version of the SR-160 would look like:


Remarkably, I've changed nothing from that original drawing in the process of bringing the rig to fruition.  Guess I got it right the first time.  Noodling. Gotta do it.

Next thing that I did was start figuring out the circuitry necessary to bring this monster to life.  This involved a lot of reading, some breadboarding of trial modules (more on this later) and several iterations of block diagrams before settling on the one below:



Now that the rig is built, I'm updating the documentation and just today revised the block diagram to reflect the "As-Built" design.  Again, noodling paid off as very little changed:

I think that, at this point, I've exhausted the attention span of all but the most focused individuals, so I'm going to save delving into the modularity concept and circuit blocks for another day. 

Saturday, July 1, 2017

I've been slackin'

Thanks to Bill, N2CQR for adding a link to my blog on his SolderSmoke page, I've seen a notable increase in the number of visitors, so I feel somewhat shamed into adding something new. Hey, I don't like rushing into things, and it's only been six months, hi.

Truth is, I've been incredibly busy with my current project, and I have to admit that I enjoy working at the bench much more than I do blogging about it.  Not that I don't enjoy that too, but there's only so many hours in the day!

So, what it is, this current project? I call it the "SR-16" and here's a peek:


Those acquainted with early 60's rigs will likely notice a resemblance to the Hallicrafters SR series, particularly the SR-160, which served as the inspiration for this rig.  Accordingly, the PC board in the foreground is a 2017 version of the venerable TO keyer that I'm building to go along with it. N2CQR would approve of the keyer as it uses only discreet components.

Like the SR-160, it is a single conversion SSB & CW transceiver covering the 20, 40 and 80 meter bands.  Unlike the SR-160, it hasn't a single thermionic element, just several dozen transistors and a handful of ICs.

So, why the "SR-16" moniker?  Aside from its obvious derivation from the 55 year old Hallicrafters nomenclature, it also denotes the active devices used in the power amplifier: Two Mitsubishi RD16HHF1 MOSFETs in push-pull.

Pete, N6QW's KWM-4 also served as an inspiration for this rig.  If you haven't visited the web page where he describes it, you should - it's a true work of radio art! 

This has been my most ambitious transceiver project to date (again - that's why I haven't been blogging!) and I'm very pleased with how it's turning out.  The heart of the receiver is the Hybrid Cascode IF strip described in the December, 2007 QST article by Wes Hayward, W7ZOI and Jeff Damm, WA7MLH.  This circuit is really slick, and makes operating the rig a real joy.

In the upcoming days/weeks, I'll go into some details of the circuitry, construction and firmware (Arduino) used in this rig - not to the point of creating a "How To" guide - I'm not qualified to do that - but to maybe give anyone bored enough to read my ramblings some ideas.  There are a few things that I'm doing in this rig that I haven't seen done before that I think are pretty cool - stay tuned.

73 - Steve N8NM