I’m not going to try to review the kit, because Jack Smith wrote the canonical review of it already. Instead, I will share some impressions of the kit.

First off, the PCB layout has not gotten better. There are some crazy things about it, including through-hole parts mounted on opposite sides of the board, such that one component prevents access to the terminals for another. The layout of the output circuit is also odd. In an effort to provide for many different output options, apparently while keeping trace lengths to a minimum, the output section is crowded and hard to navigate.

I had to do only a little debugging after assembly. The first problem was that the two pads at the ends of the Si570 were not well-soldered. Jack Smith ran into the same problem. My second problem was a little more subtle. I fired up the circuit and saw output at the right frequency, but 0.5 V in amplitude. I purchased the CMOS output option, so it should have been a 3.3 V square wave. Tracing out the circuit, I found that the signal was getting knocked down when it passed through a DC blocking capacitor. Oddly enough, I noticed that when my ‘scope probe pushed down on the right spot on the capacitor, the output jumped up to 3.3 V. I probably fractured the cap with the heat of soldering. I had changed my mind about capacitive coupling anyway, so I replaced the cap with a 0 ohm resistor and now I get the output I expect.

The ‘scope shot shows the output, which is a reasonably clean 3.3 V CMOS signal. There is almost a volt of overshoot on the transitions, which is a little concerning, but I am not too worried about it at this point. The CMOS edges are fast, making overshoot understandable, and the size of the overshoot is likely to change as the VFO is integrated into the radio. I will worry about it later.

All in all, I have to say that the board works a treat. It is awesome to see 1 Hz tuning resolution and crystal oscillator stability coming out of a tiny 8-pin surface-mount part. I measured the frequency as being off by about 14 to 17 Hz at 10 MHz, which works out to about 1.7 ppm. Drift is confined to that 3 Hz range, at least when sitting on my basement workbench. The board does have a provision to calibrate out the frequency error, which I have not used yet. This much error really doesn’t matter.

The microcontroller firmware with the kit works well. The user interface is slightly unusual, with a decimal point used as an input cursor, but it works fine in practice. I do wish there was a way to configure band limits. The board has provisions for band selection, with up to eight bands possible. However, regardless of the band selection, the device will tune over its entire range. In a multi-band radio that is a poor idea, because it would be too easy to transmit at the wrong frequency and damage the final amplifier. With hundreds of on-board memories (100 per band, minus 20 reserved for setup), it would be nice if a few configuration memories were used to choose tuning limits for each band.

Over all I am happy with the board. It will serve just fine as my VFO.

That rang a bell, and suddenly I realized he was singing my oscilloscope’s front panel. Music by Mother Goose, lyrics by Tektronix.

When he came downstairs, I was working on assembling the K5JHF/K5BCQ Si570 synthesizer kit. It turned out to be a bit fiddly, but it is a decent kit. That said, I would not lay out a PCB like this one. It has a number of vias in the middle of pads, and while that’s not a big problem for hand-soldering, I would avoid it in a PCB as a matter of good practice. You never know who might decide to use solder paste and reflow to assemble the board, and then those vias will be trouble.

Worse, though, is the positioning of the connector for the LCD. It is laid out smack in the middle of the footprint for the microcontroller, but on the opposite side of the board. If you look at the big black socket in the picture above, you will see the back side of the microcontroller’s pins poking through the board on either side of it. This positioning means one has to solder the header on one side of the board, then insert the micro on top of the pins one just soldered, flip over the board and solder the micro’s pins next to the header. The header pins are non-serviceable once the microcontroller is installed, and the microcontroller won’t be easy to get out, either. DIP desoldering tools won’t fit with the header in the way. I’m not sure why the board is laid out this way, except that it makes the board a little smaller. Maybe that was the only concern.

At this point, it’s fully assembled except for the encoder/switch, which is about half wired. What am I doing blogging? I could be soldering!

Even when building a radio from kits, as I am here, there are many decisions to be made. When I bought the KK7B R2 and T2 kits, I had no thoughts about what to use for a local oscillator. Technology has advanced mightily since then, and now I have the option of an Si570 frequency synthesizer. This little chip provides a precise, low-noise  digital clock at programmable frequencies between 3.5 MHz and 1.4 GHz, depending on the variant one buys.

After looking around a bit, I picked John Fisher K5JHF and Kees Talen K5BCQ’s SI570 controller/frequency generator kit. Once it arrived, I had trouble figuring out how to fit it into my case. This case has a 0.125″ thick aluminum front panel. The threaded bushing on the kit’s encoder/switch was not long enough for this thick panel and a mounting nut, let alone a washer. There were also some mechanical things I didn’t like about the circuit board. I thought a bit about designing a new board for the parts from the kit, but I decided I could fix the worst of the problems with a new encoder. A little browsing at Mouser turned up an extremely similar model that had the longer bushing I needed. It even has the same footprint.

I’m a little stumped by how similar they are. The Mouser one (on the right) is from Bourns, but looking over the data sheet, I couldn’t find a model with a bushing and shaft length matching the one from the kit. The body of both units is essentially identical. Hopefully they are electrically close enough, too. I had to guess at how many pulses per rotation it should have.

I’m still chewing on another mechanical question. The kit is designed to have the PCB soldered to one end of the LCD, with the encoder mounted off the PCB, on the right of the LCD. I want to have the tuning knob centered below the LCD, so the PCB is going to have to stay with either the LCB or the encoder, and the other will have to be connected with wires. My initial thought was to mount the encoder on the PCB and wire the LCD remotely, but I’m beginning to favor mounting the PCB on the LCD and running wires to the encoder. The connection between the PCB and LCD will involve high-frequency digital signals, while the connection to the encoder is analog switch closures that have less potential for RF interference. It would be better to have the LCD signals cover a shorter distance so they radiate less.

On top of that, putting the PCB and the LCD together will make it easier to surround them with a shield.

All this rambling aside, yes, I’m making slow progress on the R2/T2 rig. When I’m working on a project, sometimes I spend a lot of time doing and other times I spend my time thinking. I’m a little out of my element with the mechanical design of the radio, so lately I’ve been planning the design carefully.

My ambivalence with Forth started back in the 1980′s, when an engineer named Tom Harsch mentored a very young me in digital electronics and computer architecture. Tom is an all-around engineer, versed in both hardware and software. He had a fondness for Forth, and he introduced it to me. Or perhaps I should say

ME FORTH TOM INTRODUCED

You see, the very first quirk one runs into when encountering Forth is its use of postfix notation to represent operations. While mainstream languages like BASIC and C would have syntax resembling this,

print 2 + 3

Or this,

printf(“%d\n”, 2 + 3);

Forth, in common with German, likes its verbs last. Here’s the Forth version:

2 3 + .

Don’t overlook that period, “.”, at the end. In Forth, that does not end a sentence; it is the command for printing a number.

Postfix notation is intellectually appealing, for several reasons. In postfix, every operation can be expressed with the same basic syntax, so there is no longer a need to distinguish between infix operators (+, -, *, etc.), unary prefix operators (like negation, -), and function calls. They all fit the same basic syntactic framework. Another advantage is that it maps very simply onto a stack-based processor model, which in turn can be implemented reasonably efficiently on many traditional CPUs or which really flies on dedicated hardware.

Forth uses postfix notation to permit the implementation of a simple compiler, which is usually built right into the run-time environment. The simplicity of the compiler results in further bizarre constructs, like the IF…ELSE…THEN statement. Not only are “ELSE” and “THEN” ordered backwards from pretty much every other language in the world, thanks to postfix notation, the “THEN” keyword comes after the code for the ELSE:

( condition ) IF ( then-actions ) ELSE ( else-actions ) THEN

On the bright side, this did give rise to a classic bumper sticker from the Forth Interest Group:

FORTH LOVE IF HONK THEN

Defining a function is straightforward, if you don’t mind punctuation:

: 2times 2 * ;

The colon (:) command defines a new “word” for the language. The next text, “2times”, is the name of the new word. That is followed by the instructions for the word and a semicolon (;) that ends the definition.

So what does this new word do? It multiplies whatever number came before it by 2. “5 2times .” is equivalent to “5 2 * .” and prints the number 10.

