Off The Breadboard - Audio Stage

Now that I've managed to get the LCD and rotary encoder working with the Arduino, it was time to take a break from the signal generator project for a bit. The Si5351 board still needs to be connected and code tested and I realized that I need to craft up some sort of menu system to control the frequency and drive level of the Si5351 outputs. After a bit of Finite State Machine thought experiments, my digital brain is saturated and needs to be brought back to earth with a little solder smoke and analog work.

Where the Neophyte had been left off was with a breadboard prototype which in some fashions functioned; the oscillator was percolating (I think), the tuning capacitor provided some level of variability in the oscillator output (I think), and the front end was can be tuned (this I know). There is yet a distressing lack of ability to actually tune an intelligible signal, but in the absence of anything more than my cheap DVM, I realize that I'm at the limit of my testing ability beyond what I described in my last Neophyte post.

Since I was at an impasse here, and I noted an exceptional amount of "hand capacitance," I decided to rip the prototype out of the breadboard and assemble it Manhattan-style on single sided copper boards. Soldering well is a bit more difficult than I remember, but then again I come from the illustrious school of "the bigger the glob, the better the job" solder training. I never had the manual dexterity to get in to the Navy's 2M (Micro-miniature) repair soldering courses of instruction. What really helped here was the Manhattan accessories offered by Rex Harper (W1REX) at his storefront www.qrpme.com. I used his MePads to mount the DIP sockets for the LM386 and SA612 chips...saved me several toasted chips, I'm sure. The MeSquares were equally awsome for rapid building.

What we have so far is the audio stage centered around the LM386 amplifier chip, along with the low pass filter coupling the down-converted audio from the SA612 mixer chip. The "dancing capacitors and resistors" in the corner of the board are the Zobel network and output coupling capacitor which filter and feed the amplified audio signal (if I ever find one) to the headphones of the receiver.

Don't ask me why I did it that way; I think it was a gut aesthetic call that struck me in the cloud of solder smoke. From a technical perspective, shorter leads tend to be better to reduce unwanted coupling and other feedback problems, but as these components are themselves filters I judged the technical risk to be low. Now, if I have to eat a little crow on that estimate, you can see I've backed myself into a corner (pun absolutely intended) since there is no copper left to which I can move the dancing components. If that is the case, I'll end up moving the two capacitors and the resistor to the headphone jack itself where it will be mounted on the front panel.

If you are not familiar with Manhattan construction, I highly recommend it to anyone interested in electronic construction. Back in the Navy days, I did some custom electronic construction of some data collection systems and had a horrible time with PCB design and etching; the chemicals are awful and my success rate was abysmal.

Manhattan style allows one to build up the circuits in a very logical, easy to design manner in which everything is visible and available to the eyes and fingers. For your further reading, I'd recommend Chuck Adams' (K7QO) two articles on the basic and advanced techniques (both links are PDFs):

• Manhattan Building Techniques, and
• Advanced Manhattan Building

Now, I've not applied power and done rough testing on this yet, but visual inspection and ohmmeter testing show no gaps or solder bridges. Tonight I'll try to get some of the mixer, oscillator, and/or front end installed.

Signal Generator Part 2b - Interrupting Oneself

Now that I've finally bulled my way into successfully reading the encoder status, I can move on to the final part of my rotary encoder experimentation.

The motivation for this final part of playing with the encoder comes from the blog post "Continual Interruptions" from Paul (M0XPD). He points out the problem of missing changes in the encoder status if the polling of the encoder is in the main loop() code. When the encoder status is read using the process() function and it is the only code in the loop, there is literally no chance of missing any status changes as the encoder shaft is rotated. Essentially the "sampling window," as Paul terms it, is 100% of the Arduino processing time.

As the loop is filled with other bits and pieces of code, the percentage of processor time available to read and process the encoder status begins to shrink. If the window becomes small enough the code will begin to miss encoder status changes, resulting in sluggish response to user input, incorrect direction decoding, or "stuttering" of output events as buffered changes flood the code. The actual impact is highly dependent on what functions/libraries are used to read and process the encoder status. In this signal generator implementation using the SQ9NJE Rotary library, we would only suffer sluggishness or occasional incorrect direction events. Note that the problem becomes significantly worse as we stuff the "loop" code full of delay(milliseconds) calls as we often do.

The "polling" method of reading the encoder is kind of like us asking the processor "has the encoder been rotated" with the risk that if we wait too long to ask, we'll miss a change. A better approach, and the one that Paul describes, is to let the processor tell us "hey, buddy, the encoder rotated, what do want me to do now?" This is the "interrupt" method of input processing and as a bonus, it's generic to any pin input code we might envision.

It's highly unlikely that the final signal generator product will have such processor intensive code or be so full of delay(milliseconds)that it will suffer the symptoms described above. That said, and because I very much enjoy the challenge, I chose to handle the reading of the encoder in an interrupt routine.

Handling pin changes on an interrupt basis seems a fairly straightforward concept in ArduinoLand: Tell the chip that it needs to handle an interrupt, tell it what to listen for, and tell it how to respond when the interrupt fires.

What appears to be the most common implementation, as used in M0XPD's Si5351 code, is to enable the pin change interrupt for one of the pins connected to the encoder (only one pin needs to be "listened to"), then write an Interrupt Service Routine (ISR) which is used to handle the arriving data from the encoder. Here's a clip of how he implements this.
/* in the setup() code */ // Enable pin change interrupt for the encoder PCICR |= (1 << PCIE2); PCMSK2 |= (1 << PCINT18) | (1 << PCINT19); sei(); /* in the "header" code */ ISR(PCINT2_vect) { unsigned char result = r.process(); if (result == DIR_CW) Turns=Turns+1; else if (result == DIR_CCW) Turns=Turns-1; }
Notice the "bit-fiddling" going on in lines 3 and 4. These are bit masking manipulations that one uses to ensure that the Arduino is paying attention to the correct pins and ports for the interrupt we are creating. The friendly names you see here are SPECIFIC to the processor AND the hardware pins used by the designer. So this explain why the code wouldn't even compile for me using a Micro, as I'm quite sure that M0XPD is using an Uno or other non-Leondardo based Arduino.

No amount of purposeful (or random) bit fiddling and deep reading on the variables used in the masking routines could avail my problem. Sidenote: The documentation on this subject is miserable, both at Arduino.cc and elsewhere.

Thankfully, there is more than one way to do interrupts. The other, easier, but more limited approach is to use external interrupts. This method avoids the need to mangle bit-masking to listen correctly; rather, in the "setup()"code we make a single call to attachInterrupt(pin, ISR, mode) and create an ISR function of any name. The first two of three arugments are an integer pin number (or friendly name) and the name of the ISR function (notice the lack of parentheses on the name). The last argument is the interrupt mode, or at what point in a pin change event will the interrupt handler fire. There are several choices for mode, but what makes the most sense for this project was to trigger on CHANGE. Line 40 in the code below shows how I implemented this, along with the rest of the signal generator code so far. The final ISR implementation is on lines 29-35; note that the function name is no longer ISR() and matches the handler called out in the attachInterrupt() function.
#include <Rotary.h> #include <Wire.h> #include <LiquidCrystal_I2C.h> // LCD/I2C Macros #define I2C_ADDR 0x27 #define BACKLIGHT_PIN 3 #define En_pin 2 #define Rw_pin 1 #define Rs_pin 0 #define D4_pin 4 #define D5_pin 5 #define D6_pin 6 #define D7_pin 7 // Rotary Encoder Macros #define ENC_PIN_A 1 // pin D1 #define ENC_PIN_B 0 // pin D0 #define ENC_PIN_SW 4 // pin D4 int turns = 0; // Create the LCD/I2C object LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin); // Create the Rotary Encoder object Rotary encoder = Rotary(ENC_PIN_A, ENC_PIN_B); // ISR for Rotary Encoder pins...here's where menu/frequency code will go. void readEncoder() { unsigned char result = encoder.process(); if (result == DIR_CW) turns=turns+1; else if (result == DIR_CCW) turns=turns-1; } void setup() { // create the ISR for changes on the Rotary Encoder attachInterrupt(ENC_PIN_A, readEncoder, CHANGE); // set up LCD and blank display lcd.begin(20,4); lcd.setBacklightPin(BACKLIGHT_PIN, POSITIVE); lcd.setBacklight(HIGH); lcd.noCursor(); lcd.home(); // set up I/O pins (NOTE: rotary encoder pins are handled in the library) pinMode(ENC_PIN_SW, INPUT); digitalWrite(ENC_PIN_SW, HIGH); // test display setup lcd.print("Rotary Encoder Test"); lcd.setCursor( 0, 1 ); // go to the 2nd line lcd.print("sq9nje \"Rotary\" lib"); lcd.setCursor ( 0, 2 ); // go to the third line lcd.print("SWITCH: "); // start at 9,2 } void loop() { // handle rotary encoder axial switch in the main code. if(digitalRead(ENC_PIN_SW)) { lcd.setCursor(9,2); lcd.print("OFF"); } else { lcd.setCursor(9,2); lcd.print("ON "); } // update Rotary Encoder position (pos. #s are right turns, neg. #s are left turns. lcd.setCursor(0,3); lcd.print(turns, DEC); }
I still need to do some more experimentation on the Pin Change Interrupt approach. Even though the system is doing what I want, I'm not fond of not reaching my objective.

Next up, getting the actual Si5351 Clock Generator on board the prototype.

Signal Generator Part 2a - Walking on Pins

Update 12/23/2014: Not being satisfied where I left my understanding of the pins and references, I spent some time digging around on the internet and in the header files for the Arduino development environment. For those who might be interested or might find it useful, I've put my notes and findings on a separate page: Arduino Micro Board Pins.

Next step is to get the rotary encoder working with the Arduino Micro. This is key, as the rotary encoder will be the user input interface for navigating menus and altering the operating parameters of the signal generator.

A rotary encoder looks like a potentiometer, but operates very differently. Instead of varying an analog value such as resistance as the user rotates the shaft, the encoder generates on/off signals that can be used to determine direction of rotation and even calculate speed and distance of travel (angular position from start). The encoder type chosen for this project also includes a momentary SPST switch which is used by pushing the shaft axially. This switch will be used as the "enter" button in the user interface.

I won't spend any time describing the internals of the encoder and the Gray code used to represent the angular motion, but the Wikipedia site for rotary encoders is a good jumping off point if the reader is curious.

Turns out that using an encoder with Arduino is (almost) trivially simple. The snarky "almost" is due to my not thoroughly understanding how to address the Arduino pins from within my code. In any Arduino sketch, one can read or write data from/to pins on the Arduino by first telling the system what which pin is an input or an output, using the pinMode(pinNumber, mode) function. To read or write that pin, we can use digitalRead(pinNumber)function or it's output counterpart digitalWrite(pinNumber). There are similar analog pin functions as well, but we'll leave that be for the time being.

Arduino Micro Pins...what's in a name?

Source: Tonylabs

Notice the pinNumber argument to these functions; this tells the system which specific pin on the board is "in play" for the function call. The argument value is expected to be an integer value, or we could use a #define macro or const int variable assignment to make a "friendlier" pin name. But what caused me no end of pain here was determining the actual pin number or name to use in the function call which would match the pins I had my rotary encoder lashed to.

From the previous Signal Generator post, you'll recall that this project uses the I2C bus to control and communicate with the LCD module and in future iterations of the projects will add the Si5351 board on to that bus. This means I've already used pins 2 (SDA) and 3 (SCL) on my Micro board. Where do you think almost all of the example code, to include the examples in the SQ9NJE Rotary library embedded in his  Si5351 project (look under the "examples" section of his repository). That's right, Virginia, pins 2 and 3.

Shouldn't be too much a problem, right? Just pick a different pair of digital pins to connect to the A and B port of the rotary encoder. You're half right; picking a pair of pins on the board is easy, but knowing how to refer to them in the code is another animal. For no particular reason, I chose the pins which had the silkscreen label TX and RX, but quickly found that one cannot refer to the pins in code with the printed label from the board, at least on the Micro. It will, generally work, on the full sized boards, according to numerous posts on the Arduino Forums just not on  the smaller boards.

