Advertisements

Posts Tagged Arduino

Algorithmic Art

This evening I’ll be showing off my Algorithmic Art at the HV Open Mad Science Fair.

There’ll be glowing glassware:

Vacuum Tube LEDs - halogen lamp - purple phase
Vacuum Tube LEDs – halogen lamp – purple phase

Ancient electronics with modern hardware:

21HB5A - Guilloche platter
21HB5A – Guilloche platter

Blinking LEDs atop Brutalist analog electronics:

Astable RGB LED - green phase
Astable RGB LED – green phase

A classic HP 7475A plotter hammering math onto paper from a Raspberry Pi running Chiplotle:

HP 7475A Plotter - LED paper illumination
HP 7475A Plotter – LED paper illumination

Some take-home art:

Superformula Plots - A-size paper
Superformula Plots – A-size paper

And, as always, a good time will be had by all!

Advertisements

,

1 Comment

Vacuum Tube Lights: Triode

With the wrecked 5U4GB safely in the trash, I popped a smaller, somewhat less stately triode from the Big Box o’ Hollow-State Electronics and wired it up with a pair of SK6812 RGBW LEDs:

Triode - Purple-green phase
Triode – Purple-green phase

The tube’s markings have long since vanished, but, at this late date, all that matters is an intact glass envelope!

After two years, the ordinary white foam tape holding the knockoff Arduino Nano lost most of its sticktivity and easily popped off the 3D printed base:

Triode - Nano PCB - white strips
Triode – Nano PCB – white strips

Two layers of 3M outdoor-rated foam tape clear the bottom-side components and, based on current evidence, its stickiness should stick forever more:

Triode - Nano PCB - 3M strips
Triode – Nano PCB – 3M strips

The alert reader will notice the mis-soldered 1 kΩ SMT resistor above-and-right of the CH340 USB interface chip. I think those two resistors are the isolators between the 328P microcontroller and the CH340, letting you use the TX and RX lines as ordinary I/O without killing either chip.

Despite the mis-soldering, it evidently passed their QC and works fine. Seeing as how I didn’t notice it until just now, it’ll remain in place until I must open the lamp base for some other reason, which may never happen.

The data output is now on pin A5, to match the rest of the glowing widgetry:

Triode - Nano installed
Triode – Nano installed

Blobs of hot melt glue affix the SK6812 and wiring to the socket:

Triode - socket wiring
Triode – socket wiring

The original “plate cap” wiring ran directly through a hole in the hard drive platter, which I embiggened for a 3.5 mm panel-mount headphone jack. The knurled metal plug looms next to this smaller tube, but it looks better (in a techie sense) than the raw hole:

Triode - plate cap plug
Triode – plate cap plug

Octal tubes have an opaque Bakelite base, so I devoted some Quality Shop Time™ to the post:

Triode - base tip exposed
Triode – base tip exposed

Although I’d made a shell drill for 5U4’s base, this base was so crumbly I simply joysticked the spinning cutter around to knock off the rest of the post:

Triode - finished base
Triode – finished base

The shell drill would open the bottom to admit a bit more light. I may do that to see if it makes any visible difference.

I didn’t expect the serrations in the top mica plate to cast interesting patterns around the platter:

Triode - cyan-purple phase
Triode – cyan-purple phase

Memo to Self: use the shell drill to avoid nicking the evacuation tip!

, ,

2 Comments

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

,

3 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