This syntax is admirably compact and naturally lends itself to a functional style. On the other hand, what is the name of the word doing after the colon?  In a postfix language, I would expect to quote the name and the function body, then use the defining word. Something like this:

’2times (2 *) :

Flip that around and add a “lambda” and it starts to look like LISP, but that’s a subject for another time. In Forth, this kind of quirkiness, where everything is postfix except for the parts that aren’t, is standard. It keeps Forth’s compiler simple, but at a cost in elegance.

Syntactic quirkiness aside, Forth has a  few things going for it. First, it makes extremely efficient use of machine resources. A reasonable Forth environment can fit in 4K of RAM and include a compiler, an interpreter, and room for a small application. A full-featured environment is larger, but still takes less resources than equivalent functionality in other languages. Forth is generally fairly speedy, too.

Forth is extremely versatile. The compiler is implemented in an extensible way. You can define Forth words that alter how the compiler works, giving another way to work at higher levels of abstraction.

The philosophy behind Forth encourages programs to be organized in a hierarchy of small, simple functions. Each layer of functions builds a higher level of abstraction than the one that lies below it. I like this kind of well-factored programming, and it would be nice to work in a language that encourages it.

That brings me to the J1 Forth CPU. This compact Verilog core is a work of brilliance, particularly in the way it uses the FPGA’s dual-port RAM in a carefully designed data path to achieve a high instruction rate. The instruction set architecture is pretty much pure Forth, and the implementation was written to be fast. James Bowman’s paper on the J1 (pdf) is well worth a read, and so is the Verilog source code.

Ever since I read the J1 paper, I’ve been itching to find a use for it. (Yes, I know, that’s a solution in search of a problem…) My oft-delayed R2/T2 transceiver project offered a chance. As I thought about what to put on the front panel, my mind strayed to thoughts of touch-panel LCDs. Wouldn’t it be nice to be able to defer most of the user interface decisions to software? It’s much easier to move a button on a screen than to un-drill a hole. eBay has a number of nice touch panels that would fit my chosen case perfectly.

Besides, I’ve been getting in a bit of a rut lately. Though there was a time when I learned every language I could find, lately I’ve been using C almost all the time. How better to shake things up than by implementing a touch-screen user interface in Forth?  My favorite way to learn a new language is to dive into a major project. In fact, I learned C by writing a text editor. Next I learned C++ by writing two text editors. Then I learned Tcl by writing a text editor, and Prolog by writing tax software. (Go figure.)

Eventually I came to my senses. First off, I’m so busy these days that I’m finding it hard to spend any time on the R2/T2, let alone write graphics software for it. A more serious problem, though, is that the Actel FPGA I have handy has only 6K of RAM and limited capability for ROM or flash. To do the graphical user interface, I would want fonts in two sizes, and the J1 on this FPGA would not be able to store even one. I was brainstorming ways to extend the J1′s address space into off-FPGA storage when I had my Arduino epiphany. It does not make sense to spend time engineering complex font storage when a cheap, off-the-shelf processor has 32K of flash and the gcc C compiler at the ready.

Even with the Arduino standing by, I can’t get avoid being busy. No, the R2/T2 will have to make do with switches and knobs. Maybe in the future I can replace them with a touchscreen.

That settled, only one problem remains: I no longer have a problem for the J1 and Forth to solve.

Oh, well…

Updated 1/18/13 to correct the IF…ELSE…THEN syntax.

Then a few weeks ago, I was given an Arduino. My perspective has shifted. Arduinos may be populist, they may be the Radio Shack Engineer’s Notebook of the microcontroller world, but they’re also well-designed development boards worthy of any engineer’s attention.

My Arduino came as part of a Sparkfun starter kit, which includes a breadboard, hookup wires, an RGB LED, packs of 1K and 10K resistors, and some fun sensors to play with, including a touch-sensitive resistor and a bend sensor. It amounts to a microcontroller-based building set, and would particularly appeal to anyone who wants to experiment with microcontrollers without having a specific project in mind. Though my son and daughter will be too young for the kit for a few more years, it caught my eye as exactly the sort of thing I might give to one of them to help them learn about what goes on inside a computer.

I set the accessories aside and focused on the Arduino, an Uno model in this kit. Arduino’s current foundation model, the Uno includes a Atmel Atmega328 microcontroller, on-board power supplies (5V and 3.3V), a USB serial interface, a general-purpose LED, and female sockets that break out the microcontroller pins.

The Atmel processor is surprisingly speedy. It has an 8-bit CPU running at 16 MHz, which was plenty of processing power for the things I was trying to do. Perhaps the biggest limitation of the processor is its 2K of RAM. The 32K of flash on-board is great, and conservative programming techniques can fit a surprising amount of functionality into 2K of RAM, but sometimes it’s easier and faster to use a controller with more RAM.

The USB serial interface was a surprise as well. It is implemented by a second, smaller Atmel CPU, programmed to operate as USB-to-serial interface chip akin to the popular FTDI FT232 family. According to Arduino’s creators, the Atmel CPU was less expensive than the FTDI equivalent. Beyond being an interface, the second CPU has a USB bootloader and an ICSP (in-circuit serial programming) header of its own, so it can be reprogrammed just like the Atmega328. The USB CPU is in a tiny QFN package, and most of its I/O lines are not brought out. Still, the ability to reprogram it opens up a lot of interesting possibilities.

Arduino’s native programming environment uses a simplified C-like language. Since I’m comfortable with standard C and prefer test-driven development, I followed Nick Christensen’s detailed instructions on how to set up an Arduino development environment with gcc, Unity, and CMock. The gcc compiler is an industry standard tool these days, and I like Unity and CMock for unit testing.

Then I found out I was a snob. The Arduino wasn’t a toy. As I dug into its schematic and capabilities, I found a well-designed little development board. It was designed with cost-reduction in mind, for sure, but without losing sight of giving access to the entire capabilities of the processor. One processor pin drives an LED, for instance, but that line is also brought out to a header, making it available for other uses. The analog input pins are brought out without analog buffering, so they are available for digital I/O. Even the serial interface pins used to download code over USB can be repurposed.

There are other low-cost development boards, some directly competing with Arduino and others aiming for a slightly different audience. Here Arduino’s advantage is its popularity. Between Radio Shack and Micro Center, I can buy an original or cloned Arduino at retail from at least four stores within three miles of my house. That is surely not true for the entire world, but Arduino and software-compatible clones are also readily available online.

For my last small project, when I needed a microcontroller, I picked an inexpensive MSP430F2011 because TI’s EZ430 USB stick (which was a freebie from TI) could serve as the programmer. Next time, there’s a good chance I will use a genuine Arduino, one of the clones, or maybe just use these development tools with a plain Atmega328.

Yep, Arduino is worth a look, even for those used to the traditional “professional” world of microcontroller design.

Tom Perrera has put together a nice overview of Rich’s keys, starting from simple straight keys and working up to novel automatic keys like this.

My mechanical skills are limited. I have a lot of respect for those who can imagine and construct fine machines like this.

Carl Herbert, AA2JZ designed and built this 40m transceiver, drawing on the NW8020 as a source of inspiration. It uses NE602 mixers and two PIC microcontrollers, and includes a keyer and a frequency counter.

I was impressed by Carl’s tidy Manhattan-style assembly technique, in which small pieces of copperclad board (PCB material) are glued down and used as points to which wires and component leads are soldered. Most impressive is that he used the same technique for the chips. Carl must have a lot of patience to be able to position the little “nibbles” of copperclad at 0.1″ spacing to take the IC leads.

In the first installment of How Delta-Sigma Works, I presented the basic first-order delta-sigma converter loop. Now it is time to begin digging a little deeper and look at how the loop works. To do this, we will need the mathematical tools of closed-loop control systems. Even without the mathematics, thinking about a delta-sigma modulator as a closed-loop controller can bring insight into how it works.

In engineering, closed-loop control is often used to keep a system working at a setpoint despite environmental disturbances or variations in the system itself. A furnace thermostat is a simple closed-loop controller, turning on the heat when the temperature drops below a setpoint and turning it back off when the temperature is above. Another example is vehicle cruise control. Unlike a thermostat, which usually has a binary output (on/off), cruise control adjusts the engine fuel control to maintain a roughly constant speed. In my car, it does this by physically moving the gas pedal. The environmental variations cruise control can encounter include hills, the quality of the fuel, and headwinds or tailwinds. The closed-loop controller adjusts the gas pedal as needed to maintain constant speed despite these effects.

A simple closed-loop control system can be drawn as in the figure below. The reference input, r, is the command input to the controller. In the thermostat example, r is the setpoint temperature, while for cruise control, it is the set speed. The output, y, is the controlled value. This is not necessarily in the same units as the reference input r. For example, in the cruise control, y might be a direct measurement of speed, or it might be something else related, such as a cumulative count of revolutions of the vehicle’s wheels.

In between the input r and the output y is the control loop. At the bottom of the loop, in its feedback path, a block h processes the output y into a form that is subtracted from the input r to create an error signal e. This error signal is an indication of how far the controller is from the desired operating point. The goal of a controller design is to keep e near, if not at, 0. The feedback block h can represent many different things. In the example of a cruise control system with the output y in units of distance, h might calculate speed by computing the derivative of y. In other systems, h might simply scale the value to convert its units. If y and r are already in the same units, such as in a thermostat example, h can pass through y unchanged ().

Now that the error signal has been calculated, it is processed by the controller gc, the output of which goes to the “plant” being controlled. (To a controls engineer, anything being controlled, whether a car, a heating system, or a giant factory, is a plant.) The plant is represented by the box g_p. The processing in the controller g_c is easy to grasp. The controller calculates some function of its input in order to find the command it should give the plant.

What happens in this plant, g_p, may be a little harder to imagine. The function g_p is a mathematical model of the physics of the actual plant. It may be calculated from basic principles (a physicist’s delight!), or it may be an empirical model derived from the inputs and outputs of the actual plant. In any event, a reasonable guess at the function g_p is necessary before one can design a closed-loop controller.

A delta-sigma modulator also has a closed loop, which suggests that perhaps insight can be gained by comparing it to a controller. The first-order delta-sigma analog-to-digital converter from the first installment, is shown again below.

The resemblance to a closed-loop controller is clear when one groups the blocks as in the next figure. The subtractor has the same function in both diagrams, comparing the input to the output. The integrator functions as the controller, g_c, and the analog-to-digital convertor and its register are the plant, g_p, being controlled. The digital-to-analog converter is the feedback path, h.

This grouping gives immediate insight into how the delta-sigma modulator does its magic: It is a linear controller for an analog-to-digital converter, which is the plant. The controller is always trying to drive that plant’s output as close as possible to the setpoint, and does so by adding up (integrating) the error signal. Also, since the integrator is adding up the history of the error signal, it can be seen that although the output at any given moment may not equal the input, the long-term average will be equal. That integrator will try to keep the long-term average of the error, e, equal to 0.

There are many controllers that can control a given plant. PID (proportional-integral-derivative) controllers are simple and very popular, while more sophisticated controllers can be designed using other techniques. If a delta-sigma modulator is a control loop, it is reasonable to ask if controllers other than an single integrator will result in a better-performing modulator. In fact, other control functions can be used in delta-sigma modulators and can give lower noise or more desirable characteristics in the frequency domain.

Finally, one should not get too carried away with a linear control model. Analog-to-digital and digital-to-analog converters are inherently non-linear, while the mathematics of control theory primarily deals with linear systems. Assuming linear behavior will get us a long way towards understanding delta-sigma techniques, but it is important not to take the analogy too far.

Next in this series: Noise shaping, the frequency-domain secret behind delta-sigma data converters.

Dana’s inspiration for the little field strength meter came when he was teaching a radio class to college students and wanted to show them the pattern of a Yagi-Uda antenna. He explained that cheap digital multimeters like this Harbor Freight model were readily available in the physics lab, so he built the field-strength circuit and  a little plug-in adapter using the DMM as the readout.

Though I don’t see much need for a field-strength meter in my shack, I admire Dana’s inventiveness in coming up with a solution that is cheap, convenient, and inexpensive.

Thanks for reading skywired.net.