The Tonylabs image of the Arduino Micro pinout was very helpful in learning the depths of the Micro's capabilities and the multi-purpose nature of the board, but it actually made solving this problem more difficult. By way of example, if you examine the pin labeled RX in the image above, you can see that it is also pin 18 on the ATmega32u4 chip and can be referred to as PD3, TXD1, and INT3, none of which can be used in the pin assignment variables as that name, no matter how much I wished and tried. Adding insult to injury, none of them are obviously transmutable to a pin integer; in other boards, a pin labeled D0 is referred to in code as the integer 0, but not in the case of my Micro.

Source: Arduino.cc

To the rescue comes the main Arduino page for the Micro, from which the image to the right came. Notice that here the  RX and TX pins have a "0" and a "1" on the graphic. Using those numbers in the pin assignments finally had me receiving the rotary encoder codes. From the code snippet below, you can see how simple it is to read the status of the pins from which you can then use some conditional logic to change the rotary encoder Gray code into a directional value (CW or CCW), a simple "turns" counter, or whatever strikes your fancy. I strongly recommend that you use a preprocessor macro or const int variable assignment, as I have below, to give the pin numbers a more friendly name. If your code ports to a new board or your hardware design changes, we don't want to try and hunt down all references to "0" and "1" in function calls to change them. If the "pin name" is assigned a value once, it only needs to be changed once to adapt to the changing hardware.
// macro friendly name (note lack of semicolon) #define ENC_PIN_A 0 // variable assignment friendly name const int ENC_PIN_B = 1; pinMode(ENC_PIN_A, INPUT_PULLUP); pinMode(ENC_PIN_B, INPUT_PULLUP); int val0 = digitalRead(ENC_PIN_A); int val1 = digitalRead(ENC_PIN_B);

Using the SQ9NJE Rotary Library

Once I resolved the pin reference problem, using this library is quite literally a no-brainer. Include the library in the code header, then simply instantiate the Rotary object, also in the header. Reading the directionality of the encoder is accomplished in the main (setup or loop) code sections. The library is exceedingly simple; there is only the one constructor, Rotary(pinA, pinB) and one function to read data, process(). The process() function only reports the direction of the encoder rotation, but one can easily use it to track the count of turns as each time the function is read, the encoder has moved one increment of rotation. Here's a snippet that shows how one uses the library.
// header code #include <Rotary.h> Rotary r = Rotary(ENC_PIN_A, ENC_PIN_B); // setup or loop code unsigned char result = r.process(); if (result) { // the "process" function either returns DIR_CW or DIR_CCW if(result == DIR_CW) Serial.println("Turning right"); if(result == DIR_CCW) Serial.println("Turning left"); }

Nota Bene: the Rotary.h header file says that there is a third return value for the process() function, DIR_NONE, presumably to indicate that the encoder is in some undecipherable state, but the actual library code can never return this value as written.

We'll just have to wait and see how I actually employ the encoder in final signal generator. We'll also have to wait for the next post (Signal Generator Part 2b), 'cause I ain't done with my rotary encoder frustration.

Signal Generator Part 1 - LCD and I2C Woes

I'm going to step away from the receiver for a bit and tackle one of the other projects lurking in the back of my brain. Bonus is that this project can only help in resolving my non-functional receiver problem. I'm going to put together a signal generator with my vintage 2007 Arduino Diecimila and the Si5351 Clock Generator board from Adafruit.

For those who might not be aware, the Si5351 is a small, very stable, very inexpensive clock generator that is addressed and controlled over I2C. More on this later, after we design and build the other non-RF parts of the signal generator.At some point the project will migrate to one of the Arduino Micros I've received, but for now the dust has been knocked off the Diecimila.

The first part of the signal generator needs to be the LCD display, as the testing and implementing the remainder will be easier if I have a visual display to which the Arduino can write data.

When I considered the display, one of my concerns was the number of connections on the traditional LCD modules. Early on in my thinking I was considering eventually moving this project to an Adafruit Trinket or other micro-micro Atmel ATtiny85 board. Well, I believe that the number of pins required to communicate with an LCD module exceed the number of pins on the actual Trinket.

Thanks to I2C interfaces which many different vendors are implementing as add-on modules, I was able to reduce the need for seven or more pins to just four: Serial Data Line (SDA), Serial Clock Line (SCL), +5VDC, and GND. Since I2C is actually a data bus, this won't cause me problems when the time comes to integrate the Si5351 module which also uses I2C for control. For my Arduino, the SDA and SLC pins are on analog pins 4 and 5, but other Arduino models may differ; make sure you check the

I ended up with the Sainsmart 20x4 LCD Module with I2C backpack which came at a good price and is based on the well-established HD44780 LCD...well at least from the pocket book perspective. There are some problems with cheap hardware that aren't immediately evident. Documentation is terrible, and not just in the "poorly translated" variety of terrible, but in the wholly wrong information variety.

The standard Arduino LiquidCrystal library doesn't support I2C interfaced LCD modules, so off I go to find a compatible library. Thanks to Francisco Malpartida for his drop-in replacement to the standard library. It retains the core functions for the LiquidCrystal standard library and adds I2C and Shift Register interfaces.

In order to use an I2C slave on the bus the I2C master (Arduino) has to know the address of the slave device; without this, nothing can happen. The Sainsmart website for the product is what passes for the documentation on this product. They tell us that the address for the LCD module is 0x3F, so off that goes into my test code for the Arduino. No joy!

Poking around on the Internet long enough and I find out that correct addressing, or more specifically the vendor documentation of it, is a common problem with these new I2C backpacks. Turns out that this module runs at address 0x27 no 0x3F. One tool that helped me here was the ubiquitous I2C Scanner code that crawls the I2C address space looking for live slave devices. Run the sketch and I see:

Scanning...
I2C device found at address 0x27 !
done

I'm quite sure that this will be useful again, given my propensity for cheap inexpensive hardware. Warning: if you have more than one slave device, this scanner cannot distinguish one from the other.

One other annoyance was getting the backlight pin (one the HD44780 module) correctly identified for the code. No software to help here, I just experimentally changed the #define BACKLIGHT_PIN  macro in the code until the LCD backlight stayed lit when the sketch ran. This particular LCD module was pin 3.

For those interested, I've pasted in the final code below which I came up with to test this setup.

Next step...rotary encoders for input and control.

#include <Wire.h> #include <LiquidCrystal_I2C.h> #define I2C_ADDR 0x27 #define BACKLIGHT_PIN 3 #define En_pin 2 #define Rw_pin 1 #define Rs_pin 0 #define D4_pin 4 #define D5_pin 5 #define D6_pin 6 #define D7_pin 7 int n = 1; // Set the LCD I2C address and pinouts LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin); void setup() { lcd.begin(20,4); // Switch on the backlight lcd.setBacklightPin(BACKLIGHT_PIN, POSITIVE); lcd.setBacklight(HIGH); // set display format and go home... lcd.noCursor(); lcd.home(); // test setup lcd.print("I2C Address: 0x"); lcd.print(I2C_ADDR, HEX); lcd.setCursor( 0, 1 ); // go to the 2nd line lcd.print("F Malpartida library"); lcd.setCursor ( 0, 2 ); // go to the third line lcd.print("Test By Chris Horner"); lcd.setCursor ( 0, 3 ); // go to the fourth line lcd.print("Iteration No: "); } void loop() { // Update the iteration count lcd.setCursor (14,3); // go col 14 of line 3 lcd.print(n++,DEC); // blink the backlight lcd.setBacklight(LOW); // Backlight off delay(25); lcd.setBacklight(HIGH); // Backlight on delay(3000); }


UPDATE:

Looks like the code is completely portable to the Arduino Micro. No edits, nudges, or hits with a code  hammer.

...and the designer said "Fiat sonus"

....and there was sound. Not intelligible, not coherent, but sound nonetheless.

The Neophyte is bread-boarded, with a plethora of tiny parts and pieces as well as a tangle of jumpers and clip wires. Let the building and testing begin!

