Posts Tagged Arduino
While that’s happening, you compare the DDS output to a reference frequency on an oscilloscope:
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:
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:
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:
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.
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:
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:
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.
After hairballing an LM75A I²C temperature sensor to verify at least one of the eBay lot worked, a bag of SOIC-to-DIP space transformers arrived, so I soldered up another LM75A:
The SOIC chip pattern sits at right angles to the DIP pins, which took some getting used to.
The slightly defocused wire connecting pin 4 (on the IC) to pins 5, 6, and 7 (on the PCB) selects address 0x48.
So I flipped it over, soldered four wires (+5 V, GND, SDA, SCL) to the numbered pins on bottom of the board, made up a little header for the other end, wired a socket strip on the crystal tester board, plugged it in, and … nothing worked.
Turns out that the other side of the board carries a TSSOP pattern, which I’d neatly masked off with a snippet of Kapton tape, surrounded by eight numbered pins. Of course, those pin numbers correspond to the TSSOP pattern facing you, so they’re mirror-imaged for the SOIC pattern on the other side.
Soooo, the proper wiring for the SOIC pattern as seen from the TSSOP side has the pin numbers exactly bass-ackwards:
The insulation looked a lot better the first time I soldered the wires to the PCB. Honest.
Anyhow, when correctly wired, the LM75A worked as it should:
It’s snuggled chip-down against the top of the 125 MHz oscillator can, with a dab of heatsink compound improving their thermal bond and a yellow cable tie around the foam holding them together. The socket header is wired pin-for-pin to the DAC I²C socket directly above it.
The OLED temperature display shows 28.250 °C, because the oscillator just started up in a cool basement. It’ll eventually settle around 39-ish °C, where its output should be pretty close to the 125 MHz – 344 Hz value hardcoded into the source.
Oh, that’s a 3 mm amber LED next to the relay can: much less glaring than the white LED, no matter what it looks like here.
Disabling the display by activating its powersave option reveals 60 Hz pulses from the USB port on the Arduino Nano:
Unplugging the USB cable, leaving just the +5 VDC power supply and coax cable to the oscilloscope, solves most of the problem:
A closer look shows some (relatively) low frequency noise remains in full effect:
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:
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.
A strip of NXP (née Philips plus Freescale, including the part of Motorola that didn’t become ON) LM75A I²C temperature sensors arrived from beyond the horizon. To see if they worked, I soldered thin wires directly to the SO-8 pins, entombed it in Kapton tape to prevent spitzensparken, and jammed it under the foam insulation atop the AD9850 DDS module:
This turns out to be easier than screwing around with thermistors, because the chip reports the temperature directly in Celcius with ⅛ °C resolution. Classic LM75 chips from National (now absorbed by TI) had ½ °C resolution, but the datasheet shows the bits have an easily extensible format:
Huh. Fixed-point data, split neatly on a byte boundary. Who’d’a thunk it?
There’s a standard Arduino library using, naturally enough, floating point numbers, but I already have big fixed point numbers lying around and, with the I²C hardware up & running from the X axis DAC and OLED display, this was straightforward:
Wire.requestFrom(LM75_ADDR,2); Temp.fx_32.high = Wire.read(); Temp.fx_32.low = (uint32_t)Wire.read() << 24; PrintFixedPtRounded(Buffer,Temp,3); u8x8.drawString(0,ln,"DDS C "); u8x8.drawString(16-strlen(Buffer),ln,Buffer); printf(",%s",Buffer); ln += 1;
The next-to-last line squirts the temperature through the serial port to make those nice plots.
Casually ignoring all I²C bus error conditions will eventually lead to heartache and confusion. In particular, the Basement Laboratory temperature must never fall below 0 °C, because I just plunk the two’s-complement temperature data into an unsigned fixed point number.
Which produces the next-to-bottom line:
Alas, the u8x8 font doesn’t include a degree symbol.
Given sufficient motivation, I can now calibrate the DDS output against the GPS-locked 10 MHz standard to get a (most likely) linear equation for the oscillator frequency offset as a function of temperature. The DDS module includes a comparator to square up its sine wave, so an XOR phase detector or something based on filtering the output of an analog switch might be feasible.
The crystal test fixture and amp huddle in front of the OLED display:
The 22 pF cap now sits across the relay’s NO contacts, so as to simplify measuring the total in-circuit capacitance. The LED turns on when the relay shorts out the capacitor, which has a 50% probability of making more sense.
The quartz tuning fork resonators have an ESR around 20 or 30 kΩ, so the off-resonance output should be down something like -60 dB = 20 log (24 / 24×10³) from the 150 mV input: 200 µV (-ish). It’s actually around 1 mV, suggesting plenty of blowby through the baling-wire connections hidden under that neat top surface. I think that’s why the whole setup shows only about 8 dB of dynamic range; more attention to detail may be in order, although the peaks probably won’t move all that much.
Anyhow, even though the AD8310 log amp module should be able to handle such a tiny signal, the MAX4255 amp provides 40 dB of gain (OK, just 39.8 dB) and rolls off the high end at 220 kHz as a side benefit of its 22 MHz GBW.
There’s way too much low frequency rumble at the amp output:
What look like grass is actually the 60 kHz resonator output: those big lumps & bumps are noise from this-and-that. The repetitive peaks and dents exactly 10 ms apart (the cursors span four of ’em) felt a lot like OLED refresh cycles and, indeed, went away when I yanked the display out. Pulling the USB connection eliminates another tremendous heap o’ noise, so there’s likely a ground loop (-ish) thing going on, too. This may call for a USB optical isolator, its commercial equivalent, or more eBay offerings. Getting rid of that junk may improve the dynamic range enough to keep me from doing anything drastic.
The AD8310 log amp input now has decent coupling caps, so it’s not seeing the VCC/2 bias, and I removed that kludged-in 50 Ω terminating resistor to present its full 1.1 kΩ input resistance to the op amp.