ESP8266 SDK reboot loops with cause:2, boot mode:(3,6)

Recently I’ve been building and flashing some projects to the ESP8266 directly using the Espressif SDK for development (not Arduino).

After changing the flash mode, I was still in a reboot loop, but was seeing “rf_cal[0] !=0x05,is 0xFF” just before reboot. This is a known issue that is resolved by reflashing the “init data” (esp_init_data_default.bin) as described here: (scroll to “SDK Init Data”).

The first thing to try is erase the flash before flashing your code: --port <serial-port-of-ESP8266> erase_flash

If that doesn’t work, flashing the “init” data will likely fix the problem: --port <serial-port-of-ESP8266> write_flash -fm <flash-mode> <flash_addr> esp_init_data_default.bin

Where <flash_mode> would be something like “dout”, “dio” or “qio” (use “dout” for ESP8285, “dio” or “qio” for ESP-12)

and <flash_addr> is determined based on flash size and this table:

  • 0x7c000 for 512 kB, modules like most ESP-01, -03, -07 etc.
  • 0xfc000 for 1 MB, modules like ESP8285, PSF-A85, some ESP-01, -03 etc.
  • 0x1fc000 for 2 MB
  • 0x3fc000 for 4 MB, modules like ESP-12E, NodeMCU devkit 1.0, WeMos D1 mini
  • 0x7fc000 for 8 MB
  • 0xffc000 for 16 MB, modules like WeMos D1 mini pro


Posted in ESP8266, Technical | Leave a comment

Trials and tribulations building and flashing ColorChord from scratch

In my efforts to create yet another improved version of my sound-response Light Suit, I elected to move to Charles Lohr’s excellent ColorChord project for sound analysis and LED driving. I wanted to add some functionality, though; mainly the ability to broadcast LED values as rapid UDP packets and some custom “modes” that didn’t involve sound (cycling rainbow, twinkle, all-on, etc). This meant tackling a task a bit more daunting than tweaking Arduino sketches – modifying and building the whole project, which is pure C code, not namby-pamby Arduino or LUA.

To document what I learned getting past some challenges for my own, increasingly poor, recollection, and for anyone else who wants to tackle this, I am writing this doc.

Since the directions are unix-oriented, I got a VirtualBox Ubuntu image to perform the build in. I used a version 16 build, but I don’t think the build is particularly sensitive to the version. I DID need to expand the root FS to 15GB and I allocated 2MB of RAM.

Create a work directory and change to it:

mkdir esp
cd esp

Clone the ColorChord repo, including the esp82xx subrepo:

git clone --recursive

Note: between October 2018 and now (Feb 2019), a bunch of changes to the esp82xx repo where merged in and seem to have resulted in this issue where setting the esp8266 to AP mode cause a crash loop. Hopefully the contributors will get that sorted out, but if you need AP mode now, you’ll have to figure out which versions of the main ColorChord repo and the esp82xx subrepo to pull in order to compile successfully and have AP mode working. 

Following cnlohr’s directions at

Create a shell script using the contents of This is a script that will download and install the Espressif SDK and all the toolchain components and dependencies, then builds it.

NOTE: I had to first run the script as root (sudo su -) since it installs additional Debian packages. I did this from a directory under root’s home dir, since it goes on to download a bunch of files which are later built, but the actual build fails if run as root. So I run it in the directory under root, it fails with “[ERROR] You must NOT be root to run crosstool-NG”. I then deleted that temp directory and exited root back to my own user. Then I ran the script again. Since all the dependent OS modules are not installed, it gets past those steps and goes on to download the SDK files (again), and run the build.

ALSO, the script installs version 1.5.2 of the Espressif SDK. This version tends to not provide enough available “iram” to build colorchord. I got error messages like “image.elf section `.text’ will not fit in region`iram1_0_seg'”. This is a known issue with SDK’s after 1.5.1. To build using 1.5.1, after getting the toolchain built using the above, next follow this process as described here:

Download the ESP8266 nonos sdk v1.5.1 from espressif & delete the sdk provided because the provided sdk is v2.0 and above:

rm sdk
wget --content-disposition ""

Finally, enter esp-open-sdk and link the sdk v1.5.x back.

cd esp-open-sdk/
ln -sf ./esp_iot_sdk_v1.5.1 sdk

I then modified the SDK_DEFAULT and SDK paths in   <colorchord_install_dir>/esp8266/user.cfg to point explicitly to the toolchain and SDK locations.

At this point, it should be ready for compiling ColorChord and flashing to your ESP.

“Attach” the USB serial port via the Virtualbox. To do this, you have to enable the USB driver and 2.0 support in the guest settings and install the driver in the guest. Then, you have to attach it once the guest is started via the little USB icon in the status bar at the bottom of the guest window. I also have to change permissions on the serial device every time I mount it since I am executing all the build stuff as myself, not as root.

sudo chmod 666 /dev/ttyUSB0

After that, you build and burn – but NOTE – I also needed the to run the “initdefault” make stage. Without it, I had an esp that just crashed on startup:

make all
make initdefault
make burn
make burnweb

After all that, you should have an esp that starts up, logs stuff to serial, and enters AP mode, at which point you should be able to connect to it via wifi, browse to and see the cool sh!t!

Posted in ESP8266, Technical | Leave a comment

Light Suit V3

Coming sooon!

Posted in Uncategorized | Leave a comment

Multi-Zone Audio Streaming on a Budget

Note – all the parts I refer to in this project are listed at the bottom of this post…

Not long ago, we purchased a rental property that came with “architectural” (or in-wall) speakers in several rooms and outside on the deck. I spent some time ruminating on what to buy to hook them all up to so that we, and guests, can listen to music in the different zones and – in the case of the speakers mounted on either side of the TV in the living room – pipe the cable tuner audio through those speakers.

You can get multizone tuners, but I have several issues with them:

  • They’re pretty pricey
  • They tend to only support a couple of independent sources –  you can’t, for example, have different audio sources playing in three zones…unless you get REALLY pricey
  • They’re complicated! I, myself, have trouble figuring out how to get those things to play a different audio source to the second channel, especially using the remote. My wife would never be able to do it, and I think it would frustrate guests.
  • Nowadays, people tend to have a bunch of music on their phones…or maybe subscribe to Spotify or whatever…that they want to play in the room they’re in (or outside)

So I was thinking, what would be nice is a system that let’s you stream music from your phone to any one of the various zones (or, in the case of the living room, choose Line-In to get the cable audio). Does such a system exist? Sort of.

After some googling around and looking at various devices currently available, I settled on the Dayton Audio WF40A “Multi-Room” WiFi 2x20W Amplifier. This is a little device that hooks up directly to your speaker wires and can connect to your network via either WiFi or Ethernet. It also has a line-in connector.  It can also operate in “Stand-alone” mode, but you’d have to connect phone to it’s access point instead of the general house WiFi. Using a phone app, you can stream music directly off your phone or use one of the supported streaming service, including iHeartRadio, Spotify, and a couple others. Actually, it’s a DLNA device, so any app that can play to a DLNA “sink” device should be able to stream to it (including the iPhone music player). You can also select Line-In as the source. It costs around $100.

So, my trial with that device went pretty well and I was considering adding 3 or 4 more zones…maybe over time rather than plunking down several hundred bucks at once. But, being a gadgeteer, I thought I’d look into whether weren’t some inexpensive components available that I could put together to do the same thing for a lot less. Naturally, the answer is YES!

There are a whole plethora of devices for around $30 that give you the streaming ability, including the WFA02, also from Dayton Audio (which seems like a somewhat more “reputable” company), although they don’t include integrated amplifiers. I actually went with an even cheaper version that was available under a dozen different names (but all say AudioCast on the case) on for about $24 a piece. Heck, there’s this one for $17 (so cheap it scared me off). There area ton of cheap little stereo amplifier boards that claim to hand up to 50W per channel available online for about $5 though! They take line-in and drive a pair of 8ohm speakers. You have to provide power to them, They tend to take 5 to 24V DC as input. A little research revealed they’re all using one of a couple different audio amp chips, so it’s mainly a choice of form factor, what kind of jacks are integrated (if any), whether there is a volume knob, etc.


Audio Amp Board








So… I wound up buying three of the little “AudioCast” WiFi gadgets for about $24 each, three audio amp boards, and a hefty 10Amp, 12V power supply intended for driving LED light strips – I think it’s pretty much just a switching power supply very similar to the ones that come with laptops. I chose an audio amp board that has an audio-in jack, making hookup easy, and a volume know (so I can potentially limit how loud guests drive the speakers). All-in, it cost me $104.

I also bought some plexiglass and some nylon stand-offs so I could put the whole thing together in a somewhat neet and “protected” package – that was a few bucks more. For convenience, I also bought a power strip that includes 4 USB ports, so I can power the whole contraption from the one power strip.

Here are a couple pictures of the assembly (not yet wired to speakers):








The audio boards, though quite small, seem to pack a pretty good wallop. I don’t have a good, decent poser speaker at home – I could only hook it up to a PC I had – but I turned the volume up till it was pretty loud. I didn’t want to blow the speaker, so I was afraid to turn it up all the way. Even at “pretty loud”, it wasn’t turned nearly all the way up, and the heatsink didn’t even get warm. Despite being small and inexpensive, I’m optimistic that these will drive the in-wall speakers pretty well. Hopefully, the 10Amp power supply is sufficient to drive all three zones at once, but I have a feeling if all three are cranked all the way up, it may be insufficient…we shall see.

A couple interesting things about these inexpensive WiFi streaming units…  There are probably a half dozen different varieties of them, and the “AudioCast” shows up under all kinds of different brand names. Different varieties point you to different phone apps – the two Dayton Audio devices say to use “Hi-Fly”, other products direct you to “AudioCast”, “MUZO Player”, “ESON”..and probably others. The funny thing is…they’re all essentially the exact same app, except with minor branding variations and slightly different streaming service choices (some of which are quite bizarre Chinese things):

Dayton Audio Hi-Fly










So, these function just the same, use essentially the same app…who wants to bet they have the same guts? And low-and-behold! On one Aliexpress AudioCast-type device, they show the guts – its essentially just a carrier board with a few components and a Linkplay A31 plugged into it. is the authorized distribution partner for these Linkplay things – they sell just he A31, as well as an eval board and, yes, a combo with a little carrier board that includes an ethernet port and line in/out connectors. So yeah, probably most of these devices are incorporating the same little board and the manufactures license the same app (which the get to brand a bit). Sadly, these little bare-bones kits cost more than buying a product from China (or even from Dayton Audio) that has one inside it!

I’ll post an update on how the installed system behaves soon.

Parts I used:

Dayton Audio WF40A Multi-Room Wi-Fi 2x20W Amplifier with IR Remote

Dayton Audio WFA02 Multi-Room Wi-Fi Audio Adapter  (no amp)

“AudioCast Wireless Multi-Room Music Streamer”

12V, 10A Power Supply

Nylon standoffs

Power Strip with USB ports


Interesting LinkPlay stuff:

LinkPlay main page on Parts-Express

LinkPlay A31 on it’s own

LinkPlay A31 eval board

LinkPlay A31 Integration Board w/IR Remote


Posted in Uncategorized | 2 Comments

Dahua DH-SD22204T Security Camera

I recently decided to install an outdoor PTZ security camera at our beach house to keep an eye on the premises, not to mention the threatening tide line during storms. After installing a “Sumpple WiFi Wireless PTZ” outdoors, it lasted about two weeks before becoming completely non-responsive. Total Crap.

For my second try, I ordered a Dahua SD22204T-GN, which is actually about $15 cheaper, supports PoE, but doesn’t have WiFi. This is fine with me (actually preferable) in this case – it turned out the WiFi signal was so weak where I want to mount the camera, I had to run 10BaseT to it anyway. PoE gives me a more convenient way to run power to it and replace the power supply, if it goes out. This time I paid an extra $5 for the insurance, so if it dies, it’s going straight back for a full refund and I’ll move on to another one 🙂

So far, this seems like a very good camera for the price. I have not installed it outdoors yet, but checking it out on my desk, it seems solid. The image quality is quite good, even at night. Although the camera has no IR LED’s, the light sensitivity is very good and I get a good image with only a small amount of ambient lighting. The web interface is robust, although live video doesn’t display natively in Google Chrome – you will have to install the “NACL” plugin. Also, although the camera does support built-in motion detection, it doesn’t have a nice feature that the Sumpple had to run a remote (ssh) command, which let me send a text via Twilio from my home server. It does support typical options to record to SD card, FTP a captured recording, or email. The email option works for me, since I can email my phone’s SMS address, but is a little annoying because it sends three  event emails; “Start”, “Recording” and “End”. I wound up setting up a “go-between” email account with a filter to only forward the “Recording” event to my phone. This onb of the three also includes a thumbnail (although occasionally the thumbnail is not present for some reason).

To install an SD card or mount the camera to a surface, you will need a T10 torx bit, as the enclosure is fastened with “tamper-proof” torx screws and the surface mount holes and SD slot are internal – not necessarily a bad thing.

Some useful information for anyone trying to use the camera with ContaCam:
I wanted to use the camera with ContaCam and it took some trial and error to get a connection to work. I finally used the following connection string with my user credentials in the “Camera login” section:
Use subtype 0 for the main stream or 1 for the secondary stream.

A more “generic” url that works with VLC is:

Posted in Uncategorized | Leave a comment

ESP8266 with ILI9341/XPT2046 TFT Display w/ touch

These 2.8″ 240×320 pixel color TFT displays for $8-10  can be found on ALiExpress. There’s also an equivalent-looking one offered by AdaFruit for $30 if you want one fast – the pins are quite differently label, but I’m willing to be it’s virtually equivalent. I just LOVE AliExpress – stuff is SO CHEAP! But, as is usually the case, the Adafruit one is well-document..the Chinese version, not so much. There are a smattering of posts and github libraries out there, but none document very clearly exactly how to hook one of these up, so I will describe here how I got one working.

I first spent a bunch of time trying to get one of the libraries that was coming up a lot for the XPT2046 touch functionality to work. That XPT2046 library seems to be the “standard” out there, but there’s no clear documentation of the hookup and it uses a somewhat cumbersome library for the TFT display.

The key that finally got me going was this blog post – it was one of the most useful, since it has a good hookup diagram, which I’ll include here, in case the post goes away. That post also refers to the XPT2046 library for touch input, but uses the AdaFruit TFT Driver and even includes a zip file containing the AdaFruit driver and examples comprised of versions of the XPTCalibrate and XPTPaint sketchs modified to use the AdaFruit display library. With those samples and the help of the hookup diagram, I was able to get things working. The diagram is a big help, since the pin labels on the cheap Chinese board don’t really match what is referred to in sample sketches. Also, it isn’t completely intuitive that you need to connect the SPI pins (SCK, CS, MOSI & MISO) to the standard pins for those signals on the ESP8266. I include the diagram here, in case that post goes away.

Once I got the pin hookup figured out, I was also able to get the sketches included with the XPT2046 library working – they use a display driver (which you also have to install) authored by the same developer, but I wound up using the AdaFruit driver for the ILI9341 TFT. It is based on AdaFruit_GFX and offers a lot more functionality, including a conventient button-drawing-press-detection framework.

Overall, this is another one of those components that just blows me away for being so cheap (especially when you buy it from China), but giving you such impressive functionality. In my next post, I’ll outline how I incorporate this into a wrist-controller form my LightSuit Version 3.


Posted in ESP8266, Technical | Leave a comment

ESP-01 V3 Doesn’t Reset or Run

I recently ordered a set of 10 new ESP-01’s from China.  After the usual few weeks, they arrived. I pulled one out, plugged it into the socket on my little interface board – which has buttons for RST and GPIO0, a 3.3V regulator, and pins to hook my USB-to-TTL cable to. That little board makes it really easy to program these minimal-feature ESP8266 boards.

So, I go through my process of setting the board options in the Arduino IDE, clicking “Program”, and then holding down the GPIO0 button, while momentarily pressing RST. I immediately noticed that I didn’t see the usual short flash of the LED (which is connect to the TX pin on ESP-01 boards). It then failed to write to flash. After some experimenting, I could get it to write to flash by holding GPIO0 down while plugging the USB cable in. However, my sketch didn’t seem to execute. I hit RST again and nothing happened. Reset was definitely not doing anything, and no matter what I did, I couldn’t get my sketch to run (I knew it worked, because I could flash it to an older ESP-01 and it ran fine).

So finally, after googling abit, I discovered that people are sometimes now receiving “V3” versions of the ESP-01. This seems to vary a bit between different vendors – some still ship V2’s, some send V3’s. And the difference on the V3 is that there is now a 6K resistor inline with the pin on the ESP-01 and the RST pin on the actual chip. This seems to prevent RST from working and prevents the chip from entering run mode on power-up. The post I found included the following picture illustrating where the resistor is. With some relatively fine soldering skills, you can remove the resistor and solder a fine jumper wire in place, which solves the problem. DON’T FORGET that you also have to pull CH_PD HIGH for the chip to enter run mode – I usually solder another jumper directly onto the ESP-01 to do this, except in cases where I what to have control over the chip entering low-power mode.

With this set of chips, I also had better luck using the “Generic ESP8285 module” profile.

This is also documented on the ESP-10 wiki here:




Posted in ESP8266, Technical | Leave a comment

Wine Fridge Temperature Controller – V2

In a previous post, I described how I replaced the highly-proprietary power supply on min wine refrigerator with an off-the-shelf supply and a Monster Moto shield to drive the fans and termoelectric peltier heat sinks based on the PWM (pulse-width modulated) signal from the controller head unit.

Recently,  I noticed the actually temperature was no longer tracking to the set temperature. Then, a couple months after that the supply completely died again. I guess the temp being off was a symptom of it dying. In any case, it was time to look at replacing it again. Last time, I was never completely happy with the klugey way I massaged the PWM signal to drive the cooling components – it never really got to where the PWM duty cycle was ON a high percentage, so it didn’t cool fast or to low temperatures. I knew what I really needed to do was put a smarter controller on the Moto shield (like a real Arduino) so that I would have full software control over the PWM driving signal. The Monstor Moto shield is intended for an Arduino in any case.

This time around, I decided to do that. This would mean effectively replacing the “head unit” too, since it had a small embedded processor that was responsible for taking input from the temp up/down buttons, the temp sensor (an NTC thermistor, I believe), driving the LED temperature display, and producing the PWM signal that controlled the original power supply output power. Rather than try to cut up the head-unit circuit board, re-route the buttons to the Arduino, and figure out how to drive the 2 8-segment LED temp display, which would require additional circuitry or some kind of display driver board, I decided to use an ESP8266 board with an OLED display in the front-end. This had the added advantages of giving me full software control over cooler operation and making it  very easy to WiFi-enable my fridge 🙂

I bought a different, higher amperage, power supply to cannibalize – I figure that will help keep it from burning out. It also has an integrated fan, which I’ll drive off the same PWM-moderated output voltage.

12V 15A AC to DC Power Supply

12V 15A AC to DC Power Supply

This is a link to what I bought – Home Usage AC-DC 12V 15A 180W Adapter Converter with Car Cigarette Lighter Socket. In case the link dies, it looks like this:

Turns out the fan was quite loud, so I also bought an “ultra quite” 12V 50mmx50mm fan off of eBay.

I found an ESP8266 board which had an on-board 32×90 pixel OLED display: The Heltec “WiFi Kit 8”

I added an Arduino, which actually drives the Moto Shield now. It also reads the temperature sensor. Based on the temperature reading, it adjusts the PWM duty cycle to be more or less aggressive about cooling, based on the difference between the “target” temperature and the measured “current” temperature.

Determining the temperature wound up being more complicated than I hoped. At first, I tried a little Arduino routine I found on the Arduino Playground for deriving temperature from an Thermistor connected to an Analog Input pin, but it was giving me values that were way out of whack…not sure why. I probably could have integrated a digital temp sensor, like the DHT11 or TMP102’s that I’ve used before, but I wanted to use the existing wiring that goes between the internal “head unit”, penetrates the enclosure, and ends where the power control circuitry is, which limits how many conductors I can use.

The internal temp sensor already had the wiring in place, and was nicely positioned in the air-stream of one of the internal fans. I wound up putting a TMP102-based ESP8266-connected sensor I use to monitor my bedroom temperature (for home automation purposes) inside the fridge, and wired the temp sensor to the Arduino A0 pin using the circuit from the Arduino Playground page. I then wrote a test sketch that drove the Moto shield and cooling hardware at constant duty cycles and logged the analog reading of the sensor connected to the serial port. I was then able to create a graph in Excel that correlated actual temperature to Analog reading:Capture

As you can see, this produced a very predictable and linear trend line. From that I was able to write a very simple routine derived from the the starting point of a reading on 830 (60°) and the slope of the line – see my Thermistor() function in WineCoolerDriver.ino. I also average multiple analog readings together before calling the function function, since the analog inputs can be a bit “noisy”. I also average ten temperature readings over time and base the PWM duty cycle on this moving average to reduce “jitter” in the “current” temperature and the duty cycle driving the cooling hardware.

I use the ESP8266 board to display the current temp and target “set_point” temperature. It also provides a WiFi interface for setting the target temp and ready the current temp values. I connected the ESP8266 to the Arduino over two of the available conductors over a “serial2” port using the SoftwareSerial library (leaving the Serial port on both boards available for debugging and  diagnostics). The ESP8266 periodically sends a one-byte target temperature setting to the Arduino, and the Arduino periodically sends the current temp to the ESP8266 for update of the display.

Here’s a Fritzing diagram of the Arduino, Moto, ESP8266 and sensor. See the last post which shows connections to fan/peltier assemblies.Fritzing

I actually added a couple of buttons (not depicted) (GPIO13 & 14) on the ESP for direct temp control.

Here’s the Moto Shield and Arduino assembly: IMG_20180204_100325742

Note that I stuck some stick-on heat sinks on either side of the VNH2SP30 chips,a s they seemed to get pretty hot under full load. That necessitated adding some extra risers between the shield and Arduino for clearance.

Here’s the Assembled “front-end”: IMG_20180209_080934852.jpg

I expanded the little window to accommodate the wider OLED and just cut a hole for the LED push-on/push-off button.


I also glued a couple of push-buttons in place behind the temperature up/down blisters (they are embedded in the white glue) and I used some Polymorph thermoplastic to form a sort of “bracket” that holds the board in place without being permanently attached. I highly recommend checking out thermoplastic – it is super versatile. You just heat it in boiling (well, not even boiling…) water. It softens at 150 degrees, at which point it’s like putty, then it hardens to normal plastic hardness when it cools.

Here it is fully operational:IMG_20180211_121133237





Posted in arduino, ESP8266, Technical | Leave a comment

Wine Cooler Power Supply

I’m just going to blog about this one briefly, in case their are any other enterprising Wine Cooler owners out there who find that, two years into owning their cheapo wine cooler, the power supply craps out. I didn’t take pics all the way through, so it won’t be much of a step-by-step build log.

A couple years ago I bought a “AZ-EA45EC-75” on Amazon. If you read reviews for these wine coolers, you WILL notice that there are more complaints about the cheaper ones breaking down after a year or two (often out of warranty). But I figured the price differential was worth it, especially if I got one  that is cooled via Peltier thermocouples, since I’d have a chance at repairing it if something went out.

Sure enough, a few months ago, the power supply went out. I can troubleshoot basic electronics, but troubleshooting a switching power supple (which this thing had) is a bit beyond me. I did try replacing some darlington transistors that showed a lot of heat discoloration on the circuit board, thinking they might have burned out (one was not very well secured to the large heat sink). No go. Maybe there was a cascade failure or something…i think maybe the winding on one of the very specialized transformers was also out. I even succeeded in tracking down the Chinese manufacturer of the power supply (the website was printed on it), and emailed them to see if I could just buy one unit. After a couple tries, I actually got a response (in bad english) that I think said I could send it to them and they would repair it for, like $80, and send it back..with me paying shipping both ways. No thanks.

In pulling the thing apart, I learned that the cooling system consists of the switching power supply, two thermocouples – each with an outside and an inside fan which look like typical PC power supply fans – some kind of internal temp sensor, and a little control board that includes the temp control buttons and current temp readout. Oh, and a little LED light array inside that you can turn on and off with a button on the control panel. They all connect to the power supply. The thermocouples and fans are just 12V powered, but clearly there is some logic somewhere to throttle how much power goes to them, since it would work harder when trying to cool down, but bee nearly silent when the internal temperature matched what you set the controller to.

The controller board had a 5 pin connector, and it was actually labeled: 12V, Gnd, LED, NTC, and PWM. I guessed (correctly) that LED controlled power to the light – I think it was just wired straight though on the power supply, since 5V regulated came out on that pin, and the LED array required 5V to light up. PWM was interesting – my guess (again, correctly) was that they Pulse Width Modulated the power to the two sets of thermocouples and fans. To verify this, I finally broke down (after 30+ years!) and bought  an inexpensive USB-based oscilloscope. I bought a Sain Smart DDS-120 for about 150 bucks and it was totally adequate for my needs…and now I finally have at least a cheap o-scope!

Anyway, using the o-scope, I verified that there was a 5V square wave coming out of the PWM in. Actually,  first I had to figure out what “NTC” was. Initially, providing 12V to the controller made the LED readout light up fine (and the LED button controlled whether 5V came out on that pin or not), but the readout would flash a few times, then show “E1”. I though on it a while and figured maybe it needed to sense a temperature to work. Turns out, it’s common to sense temperature with is an “NTC”  thermister 🙂 I wired a resistor in the 10K range across the NTC pin and Gnd and – sure enough – the readout would show 59°. When I turned the temp down below 59, the “off” period of the PWM square wave was longer – when I set the temp over 59, the “off” period got shorter. So, the “off” time of the PWM theoretically drives the power to the thermocouple clusters…kind of an inverse relationship..not a big deal, since I could easily invert that signal if necessary.

I started casting about for an easy way to drive a fair amount of power via the 5V logic signal from the PWM pin – from googling around, I estimated that driving a thermocouple and a couple of fans at full power could eat an amp or more. I prefer to find pre-assembled boards for more complicated circuits, since assembling a lot of discrete components can be pretty error-prone, plus I’m just not that great at linear circuit design. After looking around a while, I decided on the Monster Moto Shield. Intended to drive robot motors, this sucker can sink a lot of current. As the name implies, it’s intended to be used with an Arduino, but I just hard-wired the control pins to the appropriate logic level and tied the PWM pins to the PWM out from the fridge controller (after going through a couple of inverter components, described below).

I should say, in between all this – which took place over a week or two – I temporarily rigged up one thermocouple/fan set to just run continuously off a 12V laptop power supply I had lying around. This actually worked pretty well. Since I was just running one, it seemed to keep the cooler chilled, but not too cold. I even considered making it more permanent, and just buttoning it up and blowing off temp control, but that would have been to easy 🙂

Here’s a rough Fritzing diagram of the whole rig.WineFridgeFritzing_bb

I used a simple NPN transistor, to invert the signal coming from the controller board, tying the PWM inputs of the two Monster Moto channels to the “high side” (collector) of the transistor. So, when the signal coming out of the controller is low, the driver side is high and visa versa.

Update (4/28/16): As I tried this rig out hooked up, I discovered that it had trouble getting the temp below about 58°. This seemed to be due to the fact the the PWM duty never really got above more than about 60%. I added a low-side resistor on the transistor emitter to bias the output higher, then a diode and a capacitor which effectively “store” some of the “on” energy, while the diode prevents leakage backwards. This smoothed out the output, but also biased it slightly higher, resulting in more time above the Moto shield’s PWM trigger level. I basically picked the values by just experimenting – in fact, I’m not even positive of the cap value – I just found one in my tray of caps that was in-between doing almost nothing and causing the PWM signal to basically be always-on. 

I bought a cheap 12V switching power supply capable of delivering multiple amps from China. Here’s a picture of the whole thing rigged together temporarily. It looks like a rats nest, but will look a lot better when I consolidate all this into just the power supply, Moto shield, and a little daughter board.ratsnest

The Moto shield gets pretty hot when it’s really cooling, so I stuck a couple of little heat sinks I had to the two VNH2SP30’s, and even they seemed inadequate, hence the extra aluminum foil 🙂 For a more permanent solution, I’ve order a half dozen 20mm x 20mm heat sinks from Amazon that should arrive in a couple of days.

Total cost for all this – about $50. That’s not included the O-Scope, but everone deserves an o-scope! And of course, time…I spent a lot of that reverse engineering and tinkering with getting the input levels right on the Moto pins. Definitely a cheap fix, PLUS now I have something that’s much more maintainable, since I basically put the whole power circuit together myself.

Update (1/25/2018): Well, my cheapo Chinese power supply burned out – these things really don’t last well! I think part of the problem may be poor ventilation around the supply. Anyway, I bought one of these: for about $35. It has an integrated fan, which I hope will keep it cooler and help with lifespan. I intend to remove the case and just mount the guts to the wine cooler. The fan is actually kind of loud, so I may also order a quieter 50mm 12v fan. I also wasn’t very happy with the above circuit to drive the Moto shield from the PWM signal – it was never getting below about 57 degrees – I guess because the square wave didn’t have enough “on” time. So I’m just going to replace the control circuitry entirely with an Arduino. While I’m at it, I’m going to wire in an ESP8266 with an OLED screen to display the temp and let me monitor and set it via WiFi. It’s not lost on me that, at that point, aside from the thermocouple-and-fan assemblies, I’ll have practically built a wine cooler from scratch :-/  Actually…maybe there’s a business in custom wine-fridges… Anyway, I’ll do a post about it shortly.




Posted in Technical | 1 Comment

Lightsuit V2.0 (part 2)

In a previous post, I provided an overview of the “next generation” of my Christmas Light Suit (and various ‘peripherals’ 🙂  Really…it’s more like “generation 5 or 6” since the Light Suit has been through very many iterations, starting with just a couple strings of lights powered by a big-ole 12V UPS battery…


By this point, I had an Arduino-powered “Master” controller, which had 3 or 4 simple, pre-programmed sequences I could run, or all-on-or all-off. My suit lights were driven directly by the Arduino through a 4-port triac board, and other pins of the Arduino were connected to an XBee in transmitter, set up in “virtual wiring” mode, so receivers in the Cape, LakewayLightGuy’s suit, and the two Staffs, which had XBee recievers, echoed the pin outputs from the Arduino, effectively syncrhonizing all devices. I experimented a bit with sound-synchronization, but the ambient noise tended to be so high most places we went, it wasn’t really noticeable. There’s a lot more detail starting in this old post.

A big change was moving to ESP8266-based wireless ‘peripherals’ instead of XBee (although I also kept the XBee for now, for backwards compatibility). Although this means there’s a bit of a lag between sampling the octave levels of my sound source and actually getting a signal to the controllers, there are several advantages.

Independently-Addressable RGB LEDS

As I mentioned last post, this year I cranked it all up quite a bit, and it got even more complicated, but ultimately I hope it get’s a bit simpler. For example, Switching from commercial Christmas light strings to strings of WS2811 LED’s meant I had to incorporate a board that supported the WS2812 protocol, but I got rid of the inverter necessary to boost 12V to 120VAC and the Triac board necessary to do the switching. I also get 256 levels each of RGB intensity, addressable per bulb! By the way, WS2811 and WS2812 use the same protocol..just google for many discussions of the difference.

The ESP8266 supports the WS2812 protocol (I originally used this library, but it’s now also available via this online NodeMCU firmware build tool), so I can send RGB bytes of data over WiFi and have multi-color, varying-brightness, synchronized devices. Now, instead of just using XBee “virtual wiring” to echo the on/off state of GPO pins, I send packets of 3 bytes each to set the RGB values of LEDs on synchronized devices. Actually, packets are 4 bytes – I use a one-byte header to ensure receivers are in sync as they read bytes, although I think the UDP packets are received ‘atomically’, so this may not be necessary.  Right now, I just send one color, but I could easily make my over-the-air protocol more sophisticated and send longer strings of ‘colors’. Receivers (‘slaves’) can either use PWM to just adjust the intensity of attached LEDs, or use the WS2812 library to send data over a GPO pin to one or more addressable LED’s.

Inexpensive, Prolific Peripheral Devices

Another BIG reason I wanted to get away from XBees – they’re expensive! Like, $20/ea minimum.  With ESP-01’s running as low as a couple USD from China, you can build synchronized slave ‘peripherals’, like LED hats and batons, for as little as < $10. I got a few LED novelties from Windy City Novelties and by just adding an ESP-01 a little CR123A lithium battery, a really simple socket, a cheap switch, and wiring an output to the existing LEDs, I can have a synchronized Elf hat, for example. In this case, I just used GPIO2, in PWM mode, wired directly to the existing LED’s in the ornaments of this Elf hat.

But since the ESP8266 also supports the WS2812 protocol, by adding a few WS2811’s and wiring GPIO2 as the data pin, I was able to have a multi-color “wand” that pulsed in sequence with other devices.


WS2812 strip

In the future, I’ll incorporate WS2812’s into more accessories, like Santa hats. I bought a whole strip of them, so on a piece-by piece basis, they are pretty cheap.

It’s also worth noting that my suit itself is now a “slave” – the “master” control unit is completely independent of the suit-driving unit, also built around and ESP8266 (in this case, an ESPToy, which had built-in 3.3V regulation and plenty of GPO pins). This way, I don’t have to carry around as much hardware if I don’t care about sound and synchronized patterns across devices. Or I can even flash the suit unit as a “master” that just does simple (non-sound-responsive) patterns, since the difference between a UDP packet sender or receiver, Access Point or Station, is totally software driven. Here’s a schematic of the suit driver:SuitController

Note that this circuit includes a binary-coded rotary switch. I included this specifically so I could load more complex code which can behave differently depending on the switch setting – acting as a slave in one position, or as a master with one of a couple simple pre-programmed patterns in the others.



Using the WS2811’s dropped my power requirement down to 5V, but this introduced it’s own complication – I had to add regulators to  drop the voltage down to 5V. Even then, I wound up using TWO regulators, both with heat sinks added to them, and they were still getting excessively hot, as were the packs of 10 AA LiPo’s I was using for power.  After the fact, I experimentally tried dropping the battery supply down to 6V and voila! Not only did nothing get hot, the whole suit ran for about an hour an a half on a singe set of 10 batteries (rigged as 2 x 5 in parallel). This is much better, and I’m still not entirely sure why. The Buck regulators I use are supposed to be very efficient, but I suspect that may not be the case under high current draw and maybe as they start getting hot. In any case, for future holidays, I’ll be putting together 6V packs.


More on Sound

There are a couple more aspects of the sound circuitry, beyond what I talked about in Part 1, that I should probably mention. Here, again, is a block diagram, and also a schematic, of the “master” controller.


Teensy Audio Adapter schematic

I mentioned that the Teensy was really convenient for the complex audio manipulation I wanted – specifically FFT octave analysis and some audio delay, so that the audio out would be in sync with packets received by the slaves, which lagged by about 1/4 second due to WiFi propagation delay. One snag I ran into was that the RAM on-board the Teensy is only sufficient for an audio delay of about 180ms – I actually needed about 250-300ms. The ADC and DAC pins also require a bit of supporting circuitry – to level-adjust the input voltage of the Analog-In and to smooth the Digital-Out to an analog waveform, respectively. While the inventor offers an Audio Adapter that I believe addresses both the RAM issue and the Input/Output conversions, it would have been yet another board, plus, you still have to solder a RAM chip on to get the expansion and it would have cost another $20 or so, all in. The ADC and DAC example circuitry is provided in the online, graphical, audio patching tool when you choose those nodes. It’s pretty straightforward, so I just built it in myself. I had also corresponded briefly with the owner on his forum and he had suggested adding a RAM chip directly. I wasn’t sure where to start with that, but, upon inspecting the RAM portion of the schematic published for the adapter, I also realized that it’s just an 8 pin chip (available in DIP a package) connected to four pins of the Teensy, plus VCC and Gnd. I just added a DIP socket to my perfboard layout and wired it in – it worked on the first try on my protoboard!  All in all, I really like the Teensy/ESP8266 combination, especially for the kind of complex, audio-related code I needed.

Here again is the final “master” assembly, consisting of the Teensy for audio sampling and delay, passing 3-bytes, representing 3 octave ranges, to the ESP8266, which is responsible to communicating with the “slaves”. The Teensy also provides basic I/O pin-based signals to the XBee for backwards-compatibility with my original cape and staffs. and with LakewayLightGuy’s orginal “secondary”, triac-driven suit.

It’s worth pointing out that I did make a minor improvement to the XBee setup. I converted the cape over to an ESP8266 receiver, did some surgery on the 110V lights strings inside it to be many parallel sefments of fewer LEDs in series (about 15), and then used Buck/Boost regulators to boost 12V to 30V, and added a couple of darlington transistors to drive the 30V segments. These I drive via the PWM pins from the XBee, instead of just on/off IO pins. If you look closely at the above schematic, you’ll see I’ve wired both kinds of pins to the Teensy. I also changed the bases of the transistors in the staffs to be driven by the PWM pins from the XBees. So, depending on the software I flash to the Teensy and the configuration I flash to the XBee’s, I can still go with the old, on/off style of synchronized lights and pre-programmed patterns, or I can drive the PWM’s with 1024 levels of brightness, providing a much better “pulsing” responsiveness. That’s a great thing in general about this controller – now that it’s all assembled, it’s largely software configurable!

I’ll conclude this long and rambling blog entry with a link to a little video of the modified cape, along with a modified staff on the left:


Continue reading

Posted in Uncategorized | Leave a comment