• 20W RGB LED robot costume

    zakqwy10/30/2018 at 00:07 0 comments

    I was a robot for Halloween. Danica and I joined a few friends at the Muse nightclub for Strange Things, a fantastic dance/costume party hosted by Flip Phone. I even got dragged up on stage for the costume contest which I had no chance of winning due to the large number of amazing drag queens. We had a delightful time.

    The costume's structure consists of a few cardboard boxes and reinforcing pieces, stitched together with zip ties, and covered in faux stainless steel contact paper (along with most of a roll of aluminum HVAC tape). The LEDs are driven using a Teensy 3.2, huge overkill since it pretty much just ran a demo rainbow program.

    Power for the LEDs came from this terrific Milwaukee power supply. We have a few M12 tools, and this one came with Danica's heated jacket (#minnesotaproblems). It has a USB port that can supply 2.1 A for fast charging, but more importantly it also has a direct 12 V line output that is designed to power the jacket, so it can sink a lot of current.

    Battery stuff can be sketchy, so I ripped the power supply apart and verified that it had _some_ protection circuitry in the form of a polyfuse. I'm not sure the current limit, but it presumably guards against direct shorts. I'm not sure the packs themselves contain protection circuitry so this was an important safety consideration.

    The costume uses most of a strand of Adafruit 36mm RGB pixels, each rated at 160 mA / 12 VDC. I used these pixels for several years as workbench lights in my basement (they had a sweet 'party mode' that filled the room with beautiful rainbow shadows), and they were due to be repurposed. As usual, Adafruit includes a ton of demo code that just works.

    Other than the ears, all of the pixel groups were unique ad-hoc designs that used a few layers of vellum paired with a bit of 1/16" Delrin for diffusion. The high intensity from the pixels meant I could layer up a decent bit of film and still get a crazy amount of brightness.

    I keep a stash of plastic fiber optic strands around for emergency builds like this, and hoped to integrate a few dozen into the robot's head. The build got down to the wire so I didn't get a chance to use this part, but it did photograph nicely. I was able to swing the strands around fast enough that you can see the individual PWM pulses from the strands, which is pretty cool for a LED fading nerd like myself.

    If you want to do something like this, or really have _any_ application that requires substantial power in a safe and portable form factor, the Milwaukee part is pretty keen. I suppose a USB-C power bank could serve the same purpose but that sounds difficult.

  • jolly wrencher + diy teensy bodgery

    zakqwy10/11/2018 at 18:24 1 comment

    I got a Hackaday Jolly Wrencher badge kit from Brian at OHS18 a few weeks ago. I have built a few DIY Teensy 3.2 boards; they aren't too difficult as Paul publishes schematics, just make sure you buy the bootloader chip from him. I had a few extra NXP chips around from the last go-around, so I decided to add one to the badge.

    As it stands right now, the circuit pretty well duplicates the Teensy 3.2 schematic, minus the pin headers and a few power switching components. I tapped the battery right into the 3v3 output from the LDO, so the badge shouldn't be programmed with batteries aboard.

    The picture above shows the first part of the build: mounting and securing the USB port, getting the power rails and oscillator on the MX20 sorted, that sort of thing. I superglued the chip upside-down and bent its required ground pins so they could be tacked onto the ground plane of the board (which, thank goodness, exists; some badges don't have ground planes).

    The MKL04 bootloader ran into some other complications; namely, NXP doesn't mark the bottoms of their chips with a pin 1 orientation dot, and the scratched mark I added was unsurprisingly off by 90 degrees (you can see the correct mark on the MX20 above). I wasn't able to verify this was the problem on the MKL04 without ripping it off its CA mount, and the chip didn't want to play nice after I re-oriented it. It was worth a try, but I probably nuked the chip when I tried to power it through the wrong pins. Fortunately I had a spare programmed MKL04 lying around that I swapped in and the board enumerated and programmed as expected.

    More to come on this one. Right now it's a Teensy 3.2, but I have a few ideas that will actually make use of that computing horsepower. This might be a rare multi-part Weekend Novelty Project.

  • tindie badge bodge

    zakqwy12/08/2017 at 15:38 2 comments

    Yup, my #Tindie Blinky LED Badge now has extra LEDs.

    The badge runs on an ATtiny84A; I chose this chip because I had a few lying around and it's got sufficient I/O to drive each LED on a dedicated I/O line. Also, the 0.5mm pitch of the QFN nicely matches an 0804 resistor network; probably not necessary (as the coin cell has a high internal resistance) but they make soldering magnet wire a bit easier. The image above shows the badge hooked up to the AVR Listener for ISP flashing; this required a bit of wrangling with polyamide tape as the temporary programming leads like to fall off if physically disturbed.

    The t84 is held down using a resistor lead tacked to its ground pad. Otherwise, most of the connections go to LEDs via 220-ohm resistor networks where possible, or through discrete 0402 resistors where not. I did include a bypass capacitor; it's a bit tough to see in the loupe picture above, as it is tombstoned just above the chip and connected directly to the power rail. Wiring power up this way means the power switch still works!

    Each LED is connected to its own I/O port. A matrix configuration would have allowed me to use a different microcontroller and save a few solder joints, but the common-cathode scheme means a simple grounded wire loop can support all of the LEDs via one of the original LED pads. The anodes are individually connected using 34 AWG polyurethane insulated magnet wire; it's thin enough that all five leads fit through the LED (+) pad.

    Code is simple enough to not include here -- a timer interrupt to generate a tick, a helper function to update the LEDs, and an integer to store their value that increments with every loop. And it likely won't change, as I conformally coated the back of the board to protect the components a bit. We'll see how long the badge survives as the eyes are rather delicate.

  • Phonetroller

    zakqwy10/16/2017 at 22:16 0 comments

    [update 3/30/2018: This project has graduated!]

    [update 3/22/2018: I thought this broke my phone. For 5 months. Then I re-enabled USB OTG and it started working again. After using the controller for a bit of time I've gotten sick of the inaccurate joystick and painful buttons, so those will be updated shortly.]

    Behold, the latest in bodged productivity destruction technology:

    Would you believe that I've been tossing this idea about in my head since _before_ the Nintendo Switch dropped? Well.. anyway.. you get the idea, it's a compact game controller for my phone. Yes it has a little evil face on the top right whose red eyes fade in a random and alarming manner. Read on!

    The whole thing pops off the phone and can be easily stuffed into a ubiquitous (at least in my workshop) light-blue Digi-Key bag:

    Springs! Wax string! Bodgery!

    The button layout mirrors that of the venerable N64 controller, minus the L and D-pad (and I subbed the encoder-based joystick for a simpler model, for that matter). The buttons on the right do cover up a tiny slice of the screen, but most of the games I play are 4:3 so it's not a huge deal.

    I built the structure out of 1/16" FR4. I guess this would be a good project for 3D printing, but FR4 is easy to modify and doesn't require tedious CAD work or waiting for prints:

    [above: clamping and tacking together the joystick mount]

    [above: joystick mounted, soldered, and RTV'd down for good measure]

    [above: testing the joystick and Z-button position for the left hand controls]

    [above: carving locations for the six game switches (A+B+C-pad) and purple start button]

    [above: main right-hand controls done. I had to replace the buttons a few times since they didn't seem to like flux removal or shitty conformal coating...]

    [above: end of Saturday -- most controls done and the basic structure established]

    [above: generic female USB-A to male USB-C adapter I picked up on the way to the office. destruction time!]

    [surprisingly easy, but still have a few layers of silicone to get through...]

    [above: nicely labelled tiny PCB inside!]

    [above: testing time. Tried this with a keyboard I had lying around and it worked without any trouble, so I didn't ask any questions about 'USB OTG' or the like. also, this picture mostly exists for my reference..]

    [above: you can be pretty abusive to USB-C connectors and they survive; also, the metal shield makes a nice structural surface for a little scrap of FR4 and some solder fillets. and yes, I tacked this together with the phone installed to be sure it fit right. for that matter, I did the same with the rest of the structure so everything was snug. if you build one, you'll need to do the same to make sure it fits your phone + case!]

    [above: controller PCB 'routed' (including a 'zach-fucked-something-up-and-it-shorted-PTC') and chaotically waiting for the Teensy 3.2. because what else would you use for a project like this??]

    [above: Teensy 3.2 installation, feat. right angle header scraps and 34-AWG insulated magnet wire]

    [above: masking off the mechanical bits before spraying with polyurethane (the 'conformal coating') to prevent corrosion and keep some of the wires secured. note: blue painters tape is not good for this job, as most of the switches stopped working or felt weird after this and had to be replaced. and yes, my sawhorses have been to hell and back.]

    [above: this project called for a weird touch so I put a face on the top phone bracket. the 650-nm (rare!) eyes fade and the teeth are made of 0805 jumpers.]

    Code for the project is a lightly modified version of the Teensy joystick example, with a bit of other stuff thrown in to fade the eyes in a suitably random and alarming manner:

    #include <Bounce.h>
    const int pin_start = 0;
    const int pin_a = 1;
    const int pin_b = 2;
    const int pin_joy_ud = 14;
    const int pin_r = 15;
    const int pin_z...
    Read more »

  • Blackberry Curve USB keyboard

    zakqwy09/29/2017 at 19:07 0 comments

    [hooray for vertical videos... ]

    I had a Blackberry Curve a number of years ago and liked the keyboard. Yay tiny buttons! Sadly, I didn't see @WooDWorkeR's  #PIMP (Personal Information Manager & Pager)  project until I'd already torn into my Model 8530; the Q10 keyboard used there would have made this project a bit less tedious. Ah well, I like tedious and this bodge-tastic project does keep half a Blackberry out of the landfill.

    Step One was to tear apart the phone (kindly held together with relatively common T6s and zero glue) and hot air everything until my desk was covered in parts. I wasn't sure this was going anywhere so I didn't get any pictures, and the desoldering effort was not insignificant; nearly all of the Curve's electronics were sealed under custom-sized RF cans.

    My initial hope was to easily extract a nice keyboard module that I could reverse engineer and use by itself. Sadly, this phone uses a single main board for everything. After a bit of study, I found a pair mysterious DFN16 components on my desk that looked hopeful:

    The chips are both marked '2398P' which (of course) didn't turn up anything on Google, but the large number of pins and adjacent resistor networks (pullups?) made me think they could be some kind of matrix controllers. I tacked on a few bits of magnet wire, bridging a bunch of pins each time, and took a few continuity readings -- confirmed! Time to break the footprint out!

    The picture above is after final assembly, hence the layers of Kapton (an attempt at strain relief) and the Teensy control board on the left. In any case, tacking 34-AWG magnet wires onto 16 0.5mm spaced pads certainly isn't impossible, but it does take a steady hand and a great deal of patience. I actually considered soldering on a pair of 8-pin FFC connectors I had left over from #TP-BMP, but soon realized that one of the connectors would get in the way of the other and I don't have any flat cable on hand. Assuming the space between the two footprints is a multiple of 0.5mm, a decent solution for anyone else attempting this could be to use a 17 or 18-pin FFC connector. You could probably even tack the support tabs onto the RF can outline or some of the other desoldered footprints for extra mechanical strength.

    The last step, at least for now, was to remove the IR touch 'mouse' and replace it with a SHIFT/ALT (as in, alternate button function) indicator. I think reverse engineering the sensor could have been possible, but it used one of those fussy double-row flat flex connectors that really beg for a custom PCB (and more time than I'm willing to spend on a hacky bodgy project like this). So I installed a pair of LEDs, using a bit of right angle header and the Teensy's uUSB connector for support:

    ... and glued a bit of diffusing material, a paper label, and a black light shield into the other side of the case:

    The effect isn't ideal; it's a bit tough to read SHIFT and ALT due to the diffusing material and small font, but at least the demarcation between indicators is sharp:

    Re-assembly was simple enough (no glue! T6 screws! thank you RIM!) after trimming away a bit of excess plastic so the Teensy would fit. I may add a backing plate as the wiring is somewhat exposed, but for now it's probably time to move on to more productive pursuits:

    Firmware is simple enough, thanks to the excellent USB HID support native to the #Teensy 3.0 & 3.1 & 3.2 & 3.5 & 3.6 platform. I used a few arrays and implemented a version of @Elliot Williams's pattern-based debounce scheme. Adding things like rollover and other buttons (Ctrl, Tab, etc) would be simple enough and may happen someday. The eight rows (r0 - r7) and eight columns (c0 - c7) refer to the pads from left to right; all keys were figured out using a serial terminal and a beer on the couch. Code (no more text beyond this block, so feel free to move on now if you wish...):

    const int r0 = 11;
    const int r1 = 10;
    const int r2 = 9;
    const int r3 = 8;
    const int r4 = 14;
    Read more »

  • Simon .. uh .. suggests.

    zakqwy12/21/2016 at 18:12 0 comments

    Codename MrBeepers. Any similarity to the popular electronic game from 1978 is purely coincidental. This is the project I referred to in the last project log that spawned the AVR Listener side side project.

    [filmed through a 4" ring magnifier to support the phone, so the video is a bit distorted.]

    I built this project as a Christmas present for my family's secret Santa recipient, so don't tell (as it's not yet shipped). Fortunately I don't think the target audience follows my Hackaday projects.

    [a thousand apologies for the unnecessary Instagram filter. grow up, zach.]

    As with many freehand FR4 projects, this one kinda designed itself as I went along. I based the overall geometry of the board on the 4xAA battery packs I discovered as part of the #NeuroBytes project. They use PC pins for mounting, and can be secured to a circuit board using a pair of McMaster nylon rivets that are amazingly the perfect size.

    [1.6 second exposure at f22 and ISO200. it took a few trials to get the right pattern to play back in order to light up all four LEDs.]

    I'm especially proud of the ergonomic-ish and aesthetically pleasing layout of the PCB; the four LEDs and buttons are symmetrically oriented in the four corners of the board, the main processor is in the center, and the other main circuit elements (power switch, regulator, and piezo elements) are in-line as well. The pushbuttons are some of the largest I could find, and are quite pleasing to the touch. At some point, I may spin up a proper PCB for this project, and likely won't change much about the layout; it works quite well. Okay, I may add a set of programming pogo pads, as the soldered on leads were a bit of a pain.

    Parts list:

    • ATtiny44A, SOIC-14, qty 1
    • 4xAA battery pack, qty 1
    • 1A / 5VDC LDO, qty 1
    • Piezo elements, qty 2
    • 12mm pushbuttons, qty 4
    • 0805 LEDs, QT Brightek series, 470nm, 525nm, 590nm, 625nm
    • Various support components: current limiting resistors, reverse protection diodes for the piezo elements, tantalum capacitors for the LDO, ceramic bypass cap for the ATtiny44A
    • Aforementioned nylon rivets
    • 1/16" single sided FR4, tin-snipped to size
    • 34 AWG polyurethane insulated magnet wire
    • A goodly bit of RoHS-compliant solder and flux
    • A bit of spray polyurethane to insulate and protect the whole works

    Initially, I used a smaller piezo element driven using an NPN transistor; however, the element wasn't nearly loud enough, and through a few happy accidents I discovered that driving the devices directly from the ATtiny's I/O ports didn't seem to cause any issues. I increased the size of the piezo element and added a second, allowing me to create the spooky and annoying two-tone harmony heard in the video at the top of this post.

    Firmware is pretty simple. I'm trying to use better programming practices (hah!) so I broke out a hardware abstraction layer into a separate *.c and header file. Timer0 is used as a 1ms tick for game logic, while Timer1 is used in Fast PWM mode (since that way the TOP values are double-buffered and can be changed on the fly) to generate interrupts for tone generation. I originally used the compare output pins directly for the piezo elements, but changed to standard pins with ISR-driven toggles so I could produce two different tones simultaneously. As usual, button debounce is handled using Elliott Williams' pattern-based method, and the pseudo-random initialization is based around @Vojtak's implementation from #Simon game with ATtiny13. The recursive algorithm is seeded using an unconnected ADC pin and it's good enough to make the game feel random; I didn't implement the fancy watchdog timer jitter deal he did so it's not perfect. The game-over state is terminal -- it generates a low tone and then puts the processor to sleep, so the user has to hard-reset the device to play again. Yeah, I got tired of programming towards the end, and no, unlike his excellent and compact code, my less-capable implementation comes in over 1k (1356 bytes exactly).

    Nothing past the code dump, so feel free...

    Read more »

  • AVR Listener

    zakqwy12/11/2016 at 01:26 8 comments

    I was working on a side project (which will surely appear as a log here at some point) and carelessly used one of an ATTiny's ISP pins as a piezo buzzer output. During programming, the buzzer made a series of interesting noises. This side side project (you can pronounce that "side squared project", like "e squared prom") extends that concept to all three ISP data lines (MOSI, MISO, and SCK) and adds three bright LEDs.

    In this video, I've attached the AVR Listener in line with my USBtinyISP, and I am using it to program a #NeuroBytes v0.91 board. I tried to keep the terminal window in the frame so you can see which steps produce which sound; in this case, the first section is writing, the second section is reading, and the third blip after the pause is setting the fuses:

    [apologies for the shaky video. Auto-stabilization makes it worse, unfortunately. Someday I'll graduate from my current phone-based video setup.]

    The AVR Listener is consists of three surface mount piezo transducers (originally purchased for the aforementioned side project) along with a trio of 2N2222 BJTs, protection diodes, and resistors to drive them. I also included three 0805 LEDs to visually highlight each 'channel'; in this case, green is MISO, yellow is SCK, and red is MOSI. The LEDs are routed through current limiting resistors and are wired in parallel with the piezo elements, so they're driven by the transistors too.

    The original side project doesn't have an ISP header, so I used a set of 0.1-spacing terminal blocks I had lying around for the target board connections. In order to program the #NeuroBytes board, I also fabricated a simple ISP adapter that plugs into the terminal block. Finally, I Inkscaped and printed a quick label since I'm bound to forget the pinout otherwise, and taped it to the back of the FR4:

    We'll see how much use the AVR Listener actually gets. At the very least, I'll plug it in each time I make substantial code changes to existing programs to see if I can hear the difference [highly unlikely]. Next step, however, is masking off the buzzers and giving the circuit a quick coat of poly to avoid corrosion.

  • Badgery Bodgery

    zakqwy11/09/2016 at 20:32 0 comments

    I spent a bit of time at the 2016 Supercon on some tedious LED rework. I was first to present Sunday evening and the webcam wasn't up yet, so I figured I'd put a few better photos up here. The badge hack fits the criteria of this project nicely, as I started on Saturday afternoon and finished up very early Sunday morning. All in all it was a great side event--tons of folks working on badge hacks at all hours. Not as much hardware stuff as last year, but still great to see so many cool projects.

    I wanted to highlight Voja's excellent design work while simultaneously increasing the badge's annoyingness factor by making the display unnecessarily large. He was kind enough to arrange the LEDs in an 8x16 matrix, meaning a wire grid with LEDs at each intersection worked perfectly. I used 34 AWG magnet wire with a clear enamel; it's pretty handy stuff but burning off the insulation with a tinned iron leaves some debris, and as such all of the solder joints are a bit horrible. Also, the whole thing is covered in flux residue, so it's really a 'good from far, far from good' type project.

    The frame is made out of four strips of FR4 I'd brought from home; the PCB stock at the conference appeared to be FR1 (or something else ideal for their Othermills), which wasn't quite as strong and didn't like my tin snips.

    Everything is held onto the original badge with a few insulated wires; you'll notice that two of them loop around the back and are tied rather than soldered together, since their mounting pads are two different column pads. My only suggestion for future badges: give us a bit of ground plane so we can scrape off solder mask and use it as a structural support. The only real option I had was the top of the USB connector, which worked well enough but limits the badge's software hackability.

    Ben was kind enough to let me use his hot air station to desolder the LEDs. I lost two, replacing them each with some yellow units I brought from home. 126/128 isn't bad.

  • twisty watch

    zakqwy10/12/2016 at 18:41 0 comments

    Or 'Twist Wrist', or 'persistence-of-vision arm clock', or something like that. This project doesn't technically fall into the #weekend novelty projects category, mostly because I worked on it for slightly more than a weekend (with a large gap in the middle). However, I'm not likely to take it much further, so here the documentation will remain. Everything is released under the MIT License, and the pertinent files are stored in the project page's file repository.

    Yes, as the picture above suggests: this project is actually Pretty Damn Cool, although for now (and likely for a long time) it only works in 'Hackaday pandering mode'. I haven't had a chance to put together a proper font library or any of the time setting functions, and I really need to run the accelerometer in interrupt mode to improve the repeatability of the image generation. Someday I hope it will display the current time when prompted.


    The project consists of three boards shown above left to right: a processor / accelerometer board, a display board, and a LiPo battery / backup battery / charging circuit board. The boards are linked together using JST GH jumpers (since I have the tool to make the crimp terminals), carefully sized to accommodate my left wrist:

    The 'watch' is a bit pinchy and isn't very fun when your arm sweats. Also it looks rather ridiculous. I have much to learn about wearables.

    Processor Board

    The processor board, shown above during assembly, consists of a small piece of FR4 with JST GH headers at each corner, along with interconnected mounting pads intended to mate up to specific pins on the Teensy v3.2 and Adafruit accelerometer breakout board. These two components are supported using trimmed bits of right angle header.

    Teensy 3.2 without headers (OSHpark edition optional)1
    Adafruit MMA8451 accelerometer breakout board1
    32.768 kHz 12.5 pF SMD crystal1
    FR4, 1/16", 1oz copper (single sided)22x67 mm
    JST GH Headers, 4-position, side entry4
    SPST Swtich, right angle SMD, E-Switch p/n TL3330AF130QG2
    26 AWG stranded wire, insulated30 cm
    34 AWG solid copper wire, enameled20 cm
    10k resistor, 04022
    Header pins, right angle, trimmed as needed~20

    Once everything is soldered down and trimmed the board is quite a bit more compact, and all the wiring is somewhat protected underneath:

    I didn't put together a schematic for this board; the pin assignments are called out in the Arduino sketch that runs the whole thing, discussed later. The only added components are pulldown resistors for the two input buttons.

    Power Board

    Let me start by suggesting that this board is a bit sketchy. I insulated the battery leads fairly thoroughly and used quite a bit of care and clearance with the solder joints, but I still recommend against duplicating it unless you know what you are doing.

    The power board consists of two supplies: a 3v 2032 lithium coin cell and a 1S 150mA LiPo cell with an accompanying charge circuit and uUSB plug. The coin cell was originally intended to power the Teensy's battery backup circuit, but I think I wired the grounds up wrong and it didn't work properly (hence the lack of battery in the clip). The rechargable side is essentially the reference circuit from the Microchip MCP73831 datasheet, tweaked to provide a 100mA charging rate. As such, the BOM is as follows:

    LiPo battery with protection circuit, 150mA, 1S1
    CR2032 coin cell clip, SMD, with trimmed 'wings'1
    Micro-USB plug, SMD1
    FR4, 1/16", 1oz copper (single sided)25x67 mm
    JST GH Headers, 4-position, side entry4
    26 AWG wire, insulated10 cm
    0603 LED, 650nm1
    4.7 uF ceramic capacitors, 10vdc2
    330 ohm resistor, 06031
    10k resistor, 0603 (replaces 2k resistor in reference circuit)1
    Kapton tape10 cm

    Again--a bit sketchy, because LiPo batteries can be dangerous if accidentally shorted or otherwise damaged. My battery does include a built-in protection circuit and the charging bits are solid, but the construction method means it is still vulnerable.

    Display Board

    This part kinda disqualifies the project from...

    Read more »

  • Illumi-Loupe

    zakqwy09/06/2016 at 22:33 0 comments

    I really love my Bausch & Lomb 10x Hastings triplet. Decent working distance, super-portable, low-distortion, durable, etc... I use it all the time to inspect crappy solder joints. Except when it's dark out! Or just not quite bright enough in the room. Then the itty bitty lens just can't gather enough light and it's tough to see much of anything.


    No fancy microcontroller nonsense on this one, just a bit of FR4, a tiny slide switch, a current limiting resistor, a CR2032 battery and holder, some sticky copper tape, and some Kapton tape. Also some wire.

    I used a few crimp terminals I had lying around to strain-relieve the wires; this way, the soldered-down mechanical crimp holds the wire and its insulating jacket. We'll see how it holds up.

    The two tiny white right-angle LEDs are just close enough together to avoid a noticeable dead zone when objects under study (such as the ATtiny88 shown above) are held at the focal point. I did take a "no light" picture but it wasn't terribly impressive since my phone camera automatically adjusted its shutter to compensate. Ugh.

    This is actually the second version of the project; an early design used a large(ish) piece of FR4 epoxied to the back of the loupe to hold the battery clip, and didn't have a backstop to prevent the lens from being twisted the wrong way. As you can imagine this happened pretty quickly and the wires ripped off. The new version shown here uses a strip of FR4 to prevent over-rotation of the lens, and to provide mechanical support for the switch and resistor.

    Biggest surprise? I was able to solder to the casing! I assumed the brushed metal was stainless steel and tried anyway with an 850 F iron and plenty of flux, and the joints appeared to wet properly. I'm assuming the case is actually plated brass of some kind, as I don't think the solder I'm using (SAC305) bonds to ferrous alloys...

    ... and yes, the excessive heat did mess with the plastic lens assembly a bit. Mostly loosened the joint up, so I added a solder blob detent to keep the thing closed in my pocket.