The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Electronics Workbench

Electrical & Electronic gadgets

  • AD8310 Log Amp Module: Corrected Input Circuit

    After puzzling over the AD8310 Log Amp module’s peculiar frequency response, I hacked up the front end circuitry to match the data sheet’s recommended layout:

    AD8310 Log Amp module - revised
    AD8310 Log Amp module – revised

    Given the intended LF crystal-measurement application, a hulking 51 Ω metal film resistor sprawled across the ground plane will work just fine. All three ceramic caps measure a bit under 1 µF; I intended to solder the input caps atop the existing 10 nF caps, but that didn’t work out well at all.

    I should harvest the InLo SMA connector to prevent anyone from mistaking it for an actual input.

    With that in place, the log amp output makes more sense:

    AD8310 - modified - 100 kHz 150 MHz - 0 dB atten
    AD8310 – modified – 100 kHz 150 MHz – 0 dB atten

    That trace tops out at 150 MHz, not the previous 500 MHz, but now the response is flat all the way out. The log amp generates plenty of hash when the tracking generator isn’t producing a valid signal.

    The 60 kHz response looks different:

    AD8310 - modified - 60 kHz 1Vpp
    AD8310 – modified – 60 kHz 1Vpp

    So it’s really the log amp response to the absolute value of the sine wave (or, more accurately, to the sine wave re-zeroed around Vcc/2), with minimum output at the input’s zero crossings. At 500 mV/div, the log amp says the input varies by 42 dB = 1000 mV/(24 mV/dB), which might actually be about right for a zero-crossing (or zero-approaching absolute value of a) signal; logarithms don’t deal well with zeros.

    The AD8310 datasheet  and AN-691 suggest the 2.5 V output corresponds to +10 dBm = 12.5 Vrms input, which flat-out isn’t the case. However, the actual 500 mVpeak = 350 mVrms input is 2.5 mW = +4 dBm, so maybe it’s within spitting distance of being right.

    AN-691 recommends 10 µF input caps for “low frequency” use, showing results down to 20 Hz; 1 µF seems to get the circuit close enough to the goal for use near 60 kHz.

    It also recommends a cap on the BFIN pin (pin 6) to reduce the output stage bandwidth = “video bandwidth” and improve the overall accuracy, which remains to be done. The datasheet suggests rolling VBW off at 1/10 the minimum input frequency, which would be around 3 kHz for use with 32.768 kHz crystals. The equation, with reference to the internal 3 kΩ bias resistor:

    CFILT = 1/(2π 3 kΩ VBW) – 2.1 pF = 18 nF

    For a bit more margin, 1 kHz would require 56-ish nF.

    The PCB has a convenient pair of pads labeled C6 for that capacitor. This may require protracted rummaging in the SMD capacitor stash.

    Rolling off the VBW should reduce the hash on the 100 kHz end of the frequency sweep and filter the 60 kHz response down to pretty much a DC level.

    Applying the 10 dB and 20 dB SMA attenuators to the input from the tracking generator and recording the log amp output voltage produces this useful table:

    AD8310 Log Amp - mods and log response
    AD8310 Log Amp – mods and log response

    With the terminating resistor on the correct side of the input caps, the log amp seems to be working the way it should, with an output varying a bit under the nominal 24-ish mV/dB over a 30 dB range.

    We need caps! Lots of caps!

    A quick search with the obvious keywords suggests nobody else has noticed how these modules work over a reasonable bandwidth. Maybe I’m the first person to use them in the LF band?

  • Kindle Fire Power Button: Some Things Don’t Last

    Once again, the single moving part on my first-generation Kindle Fire stopped working. As before, the switch contacts accumulated enough fuzz & contamination to prevent any current flow, but this time the (soft) solder joints attaching the switch body to the PCB failed:

    Kindle Fire power switch - failed anchor
    Kindle Fire power switch – failed anchor

    My joint cleaning & fluxing wasn’t up to contemporary standards, as shown by the obviously un-fused footprints left in the upper pads:

    Kindle Fire power switch - failed anchor joints
    Kindle Fire power switch – failed anchor joints

    The switch frame seems to be unplated steel, which shouldn’t be an excuse.

    So I dismantled the switch, cleaned the contacts and tactile bump plate, put it all back together, and did a much better job of surface preparation:

    Kindle Fire power switch - rebuilt - right anchor
    Kindle Fire power switch – rebuilt – right anchor

    The other joint:

    Kindle Fire power switch - rebuilt - left anchor
    Kindle Fire power switch – rebuilt – left anchor

    And, for completeness, the switch leads:

    Kindle Fire power switch - rebuilt - switch pads
    Kindle Fire power switch – rebuilt – switch pads

    I don’t like the way the joint on the right looks, either, but we’ll see how long the whole affair holds together.

    This may be the last time I can repair the Kindle, as a bypass cap came loose while I was working on the PCB, the screen has been accumulating dust at an increasing pace, and several latches securing the back of the case have cracked.

    Methinks it’s getting on time for a new pocketable memory device; if only Pixel XL phablets had a bigger screen and didn’t cost night onto a kilobuck.

     

  • AD8310 Log Amp Module: LF Response

    The label atop a generic AD8310 Log Amp module seemed unambiguous:

    AD8310 Log Amp module - overview
    AD8310 Log Amp module – overview

    Firing the HP 8591 tracking generator into the InHi SMA, terminating InLo (not shown above, for reasons you’ll see below), connecting the Out SMA to the scope’s Trace 1, and the spectrum analyzer’s sweep output to Trace 2 produced an oddity:

    AD8310 Log Amp - 100 kHz 500 MHz
    AD8310 Log Amp – 100 kHz 500 MHz

    The upward-sloping ramp (lower trace) shows the HP 8591’s horizontal sweep, with the tracking generator tuning from 100 kHz to 500 MHz during the 20 ms sweep. The log amp output (upper trace) drops more-or-less linearly with increasing frequency, which seems odd. The tracking generator signal should be pretty much level and the log amp’s output should be more-or-less flat.

    My oscilloscope tops out at 150 MHz. The displayed RF is down by 3 dB = 0.6 div at 1.5 division = 190 MHz into the sweep:

    AD8310 Log Amp - 100 kHz 500 MHz - RF 50 ohm term
    AD8310 Log Amp – 100 kHz 500 MHz – RF 50 ohm term

    However, the RF looks pretty much flat up to 125 MHz and it’s still visible beyond 400 MHz, so I think the tracking generator is doing what it’s supposed to. If the RF were decreasing, then the trace would look different, methinks.

    The response to a 60 kHz sine wave doesn’t look quite right:

    AD8310 Log Amp - 60 kHz 1 Vpk
    AD8310 Log Amp – 60 kHz 1 Vpk

    Eyeballometrically, it might be a log response to the absolute value of the derivative: kinda flat on the ups-and-downs, kinda zero-ish at the tops-and-bottoms. Or maybe it’s the log response to a phase-shifted version of the input, with the lows corresponding to the zero crossings.

    Documentation for the circuit seems nonexistent, because eBay. Fortunately, one can pop the top to reveal the straightforward PCB layout:

    AD8310 Log Amp module - uncovered
    AD8310 Log Amp module – uncovered

    A closer look:

    AD8310 Log Amp module - PCB detail
    AD8310 Log Amp module – PCB detail

    A capacitance meter says input capacitors C5 and C7 are both 10 nF.

    A sketch of the circuitry:

    AD8310 Log Amp module - input circuit
    AD8310 Log Amp module – input circuit

    The datasheet puts the terminating resistor on the other side of the input caps, where it surely belongs:

    AD8310 Datasheet - Basic Connections diagram
    AD8310 Datasheet – Basic Connections diagram

     

    Achtung: the solder blob just to the left of C7 grounds the signal pin on the InLo SMA. Don’t connect anything to InLo which might take offense at having its output shorted to ground; the SMA terminator I used had no effect whatsoever.

    The AD8310 chip (assuming that’s what it really is) has a differential input resistance = 1 kΩ and capacitance = 1.4 pF in parallel with R3, the 52.3 Ω terminating resistor, making the net resistance just under 50 Ω.

    At 60 kHz, the input caps have a reactance of 270 Ω apiece, which means the “terminating” resistor is maybe 10% of the mostly capacitive input impedance seen at the InHi connector. That means the AD8310 inputs see maybe 10% of the input signal.

    In fact, if you regard those three parts as an RC high pass filter and merge the caps into a single 5 nF unit, it rolls off at 620 kHz = 1/(2π · 52 · 5 pF). Obviously, it’ll be a fine differentiator at 1/10 the breakpoint frequency.

    A simulation shows it in action (clicky for more dots):

    AD8310 Log Amp module - input circuit simulation
    AD8310 Log Amp module – input circuit simulation

    The two 1 MΩ resistors provide a balanced DC path-to-ground for R3 to keep the simulator happy.

    The (+) input tends toward 0 dB as C5 tends toward a short, the (-) input tends toward ground as C7 does likewise, but their difference isn’t a constant value. Seeing as how a log amp should respond to small differences, methinks it’s hard at work.

    The AD8310 data sheet says the scale factor is about 24 mV/dB between 10 MHz and 200 MHz, with no frequency dependence worth mentioning. Eyeballometrically, the output has a 240 mV = 10 dB straight-line decrease over the entire frequency range of that scope shot. It drops by 220 mV = 9.2 dB in the decade from 50 to 500 MHz, half of the 20 dB you’d expect from a first-order filter response.

    The AD8310 has an internal 2 MHz high pass feedback loop to suppress low frequency input offset voltages. The doc recommends a 1 µF cap from OLFT to ground for frequencies down in the low audio range. One might solder the cap across the convenient pads labeled C8 below the chip.

    Rearranging the input circuitry seems in order:

    • Move R3 outside C5 and C7, per the datasheet
    • Increase C5 and C7 to 1 µF -ish
    • Add 100nF – 1 µF bypass cap at C8

    I have the uneasy feeling I’m overlooking something obvious …

    Update – The rest of the story: Corrected Input Circuit and Video Bandwidth Rolloff.

  • Arduino Joystick

    A bag of sub-one-dollar resistive joysticks arrived from halfway around the planet:

    Arduino UNO - resistive joystick
    Arduino UNO – resistive joystick

    A quick-and-dirty test routine showed the sticks start out close to VCC/2:

    Welcome to minicom 2.7
    
    OPTIONS: I18n
    Compiled on Feb  7 2016, 13:37:27.
    Port /dev/ttyACM0, 10:23:45
    
    Press CTRL-A Z for help on special keys
    
    Joystick exercise
    Ed Nisley - KE4ZNU - May 2017
    00524 - 00513 - 1
    

    That’s from minicom on the serial port, as the Arduino IDE’s built-in serial monitor ignores bare Carriage Return characters.

    The joystick hat tilts ±25° from its spring-loaded center position, but the active region seems to cover only 15° of that arc, with a 5° dead zone around the center and 5° of overtravel at the limits. This is not a high-resolution instrument intended for fine motor control operations.

    The analog input values range from 0x000 to 0x3FF across the active region. Aim the connector at your tummy to make the axes work the way you’d expect: left / down = minimum, right / up = maximum.

    The delay(100) statements may or may not be needed for good analog input values, depending on some imponderables that seem not to apply for this lashup, but they pace the loop() to a reasonable update rate.

    Pushing the hat toward the PCB activates the simple switch you can see in the picture. It requires an external pullup resistor (hence the INPUT_PULLUP configuration) and reports low = 0 when pressed.

    Those are 0.125 inch (exactly!) holes on a 19.5×26.25 mm grid in a 26.5×34.25 mm PCB. Makes no sense to me, either.

    The trivial Arduino source code as a GitHub Gist:

    // Joystick exercise
    #define JOYX A0
    #define JOYY A1
    #define BUTTON 7
    int JoyX,JoyY;
    boolean Button;
    //– Helper routine for printf()
    int s_putc(char c, FILE *t) {
    Serial.write(c);
    }
    void setup() {
    Serial.begin (9600);
    fdevopen(&s_putc,0); // set up serial output for printf()
    Serial.println ("Joystick exercise");
    Serial.println ("Ed Nisley – KE4ZNU – May 2017");
    pinMode(BUTTON,INPUT_PULLUP);
    }
    void loop() {
    JoyX = analogRead(JOYX);
    delay(100);
    JoyY = analogRead(JOYY);
    delay(100);
    Button = digitalRead(BUTTON);
    printf("%05d – %05d – %1d\r",JoyX,JoyY,Button);
    }
  • Wearable LED vs. Astable Multivibrator vs. Dead Lithium Cells

    Mashing the wearable LED from the completely dead CR2032 cell with a classic astable multivibrator circuit and a not-dead-yet CR123 cell produced a pure-analog desktop blinky:

    CR123A Astable - front
    CR123A Astable – front

    Of course, I managed to swap the base resistors, which meant the LED stayed on most of the time, which accounts for the slightly off-kilter brown resistor just under the LED.

    It doesn’t look like much with the LED off:

    CR123A Astable - top - off
    CR123A Astable – top – off

    Running from a 2.8 V (= dead) lithium cell, the LED lights a dark room at 3 mA:

    CR123A Astable - top - on
    CR123A Astable – top – on

    The LTSpice schematic gives the details:

    Astable Multivibrator - CR2032 - schematic
    Astable Multivibrator – CR2032 – schematic

    The LED definitely didn’t come from Nichia and the 2N3704 transistors aren’t the 2N3904s found in the LTSpice library, but, by and large, this is the kind of circuit where nearly anything will work.

    The actual LED current obviously depends critically on the particular LED and the cell voltage, so this represents more of a serving suggestion than an actual prediction:

    Astable Multivibrator - CR2032 - waveform
    Astable Multivibrator – CR2032 – waveform

    Indeed, a Tek current probe clamped around one of those 10 AWG copper wires shows a much more enthusiastic LED current (1 mA/div):

    Astable - CR123A 2.8 V - 1 mA -green
    Astable – CR123A 2.8 V – 1 mA -green

    I don’t trust the baseline very much. The simulation & back of the envelope agree: the LED-off current should be around 400 µA (which doesn’t depend on the LED at all), so it’s in the right ballpark.

    Your mileage will definitely differ.

    It runs without a trace of software, which everybody at Squidwrench thought was wonderful …

  • Monthly Science: CR2023 Lithium Cells vs. Wearable LEDs

    Those wearable LEDs spent the last five months sitting on the kitchen window sash, quietly discharging their CR2032 lithium cells:

    Wearable LED with CR2023 cell
    Wearable LED with CR2023 cell

    Occasional voltage measurements produced an interesting graph:

    CR2032 vs Wearable LEDs
    CR2032 vs Wearable LEDs

    CR2023 primary lithium cells start out around 3.3 V, so these were pretty much dead (from their previous lives in dataloggers) when I slipped them into their holders. The LEDs seem to be blue LEDs, with threshold voltages around 3.6 V, with colored phosphors / filters, so they started out dim and got dimmer. The green(-ish) LED obviously fell over a cliff and went dark in late January; I have no way to measure long-term microamp currents, alas.

    The reddish LED is still going, mmm, strong.

    If you need a rather dim light for a surprisingly long time, these things will do the trick.

    I should gimmick up another astable multivibrator to blink one LED.

    The original data:

    CR2032 vs Wearable LEDs - data
    CR2032 vs Wearable LEDs – data
  • Eneloop AAA Cells: First Charge

    With an AAA-to-AA adapter in hand, the Eneloop AAA cells looked like this:

    Eneloop AAA - as received - Ah scale - 2017-04-20
    Eneloop AAA – as received – Ah scale – 2017-04-20

    The glitch comes from a not-quite-seated cell, showing that a poor connection matters.

    The package touts “up to 800 mA·h, 750 mA·h min”, with asterisks and superscripts leading to “Based on IEC 61951-2(7.3.2)“, access to which requires coughing up 281 bucks. So it goes.

    A full charge made them happier:

    Eneloop AAA - first charge - Ah scale - 2017-04-22
    Eneloop AAA – first charge – Ah scale – 2017-04-22

    The as-delivered 530 mA·h capacity represents 73% of the 725 mA·h after the first charge, so I suppose they’re more-or-less within the “Maintains up to 70% charge after 10 years of storage” claim. The 16-10 date code suggests they’re hot off the factory charger, so they must ship with somewhat less than a full charge.

    Comparing the capacity in W·h makes more sense, because most devices (other than the Planet Bike blinky light these will go into, of course) use a boost converter to get a fixed voltage from the declining terminal voltage.

    They arrived bearing just over 600 mW·h:

    Eneloop AAA - as received - Wh scale - 2017-04-20
    Eneloop AAA – as received – Wh scale – 2017-04-20

    After charging, that went a bit over 850 mW·h :

    Eneloop AAA - first charge - Wh scale - 2017-04-22
    Eneloop AAA – first charge – Wh scale – 2017-04-22

    Call it 71% of full capacity on arrival. Close enough.

    The Planet Bike blinky will be somewhat dimmer with two NiMH cells delivering 2.3-ish V, compared with the initial 3-ish V from a pair of alkaline cells. I generally burn the alkalines down to 1.1 V apiece, so perhaps they’ll be Good Enough.

    Now, if I were gutsy, I’d install a rechargeable lithium AAA cell, with a dummy pass-through adapter in the other cell socket, and run the blinky at 3.7 V. At least for a few moments, anyhow …