Archive for category Amateur Radio

LF Crystal Tester: Bring the Noise!

The OLED display refresh contributes 100 Hz noise pulses to the low-level sine wave from the crystal test fixture:

OLED Enabled - 100 Hz display refresh

OLED Enabled – 100 Hz display refresh

Disabling the display by activating its powersave option reveals 60 Hz pulses from the USB port on the Arduino Nano:

OLED Powersave - 60 Hz USB Ground Loop

OLED Powersave – 60 Hz USB Ground Loop

Unplugging the USB cable, leaving just the +5 VDC power supply and coax cable to the oscilloscope, solves most of the problem:

OLED Powersave - USB unplugged

OLED Powersave – USB unplugged

A closer look shows some (relatively) low frequency noise remains in full effect:

OLED Powersave - USB unplugged - detail

OLED Powersave – USB unplugged – detail

Disabling the display while measuring the crystal seems sensible, although, to avoid surprises, a pushbutton should start the process. Unplugging the USB port puts a real crimp in the data collection, although that’s probably survivable with a USB isolator, one of which is on the way around the planet.

The remaining low-level chop requires more thought. Somewhat to my surprise, holding the Arduino Reset button down doesn’t change much of anything, so it’s not a firmware thing.

Those 10 µF coupling caps gotta go.

With the OLED dark and the USB carrying data:

Spectrum - OLED Powersave - USB in

Spectrum – OLED Powersave – USB in

Compare that to the first pass:



Tamping down the noise seems to reduce the overall amplitude variation, but it also makes the capacitor-in and capacitor-out curves more consistent. There may be other things going on that I haven’t accounted for.

The peak frequencies differ by 0.2 Hz, which is probably due to a few degrees of temperature difference. Obviously, it’s badly in need of a temperature calibration & correction.


, ,

1 Comment

LF Crystal Tester: DDS Buffer Amp

The Big Ideas: the DDS output, being more-or-less constant, needs a variable-gain amp to set the crystal drive level. The amp also fixes the impedance mismatch between the DDS output and the crystal, which may not be much of a problem for the (very) high ESR quartz tuning fork resonators in play.

The AD8950 DDS output feeds a 70 MHz (-ish) elliptical reconstruction filter chopping off image frequencies descending from the 125 MHz sampling clock, with a 100 Ω (-ish) output impedance that’s just about purely resistive at 60 kHz. An on-board 3.9 kΩ resistor (labeled with 392 on their schematic) sets the full-scale output current to 10 mA for a peak voltage of 1 V. The module uses only the + output of the differential pair, which means the sine wave runs from 0 V to 1 V: 1 Vpp = 500 mVpeak = 353 mVrms (ignoring the 500 mV offset).

Pin header J3 normally sports a jumper to connect the 3.9 kΩ RSET resistor, but you can insert an external resistor to increase the resistance and decrease the output current:

IOUT = 32 × 1.248 V / RSET

A little hot-melt glue action produced a suitable lashup from a 5 kΩ trimpot:

AD9850 DDS Module - 5 k external RSET trimpot

AD9850 DDS Module – 5 k external RSET trimpot

The pillars of green wire insulation forestall screwdriver shorts to the bare pin headers, although that’s less of risk with the upper insulating foam sheet in place:

Crystal Tester - First Light

Crystal Tester – First Light

A 5 kΩ trimpot can vary the output voltage downward by a factor of 2 = -6 dB, more or less.

All the quartz tuning fork resonator specs I’ve found, none of which may apply to the units on hand, seem to require no more than 1 µW drive. Given a resonator’s equivalent series resistance of around 20 kΩ (for real!), the drive voltage will be 150 mV (-ish):

1 µW = V² / 20 kΩ, so V = sqrt(20×10³) = 141 mV

The nominal version of the crystal tester had a 50 Ω input impedance, so I picked a MAX4165 op amp with mojo sufficient for anything over 25 Ω; in retrospect, a lighter load than 48 Ω would be fine.

In any event, the amp looks like this:

MAX4165 Buffer Amp

MAX4165 Buffer Amp

What looks like a DIP switch is really the 3×2 jumper header just to the right of the foam insulation, in front of the SOT23 space transformer PCB carrying the MAX4165. No jumper = 0 dB gain, then 6 dB steps upward from there. The -6 dB trimpot range gives more-or-less continuous output tweakage across 24 dB, -6 dB to +18 dB, which is certainly excessive. The 24 Ω terminating resistors provide 6 dB loss into the crystal, so the effective range is -12 to +12 dB, with 0 dB = 350 mVrms and -6 dB = 150 mVrms (-ish) at the crystal.

It’s a non-inverting amplifier, which (also in retrospect) probably isn’t a win:

  • Yet Another Bypass Cap on the cold end of the gain-setting resistors
  • Overly elaborate VCC/2 biasing to maintain sufficiently high input impedance

I’m reasonably sure all those big caps contribute to some low-level motorboating, but haven’t tracked it down.


1 Comment

Teledyne 732TN-5 Relay: Zowie!

The first pass at the crystal tester used a manual jumper to switch the 33 pF series capacitor in / out of the circuit:

Quartz crystal resonance test fixture

Quartz crystal resonance test fixture

With an Arduino close at hand, however, a relay makes somewhat more sense. For long-forgotten reasons, I have a small fortune in Teledyne 732TN-5 relays intended for RF switching:

Teledyne 732TN-5 Relay

Teledyne 732TN-5 Relay

The 7820 date code on the side suggests they’ve been in the heap basically forever, although some fractions of Teledyne still exist and you can apparently buy the same relay today at 50 bucks a pop. It’s definitely overqualified for this job and you can surely get away with an ordinary DIP DPDT (or, heck, even SPST) relay.

It seems I picked a hyper-bright white LED: the red ink tones it down a bit. Black might be more effective. A diffused LED may be in order.

The “TN” suffix indicates a built-in transistor driver with a catch diode on the relay coil, so the relay needs power, ground, and a current drive into the transistor’s base terminal:

Teledyne 732TN relay - drive schematic

Teledyne 732TN relay – drive schematic

Even with the internal catch diode, I ran the +5 V power through a 12 Ω resistor to a 10 µF cap in hopes of isolating the inevitable switching transients from the DDS and log amp. As a result, the turn-on transient isn’t much of a transient at all:

Teledyne 732TN Relay - turn-on transient

Teledyne 732TN Relay – turn-on transient

The 560 mV drop suggests a 47 mA coil current through the 12 Ω resistor, just about spot on for a 100 Ω coil.

The energy stored in the coil makes the turn-off transient much steeper:

Teledyne 732TN Relay - turn-off transient

Teledyne 732TN Relay – turn-off transient

Note the 1.5 µs delay from the falling control input to the relay opening. Granted, it’s running at 4.7 V, not the rated 5 V, but that’s still rather peppy. The turn-on delay seems to be about the same, making the datasheet’s “6 ms nominal” operating time look rather conservative.

Dang, that’s a nice gadget!



AD9850 DDS Module: 1.3 inch I²C OLED FTW

A white 1.3 inch I²C OLED turns out to be much more readable than the yellow-blue 0.96 inch version:

Arduino with OLED - white 1.3 inch

Arduino with OLED – white 1.3 inch

Of course, after you make it readable, you immediately make room to cram more data on it:

White 1.3 inch OLED on crystal tester

White 1.3 inch OLED on crystal tester

That’s on the proto board with the Arduino and AD9850 DDS ticking away on the left; the bright red MCP4725 DAC will eventually drive the scope’s X axis. Shifting the display to the I²C interface and cleaning up my SPI initialization code worked wonders: the DDS now steps a sine wave at 0.1 Hz (pretty nearly) intervals from 57.0 to 60.3 Hz.

, ,


AD9850 DDS Module: OLED Display

Those little OLED displays might just work:

Arduino with OLED - simulated DDS

Arduino with OLED – simulated DDS

The U8X8 driver produces those double-size bitmap characters; the default 8×8 matrix seem pretty much unreadable on a 0.96 inch OLED at any practical distance from a benchtop instrument. They might be workable on a 1.3 inch white OLED, minus the attractive yellow highlight for the frequency in the top line.

The OLED uses an SPI interface, although the U8X8 library clobbers my (simpleminded) SPI configuration for the AD9850 DDS and I’ve dummied out the DDS outputs. A soon-to-arrive I²C OLED should resolve that problem; changing the interface from SPI to I²C involves changing the single line of code constructing the driver object, so It Should Just Work.

The U8X8 driver writes directly to the display, thus eliminating the need for a backing buffer in the Arduino’s painfully limited RAM. I think the library hauls in all possible fonts to support font selection at runtime, even though I need at most two fonts, so it may be worthwhile to hack the unneeded ones from the library (or figure out if I misunderstand the situation and the Flash image includes only the fonts actually used). Each font occupies anywhere from 200 to 2000 bytes, which I’d rather have available for program code. Chopping out unused functions would certainly be less useful.

The display formatting is a crude hack just to see what the numbers look like:

    int ln = 0;
    ln += 2;

    TestFreq.fx_64 = ScanTo.fx_64 - ScanFrom.fx_64;
    u8x8.draw2x2String(0,ln,"W       ");
    ln += 2;

    u8x8.draw2x2String(0,ln,"S       ");
    ln += 2;

    TestFreq.fx_32.high = SCAN_SETTLE;                    // milliseconds
    TestFreq.fx_32.low = 0;
    TestFreq.fx_64 /= KILO;                               // to seconds
    u8x8.draw2x2String(0,ln,"T       ");
    ln += 2;

Updating the display produces a noticeable and annoying flicker, which isn’t too surprising, so each value should have an “update me” flag to avoid gratuitous writes. Abstracting the display formatting into a table-driven routine might be appropriate, when I need more than one layout, but sheesh.

I calculate the actual frequency from the 32 bit integer delta phase word written to the DDS, rather than use the achingly precise fixed point value, so a tidy 0.100 Hz frequency step doesn’t produce neat results. Instead, the displayed value will be within ±0.0291 Hz (the frequency resolution) of the desired frequency, which probably makes more sense for the very narrow bandwidths involved in a quartz crystal test gadget.

Computing the frequency step size makes heavy use of 64 bit integers:

//  ScanStep.fx_64 = One.fx_64 / 4;                       // 0.25 Hz = 8 or 9 tuning register steps
  ScanStep.fx_64 = One.fx_64 / 10;                    // 0.1 Hz = 3 or 4 tuning register steps
//  ScanStep.fx_64 = One.fx_64 / 20;                    // 0.05 Hz = 2 or 3 tuning register steps
//  ScanStep = HzPerCt;                                   // smallest possible frequency step

The fixed point numbers resulting from those divisions will be accurate to nine decimal places; good enough for what I need.

The sensible way of handling discrete scan width / step size / settling time options is through menus showing the allowed choices, with joystick / joyswitch navigation & selection, rather than keyboard entry. An analog joystick has the distinct advantage of using two analog inputs, not four digital pins, although the U8X8 driver includes a switch-driven menu handler.

There’s a definite need to log all the values through the serial output for data collection without hand transcription.

The Arduino source code as a GitHub Gist:

, ,


AD9850 DDS Module: Temperature Sensitivity

While tinkering with the SPI code for the AD9850 DDS module, I wrote down the ambient temperature and the frequency tweak required to zero-beat the 10 MHz output with the GPS-locked oscillator. A quick-n-dirty plot summarizing two days of randomly timed observations ensued:

AD9850 DDS Module - Frequency vs Temperature

AD9850 DDS Module – Frequency vs Temperature

The frequency offset comes from the tweak required to zero-beat the output by adjusting the initial oscillator error: a positive tweak produces a smaller count-per-hertz coefficient and reduces the output frequency. As a result, the thermal coefficient sign is backwards, because increasing temperature raises the oscillator frequency and reduces the necessary tweak. I think so, anyway; you know how these things can go wrong. More automation and reliable data would be a nice touch.

Foam sheets formed a block around the DDS module, isolating it from stray air currents and reducing the clock oscillator’s sensitivity:

AD9850 DDS module - foam insulation

AD9850 DDS module – foam insulation

I used the ambient temperature, because the thermocouple inside the foam (not shown in the picture) really wasn’t making good contact with the board, the readings didn’t make consistent sense, and, given a (nearly) constant power dissipation, the (average) oscillator temperature inside the foam should track ambient temperature with a constant offset. I think so, anyway.

The coefficient works out to 0.02 ppm/°C. Of course, the initial frequency offset is something like -400 Hz = 3 ppm, so we’re not dealing with lab-grade instrumentation here.



AD9850 DDS Module: Hardware Assisted SPI and Fixed-point Frequency Stepping

Having conjured fixed-point arithmetic into working, the next step is to squirt data to the AD9850 DDS chip. Given that using the Arduino’s hardware-assisted SPI doesn’t require much in the way of software, the wiring looks like this:

Nano to DDS schematic

Nano to DDS schematic

Not much to it, is there? For reference, it looks a lot like you’d expect:

AD9850 DDS Module - swapped GND D7 pins

AD9850 DDS Module – swapped GND D7 pins

There’s no point in building an asynchronous interface with SPI interrupts and callbacks and all that rot, because squirting one byte at 1 Mb/s (a reasonable speed for hand wiring; the AD9850 can accept bits at 140+ MHz) doesn’t take all that long and it’s easier to have the low-level code stall until the hardware finishes:

#define PIN_HEARTBEAT    9          // added LED

#define PIN_RESET_DDS    7          // Reset DDS module
#define PIN_LATCH_DDS    8          // Latch serial data into DDS

#define PIN_SCK        13          // SPI clock (also Arduino LED!)
#define PIN_MISO      12          // SPI data input
#define PIN_MOSI      11          // SPI data output
#define PIN_SS        10          // SPI slave select - MUST BE OUTPUT = HIGH

void EnableSPI(void) {
  digitalWrite(PIN_SS,HIGH);        // set SPI into Master mode
  SPCR |= 1 << SPE;

void DisableSPI(void) {
  SPCR &= ~(1 << SPE);

void WaitSPIF(void) {
  while (! (SPSR & (1 << SPIF))) {

byte SendRecSPI(byte Dbyte) {           // send one byte, get another in exchange
  SPDR = Dbyte;
  return SPDR;                          // SPIF will be cleared

With that in hand, turning on the SPI hardware and waking up the AD9850 looks like this:

void EnableDDS(void) {

  digitalWrite(PIN_LATCH_DDS,LOW);          // ensure proper startup

  digitalWrite(PIN_RESET_DDS,HIGH);         // minimum reset pulse 40 ns, not a problem
  delayMicroseconds(1);                     // max latency 100 ns, not a problem

  DisableSPI();                             // allow manual control of outputs
  digitalWrite(PIN_SCK,LOW);                // ensure clean SCK pulse
  PulsePin(PIN_SCK);                        //  ... to latch hardwired config bits
  PulsePin(PIN_LATCH_DDS);                  // load hardwired config bits = begin serial mode

  EnableSPI();                              // turn on hardware SPI controls
  SendRecSPI(0x00);                         // shift in serial config bits
  PulsePin(PIN_LATCH_DDS);                  // load serial config bits

Given 32 bits of delta phase data and knowing the DDS output phase angle is always zero, you just drop five bytes into a hole in the floor labeled “SPI” and away they go:

void WriteDDS(uint32_t DeltaPhase) {

  SendRecSPI((byte)DeltaPhase);             // low-order byte first
  SendRecSPI((byte)(DeltaPhase >> 8));
  SendRecSPI((byte)(DeltaPhase >> 16));
  SendRecSPI((byte)(DeltaPhase >> 24));

  SendRecSPI(0x00);                         // 5 MSBs = phase = 0, 3 LSBs must be zero

  PulsePin(PIN_LATCH_DDS);                  // write data to DDS

In order to have something to watch, the loop() increments the output frequency in steps of 0.1 Hz between 10.0 MHz ± 3 Hz, as set by the obvious global variables:


      TestCount.fx_64 = MultiplyFixedPt(ScanFreq,CtPerHz);
      printf("%12s -> %9ld\n",Buffer,TestCount.fx_32.high);


      ScanFreq.fx_64 += ScanStep.fx_64;

      if (ScanFreq.fx_64 > (ScanTo.fx_64 + ScanStep.fx_64 / 2)) {
        ScanFreq = ScanFrom;
        Serial.println("Scan restart");

Which produces output like this:

DDS SPI exercise
Ed Nisley - KE4ZNU - May 2017

Inputs: 124999656 = 125000000-344
Osc freq: 124999656.000000000
Hz/Ct: 0.029103750
Ct/Hz: 34.359832926
0.1 Hz Ct: 3.435983287
Test frequency:  10000000.0000
Delta phase: 343598329

Scan limits
 from:   9999997.0
   at:  10000000.0
   to:  10000003.0

Sleeping for a while ...

Startup done!

Begin scanning

  10000000.0 -> 343598329
  10000000.1 -> 343598332
  10000000.2 -> 343598336
  10000000.3 -> 343598339
  10000000.4 -> 343598343
  10000000.5 -> 343598346
  10000000.6 -> 343598349
  10000000.7 -> 343598353
  10000000.8 -> 343598356
  10000000.9 -> 343598360
  10000001.0 -> 343598363
  10000001.1 -> 343598367
  10000001.2 -> 343598370
  10000001.3 -> 343598373
<<< snippage >>>

The real excitement happens while watching the DDS output crawl across the scope screen in relation to the 10 MHz signal from the Z8301 GPS-locked reference:

DDS GPS - 10 MHz -48 Hz offset - zero beat

DDS GPS – 10 MHz -48 Hz offset – zero beat

The DDS sine in the upper trace is zero-beat against the GPS reference in the lower trace. There’s no hardware interlock, but they’re dead stationary during whatever DDS output step produces exactly 10.0000000 MHz. The temperature coefficient seems to be around 2.4 Hz/°C, so the merest whiff of air changes the frequency by more than 0.1 Hz.

It’s kinda like watching paint dry or a 3D printer at work, but it’s my paint: I like it a lot!

The Arduino source code as a GitHub Gist: