Advertisements

Posts Tagged Arduino

Another WS2812 Failure: Broken Glass

The WS2812 under the 5U4GB full-wave rectifier tube went into pinball panic mode:

Failed WS2812 - 5U4GB Rectifier
Failed WS2812 – 5U4GB Rectifier

It’s been running more-or-less continuously since late 2016, so call it

Because I’d be crazy to replace it with another likely-to-fail WS2812, I had to remove both of them before installing SK6812 RGBW LEDs and updating the Arduino Nano.

Unfortunately, I did a really good job of bonding the side light to the tube with epoxy:

Failed WS2812 - 5U4GB broken glass
Failed WS2812 – 5U4GB broken glass

The last tube manufacturing step involved flashing the getter onto the tube envelope, so as to remove the last vestige of air. Admitting air oxidizes the getter:

Failed WS2812 - 5U4GB getter oxidation
Failed WS2812 – 5U4GB getter oxidation

It was such a pretty tube, too …

5U4GB Full-wave vacuum rectifier - cyan red phase
5U4GB Full-wave vacuum rectifier – cyan red phase
Advertisements

,

2 Comments

Monthly Science: Lithium Cells vs. Low Discharge Current

The amount of energy you can extract from a battery depends strongly on the discharge current, which is why the advertised capacity always exceeds the real-world capacity. Testing the NP-BX1 batteries for my Sony HDR-AS30V at about an amp produces a reasonable estimate of their run time in the camera:

Sony NP-BX1 - Wasabi GHIJK - 2017-09-01 - annotated
Sony NP-BX1 – Wasabi GHIJK – 2017-09-01 – annotated

Even though defunct cells lack enough capacity to keep the camera alive during a typical bike ride, they should power a microcontroller or astable multivibrator for quite a while.

My CBA II has a 100 mA minimum test current, which is far higher than the 15-ish mA drawn by the Arduino Pro Mini / Nano and SK6812 LEDs in a vacuum tube light, so these tests should provide a lower bound on the expected run time:

Defunct NP-BX1 for Blinkies and Glowies - AmpHr - 2019-01
Defunct NP-BX1 for Blinkies and Glowies – AmpHr – 2019-01

The two dotted lines show a “good” battery (Wasabi 2017 K) tested at 100 mA has a 1 A·h capacity similar to the “defunct” batteries. Testing at 1 A drops the capacity by a factor of two and eliminates the relatively constant voltage part of its discharge curve.

Handwaving: a 15 mA load on a battery with 1 A·hr capacity should run for 66 hours, ignoring nuances like the Arduino’s minimum voltage requirement and LED minimum forward voltages.

A few days of informal (“Oh, it stopped a while ago”) testing showed 50 hour run times, with little difference in the results for batteries with 800 mA·h and 1300 mA·h capacity:

Arduino Pro Mini - NP-BX1 cell - SK6812 - blue phase
Arduino Pro Mini – NP-BX1 cell – SK6812 – blue phase

The red power LED remains on long after the SK6812 LEDs dim out and the Arduino stops running. The blue and green LEDs fade before the red LED.

The run time test data:

Arduino Pro Mini - NP-BX1 run times - single SK6812 - 2019-01
Arduino Pro Mini – NP-BX1 run times – single SK6812 – 2019-01

The 100 mA graph plotted against watt·hours has a similar shape:

Defunct NP-BX1 for Blinkies and Glowies - 2019-01
Defunct NP-BX1 for Blinkies and Glowies – 2019-01

You’d use those results for a constant power load similar to a camera or, basically, any electronics with a boost supply.

Leave a comment

Vacuum Tube LEDs: Radome Prototype

Definitely not a vacuum tube:

Arduino Pro Mini - NP-BX1 cell - SK6812 - blue phase
Arduino Pro Mini – NP-BX1 cell – SK6812 – blue phase

It’s running the same firmware, though, with the Arduino Pro Mini and the LEDs drawing power from the (mostly) defunct lithium battery.

The LED holder is identical to the Pirhana holder, with a 10 mm diameter recess punched into it for the SK6812 PCB:

Astable Multivibrator Battery Holder - Neopixel PCB - Slic3r
Astable Multivibrator Battery Holder – Neopixel PCB – Slic3r

Those embossed legends sit in debossed rectangles for improved legibility. If I repeat it often enough, I’m sure I’ll remember which is which.

The 3.6 V (and declining) power supply may not produce as much light from the SK6812 LEDs, but it’s entirely adequate for anything other than a well-lit room. The 28 AWG silicone wires require a bit of careful dressing to emerge from the holes in the radome holder:

SK6812 LED PCB - Pirhana holder wiring
SK6812 LED PCB – Pirhana holder wiring

The firmware cycles through all the usual colors:

Arduino Pro Mini - NP-BX1 cell - SK6812 - orange phase
Arduino Pro Mini – NP-BX1 cell – SK6812 – orange phase

A pair of tensilized 22 AWG copper wires support the Pro Mini between the rear struts. The whole affair looks a bit heavier than I expected, though, so I should reduce the spider to a single pair of legs with a third hole in the bottom of the LED recess for the data wire.

The OpenSCAD source code needs some refactoring and tweaking, but the Pirhana LED solid model version of the battery holder should give you the general idea.

, ,

Leave a comment

FM DDS: First Light Hardware

Some Barely Viable Prototype hardware for a frequency modulated DDS to replace Channel Elements requiring now-unobtainable crystals:

FM DDS - First Light layout

FM DDS – First Light layout

