Posts Tagged Arduino
Isolating the USB port from the laptop eliminated a nasty ground loop, turning off the OLED while making measurements stifled a huge noise source, and averaging a few ADC readings produced this pleasing plot:
Those nice smooth curves suggest the tester isn’t just measuring random junk.
The OLED summarizes the results after the test sequence:
Collecting all the numbers for that resonator in one place:
- C0 = 1.0 pF
- Rm = 9.0 kΩ
- fs = 59996.10 Hz
- fc = 59997.79 Hz
- fc – fs = 1.69 Hz
- Cx = 24 pF
Turning the crank:
I ripped that nice layout directly from my November Circuit Cellar column, because I’m absolutely not even going to try to recreate those equations here.
Another two dozen resonators to go …
They look much better without a flash, honest. The cut-up cardboard box threw much needed shade; the auditorium has big incandescent can lights directly overhead.
Anyhow, what with one thing and another, the two LED test fixtures spent another few dark and cool days in the Basement Laboratory. When I finally plugged them in, the SK6812 RGBW LED array light up just fine, but three more WS2812 RGB LEDs went toes-up:
That brought the total to about 8 (one looks like it’s working) out of 28: call it a 28% failure rate. While WS2812 LEDs don’t offer much in the way of reliability, running them continuously seems to minimize the carnage.
So I wired around the new deaders and took that picture.
Flushed with success and anxious to get this over with, I sealed the tester in a plastic bag and tossed it in the freezer for a few hours …
Which promptly killed most of the remaining WS2812 chips, to the extent even a protracted session on the Squidwrench Operating Table couldn’t fix it. When I though I had all the deaders bypassed, an LED early in the string would wig out and flip the panel back to pinball panic mode.
It’s not a 100% failure rate, but close enough: they’re dead to me.
As the remaining WS2812 LEDs on the various vacuum tubes and bulbs go bad, I’m replacing them with SK6812 RGBW LEDs.
For whatever it’s worth, freezing the SK6812 tester had no effect: all 25 LEDs lit up perfectly and run fine. Maybe some of those chips will die in a few days, but, to date, they’ve been utterly reliable.
The LEDs adorning the 0D3 rectifier tube became unreliable:
After failing to plug in a different USB power supply, a close look at the USB connector showed the problem:
I tried applying the world’s smallest dot of epoxy to the fracture, probably slobbered epoxy along the pins while reinserting it, and the Nano still doesn’t light up.
Given that knockoff Nano boards cost a touch over two bucks delivered, it’s not clear transplanting a connector from one of the never-sufficiently-to-be-damned counterfeit FTDI USB adapters makes any sense.
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:
Even the ⅛ inch pinhole made the bulb too dim, so I settled for a fuzzy shadow:
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.
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.
With an LM75 atop the 125 MHz oscillator and the whole thing wrapped in foam:
Let it cool overnight in the Basement Laboratory, fire it up, record the temperature every 30 seconds, and get the slightly chunky blue curve:
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:
|Time s||Temp °C||Exp App||Error²|
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.
A day of jockeying the AD9850 DDS oscillator shows an interesting relation between the frequency offset and the oscillator temperature:
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:
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:
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: