REM-detecting white-noise-generating sleep mask (or, biting off more than you can chew)

For my next project, I'm going to design and build a sleep mask that has the ability to detect rapid eye movement (REM, which indicates dreaming sleep) and present sounds and lights to the wearer to enhance the sleeping experience.

First, the device will sound an alarm when the user is at the 'optimal' time to wake up, relative to their sleep cycle.  It's asserted in various places on the internet that the ideal time to wake up is at the end of an REM cycle; I'm still searching for peer-reviewed research to this effect, but there already exist devices on the market that trade on this possibly-more-substantial-than-folk wisdom.  Specifically, there is a headband that records EEG (brainwaves) to detect REM sleep, and a wristwatch which detects REM through arm/body movement and/or elevated heart rate (I can't tell how exactly it detects REM from the wrist, but those are my guesses).  Additionally, there are several smartphone applications and this alarm clock that detect REM through the amount of body movement a person exhibits.  I will detect REM directly, by illuminating the eye with pulsed infrared light and recording the changes in the reflected power.  The EEG headband device is very expensive, and my device will end up with a far wider range of features than both devices, so I don't think I'm duplicating any existing products.  Additionally, the timing and duration of REM cycles will be recorded and accessible by USB.

Second, the device will present noise to the wearer to assist in sleep.  I more-or-less need a 'red' noise generator running in the room to sleep well; devices on the market exist that produce white, pink and red noise as well as other 'nature' sounds to improve sleep.  By generating the noise in the mask, it becomes a sort of 'best sleep in a box'; with the alarm and noise generator, you can easily have as good a night's sleep in a hotel room as you do at home.  While there exist myriad smartphone programs to generate these noises (here is a site for a company that makes a good, no-nonsense one that also works for free on a computer), I don't own a smartphone.  So there.  Also, these features wrapped up into one common device elevates the mask to the status of a general sleep appliance that would be useful as a discrete device with one interface, one battery to charge and no monthly fee.

Third, the device will be able to deliver light and sound to the wearer during REM sleep to help induce 'lucid dreaming'.  Lucid dreaming is a state where you are dreaming, but consciously aware of that fact and thus able to influence the contents and progression of the dream.  The ability to dream lucidly is a talent that can be developed; one method is to train yourself to periodically perform 'reality checks' so that if you are dreaming, you will become aware of it as soon as your next 'reality check'.  There are also devices which attempt to present flashes of light or sound pulses during REM sleep which can indicate to the dreamer that they are asleep.  There already exists a 'commercial' product that attempts to do this called the NovaDreamer; it uses a simple delay to hopefully flash lights at the user during REM.  Since this device is no longer being made, and since it uses such a simple REM prediction method (that doesn't take into account any real-time information about the user), this feature is treading in a more-or-less untapped market.

Together, these features make a device that will, hopefully, allow the user to have more enjoyable wake-ups, better sleep and possibly troubleshoot their sleep by analyzing the recorded sleep cycle data.  Additionally, I will design the hardware with 'future-proofing' in mind: I will attempt to make features software-configurable and extensible so that A) features can be progressively added an debugged on the prototype hardware and B) extra features can be added beyond the immediate scope outlined above.

Overall system scope

• The most important design constraint, considering our culture's current level of microelectronic and battery technology, is device size and shape.  I want this device to basically be a slightly bulky sleep mask; the battery and electronics/interface board will be mounted on the front of the eye-cups and small speakers for the noise generator will be built into the band (EDIT: this speaker-in-the-band approach has apparently been done before).
• The device should be able to run for at least three nights without recharging, and should be able to be used while charging (I absolutely loathe cordless devices that can't charge while being used; burn in hell, cheap knock-off cordless drill!).
• The interface should be quick and simple for common tasks but allow for more detailed settings to be accessed relatively easily; additionally, common during-sleep interactions like volume control and snooze should be easy to perform while wearing the device.
• Charging, sleep data downloading and firmware updating should occur through micro USB port due to the ubiquity of micro-USB cables and chargers for cellphones (and even for dumb devices, of late).

Overall system design

Mechanical

The mechanical design will consolidate as much of the electronics as possible onto a single board over the left eye; REM detection will occur through emitter/detector pair whose leads go through the left eyecup; the battery will be mounted over the right eyecup; and the speakers will be built into the sleep mask's band.  Eventually it will make sense to design a hard plastic enclosure/casing for the electronics in and around the mask, but for now I'm going to focus on the electronic side of the design.

Electronic

The electronics will consist of several subsystems:

• Power management: a Microchip LiPo battery charger IC will sit between the USB V+ rail, the LiPo battery and the application circuit.  Everything downstream of the battery will run off a +3.3V rail provided by a high-efficiency buck converter.

• REM detection: the center of the detector will be an IR emitter and a pair of IR phototransistors.  the detectors will be stacked to allow for differential current measurement, which will be amplified by a transimpedance amplifier cascaded with an inverting gain stage.  All signals will be 'unsigned' (0 to +3.3V) and full dynamic range ensured by proper biasing.  This circuit is cribbed fairly liberally from an undergraduate project to implement REM detection for a sleep alarm (design document mirrored here).  A similar project  is  here.  Since the signal of interest is very low bandwidth, the emitter will be pulsed in time with ADC sampling of the output; this is a significant difference from the previous work and should result in significant power savings.

• Noise generation: an attractively-featured Maxim headphone amplifier will be fed with the DAC outputs of the microcontroller.  The chosen amplifier breaks out the feedback path, allowing me to design in a suitable bandpass to cut off the high-frequency DAC switching transients and also block the +3.3/2V DC component in the DAC outputs.

• Interface: the interface will consist of four appropriately labeled pushbuttons and a nifty ultra-tiny OLED display manufactured by Univision Technology Inc..  I was able to find two for cheap off eBay; I found the module and controller datasheets on the Adafruit website (here and here).  The module contains its own driver stepup and is controlled over SPI.
• Controller: ATXMEGA32A4U.  I wanted built-in DACs and USB support; additionally, the timers for the ATXMEGA (along with most everything else) are very expansively featured and allow for 32MHz operation down to 2.7V.  Migrating to ATXMEGA from the ATTINY and ATMEGA I've played with in the past means that I needed to find a cheap PDI programmer; I found the ZeptoProg on eBay for reasonable cheap and it plays well with AVR Studio 6 (I tried to get it to play well with AVRDUDE and the open source toolchain I used to use... but the problems have not yet been resolved).

The minimum usable endurance for the device is one night; assuming a middle-of-the-line, appropriately sized LiPo battery of 1000mAH capacity, this means that our device needs to draw about 100mA in the mean.  Tallying up the current usage of the various subsystems in theory yields a number far less than this, but I want to plan for the worst in putting together the prototype.  The buck can handle more than 100mA, and the battery charger circuit was designed with trimpots to allow for an appropriately-sized battery to be chosen after the completed device has been tested for real-life current usage.

Software

I've only designed the software in the broadest strokes; there will be a 'mission' mode, wherein the device keeps time, generates noise and detects REM, and an 'interface' mode, where the user is navigating menus and setting things up.  The reason I plan to segregate this way is twofold: first, the user can't navigate most of the menus while wearing the device, so we'll never have to do both (generated noise/sense REM and generate the interface display); second, generating the random numbers for the noise might take up a significant fraction of the available processing power, so I want to leave as many cycles spare as I can during  'mission' operation.

For particular computational tasks, I have put together some research/notes and even performed some simulations to verify cycle costs and correct theoretical behavior.  Specifically, I've collected a number of online resources toward the task of generating reasonably white noise from pseudorandom noise generators on a microcontroller substrate (8-bit XORshift, wider XORshift, linear congruential generators).  Additionally, there are a couple of good online treatments of the problem of generating pink noise from white noise (here and here; while red noise is easy (just integrate), pink noise falls off as though passed through a 'half-order' filter, making the whole proposition interesting).  In a future post, I'll go over these methods and the results of my simulations/implementations.

Futureproofing

I cut off the ballooning feature list as outlined above; however, there is a lot left I want to implement.  Additionally, since this is a prototype, I wanted the design to be able to be implemented incrementally with the same printed circuit board; I am a poor, struggling, starving, barely-making-the-rent artist type so I really only want to order one version of the board.

For debug-proofing, the following features will be added, to allow for incremental feature roll-out

• Test pads allowing easy access to the programming port and a simple UART.  This will allow for ease of programming before I figure out how to work Atmel's super nifty firmware-update-over-usb bootloader.  The UART will allow for debug information to pass easily from the device, and allow for proto-interfaces to be coded for the UART before I get the real SPI-OLED interface up.
• Trimpots to set the charger IC's constant-current charge level and constant-voltage current threshold. Since the overall power usage is not 100% nailed down at this point, I wanted easy options for the battery.  Additionally, this allows me to eventually make the weight/cost/benefit tradeoff without having to pull up and replace set resistors on the board.
• Pads and jumpers inline with the REM and noise signals paths.  This will allow me to troubleshoot problems with those subsystems (though I hope to have the circuits finalized through practical testing before I order the boards).
• The option of a manual trimpot or microcontroller PWM control of the bias level for the REM circuit.  My current plan is to use the ongoing signal levels in the REM circuit to set the bias level, allowing for greater signal amplification without running into the edge of my dynamic range.  However, this may not be the best solution (or it may just take some finite time to implement), so I'm giving myself the option of manual setting via a trimpot.

As for future-proofing, there is really only one thing that I am altering the hardware for to possibly allow in the future, and that is a pulse oxygenation sensor.  This sort of a sensor would allow the device to have access to both the user's pulse rate (potentially improving the REM detection) and the user's blood oxygenation (a decent measure of the efficacy/rate of their breathing).  Being able to record these two things would make sleep-problem diagnosis with the device significantly more powerful.  Admittedly, my current knowledge of the practical tribulations involved in building a robust pulseox sensor is minimal; however, I know that I will need an analog input, two 180-degree out-of-phase PWM signals and two analog outputs to set the emitter gains (which I will implement with lowpassed PWM signals).

Additional futureproofing would involve adding a micro SDHC card slot to allow for datalogging of more user sleep data (especially if the pulseox is ever added).  Since, in terms of harware, this is as simple as connecting to an SPI port, I will add the footprint and pullup resistors at the end of the board design process if the added device size seems reasonable.

All of my other potential future features are software changes; for example, I might want to add some code to slowly bring up the visible LED levels to simulate sunrise, leading to better wake-ups.  By having the LEDs driven by PWM from the start, this should not require any hardware futureproofing.

Work to date

Beyond the general design work, I've begun to mock up sub-circuits to test them and refine the design.  Additionally, I've begun to modify a sleep mask with the various bits and bobs necessary to detect rapid eye movement.

I've mocked up the 3.3V buck circuit (shown below).  It is able to source more than 100mA, as detailed in the data sheet.  In fairness, it probably wasn't necessary to verify this simple circuit, but I had a bad time with a similar boost as part of a project during college, so I'm paranoid about switched supplies.

Here is the sleep mask with the infrared REM emitter/detectors installed; I've tried to keep as little as possible of the circuit installed on the mask.  The leads from the emitter and detectors (emitter in the middle) are folded over to keep them all in place.  The wires are sewn onto the mask to keep things tidy.  The longer  unconnected wires will eventually be trimmed and connected to a visible LED in each eyecup.

Finally, I've put together the first stage of the REM detector amplifier (shown below).  I've already had to reduce the value of the transimpedance feedback resistor from what had been used before to prevent output saturation.

Next steps

The immediate next step is to take a look at the output of the mocked-up amplifier to determine the characteristics of the REM reflectance signal.  My first priority is to nail down the ideal value of the transimpedance feedback resistor to allow for the largest gain without being unable to maintain the voltage between the phototransistors at 3.3V/2.  Additionally, this investigation should reveal what the effective bandwidth of the signal is, informing my choice of sampling rate.

After that, I will completely specify and prototype the whole REM detector circuit.  Specifically, I will try out the pulsed-emitter idea I had to reduce power consumption.  It will be necessary to see how long the rise time is for the output once the emitter is activated; also, I've got to make certain that the differential output current isn't affected (beyond the obvious) by being pulsed.

Soon after (and during) those steps, I'm going to mock up the power and programming and USB lines for the ATXMEGA controller, programming it with Atmel's USB-based bootloader to make subsequent reprogramming easier.  I'll also make sure that I can talk to the OLED display.

At that point, I think I'll be ready to design and purchase the boards.  I still won't have prototyped the LiPo charger and headphone amplifier circuits, but these are very straightforward (and adequately datasheet-ed) and shouldn't present any surprises.

Signal gloves revisited (or, 0.77$ of plastic and dirty silicon can make a world of difference)

So, as I said last time, the interface for the signal glove left a lot to be desired.  The button was easy to miss, and difficult to depress for any appreciable time.

Since I was putting together another Mouser order for a significantly more ambitious project, I decided to toss on some Hall sensors (an idea courtesy of my dad, who came up with it within about 0.23 seconds of hearing my button problem).  For those not in-the-know, a Hall sensor detects magnetic fields by using the Hall effect, which takes advantage of the force exerted on moving charges (electrons) by magnetic fields.  By applying a current 'down' a slab of conductor, you are forcing electrons to move; if there is a magnetic field perpendicular to the plane of the slab, it will apply a force to the 'left' or 'right' of the slab.  This force will cause the development of a voltage between the left and right sides of the slab, which can be measured; the magnitude relates to the magnitude of the magnetic field, and the sign of the voltage relates to the direction of the magnetic field (into or out of the face of the slab).

By placing a Hall sensor on the closest knuckle of the index finger (toward the thumb) and a magnet on the thumb (toward the index finger), I can switch on or off the signal without having to exert any force (beyond the force needed to move my thumb).

Hardware

The ideal solution would be 'backward compatible' with the existing switch, and be able to exist alongside it. The original design used a pull-up resistor from the input pin on the microcontroller; the switch shorts the pin to ground.  Fortunately, open-drain is a common configuration for digital outputs; this more-or-less means that the output is a normally-open switch to ground, rather than actively driving any particular output voltage level.  This gives the user more options for use, especially as regards logical level voltage thresholds.

The one I chose was one of the cheapest ones that came up on Mouser (TLV4906K from Infineon, part of an order for a more ambitious couple of projects whose invoice is posted here).  The part accepted the voltage range of interest (down below 2.5V) and didn't soak up altogether too much current (nominal 4mA).  The altered schematic, including the hall sensor, is shown below.

The hall sensor and its 100Ohm SMD resistor were assembled along with a set of wires and epoxied to a bit of substrate, similar to the original switch.  It was then sewn into the glove and routed to the controller module as before.  While I had the glove inside-out, I also sewed a felt panel over the controller module to make donning and doffing easier and to protect the module.  I also put a suture into one of the palm-back LED bases to keep it pointed in the correct direction when my fingers are fully extended during signalling.  The most difficult aspect of the upgrade was getting at the relevant pins on the module connector and soldering to them without damaging any of the other leads or the glove itself.

The new hall module is shown in the two pictures below.  It is mounted on the index finger, facing the tip of the thumb.  Two rare-earth ring magnets are sewn onto the thumb-tip to allow the Hall sensor to trigger the lights when the thumb is moved close to the index finger.

The Hall sensor trigger is much easier to use and more consistently triggered than the pushbutton switch.

Lessons

The main lesson was "magnets are awesome and should be a part of every design ever".  The only down side is that a strong magnet can have deleterious effects on magnetic storage media (does that count as a pun?); however, this shouldn't generally be a problem, especially in this wondrous age of solid-state media.

Cycling turn signal gloves (or, ever so slightly less inconsequential blinking lights)

Building on the lessons learned in the making of the festivity gloves, I have completed my turn signal glove.  It's controlled manually by a single switch between the index and middle fingers (yes, I had to look up the names of the fingers on Wikipedia), and is really only convenient for turning left (unless you feel like contortion while riding).  The left-only limitation seemed reasonable to me, as I hug the curb out of terror while riding on the mean streets of Chicago, so I really only need to signal for lefts.

My professional ethics require me to state that this is not the first turning signal cycling glove; before getting started on this project, I did a quick Google search and found a guy who has built something slightly different.  His interface is an accelerometer, and is ostensibly compatible with the standard cycling hand signals. It looks cool, but he isn't selling them yet, and I already had an artistic vision in mind by the time I saw it, so mine is different enough to merit the necessary effort.  Also, I was interested in something that would be slightly water resistant (while the glove I made is not strictly water-resistant, everything other than the controller module is.  It would be relatively straightforward to water-resist that, too).

I wanted a glove-only turn signal approach (as opposed to something bike-mounted) because I ride a super-cheapo folding bike, and didn't want to deal with wires and whatnot having to cross the folding joints of the bike and getting repeatedly flexed and stretched.  Also, I wanted something that would easily transfer from bike to bike.  As an added bonus, always wearing a flashing glove gives you extra options for finding/guiding people in crowds.

In summary, here's an image of the completed gloves, followed by a video of them in action.

Oh, and if anybody knows somebody who knows somebody in the cycling accessory industry... let me know.

Hardware

All of the basic elements of the hardware are shown immediately below.  The black circle is one of the LED modules; below that is the switch module, next to the switch inside it.  Below that is the battery/controller module.  As before, for size and convenience reasons I am using the oh-so-beefy CR2450 watch cell for power.  The ATTINY85 is the controller; it's abilities are far more than what's necessary for this project, but it had just barely enough pins and I have some on hand.

In the interests of water-resistance, all of the exposed metal in the LED and switch modules are covered with two-part epoxy.  The switch was put inside a length of shrink wrap to allow it to be water-resisted without gumming up its delicate internal mechanisms.  Additionally, the controller module and connector are epoxy-coated.

For compactness, the ATTINY85, two dual FET switches for 'high-current' LED control and a switch and capacitor were superglued to the CR2450 watch cell snap and then epoxied for mechanical strength and a small amount of water-resistance.

The LEDs and switch are mounted on a rigid plastic to keep them oriented appropriately.  The plastic is from some binder dividers.  The wires are a very flexible stranded stainless steel insulated in white PTFE that I had laying around (I assume it was PTFE, judging by how impossible it was to strip, mechanically or with the iron tip.  I ended up burning the insulation off with a pentorch).

The wires were passed through the glove, along with a bunch of thread for mechanical stability.  I then gently pulled the glove inside-out, tied all of the sutures to keep the LEDs and switch on the glove, and then sutured the wires back to the wrist of the glove (the inside-out glove, assembled with extra slack in the leads to allow for testing, is shown directly below).

After turning the glove back out and testing the lights/switch, I shortened the leads and re-attached them to the module connector (shown below).  I then epoxied the connector and pentuple-sutured it three times to one of the heavy-stitched seams along the inside of the wrist.

The electronic design was similar to that used for by previous glove project, except that I needed to provide for more than two times as much current per channel.  I decided to go for the maximum current through each LED (30mA); for three in parallel, this far outstripped the 40mA limit on the ATTINY85 output pins.  To accomplish this, I picked some N-channel FETs (NTMD4840NR2G, the specs are way past what I needed here, but I picked these so I could buy a bunch and not have to worry about them being insufficient for future projects).  There is no resistor between the ATTINY pins and the gate of the FETs; the ATTINY outputs are going to be either all the way high or all the way low during normal operation, and the switch allows me to completely shut off power during 'abnormal' operation, so I saw no need for pull-down or gate-current-limiting resistors.

The switch pulls the relevant pin down to ground; an ATTINY internal pullup is enabled to keep the pin high otherwise.

To allow for easy programming and debugging, the connector has three extra pins (~Reset, MOSI and MISO).  SCK is the same pin as the switch.

Oh, and the parts for this project (excepting the glove, thread, needles, shrink wrap, two-part epoxy and plastic binder separators) are a subset of the Mouser order detailed in this document.

Software

The desired behavior for the lights was to go through wrist-to-fingertip flashing patterns (flashing the fingertip lights three times) so long as the switch was depressed.  This was to mimic the pattern you see on newer turn signals on emergency vehicles.  Additionally, the flash pattern should always be completely run before turning off (so no wiring the switch between the controller and the battery).

The software for this project was very simple (as you can imagine).  After power-on, the ports are set up and the outputs are set to low/off.  The device then sets up an interrupt on the switch and goes to sleep.

Upon switch-interrupt, the device wakes up and sets the lights to the first state in the hard-coded pattern (which so attractively flashes from wrist to fingertip, before flashing the fingertips three times before repeating).  It then resets a timer, un-sets the switch interrupt, and sets an interrupt on timer compare before going to sleep.

Upon waking up for the timer compare match, the pattern counter is incremented.  If the counter is less than the maximum, the new pattern is applied to the outputs and the device re-enters the sleep state.

If the counter is at the end of the pattern, it is reset to 0.  If the switch is still depressed, we continue on as we have (don't change any interrupts).  If, however, the switch is no longer depressed, we turn off the lights, un-set the timer interrupt, set the switch interrupt and go to sleep.

As I said, very simple.

Source and hex.

Lessons

I didn't learn too much on this project that was abstract-able past the limited scope of 'making gloves light up'.  The build went very well, and the device works nicely.  There are really only two things I would have changed (and likely will change on this glove):

1: If you have an interface whose ergonomics and function you aren't certain of, mock them up and test them out first.  The between-the-fingers switch has two marks against it; first, its base had to be narrow so as not to interfere with finger movement, and second, the heat-shrinking makes it more difficult to depress.  I've tried to add something to the switch to make it easier to depress, but it's still tough and often falls over.  Additionally, index-middle finger adduction is not a common task, and the muscles just don't have that much endurance.  I might end up making another switch and putting it between the thumb and the rest of the hand, or possibly replacing the switch with one that has a greater displacement distance or that is intrinsically water-resistant.

2: The controller module needs to be better attached inside the glove.  The controller connector is very well-connected, but I didn't want to directly suture in the controller module, to allow for ease of reprogramming.  However, this means that donning the glove is ever-so-slightly more involved that it aught to be (doffing is as easy as ever, though I have been babying the fingertips more than I used to).  Adding a felt panel might do the trick, allowing the hand to enter easily but still allowing the module to be removed easily.

Overall, I'm very happy with the way this turned out.  Hopefully it will make me slightly more visible on the street when crossing through traffic.  Additionally, it should really help when someone is trying to find me in a crowd.

Yule-themed gloves (or, inconsequential blinking lights)

I recently had the idea to make a coin-cell-powered cycling signal glove for myself; to 'prototype' the idea, I decided to put together a set of holiday-themed blinky-light gloves as a christmas present.  The objective was to make the electronics as unobtrusive as possible; they ended up being barely bigger than a CR2450 coin cell battery.

Here are the gloves, in 2D and 3D:

Hardware

There are two halves to the 'hardware': the glove side (gloves, LEDs, wiring and connector) and the battery module side (battery, switch, controller and connector).

The overall electrical diagram for the project is below (sorry for the handwritten schematic; my philosophy is, if I'm not going to make a board or do any complicated simulation, the circuit doesn't get any further than dead trees)

As you can see, it is super simple.  The module is basically a battery, a capacitor, a switch and a breakout of the ATTINY85 to the connector.  The gloves are just LEDs and current limiting resistors (all of the resistors ended up being 30Ohm) wired common-cathode to the connector.

The battery modules were hand-made as small as possible; I roughed up the plastic of the CR2450 battery clip to allow the capacitor, ATTINY, switch and connector to be superglued directly to it.  I then made a bunch of tiny end-stripped lengths of wire-wrap (because it was on hand) and hand-soldered all the connections.  Since the connectors are 0.1" spacing and completely break out the pins of the ATTINY, this solution also had the benefit of making programming and debugging easy.

The gloves were just a bunch of fun arts+crafts work.  The green is felt, attached to some cheap CVS gloves with white string (surgeon's knots, in case anyone cares).  Each LED was soldered to two lengths of wire; the wires were then passed all the way through the gloves using large-gauge sewing needles.  The gloves were then turned inside-out, and the wires carefully routed to the wrist (with thread ties every so often; see immediately below).

The wires from the LEDs were then terminated through current-limiting resistors into the connector.  These connections, as well as those on the battery module, were mechanically stabilized with two-part epoxy.  The battery module is shown plugged into the glove with the wrist of the glove rolled up below.

Here is a document outlining the mouser order that contained all of the components used here, except the 10Ohm resistors, hookup wire, gloves and felt.

Software

As you can imagine, the software is exceptionally simple.  There are two firmwares, one for each glove.

Tree Glove

Here, I wanted the 'star' LED to flicker and the other LED pairs to randomly turn on and off at about 2Hz.  At any given time, no fewer than 1 and no more than 3 red LED pairs would be on at the same time.

The 'star' LED is driven by one of the PWM channels; 8 levels of amplitude seemed sufficient to me.  The evolution of the brightness levels was a random walk; it was equally likely to stay at the same level or rise or fall by 1, 2 or 3.  Any over/underflow beyond the [0 7] range is reflected back.

Instead of implementing a random number generator in software (Dec. 25 was fast approaching), I pre-generated a sequence of random bytes using MATLAB, and hard-coded them into the source.  The lower four bits specify which LED pairs are on, and the upper 3 bits specify the PWM duty cycle.

Source and hex.

Wreath Glove

For this one, I wanted all of the LED pairs to flicker independently.  Four amplitude levels for each LED pair seemed sufficient.  Additionally, this allows me to pre-generate and hardcode the necessary random bytes without reusing too many of the bits and thus doing unfortunate things to the independence between the channels). Bits 7:6 determine the level of pair 4, 5:4 -> pair 3, 3:2 -> pair 2, 1:0 -> pair 1, 4:3 -> pair 0.

Unfortunately, the ATTINY85 doesn't have five PWM output channels, so I had to improvise.  I could have simply implemented a five-channel PWM in software, driven by timer overflow interrupts.  However, since I only need four levels, including 'off'', I was able to use the timer overflow and two compare interrupts to set/clear the LED port according to the commanded level:

0-------->COMPa-------->COMPb-------->OVF

All levels (except 'off') result in a port being set at the OVF interrupt; only the 'high' and 'medium' levels are set at the COMPa interrupt; and only the 'high' level pairs are set at the COMPb interrupt.

Source and hex.

Lessons
Overall, this project turned out better than I would have expected.  I was especially pleased with the way the flickering star ended up; the walk frequency and pattern ended up looking exactly like I wanted.  Additionally, the battery modules ended up being nice and small, and with the epoxy ended up being reasonably comfortable.

The biggest thing that I would have changed is the choice of wire.  The wire I used was a stiff, insulated solid-core wire that I happened to have on hand.  This was fine for the holiday gloves, since they are not going to be used much and the wires are all on the back of the hand, thus safe from excessive flexing.  However, moving forward to the turn signal cycling gloves, I will have to find wire which can flex repeatedly without breaking.

Why would I do this?

I am currently trying to finish up a degree in neuroscience (officially biomedical engineering… doing basic motor control and behavioral research; mostly statistical analysis, experimentation and modeling).  Because of this, and a desire to get back into the electronical hobby I previously enjoyed, I have decided it would be in my best interests to document the little projects I design and fabricate.  It is my hope that the projects to come will indicate some useful talents to round out my professional representation, reflecting the training and talents which wouldn't be obvious from my CV.

Of course, it is considerably more likely that I will post inconsequential blinking-light projects (only slightly more likely than the possibility that this will be my last post).