What I have not managed to created is a functioning direct conversion receiver...yet. I can hear....stuff...in the headphones, but I'm not able to copy any phone or CW signals on 40 meters. Let me tell you what  I've done to make it work (full disclosure: as of this post, it still ain't working).

In some respects this project is fully functioning as a theremin, albeit without the wide audio range normally enjoyed in this type of musical instrument. If I wave my hand around the breadboard, particularly in the vicinity of the oscillator components, the noise characteristics change in the headphones. So it would seem to be that I've at least managed to get the oscillator to percolate.

When I adjust the main tuning capacitor (C12), the headphone noise changes as well. In fact, there are two distinct spots in the rotation of the capacitor at which the audio is distinctively "radio-like." As I'm tuning through those spots, the audio changes from background noise to a high pitch signal, descending down in frequency until the signal disappears, and the rising back up through the audio range. A better description would be the swooping sound of trying to zero beat a carrier.  This occurs twice across the range of the capacitor, both in the upper and lower thirds of the capacitor. From this I can surmise that the oscillator is both percolating and variable.

Since I cannot even copy a single intelligible signal, I am completely unable to estimate if the Neophyte is oscillating and variable in the correct band. So, out comes the frequency counter....oh, wait, that's right, I don't have one. What I do have is my first unknown!

The conclusions regarding the oscillator (functioning and tuning) allow me to infer one other key piece of information: Since the headphones produce sound, the audio amplifier section is functioning correctly. To share a secret learned from one of N6QW's videos, I already knew that the audio amplifier was functioning by touching the input components to the LM386 chip. If you hear "hum" on the headphones when you do this, you can confirm that the amplifier is working.

Having found no obvious problems so far, at least with the tools available here, I started to look at the front end. The tunable front end works, since I can peak the signal level using C4, the polyethylene variable capacitor and the 42IF123 transformer can. Also, when I remove the "antenna" leads, the noise floor drops away to nothing in the headphones. More on the antenna in another post as this might really be part of my problem.

So, no working receiver, but some useful findings.

What I know:

• The oscillator is percolating.
• The oscillator is tuning.
• The mixer is functioning.
• The front end is working and tuning.
• The audio section is functioning.

What I don't know:

• The oscillator operating frequency and range.
• The antenna input level sufficiency.
• What needs to be hammered on to make the Neophyte work.

From here I'll have to look at the antenna (currently ten clip wires set end to end) as a potential problem, but I'm also going to have to wire up my Arduino and Si5351 clock generator to see if I can squirt some RF into the Neophyte and make a little coherent sound this time.

Parts and Pieces

Well, hey, I'm solving the junk box program quite handily now. Thanks to Mouser, Adafruit, RSR Electronics, and the Xtal Set Society, I've managed to accumulate all the parts I need for the Neophyte project.

With apologies to Percy Shelley, "Look upon my (consumerist) works, ye Mighty, and despair"

Taking a supply management cue from my time with Navy EOD, as well as heeding the advice given on the SolderSmoke podcasts from Bill Meara (N2CQR), I adopted the "two is one, one is none" procurement strategy. As a result, there are enough components to build two receivers, or more likely, enough to provide spare parts when I let the smoke out of something.

The only exception was the main tuning capacitor (C12, in the schematic I posted earlier). It's an air variable capacitor with a 365 pF maximum value. This is one of those parts that shows up in various texts and designs where the author implies that it should be something in your junk box or easily and inexpensively available.

Not so...

These once common capacitors are apparently very difficult to come by on the open market. Worse, they're quite pricey in comparison to the costs of the remainder of my receiver. My research only turned up three vendors selling these new; turns out one of them is no longer in business, another doesn't offer the ancillary mounts and reducers I wanted. The third, though, came through big time. The Xtal Set Society sells them, and a lot more. The capacitors and related parts are a little expensive, but worth every penny, I think.

Yes, that is EMRFD doubling as a photo stand

Gorgeous, no? I haven't even mounted the 6:1 Planetary Reduction Drive yet, and I can't stop admiring the piece. Perhaps I'll figure out some cabinetry trick to try and showcase the beautiful mechanics of the tuning capacitor.

If the junk box seems a little overstuffed for a simple Direct Conversion Receiver, well there are a number of parts in there that aren't directly related to the Neophyte design. Also on my workbench, or more correctly banging around in the back of my brain, is a need to play with the signal generation so that I can have some sort of testing equipment beyond the uber-simple DVM. So, in that pile are some Arduino boards, LCD panels, rotary encoders, and some Si5351A Clock Generator boards to play with. 

This DDS interest is thanks to folks like Jason Mildrum (NT7S), M0XPD, and numerous others. I look forward to plagiarizing ruthlessly leveraging their hard experimental work in the near future.

First Steps

So...the question I asked my self was "what the heck shall I build?" Now that the "knack" has struck, where do I go from here? 

So many articles and instructions out there have a phrase much like "...and pull <component> from your junk box..." or presume that the reader has ready access to tons of advanced test and measurement systems. That certainly does not describe me. 

Allow me show you the parts available in my junk box:

My test equipment list is only slightly more comprehensive; I do have a DVM, although it won't do current measurements. I must have been exceptionally cheap the day I bought that one...

Filling the junk box can be handled with the judicious application of magic plastic cards, with some guidance from Pete Juliano (N6QW) in his bit on what should be in an experimenter's junk box. On the same page that has the junk box discussion, there are some great pieces on construction techniques and homebrew test gear, so perhaps I'll "self-help" my way in to some functional test gear.

As I mentioned in my previous post, I don't have even my Technician Class amateur radio license so I won't be building any transmitters yet (if I can't use it I can't see the point in building it). Well, if one cannot or will not build a transmitter and one is interested in radio, that only leaves us with the...receiver. 

I won't bore anyone with the lengthy list of design ideas a sources I pored over to finally find a design to build up, but ultimately the Neophyte (PDF link) 40 meter receiver from John Dillon was the winner. Some thought was given to an all-discrete-component project, but baby steps are needed for someone who has wielded more PowerPoint slides than soldering irons in the last two decades.

The Neophyte design is a simple one, both in concept and physical design:

• Direct Conversion design - no IF needed.
• Tuned front-end for some pre-selection.
• Double balanced Gilbert Cell mixer in the form of an SA602 chip.
• Wide tuning range oscillator circuit.
• Simple low pass filter.
• Ubiquitous LM386 style audio output amplifier.

Give what little I have of parts on hand or test equipment, simpler is better, no? Well, we'll have to see...

Tap, Tap, Tap....Is This Thing On?

Perhaps not the most innovative or insightful opening post on a new blog, but one must start somewhere. Somewhat soon I may just kill off this post, but in the meantime, allow me to explain what am I trying to accomplish on this, my first blog.

There will be no deluge of pictures or videos of my kids; that's Facebook. Micro-thoughts and mini-witticisms won't fly across this screen; that's Twitter. Frankly, I don't totally get Google+, so whatever happens there likely won't be seen here...or maybe it will. Who can say?

The purpose of this blog, as of today, is to help me document my re-entry, if you will, into the radio arts.

I've spent twenty years before the mast primarily working with radio systems on all manner of ships and other odd locales. After retiring from the Navy, I found a great job where I continued to work in the realm of radios and more importantly, I continued to work with the some of the finest folks I have ever met.

As some have no doubt discovered, either in civil or military professions, the longer you work in your field and the better you become at your trade, the farther away you are drawn from some of those things about your field that caused you to fall in love with it in the first place. While I truly enjoy what I do now and find wonderful challenges in it, the fact is that I don't actually see radios much any more, let alone do any troubleshooting or design work. This gap has progressed from a little itch to full blown dissatisfaction, but I had a hard time envisioning a way to solve my problem. What is a frustrated geek to do?

I've toyed with getting my amateur radio ticket for some time; many of us techie types in the Navy were hams, but I never bothered to get the license, and in fact still have not although I'm actively studying. My resurgent interest in radio electronics coupled with my borderline OCD research addiction led me down a wandering path of books, blogs, mailing lists, fora, and podcasts.  The final result is that I've discovered that I want need to build radios and other electronics, particularly with an experimental focus. Reproduction from schematics is where I'll start, but my goal is to design and build rigs that meet my needs and are come from my hands

From my online reading and interacting with other like minded folks, I've come to realize how friendly and mutually supportive a group of people exist in the amateur radio and experimental RF design world. As I progress in my own way in this avocation, I hope to continue this, draw from these folks, and hopefully contribute back to them.

So, this blog has two purposes...to document my technical and philosphic progress in this hobby, and just as importantly, to become another node in the network of amateurs and experimenters.





...oh yeah, and maybe get my amateur ticket at some point so my experimentation isn't limited to designing and building receivers.