Posts Tagged Improvements

LF Crystal Tester: Pretty Plots

A slight modification spits out the (actual) frequency and dBV response (without subtracting the 108 dB intercept to avoid negative numbers for now) to the serial port in CSV format, wherein a quick copypasta into a LibreOffice Calc spreadsheet produces this:



Changing the center frequency and swapping in a 60 kHz resonator:



Much prettier than the raw scope shot with the same data, there can be no denyin’:

Log V vs F - 32766 4 Hz - CX overlay

Log V vs F – 32766 4 Hz – CX overlay

I think the wobbulations around the parallel resonant dip come from the excessively hugely too large 10 µF caps in the signal path, particularly right before the log amp input, although the video bandwidth hack on the AD8310 module may contribute to the problem. In any event, I can see the log amp output wobbling for about a second, which is way too long.

Anyhow, the series-resonant peaks look about 1 Hz wide at the -3 dBV points, more or less agreeing with what I found with the HP 8591 spectrum analyzer. The series cap is a bit smaller, producing a slightly larger frequency change in the series resonant frequency: a bit under 2 Hz, rather than the 1 Hz estimated with the function generator and spectrum analyzer.

I still don’t understand why the parallel resonant dip changes, although I haven’t actually done the pencil pushing required for true understanding.

Ain’t they lovely, though?


, ,


Proto Board Holder: Revised Screw Mounts

Improving the crystal tester’s (nonexistent) grounding requires a band of copper tape around the inside of the proto board holder. Rather than cut the tape lengthwise to fit the holder, a new one will be just tall enough:

Proto Board - 80x120 - revised inserts - Slic3r

Proto Board – 80×120 – revised inserts – Slic3r

While I was at it, I deleted the washer recesses, because those didn’t work out well, and fiddled the screw holes to put the inserts in from the bottom:

Proto Board - 80x120 - revised inserts - detail - Slic3r

Proto Board – 80×120 – revised inserts – detail – Slic3r

Although the overhang inside the holes will be ugly, I’ll epoxy the inserts flush with the bottom and nobody will ever know.

The copper tape now makes a tidy ground strap:

Crystal Tester - ground strap - rear

Crystal Tester – ground strap – rear

With a gap in the front to eliminate the obvious loop:

Crystal Tester - ground strap - front gap

Crystal Tester – ground strap – front gap

The OpenSCAD source code as a GitHub Gist:


1 Comment

Under-cabinet LED Strip IR Sensor: Re-aimed

The under-cabinet LED strips work wonderfully well, except that the IR sensor seemed rather hypersensitive, so I added a small reflector made of shiny steel:

Under-cabinet light - IR sensor mirror

Under-cabinet light – IR sensor mirror

Even though I rounded those corners and deburred the edges, it does look a bit threatening, doesn’t it?

It moves the sensor’s hotspot back about half a foot, which seems Good Enough to eliminate false triggering from normal activity over the cutting board.

Leave a comment

AD8310 Log Amp Module: Sidesaddle Bracket

This little bracket attaches to a proto board holder, with holes for M3 inserts to mount the AD8310 log amp module:

PCB Side Bracket - 80x120

PCB Side Bracket – 80×120


AD8310 module bracket on proto board holder - component side

AD8310 module bracket on proto board holder – component side

The OLED display looks a bit faded, which seems to be an interaction between matrix refresh and camera shutter: looks just fine in person!

Not much to see from the other side:

AD8310 module bracket on proto board holder - solder side

AD8310 module bracket on proto board holder – solder side

I should have included an offset to slide it a bit forward; then I could mount it on the other end with clearance for the Nano’s USB port. Maybe next time.

The OpenSCAD source code as a GitHub Gist:

, ,

Leave a comment

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:

, ,


Bathroom Door Retainer

The weather got warm enough to open the windows before pollen season started, which led to the front bathroom door slamming closed in the middle of the night when a gusty rainstorm blew through town. After far too many years, I decided this was an annoyance up with which I need no longer put.

A few minutes with OpenSCAD and Slic3r produces the shape:

Bathroom Door Retainer - Slic3r

Bathroom Door Retainer – Slic3r

It’s basically an extrusion of a 2D shape with a rectangular recess for the door chewed out.

An hour later, it’s in full effect:

Bathroom Door Retainer - installed

Bathroom Door Retainer – installed

The model now sports a little ball to secure the retainer against the towel bar:

Bathroom Door Retainer - bump

Bathroom Door Retainer – bump

Maybe someday I’ll reprint it.

That was easy …

The cast-iron pig sometimes standing guard as a doorstop in the relatively narrow doorway poses a bit of a foot hazard, so he moves into a closet during the off season. He can now remain there, snug and comfy, until a need for ballast arises.

The OpenSCAD source code as a GitHub Gist: