The documentation provided by the seller was very helpful, but it omitted a couple of key specs such as the intended phase-detector comparison frequency, as well as important performance characteristics including phase noise and lockup time. Get the comparison frequency wrong, and your synthesizer may work only in "spread spectrum" mode! So, before contemplating any embedded applications for the Stellex synthesizer, it made sense to develop an experimental application that could control the synth from my Windows PC, with the goal of determining the missing specs empirically.

Several recent projects have used the LMX2326 PLL and similar chips, so I already had a good head start at programming the synthesizer. My control program, stellex.exe, along with all of the schematics and other documentation I received from the seller, may be downloaded here.

Full C++ source code, compatible with both Microsoft Visual Studio 2005 for Win32 and AVR-GCC for Atmel microcontrollers, is also included in this zipfile.

To run stellex.exe on a Windows 2000 or XP box, you will need to connect the synthesizer to a parallel port on your PC as follows:

20-pin connector on board	DB-25 LPT port connector	Signal
12	4	LATCH
10	3	DATA
7	2	CLOCK
14	15	LOCK_DETECT
1,2,3,4,17,18	18-25	GROUND

Next, you'll need to determine the base address of the parallel port. This can usually be done by inspecting the first Input/Output Range entry in the Resources tab for your parallel port in the Windows Device Manager. It will usually be 378, 278, or 3BC.

Once you know this base address, you should be able to run a command of the form stellex 3bc at a DOS prompt or as a Start->Run command from the taskbar.

The synthesizer should lock within a few hundred milliseconds at most. If, instead, you see a continuous line of periods (. . .), you'll need to do some troubleshooting. Search for a few of the different ways to verify that your parallel-port base address is correct. Try setting the port to standard mode, rather than ECP/EPP. Hang a scope on pin 2 (the first data line) to watch for activity when stellex.exe starts up.

One possible source of trouble: in order to achieve reliable lockup detection, I had to remove a 1K resistor from my synthesizer board between pin 14 of the LMX2326 (Fo/Ld) and pin 14 of the 20-pin IDC header. This resistor does not appear on the schematic. Replace it with a much smaller one (100 ohms or so), or a jumper. Otherwise, the pullup resistors in your PC's parallel-port interface may be too "stiff" to allow the lock-detect line to be read.

Another problem lies in the reversal of connections to pins 19 and 20 in at least some versions of the 6942A_2 ("CODELOADER INTERFACE CABLE") diagram provided with the synthesizer. Pin 19 is the 10 MHz output sample from the TCVCXO, while pin 20 is the TCVCXO's tuning control voltage. These pins are shown correctly on the other two diagrams ("BEST_INTERFACE_SCHEMATIC2" and "GOOD_INTERFACE_SCHEMATIC1").

Other than these minor issues, the connections shown on the CODELOADER_CABLE.pdf interface cable schematic are all that's necessary to run stellex.exe.

Update, July 10, 2010: I've revised the stellex.exe control program to support a wider range of oscillators. Three new optional command-line parameters allow you to specify the minimum, maximum, and initial tuning frequencies in MHz. For example,

stellex 3bc 9000 11000 10000

As always, you can run stellex.exe with no command-line parameters for a list of options supported by the current version.

• 5 MHz: Loop unstable
• 1 MHz: Loop locks, but with large 'ears' a few kHz from the carrier
• 500 kHz: Relatively-stable, less peaking
• 250 kHz: Seems optimal; stable and consistent behavior during frequency transitions
• 200 kHz: Also relatively stable
• 100 kHz: Very slow locking/stabilization times observed
• 50 kHz: Loop unstable

The phase-noise measurements below were taken with the 250 kHz Fcomp value.

Once the board was operating from a stable 10 MHz reference, another problem with the phase-noise measurement process became apparent: the synthesizer was too clean for the HP 8566B spectrum analyzer to measure accurately at offsets beyond about 5 kHz from the carrier. Note the increasing convergence of the blue analyzer-baseline trace and the green measurement trace in the graph above. This situation is worse than it looks: a proper noise baseline trace, if taken at the measurement frequency of 9 GHz where harmonic mixing is used, would be at least 6 dB higher than these 100-MHz traces.

A partial solution to this measurement difficulty can be reached by opening up the HP 8566B and replacing its own YIG synthesizer reference with a cleaner version obtained from an HP 8662A signal generator.

Briefly, when the analyzer is tuned to center frequencies near 9 GHz, an internal "M/N" reference signal is generated at approximately 189.565 MHz. The M/N signal is used as a basis for phase-locking the analyzer's local oscillator, so any improvement in M/N spectral purity will improve the analyzer's baseline noise performance. (See HP Application Note 283-3, chapter 11, for an overview of this technique as it applies to the physically-similar HP 8672A microwave signal generator.)

The purple baseline trace reflects this improvement, as does the red measurement trace... not a dramatic difference, but enough to reveal that the Stellex synthesizer is performing a few dB better than initially observed. The peaking characteristics in the analyzer's baseline trace, even the improved one, are still clearly visible in the measurement trace at offsets between 10 and 30 kHz.

Important: If you add an external clock input to your board, keep both its signal path and ground return away from the PLL chip's RF input circuitry, including the YIG input jacks and prescaler/buffer MMICs. You may have trouble getting the synthesizer to lock if there's any clock-induced ground bounce or crosstalk. Avoid doing what I did in this photo, where the ground return from the 10 MHz clock ran near the RF input traces. Ideally, any clock-input hardware and wiring should be added near the opposite edge of the board, as seen in my later prototypes below.

Even if you're using a different microcontroller (PIC, etc.) in your project, I'd recommend basing your firmware development on the stellavr.cpp module in this zipfile. It's much easier to read, debug, and customize than the Windows version mentioned above.

Another Atmel implementation used similar firmware with the ATmega163. I used the ATmega163 here because it was handy; this version of the synthesizer could also have used an ATTiny2313 or similar low-end part.

Below, an interior view reveals the same BCD thumbwheel switch and MC100EL16 input-clock conditioner that the earlier project used, along with the necessary regulators to allow operation from a single +12V supply. The clock shaper circuit is identical to the input stage in an earlier comb generator project.

A toggle switch allows selection of an external 10 MHz source or the board's own 10 MHz TCXO. Again, be careful to keep the LMX2326's clock-reference and RF paths separate.

In-band phase noise is about -65 dBc/Hz, or approximately 15 dB better than composite noise (AM+PM) measurements made via spectrum analysis, either with PN.EXE or as seen in the 8566B photo above. I'm not sure why the difference is so large... some AM noise may be showing up on the spectrum analyzer and not on the 3048A, but I'm not sure where it would come from. More investigation is needed (see March 13, 2013 update below).

The clock source for this measurement was the 10 MHz output from a Trimble Thunderbolt.

You were right (in private email) about the unit not oscillating up to 10GHz and higher. The actual + voltage at the YIG was not high enough. There was about 1.8V dropped through the controller, which meant that the YIG would never reach the same frequency as when a direct regulated voltage was applied to it.

Regarding (PIC programming), I found on the net, on the website of Andy Talbot, G4JNT, some of the info that I needed. Andy and his radio club have done extensive work with beacons, repeaters, etc, and they have programmed LM2326 PLLs for these uses. I wrote to Andy, and he was kind enough to send me 2 links which he had overlooked putting on his site, which deal directly with programming 12F675 PICs to control LM2326s. Here are the links...

http://www.g4jnt.com/BridgeWave_Synth.pdf
http://www.g4jnt.com/bridgewave.zip

You may find something interesting there, courtesy of Andy.

In this photo at right, I've modified one of the synthesizers shown earlier on this page by replacing its original ATmega163 chip with a USnooBie. As a result, I can reprogram the board over USB, instead of dragging my Atmel STK-500 programmer out of the closet.

The source code and precompiled .hex file may be downloaded here. A makefile is provided to recompile the .cpp module if desired, or you can just run p.bat to upload the .hex file after putting the USnooBie in its bootloader mode as demonstrated in the video on the USnooBie page.

To get a copy of the required avrdude.exe programmer utility, you'll need to install either the WinAVR toolkit distribution if you're working under Windows, or the appropriate version of avr-gcc and its associated tools for other platforms. (You could also use the more up-to-date MHV AVR Tools distribution or Atmel's own AVR Studio toolchain, but I'm still using WinAVR as of this writing.)

The connections between the Stellex board's 0.1" header and the USnooBie are listed in the table below.

Synthesizer pin	USnooBie pin	Signal
10	B1	DATA
7	B2	CLOCK
12	3	LATCH
14	B4	LOCK_DETECT
1,2,3,4,17,18	GND	GROUND
5,6	V+	+5 VDC

In addition to the required connections to the Stellex board, the firmware assumes that a two-color red/green LED is connected to the C4 and C5 pins for use as a lock indicator. The LED's common anode is tied to the +5V pin on the USnooBie board, and appropriate resistors (470 ohms or so) are used in the two cathode leads to limit the current.

The firmware expects the frequency in MHz to be entered with a 4-digit BCD thumbwheel switch. Each of the four switch digits has a common contact and four other contacts marked 1, 2, 4, and 8. The switch represents a given digit from 0-10 by closing a circuit between its common contact and the appropriate combination of binary place values that add up to the digit in question.

You'll need to connect the individual digits' common lines to pins D0 (LSD, "ones" place) through D3 (MSD, "thousands" place). The binary place-value contacts at all four switches are connected in parallel with 1N914 or similar steering diodes and tied to pins C0 ('1'), C1 ('2'), C2 ('4'), and C3 ('8'). Click on the photo above for a closer look at this arrangement.

In operation, the microcontroller "addresses" each switch in turn by grounding that switch's common pin at D0-D3, and then reads the switch's value by polling the rudimentary four-bit data bus created by wire-OR'ing the four switches' binary place-value terminals together with the steering diodes. This scheme allows values from 0000-9999 to be read with only eight wires. (Frequencies above 10 GHz are entered with the '1' digit omitted; e.g., 0050 would be 10050 MHz.)

Finally, when using a USnooBie or similar board to drive the synthesizer, you can (and should) omit the controller board's own power-distribution components. The Atmel chip should receive +5V only from the supply that drives the rest of the synthesizer hardware, even when it's being programmed over USB. You could use Schottky diodes to power the microcontroller from either USB or the synthesizer supply, but this can cause the MCU to send power to the PLL chip through its output pins, causing flaky behavior (at best). In the USnooBie's case, you should omit F1, IC2, JP4, and the jumper that would ordinarily be used at D3.

Note: It appears that the first few USnooBie boards have shipped with the wrong bootloader code. If you have trouble getting Plug-and-Play to recognize the board properly and install its V-USB drivers, and you don't have the necessary hardware programmer to reflash the ATmega328P with the necessary atmega328p_2k_12000000.hex file from the USnooBie Downloads page, you'll need to contact frank (at) circleofcurrent (dotcom) for assistance.

It's possible that the excessive close-in noise reported by the HP 3048A is caused by violation of the small-angle criterion associated with L(f) measurements (see page 7 of Decker & Semple), but why does the inband noise between 100 Hz - 1 kHz appear to be underestimated by the 3048A? The conclusion from the April 2009 measurement still stands: "More investigation is needed."