The heatsink (surely harvested from a PC, then salvaged from a box o’ goodies) runs about 25 °C above ambient while dropping a 12 V input to 5 V at 180 mA, so it’s good for maybe 2°C/W. It carries a KA278RA05C LDO regulator; you’d probably want something fancier in real life.

The AD9851 DDS requires a 5 V supply to run at 180 MHz from the 30 MHz oscillator on its PCB, with the side effect of putting its minimum Logic 1 Voltage threshold at 3.5 V. Because the Teensy 3.6 runs at 3.3 V from its own on-board linear regulator, the DIP 74AHCT125 level shifter between the two boosts the Teensy’s LVCMOS SPI signals to good old TTL.

The sticker on the CPU reminds me of the jumper cut between the USB +5 V line and the VIN pin, thus putting the Teensy on the better-regulated local supply for the benefit of its ADC reference:

Teensy 3.6 Back - VIN to VUSB jumper

Teensy 3.6 Back – VIN to VUSB jumper

The picture comes from PJRC’s exceedingly helpful Teensy 3.6 reference cards.

I ran header pins along both sides of the Teensy to simplify attaching scope probes and suchlike; the dangling gray wire brings the scope’s Arbitrary Function generator signal to the Teensy’s A9 input.

The FMDDS Mock 3 firmware lit right up, albeit with the faceplant of sending the SPI bytes in the wrong order and the wrong bit direction, which was easily fixed after a bit of puzzling:

FM DDS 10 MHz - SPI 16 MHz LSB

FM DDS 10 MHz – SPI 16 MHz LSB

Just a typo, could happen to anyone …

, , ,

Leave a comment

Teensy 3.6 USB Serial Startup

The Arduino Serial doc says the USB hardware on the (now obsolescent) Leonardo requires a test-for-open before using the serial port:

  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB
  }
}

As it happens, you must also use that test on the ARM-based Teensy 3.6.

The gotcha happens when the USB port doesn’t become available, in which case the conditional remains true and the loop continues forever, which is precisely what happened when I powered the Teensy from a USB battery pack on the Squidwrench Operating Table.

After some flailing around, this startup snippet falls through after ahem awhile:

#define BUILTIN_LED 13

... snippage ...

Serial.begin(115200);

int waited = 0;
while (!Serial && waited < 3000) {
  delay(1);
  waited++;
  if (! (waited % 50))
    FlipPin(BUILTIN_LED);
}

... snippage ...

Serial.printf(" serial wait: %d ms\n\n",waited);

The serial startup delay seems to vary unpredictably between 800 and 1800 ms, so 3000 ms may be too short:

serial wait: 1033 ms
serial wait: 899 ms
serial wait: 907 ms

The ARM Teensy connects the board's built-in LED to the same SPI clock as on the AVR Arduinos, so it's only useful during startup, but having some hint will come in handy the next time it jams for another reason.

,

3 Comments

MPCNC: Epoxy-filled Connector

When I wired up the MPCNC’s tool length probe, I planned to reinforce the wiring with a dab of epoxy. What I didn’t notice in my enthusiasm, alas, was the opening from the rear to the front in each pin slot:

Epoxied connector - rear

Epoxied connector – rear

Which let the epoxy flow completely through the connector:

Epoxied connector - front

Epoxied connector – front

So I cut the mess off and applied heatstink tubing on each wire, just like I should have in the first place.

Now you know the rest of the story …

I really dislike pin headers as cable connectors, but that’s what the Protoneer CNC board uses:

MPCNC - Protoneer Wiring - SSR

MPCNC – Protoneer Wiring – SSR

It’ll be Good Enough if I don’t do anything else particularly stupid.

, ,

5 Comments

MPCNC: Tool Length Probe Station

Having a tool length probe station on the Sherline, I had to build one for the MPCNC:

MPCNC Tool Length Probe - plotter pen

MPCNC Tool Length Probe – plotter pen

It’s little more than a flange atop a wide base:

MPCNC Tool Length Probe - Slic3r preview

MPCNC Tool Length Probe – Slic3r preview

The flange offset puts the switch actuator on the midline of the base, not that that matters, and the base features rounded corners and a suitable legend, because I can.

I clipped the PCB’s through-hold leads nearly flush and stuck it to the flange with 3M permanent foam tape, which seems to work much better than screws & inserts for simple things that need never come apart.

The Protoneer CNC Shield includes a Probe input on the GRBL-compliant A5, although it took me a while to find the legend on the SCL pin in the I2C header. I moved the endstop power jumper to another header, then conjured a quick-and-dirty connector:

Protoneer CNC Shield - Tool Probe Wiring

Protoneer CNC Shield – Tool Probe Wiring

When I embed the endstop switch PCB in epoxy, I’ll add a drop to the connector while engaging in Magical Thinking. The whole Arduino + CNC Shield must go into an enclosure after I finish measuring the motor currents.

To forestall discussions about switch repeatability and accuracy, suffice it to say the MPCNC doesn’t claim to be much more than a woodworking router, so those switches seem Good Enough.

The OpenSCAD source code as a GitHub Gist:

The original doodles show a severely over-complexicated solution desperately searching for an actual problem:

MPCNC Tool Length Probe - doodles

MPCNC Tool Length Probe – doodles

Putting a large flat pan at the end of a relatively long lever arm, with the pivot arranged to put the pan level at the switch actuation point, made sense at the time. Give the relatively small tools I expect to use, directly ramming them into the switch lever should work just as well.

Putting all that complexity in harm’s way seemed like a Bad Idea when I sat down and looked at it in cold blood.

, , ,

6 Comments