Posts Tagged Arduino

Vacuum Tube LEDs: Mogul Bulb Side Light

The knockoff Neopixel on the 500 W mogul-base bulb failed in the usual way, so I rebuilt it with an SK6812 RGBW LED in a round cap:

Mogul lamp socket - SK6812 LED side cap

Mogul lamp socket – SK6812 LED side cap

The nice 1-¼ inch stainless socket-head cap screws replace the 1 inch pan-head screws that engaged maybe one thread due to the additional spacer between the USB port and the upper hard drive platter I added for good looks.

I tried a few iterations of an aluminized Mylar (*) disk with various sized pinholes over the RGB trio to crisp up the filament shadow, because the SK6812 LED casts a more diffuse light than the W2812 LEDs:

Aluminized Mylar pinholes for SK6812 RGBW LED

Aluminized Mylar pinholes for SK6812 RGBW LED

Even the ⅛ inch pinhole made the bulb too dim, so I settled for a fuzzy shadow:

500 W Mogul bulb - SK6812 RGBW LED - no pinhole - green phase

500 W Mogul bulb – SK6812 RGBW LED – no pinhole – green phase

The firmware has a tweak forcing the white LED to PWM=0, because this bulb looks better in saturated colors.

(*) Here on earth, aluminized Mylar is nonconductive.



1 Comment

LF Crystal Tester: OLED Noise vs. Log Amp

Having installed a cheap USB isolator to remove some obvious 60 Hz interference, the 100 Hz OLED refresh noise definitely stands out:

Log amp - xtal amp - OLED noise

Log amp – xtal amp – OLED noise

The bottom trace comes from the 100× = 40 dB MAX4255 amplifier boosting the crystal output to a useful level. The fuzz on the waveform is actually the desired (off resonance) 60 kHz signal at maybe 30 mVpp, so the input is 300 µVpp.

The worst part of the OLED noise looks like 100 mVpp, for about 1 mVpp at the crystal output, call it +10 dB over the desired signal. Some high-pass filtering would help, but it’s easier to just shut the display off while measuring the crystal.

The top trace is the log amp output at (allegedly) 24 mV/dBV. The input bandwidth obviously extends way too low, as it’s neatly demodulating the input signal: the peaks correspond to both the positive and negative signal levels, so reducing the 1 µF input coupling caps will be in order.

In between those 100 Hz groups, the input signal shines through to the log amp output at the V1 cursor. The peak noise rises 290 mV above that, so the log amp thinks it’s 12 dB higher. Pretty close to my guesstimated 10 dB, methinks.

So, turning off the OLED should help a lot, which is feasible in this situation. If you must run the display while caring deeply about signal quality, you must devote considerably more attention to circuit construction quality.


1 Comment

AD9850 Module: Oscillator Thermal Time Constant

With an LM75 atop the 125 MHz oscillator and the whole thing wrapped in foam:

LM75A Temperature Sensor - installed

LM75A Temperature Sensor – installed

Let it cool overnight in the Basement Laboratory, fire it up, record the temperature every 30 seconds, and get the slightly chunky blue curve:

125 MHz Oscillator - Heating Time Constant

125 MHz Oscillator – Heating Time Constant

Because we know this is one of those exponential-approach problems, the equation looks like:

Temp(t) = Tfinal + (Tinit - Tfinal) × e-t/τ

We can find the time constant by either going through the hassle of an RMS curve fit or just winging it by assuming:

  • The initial temperature, which is 22.5 °C = close to 22.7 °C ambient
  • The final temperature (call it 42 °C)
  • Any good data point will suffice

The point at 480 s is a nice, round 40 °C, so plug ’em in:

40.0 = 42.0 + (22.7 - 42.0) × e-480/τ

Turning the crank produces τ = 212 s, which looks about right.

Trying it again with the 36.125 °C point at 240 s pops out 200.0 °C.

Time for a third opinion!

Because we live in the future, the ever-so-smooth red curve comes from unleashing LibreOffice Calc’s Goal Seek to find a time constant that minimizes the RMS Error. After a moment, it suggests 199.4 s, which I’ll accept as definitive.

The spreadsheet looks like this:

T_init 22.5
T_final 42.0
Tau 199.4
Time s Temp °C Exp App Error²
0 22.250 22.500 0.063
30 25.500 25.224 0.076
60 28.000 27.567 0.187
90 30.125 29.583 0.294
120 31.750 31.317 0.187
150 33.250 32.810 0.194
180 34.375 34.093 0.079
210 35.375 35.198 0.031
240 36.125 36.148 0.001
270 36.813 36.965 0.023
300 37.500 37.668 0.028
330 38.125 38.273 0.022
360 38.500 38.794 0.086
390 39.000 39.242 0.058
420 39.500 39.627 0.016
450 39.750 39.959 0.043
480 40.000 40.244 0.059
510 40.250 40.489 0.057
540 40.500 40.700 0.040
570 40.750 40.882 0.017
600 41.000 41.038 0.001
RMS Error 0.273

The Exp App column is the exponential equation, assuming the three variables at the top, the Error² column is the squared error between the measurement and the equation, and the RMS Error cell contains the square root of the average of those squared errors.

The Goal Seeker couldn’t push RMS Error to zero and gave up with Tau = 199.4. That’s sensitive to the initial and final temperatures, but close enough to my back of the envelope to remind me not to screw around with extensive calculations when “two minutes” will suffice.

Basically, after five time constants = 1000 s = 15 minutes, the oscillator is stable enough to not worry about.



AD9850 DDS Module: 125 MHz Oscillator vs. Temperature, Linear Edition

A day of jockeying the AD9850 DDS oscillator shows an interesting relation between the frequency offset and the oscillator temperature:

DDS Oscillator Frequency Offset vs. Temperature - complete

DDS Oscillator Frequency Offset vs. Temperature – complete

Now, as it turns out, the one lonely little dot off the line happened just after I lit the board up after a tweak, so the oscillator temperature hadn’t stabilized. Tossing it out produces a much nicer fit:

DDS Oscillator Frequency Offset vs. Temperature

DDS Oscillator Frequency Offset vs. Temperature

Looks like I made it up, doesn’t it?

The first-order coefficient shows the frequency varies by -36 Hz/°C. The actual oscillator frequency decreases with increasing temperature, which means the compensating offset must become more negative to make the oscillator frequency variable match reality. In previous iterations, I’ve gotten this wrong.

For example, at 42.5 °C the oscillator runs at:

125.000000 MHz - 412 Hz = 124.999588 MHz

Dividing that into 232 = 34.35985169 count/Hz, which is the coefficient converting a desired frequency into the DDS delta phase register value. Then, to get 10.000000 MHz at the DDS output, you multiply:
10×106 × 34.35985169 = 343.598517×106

Stuff that into the DDS and away it goes.

Warmed half a degree to 43.0 °C, the oscillator runs at:

125.000000 MHz - 430 Hz = 124.999570 MHz

That’s 18 Hz lower, so the coefficient becomes 34.35985667, and the corresponding delta phase for a 10 MHz output is 343.598567×106.

Obviously, you need Pretty Good Precision in your arithmetic to get those answers.

After insulating the DDS module to reduce the effect of passing breezes, I thought the oscillator temperature would track the ambient temperature fairly closely, because of the more-or-less constant power dissipation inside the foam blanket. Which turned out to be the case:

DDS Oscillator Temperature vs. Ambient

DDS Oscillator Temperature vs. Ambient

The little dingle-dangle shows startup conditions, where the oscillator warms up at a constant room temperature. The outlier dot sits 0.125 °C to the right of the lowest pair of points, being really conspicuous, which was another hint it didn’t belong with the rest of the contestants.

So, given the ambient temperature, the oscillator temperature will stabilize at 0.97 × ambient + 20.24, which is close enough to a nice, even 20 °C hotter.

The insulation blanket reduces short-term variations due to breezes, which, given the -36 Hz/°C = 0.29 ppm temperature coefficient, makes good sense; you can watch the DDS output frequency blow in the breeze. It does, however, increase the oscillator temperature enough to drop the frequency by 720 Hz, so you probably shouldn’t use the DDS oscillator without compensating for at least its zero-th order offset at whatever temperature you expect.

Of course, that’s over a teeny-tiny temperature range, where nearly anything would be linear.

The original data:

DDS Oscillator offset vs temperature - 2017-06-24

DDS Oscillator offset vs temperature – 2017-06-24

, ,

1 Comment

LF Crystal Tester: Joystick for Oscillator Offset Adjustment

With the joystick button and LM75 temperature sensor running, this chunk of code lets you nudge the nominal DDS oscillator frequency by 1 Hz every 100 ms:

While that’s happening, you compare the DDS output to a reference frequency on an oscilloscope:

Zero-beat oscillator

Zero-beat oscillator

The top trace (and scope trigger) is the GPS-locked 10 MHz reference, the lower trace is the AD9850 DDS output (not through the MAX4165 buffer amp, because bandwidth). If the frequencies aren’t identical, the DDS trace will crawl left or right with respect to the reference: leftward if the DDS frequency is too high, rightward if it’s too low. If the DDS frequency is way off, then the waveform may scamper or run, with the distinct possibility of aliasing on digital scopes; you have been warned.

The joystick acts as a bidirectional switch, rather than an analog input, with the loop determining the step increment and timing. The ad-hoc axis orientation lets you (well, me) push the joystick against the waveform crawl, which gradually slows down and stops when the offset value makes the DDS output match the reference.

The OLED displays the current status:

DDS Offset zero-beat display

DDS Offset zero-beat display

The lurid red glow along the bottom is lens flare from the amber LED showing the relay is turned on. The slightly dimmer characters across the middle of the display show how the refresh interacts with the camera shutter at 1/30 s exposure.

N.B.: Normally, you know the DDS clock oscillator frequency with some accuracy. Dividing that value into 232 (for the AD9850) gives you the delta-phase count / frequency ratio that converts a desired DDS output frequency into the delta-phase value telling the DDS to make it happen.

In this case, I want the output frequency to be exactly 10.000000 MHz, so I’m adjusting the oscillator frequency (nominal 125 MHz + offset), calculating the corresponding count-to-Hz ratio, multiplying the ratio by 10.000000 MHz, stuffing the ensuing count into the DDS, and eyeballing what happens. When the oscillator frequency variable matches the actual oscillator frequency, then the actual output will 10.000000 MHz and the ratio will be correct.

Got it? Took me a while.

Although the intent is to tune for best frequency match and move on, you (well, I) can use this to accumulate a table of frequency offset vs. temperature pairs, from which a (presumably simple) formula can be conjured to render this step unnecessary.

The Arduino source code as a GitHub Gist:



1 Comment

Monthly Science: Cheap WS2812 LED Failures

The two knockoff Neopixel test fixtures went dark while their USB charger accompanied me on a trip, so they spent a few days at ambient basement conditions. When I plugged them back into the charger, pretty much the entire array lit up in pinball panic mode:

WS2812 LED - test fixture multiple failures

WS2812 LED – test fixture multiple failures

Turns out three more WS2812 chips failed in quick succession. I’ve hotwired around the deaders (output disconnected, next chip input in parallel) and, as with the other zombies, they sometimes work and sometimes flicker. That’s five failures in 28 LEDs over four months, a bit under 3000 operating hours.

For lack of a better explanation: the cool chips pulled relatively moist air through their failed silicone encapsulation, quietly rotted out in the dark, then failed when reheated. After they spend enough time flailing around, the more-or-less normal operating temperatures drives out the moisture and they (sometimes) resume working.

Remember, all of them passed the Josh Sharpie Test, so you can’t identify weak ones ahead of time.



Arduino Joystick: Button Pullup FAIL

I wired a resistive joystick to the knockoff Nano controlling the crystal tester and connected the button to an analog input because I have a lot of those left over and why not. Unfortunately, the ADC returned a sequence of random-ish numbers indicating the button didn’t have a pullup to +5 V.

One might be forgiven for assuming the pads marked R5 would hold such a pullup resistor, had the joystick not been relentlessly cost-reduced:

Keyes resistive joystick - R5 location

Keyes resistive joystick – R5 location

One would, of course, be completely wrong.

Having been around this block several times, I measured the pad-to-pin resistances and found R5 firmly affixed to the GND and +5V pins, with the SW (a.k.a. button) pin floating free. Pressing the joystick hat closes the switch next to R5, thereby connecting the SW pin to GND.

Baffles me. Maybe a fresh intern did the PCB layout and just misplaced the resistor?

So I soldered an ordinary resistor (*) between the +5 V and SW pins:

Keyes resistive joystick - button pullup

Keyes resistive joystick – button pullup

Now it works just as it should.

(*) For long-lost reasons, I have a zillion 12.4 kΩ 1% resistors appearing in place of simple 10 kΩ resistors.