Can’t upload new LUA files once ESP8266 init.lua starts

I’ve been having this frustrating problem with my NodeMCU projects on the cheaper ESP8266 devices: Once you get into a loop in your code, or worse yet, if you have an error that causes a reboot loop, there’s no way to upload a new .lus file short of re-flashing – a major pain!

Well, I finally found a nice solution on Big Dan’s blog. Thanks to Big Dan, a simple code addition for startup of you app in init.lua gives you time to interrupt it using a simple “snippet” assigned to a button in NodeMCU.

Add some code like this to your init.lua:

function startup()
    if abort == true then
        print('startup aborted')
    print('in startup')

abort = false

Then edit the code behind a “snippet” button to execute “abort=true”. Then you just have to click that snippet button before 5 seconds expire at startup time to abort starting your code.  Many thanks, Big Dan!

Posted in Uncategorized | Leave a comment

Light Dimming Using Ardiuno with Inverters

Since there’s not a lot of information about it out there in one place, I thought I’d share some insight into a problem I’ve been grappling with – dimming 110V LED lights run off an inverter using Arduino-driven triacs.

Recently, I’ve been experimenting with dimming strings of LED lights using an Arduino and similar devices. My goal is to kick my Light Suit up a notch by going from simple on-off flashing patterns to dimming intensities, ultimately driven by sound spectrum intensities – so that the strings throb in sync with music sources.

There is a trick to dimming 110V AC strings – since you’re typically using triacs to control hihg-voltage AC power, you have to worry about “Zero Crossing”. The problem is that, once you turn a triac on, it stays on until the voltage falls to the “zero crossing” point – the point at which the voltage is at (actually near) zero, even if you turn off the controlling voltage. So, to dim 110V strings, you actually have to do some timing – where you wait a small amount of time into the phase of the AC sine wave before turning the triac on. That way, you only voltage during a portion of the since wave – reducing the overall power. There’s a good article on the technique here: That is basically the setup I’m using.

A problem I’ve been encountering though, is that I’m running these strings off of a 12V-powered inverter. That was the easy way to take commercial string of LED lights attached to the suit and still be mobile. The problem I’m running into is that, at least in the case of small, inexpensive inverters, they use a modified sine wave, not a true sine wave. Google it for more details, but this is basically a notched square wave which emulates a sine wave in terms of total power delivered. But since the beginning and end of each phase of a modified square wave are at zero voltage, if you try to turn the triac ON at the beginning or end of the phase, it doesn’t happen, since the voltage is at zero.


You have to turn in on at some point during the “notch”, which is a narrower window than you have with a full sine wave.


What was happening for me was that, at low or high dim values, the lights would start flickering erratically or not coming on at all. Limiting the triac firing to the window of the actually square “modified sine” wave helps tremendously. It’s also worth noting that my two inverters behave differently – one flickers quite a bit even when I limit the firing window. I’m guessing it must be a “dirty” square wave or something, but can’t really be sure without a oscilloscope (this is one of those occasions where I really consider plunking down some $$ for one).

Also, I’m not sure why, but I still get some flickering when I drive the triacs from an Arduino Uno. When I use a chipKIT uC32 (an 80Mhz pic-32 “Arduino clone”), it works smoothly. I have know idea what’s going on here, but I’m kind of guessing that the speed with which the Arduino responds to a hardware interrupt can very a bit based on how busy the processor is or something.

Posted in Uncategorized | Leave a comment

ESP8266 Update

OK, since my first post on the ESP8266 and some replies I posted there as I made progress getting it to work, I’ve now had a chance to play with it a bit more.

One thing about the inexpensive ‘bare-bones’ variants – the advice everyone gives about NOT powering them from your serial adapter is definitely valid. I got significantly more flakiness with them, especially when trying to flash. Sometime it would take several tries to flash correctly. At times, the power draw even seems to have messed up USB hub, causing my mouse to go dead, for instance. The flashing flakiness applies both to flashing the full firmware and to simply trying to flash .LUA files to them.

So far, I’ve done almost all my experimenting using LUA and ESPlorer. This is mainly due to the convenience and to eliminate potential weirdness the Arduino build for ESP8266 might introduce. I’m not saying there is any – I just want to have a controlled comparison before digging deeper.

I do think there could be some issues trying to use certain Arduino libraries with the ESP, though. NodeMCU appears to be essentially a single-threaded, event-driven language, like Node.js. Since some Arduino libraries likely rely on interrupts for timing (SoftwareSerial, for example), you could end up messing up timing within the core firmware that controls the WiFi stack. So far, I have no evidence of this, it is mainly conjecture.

My little test project is to read the temperature from a TMP102 sensor from Sparkfun (my version has been retired, but the new one is essentially the same) and publish it to my OpenHAB server via MQTT over WiFi. The TMP102 uses an I2C connection with some specific addressing. Fortunately, both MQTT and I2C libraries are compiled into the latest NodeMCU firmware – I really just had to write a little MQTT code and pilfer some I2C communication code from, which I found in the BMP085 module under the LUA firmware project:, and wire the SDA and SCL pins to GPIO14 and 12, respectively. My complete set of code is here: One more thing – apparently LUA is integer-based (lame) and this messed up my conversions to Centigrade. I had to download and flash a floating-point-capable firmware image (nodemcu_float_0.9.6-dev_20150406.bin) from

In any case, I mentioned in my last previous post on ESP8266 boards that both bare-bones boards I got have on-board 3.3V regulators. While this is true, they appear to be too wimpy to prove reliable when flashing or adding peripherals. Out-of-the box, I experienced a lot of flashing flakiness with the ESP-07 and ESP-12 cheapo boards, and little to none with the ESPToy. Using an external 3.3V source improved things immensely, though. At first, I just tapped the 3.3V source off an Arduino Uno connected to a USB port for power, and piped this stright to the 3.3V pin on the ESP-07 daughterboard – the little hole was just the right size to except a jumper pin 🙂  This made the device MUCH more stable.

Having had success with that, I decided to see about upgrading the chip to something that could provide more current. The seller himself indicated that it was not wise rely on the LDO (Low Drop-out regulator – similar to this one) on the ESP-07 and that its presence was actually a mistake (I think he just sources the things bulk from China, but he knows something about what he’s reselling). He recommended an LM1117MP-3.3 (linked here from DigiKey), so I ordered a couple, intending to swap out the chip. They’re both surface-mount, so this requires some soldering skills, but I was up for it. Unfortunately, I did not look compare the specs of both carefully. While they are both surface-mount chips, the 7333 is a SOT-223-3 which has smaller pins than the LM1117-33, which is a SOT-223-4. It has wider pin spacing AND the pins are not in the same order.

LM1117-22 Grafted onto ESP-07

LM1117-22 Grafted onto ESP07

So, I removed the original chip, the soldered the new one one, but spun around and with a jumper on the ground pin to connect to the original ground pad. I also put a little tape underneath it to prevent inadvertent contact with any of the boards though-hole exposed metal.

CaptureMan, after that, that thing works beautifully! I haven’t had a flash problem yet. I flashed two different firmwares and I even went into the ESPlorer Settings tab and cranked it up to Turbo mode. It still flashed program files flawlessley.

That was a lot of trouble to go to, when the ESPToy works right out of the box, but I think it proves out that an ESP-07 combined with some minimal components for a total price of about $5 is totally viable.

Here are shots of pretty much exactly the same sensor, the left one using the ESPToy powered and communicating to the PC directly over a USB cable, the right one connected to the PC via a USB-UART serial adapter. The Arduino is there purely as an easy way to get a 5V power supply while prototyping – I’ll switch to an AC adapter for the real deployment.

ESPToy with TMP102 Sensor

ESPToy with TMP102 Sensor

ESP-07 with Minimal Motherboard and TMP102 Sensor

ESP-07 with Minimal Motherboard and TMP102 Sensor

Next up…more esperimenting with the Arduino port for ESP8266!



Posted in Uncategorized | Leave a comment

Bluetooth HC-05 and Connection Status Detection

I have a project I’m anticipating where I want a bluetooth module connected to an Arduino.  I’m going to have the bluetooth module connected to an Arduino under my car seat. I’ll have the bluetooth pair with my phone automatically, then an app on my phone will send a short string through the bluetooth module to the Arduino, which will then set the position of my power seat to my preference. The same will work for my wife (naturally, mine will take precedence if we’re both nearby 😉 Ideally, I’d like to have the Arduino in sleep mode and have a signal from the bluetooth module wake it up via a hardware interrupt.

So, I found these cheap HC-05 and HC-06 Bluetooth-to-serial modules out there, which is nearly perfect. One problem – I bought one, and it wound up being an HC-06. Turns out, the State pin, which is tied to GPIO09 on the HC-06 ‘daughterboard’, and is supposed to go high when the bluetooth pairs, doesn’t work on the HC-06. I’m blogging this in case anyone else is looking to detect the state of the pairing on an HC-0X module.

Some research indicated the firmware is different on the HC-06 and that feature just isn’t even supported. Supposedly, it is supported on the HC-05. OK, no biggie – they’re, like, $5 ordered from China, mounted on a nice little break-out board. So, I order a couple of HC-05 and a couple weeks later they show up. I plug one in, pair it AND….still no go! the meantime I’ve been reading about a lot of AT commands you can send these suckers (you configure them using an “AT” command set, sort of like my first modem – a 300 baud modem, I’ll have you know). I won’t document how to get into the console here – that’s document extensively all over the place.

Anyway, I’m thinking…hmm…maybe there’s one that enables that function? I found the AT command set for the HC-05 is thoroughly documented here, and sure enough, the “AT+POLAR” command does just that! The engrish docs read a little counter-intuitively – you actually need to send “AT+POLAR=0,0” to set the board up to turn the onboard LED high and raise GPIO9 (board pin 32) HIGH when paired. But once I tried that setting, it worked like a charm! Oh, and by the way, the opposite (AT+POLAR=1,1) results in the on-board LED flashing slowly when paired and GPIO9 just always stays low.

Hope this helps anyone else looking to do the same.

Posted in Uncategorized | Leave a comment

Experimenting with the ESP8266

Recently co-hacker Jay pointed this out to me: It’s basically a little board that has an even smaller daughter board (an “ESP-12”..more on this shortly) soldered right onto it, plus a USB-serial converter, a 3v regulator, an RGB LED and a button, and it boots up running a little LUA-based firmware that let’s you load little LUA sketches on it. He’s actually running the NodeMCU code on it. A very cool little board that let’s you get little Wifi ‘node’ up and going with minimal effort at the very low cost of $17! He also references a project that led him to put together first the ESPToy 1.0, then the current 1.2. The 1.0 basically combined an ESP8266 with an Arduino, but in 1.2, he did away with the Arduino part entirely.

I was intrigued that the author had basically loaded his own firmware onto the ESP8266 (the ‘ESP-12’ module) little device and started digging into it a bit more. So, it turns out the ESP8266 line of modules have their own embedded 32bit processors, the wifi protocol stack and hardware, and some on-board flash.  They expose GPIO pins and a serial port. Most amazing of all – you can get “bare-bones” ESP modules for less than $5! So, I decided to dig deeper. The LUA runtime is OK, but there aren’t a lot of libraries out there for talking to other things using it. For instance, I’m currently kicking around the idea of an arduino-powered, web-connected universal IR remote – I’d like the greater versatility of Arduion programming, rather than LUA…and the idea little $5 Wifi-connected arduino-like devices is crazy!

So, it seems like there is at least one project out there to program these suckers using the Arduino IDE and code. I’m going to blog my experience here..

ESP Module VariationsFirst step – I ordered a couple of different ESP devices. I should point out that there are a bunch of ESP modules (ESP-01 through ESP-12 at this point).
They’re basically all the same chipset in various configurations exposing different pins and with different (or non-present) on-board antennas.

Then there are many device that have an ESP variation mounted on them an break the pins out to more convenient configurations, add voltage regulator and buttons, etc, and are still very cheap (<$5).

ESP-07 MotherboardESP-12 With Additional ComponentsI got an ESP-07 on a more-or-less bare motherboard and an ESP-12 on a board that has an regulator, RGB LED, LED’s on several GPIO’s, and apparently a photo sensor. The ESP-07 package included an external Wifi antenna that can be snapped on to provide better range than the on-bard ceramic antenna. The ESP-12 package also came with a USB-serial converter that is necessary to connect to these things. I already had one, but figured a spare wouldn’t hurt. Neither of these had any documentation with them.

 also ordered a couple of the ESPToy’s just for the hell of it too 🙂

Bare Motherboard with REgulator I should also point out that first one DOES have a 3v regulator on the back side – even the seller didn’t seem to realize this, but its clearly depicted in the bare version he also sells 🙂

Anyway, having the regulate on-bard is big plus, since it will make actually using them with simple 5V (e.g., USB) supplies easy. (Update: I message the eBay seller to tell him it did have a regulator and he indicated the next version will not, since the chip used on this one is pretty low power. ESP-07 drawing a lot of power is a topic I’ve seen more than once…for instance, they say not to try to use the 3V supply from the FTDI serial adapter like the one in the ESP-12 package, above).

So… here goes..

Everything came at the same time. I plugged an ESPToy in first, since it was the easiest – just plug in a mini-USB cable and it powers up. It fires up the first time with a simple demos that goes into Wifi host mode and serves up a simple HTML page that lets you set the RGB values of the LED. It worked fine..ok, time to go drill into the ‘bare’ modules some..

So, at first, I had trouble getting either to do much. Neither would report or respond to anything over the serial port or show up on Wifi. It seems like there is a lot of variation in terms of what the default firmware is intended to do, but supposedly you should be able to get to a command prompt and do AT commands more or less right off the bat. I tried different baud rates – apparently older firmwares may be 115200 or 57600, while the latest is supposedly 9600 – all to no avail. I was focusing mainly on ESP-12 board and, finally, GPIO JumperI started wondering about the jumper. To flash new firmwares on these suckers, you have to hold GPIO0 (zero) high when you power the board on – this puts it in firmware flash mode. Maybe the jumper is for doing that? Yes! I took the jumper off (and also verified my conjecture with the multimeter) powered it on and right away, a new Wifi network, “AI-THINKER-9B5AC7”, showed up. It took some googling to find the Wifi password, which is “ai-thinker”. I also now get a whole bunch of output over serial as it starts up (my version is operating at 115200 buad) it shows it’s listening on Hitting that url with my browser now produces a “We have a GET request” message on the serial port.

I still get get no response from AT commands, though. My theory is there is a non-standard firmware on this device that leaves AT mode to run the little HTTP demo app. In bit, I’m going to try flashing it with a newer firmware. At this point I also still haven’t gotten any response at all from the ESP-07.


Posted in Uncategorized | 3 Comments

Homemade Security Camera based on Raspberry Pi

This is a great project!

I’ve burned through some commercial consumer-grade wifi cameras – they tend to not last very long…possibly a function of the weather and our Texas heat. I’ve even repaired them a couple times; replacing the IR LED array or even the wifi daughterboad. This will be much more easily serviced and debugged, though – really cool.

I went a little further by adding an IR LED array that I happened to have lying around (from previous repairs projects). It is similar to this one – – although I can’t guarantee this is the same one – I got it a long time. A wide variety of these arrays are available – check the dimensions carefully to make sure it will fit in your enclosure. The one I had fit perfectly in the cylindrical camera body specified in the parts list, above (not the square one shown in the pics, BTW). I mounted the camera board right behind it and cut a short length of black plastic tube that fit in the center of the array to prevent back-scatter of light when the LEDs are on.

These arrays generally come with a built-in light sensor, so they only come on at night. They tend to ​run on 12V, so I use a 12V AC adapter, and a ripped the guts out of a $10 cigarette lighter USB adapter from Walmart (cheaper are available) and hard-wired it in much like described here:…


Be sure and get one that cranks out at least 1 Amp – I did have issues getting enough power to the RPi to power it and the Wifi dongle.


Posted in Uncategorized | 1 Comment

Fast Updates (frame rates) of Color Effect G35 Grids

It’s the time of the year to start playing around with Christmas Light hardware and software. Lately, I’m focusing more on simpler (i.e, less light strings) displays and more on incorporating my “mini mega light tree“.

As described in previous posts (Driving GE G-35 Light String with Digilent Uno32GE G35 ColorEffects Christmas Tree), this consists of a tree made from multiple GE G35 ColorEffects LED light strings. I adapted my light sequencing program to drive the addressable bulbs, using a Digilent ChipKit Uno32 ‘Arduino-compatible’ microcontoller as a protocol converter more or less. The PC software sends serial commands to the Uno32, and it in turn sends commands to the G35 strings via digital out pins. The software essentially treats the tree as a pixel grid which it can load bitmap to; transforms (scrolls and fades) can then be applied to the grid.

One problem that has plagued me, though, is that refreshes get bogged down when sending lots of commands to multiple strings. The effect is pretty severe when trying to do things like fade the whole tree, load an entire bitmap, or scroll a bitmap with lots of different-colored pixels around the tree (bitmaps with just a few pixel variations aren’t so bad, since I only have to update those pixels that change, not every single pixel). This year, I decided to take a stab at improving it.

Until now, I thought that my problem was shoveling a lot of data across the serial line, while also doing the work of sending the custom protocol out to various strings – possibly due to serial handling producing a lot of interrupts. Some other blog entries had misled me (or I misinterpreted them 🙂 to believe that controlling multiple strings at once with high refresh rates should be possible with Arduino-class hardware. Turns out this isn’t exactly true…or at least isn’t simple. There’s an interesting thread on the topic here.

Thinking maybe I just needed to reduce the serial data burden, I started down the path of offloading more of the work to the  microcontroller in order to reduce the data going over the USB serial line. It turns out this is NOT the reason it get’s bogged down. Even when no info is sent via serial (like during the all-string-fades I currently have during setup() execution) the delay between the update of each string increases as I increase the number of strings. One string is very fast, with no significant delay…five is noticeably bogged down. This led me to calculate how much time it takes to send a single color/intensity to every bulb on five strings based on the µSec delays built into protocol functions in the sketch. Turns out it takes over 1/20th of a second to update an entire string! Throw in some overhead for logic and serial handling and it’s nearly a quarter of a second to update five strings! I really should have calculated this sooner (or should have read that thread mentioned above :-).

It’s clear that to get faster updates, more horsepower won’t necessarily help -I need parallel string addressing. Even with more horsepower, I’d still spend too much time blocked, waiting on delay functions.  I think in that forum jwhite describes provides an implementation and provides code where he uses some kind of “ring buffer” and can theoretically update 6 strings simultaneously – I think by constantly looping through a timing cycle and writing the bits representing the ‘current’ color into six pins at once during each cycle? – effectively implementing a true raster rendering? The C code is actually over my head, so I’m kind of speculating here.

Since my C skills are probably too weak to take something like that on, it occurred to me that I could get the parallelism I want using multithreading. By driving each string from a separate thread, less time could be spent by the main thread being blocked by delay functions in the protocol implementation.  As a result, I just ordered a NetDuino Plus. I’m hopeful that this will allow me to take advantage of the multhreading support in the .Net Micro framework, not to mention giving me an easy way to port a lot of the display logic to run on the microcontroller instead of the PC. It even includes ethernet support and an SD card, so I’m thinking I should be able to put all the bitmaps in the SD and move from USB tethering to a simple network-based protocol over Ethernet. Watch here for an update 🙂

UPDATE: (11/27/2013) Dang, just realized the Thread.sleep() only has millisecond precision (and even then it’s not exact) – and although there are techniques for getting microsecond timing accuracy, they appear to be not very accurate, plus they just use loops which would probably not free up the cpu when sleeping. Going to have to think on this one some more…

Posted in Uncategorized | 6 Comments

Arduino-Based WiFi Lawn Sprinkler Controller

This post describes a project I undertook to build a home-grown, Arduino-based, WiFi-enabled lawn sprinkler controller.

I don’t know about you, but I’m never happy with my lawn sprinkler schedule. In Austin, it can rain till my garage floods one week, then return to the typical four-year drought conditions with 100°F+ temperatures for the rest of the summer. As we progress through the drought stages, we go from being allowed to water whenever we want to twice a week to once a week. I also find that the consumer-grade zone controllers have really crappy user interfaces, they are often limit you to either an “every X days” pattern or watering on specific days of the week (but not both), and they tend to limited in how many events are associated with a given zone…not to mention you have to go out to your yard – or maybe your garage if you’re lucky – every time you want to change the schedule.

Well, a while ago my controller died again (I think I’ve gone through three of them now),

Tethered Arduino UNO sprinkler controller and Triac board

Tethered Arduino UNO sprinkler controller and Triac board

so I decided to build something better. My first iteration was an Arduino UNO connected to a second-hand 8-port Triac controller board which drives the sprinkler solenoids (they operate on 24V AC). The Arduino was tethered to my pc via USB (the controller enclosure box happens to be just outside my home office window) and I cobbled together a custom C# GUI for maintaining the schedule for my six zones and sending on/off signals to the Arduino via a simple serial protocol. This worked pretty well, except my PC had to be running for any watering to occur. In the summer in Texas, if you miss a week because your PC was off, you can kiss off your vegetable garden. The lime tree your wife gave you for your anniversary 10 years ago will probably be half dead too, and then your in the doghouse. Trust me.

Anyway, before long, I grew tired of the tethered solution -I came to the conclusion that I needed to ditch the tether.

At first I was thinking along the lines of using the same PC-based UI, but having it send the schedule data to the Arduino, where a more sophisticated sketch would store it locally somehow, then determine the on/off times independently of the PC. This would require a place to persist the data in case of power failures and reboots, plus a real-time clock (RTC). As far as I could determine, there’s not really a way to persist variable data over reboots with the UNO; you can’t persist dynamic variables in the flash RAM from the sketch itself. This led me to consider other Arduino clones that include some EPROM.

As I thought about it further I also wasn’t really that fond of having to tether to the thing just to update the schedule. I realized that a way cooler solution would be to WiFi-enable it. To make a long story short, wanting WiFi and some kind of persistent data store led me to look at Arduino compatibles combined with WiFi shields.

As it happens, my company, National Instruments, recently acquired Digilent. Among other things, Digilent makes a line of very nice Arduino ‘compatible’ boards, the chipKIT series, that run PIC32 processors (see my post regarding driving addressable Christmas lights with an Uno32). As an employee, I get special pricing that makes these pretty attractive, but they’re pretty affordable even at list price. They also have a Wifi shield and, although the chipKIT boards have no EPROM, the WiFi shield includes an SD slot. You can use use the SD slot to store static web pages, but I can also persist schedule data by writing it to file on the SD card. In hindsight, it’s also clear that a faster processor is pretty much necessary for serving up web pages…it’s still a little slow even running on the PIC32, which is an 80Mhs, 32bit processor…way faster than the ATMEGA368 (sorry, Arduino). I chose the Arduin form-factor chipKIT uC32 combined with the chipKIT WiFi shield.

Complete Assembly: a uC32 Microcontroller card, WiFi shield and DS1302 daughterboard

Complete Assembly: a uC32 Microcontroller card, WiFi shield with Micro SD card and DS1302 daughterboard

DS 1302 with pullup resistor from I/O line to +5V

DS 1302 with pullup resistor from I/O line to +5V

For a real-time clock, I went with a really cheap module from which incorporates  the DS1302 chipset. As of this writing, it can be found here, but there are many similar inexpensive boards out there. I scrounged up some examples, as well as an Arduino library or two, for interfacing with the DS1302, but when I would try to make it work interfaced to the uC32, I was getting flake behavior. It worked fine on a true Arduino, however. After googling forever and trying all kinds of things code-wise, I finally stumbled across a thread or two which hinted that I might need to add at least one pull-up resistor. Eureka! Apparently the Arduino has internal pull-up resistors on I/O lines, but I guess the uC32 doesn’t – I added a 4.7K pullup from the DS1302 I/O line to the +5V pin and it immediately started working fine. I connect the +5V and Gnd pins to the corresponding pins on the USB side of the uC32 via a small ribbon cable. I also bent those pins back at 90° so that i could just plug the remaining 3 data lines directly into the female header on the WiFi shield.

DS1302 connected to Gnd and +5 pins on uC32

DS1302 connected to Gnd and +5 pins on uC32

DS1302 daughterboard attached to digital IO pins 37, 38 & 39 on uC32 and Wifi shield

DS1302 daughterboard attached to digital IO pins 37, 38 & 39 on uC32 and Wifi shield

Originally, I thought the problem was software -related. I figured the DS1302 libraries I was finding just weren’t compatible when compiled for the PIC32 – so I wound up writing a really simple custom one and that’s what the project currently uses. I now realize it was probably a hardware issue all along, so shortly I’ll update my code to switch my homegrown one out for one of the libraries already floating around out there like this one or this one. In retrospect, I suppose I could have just used Digilent’s Real-time Clock/Calendar PMOD.

Along the way, I made another discovery – the chipKIT boards also have a non-obvious, poorly publicized feature – you can solder a 32.768Khz crystal onto the board which enables an embedded real-time clock! (see Support for using it is included in the chipKIT MPIDE libraries. I went ahead and bought a pack of 20 from China for about $6 and tried this out…it also works fine! Just for the hell of it, I wrote a wrapper library that will work with either one, depending on which #DEFINE you un-comment in the project’s App.h file – so the sprinkler code works with either. Keep in mind the embedded clock does not retain the time over power interruptions, though, so you would have to provide a backup power source. With this in mind, a separate daughterboard is probably a better bet.

The project software consists of a sketch and related modules developed in the chipKIT MPIDE (available for download on Digilent’s website). This is a version of the Arduino IDE which is compatible with the chipKIT product line.  I’ve open-sourced the code and, as of this writing, the source repository is hosted here: UPDATE: Google has shut down their google code repository. The new location of the code is hre:

A significant portion of the project is code which implements a very basic webserver. Implementing an HTTP server from the ground up in C probably would have been beyond my capability; fortunately, Digilent’s Gene Apperson has written a basic implementation which I was able to use as a starting point. As of this writing, that basic server code can be found hereSince starting this project, I’ve been in touch with Gene Apperson, and subsequently Keith Vogel, at Digilent. Keith has put together a somewhat more robust version of the HTTP server which would really be better to use…I just haven’t had time to go back an re-implement on that foundation. Maybe someone out there would be willing to take that effort on? The new version supports concurrent connections, which would probably improve page load time. It is not been published just yet – I will post the URL here when it is.

Disclaimer, I am a Java guy – not a C guy – and this project got way deeper into C code than your average Arduino sketch, so I am not at all proud of the code I hacked out and will happily accept improvement contributions. I think I’ve ferreted out all the buffer overruns and pointer issues, but I’m by no means certain.

One other note regarding developing the sketch: By the end it had become really cumbersome. The project includes so many libraries, it takes about 50 seconds to compile and upload. Add to that about 30 seconds for the WiFi to connect and you’re looking at almost 1 minute and a half in ‘build time’ every time you want to make a change and test it. I feel like with projects this complex, using a “real” IDE, like MPLAB, with an inline debugger interface would save a ton of time. This would be even more true if you could emulate the WiFi connection…although I suppose you could use a plain old Network Shield during much of the development.

In an effort to keep the back-end lean and simple, I designed the web front-end to be a static web page which relies on AJAX calls to simple services on the server. The page is rendered once and includes some basic jQuery libraries. After initially being rendered, all updates and actions are handled via AJAX calls to simple service urls on the server (with JSON responses, where needed). All the html, javascript, css and image files are stored on the SD card and served up from there. The service URLs are handled via custom code added to Parser.cpp and Render.cpp. The ongoing activity of waiting for schedule on/off times and activating/deactivating zones control pins is handled in App.cpp. Once loaded, the main page, index.htm, performs AJAX http GETs to server services to store schedule changes, manually turn zones on or off, and to get the date/time as well as system status (which it does every 10 seconds).

In order to avoid long delays whenever the page first loads, I also tweaked Gene’s server code a bit to support browser-side caching of javascript, css and image files. This involved returning some cache-specific headers in response to the first request for such files in Render.cpp and watching for the “If-Modified-Since” request header coming back from the browser in Parser.cpp. If we get that header, we just return a 304, instructing the browser to use it’s cached copy. This results in much snappier refreshes after the initial load.

To interface with my 24V sprinkler solenoids, I use a 2nd-hand triac board similar to the one I used in my Christmas Lights Suit, accept that I use the 8-triac version that the author, Mark, mentions here. You can see it in the top of the first photo, above. Of course, you could build your own…triac control circuits are quite simple (example here). Note that Mark’s boards require an inverted signal – so they are OFF, when the input pin is HIGH, ON when it is LOW. To facilitate using this board, but also have the code be compatible with other boards that might be “active-high”, I provide two settings in App.h, INVERT_PINS and INVERT_MASTER_PIN. Set them to true for inverted signals, false for non-inverted.

Here’s a screenshot of the final product:

WiH20 Console Screen Shot

WiH20 Console Screen Shot

So that’s about it – the interface seems to be working pretty well, so this weekend I intend to swap the tethered UNO out for this solution. I encourage anyone who’s interested to help me improve the sketch.  Again, the code repository is at – you should definitely start with the README. In there I’ve called out a number of improvements that would be nice. Within a few days, I’ll hopefully have integrated a ‘standard’ DS1302 library instead of my cobbled-together on. I’ll also be trying out the WF32, a new board just released by Digilent that combines the PIC32, WiFi and SD all on one card.

UPDATE: I’ve now received the WF32 and switched over to it. This is a really nice board – it even includes some nice additional on-board features like more LED’s, some push-buttons, and a potentiometer, as well as a host-mode USB port…all for only $69 retail.

Digilent WF32

Digilent WF32

The transition was mostly painless – one problem I did run into is that you have to get a build of MPIDE more recent than the 07152013 distribution currently on the Digilent site. On the WF32, the i/O pins used to communicate with the SD card are different. I obtained a more recent version of the SD library files directly from the source repository here: .  Once I overwrote the library files under the chipKIT MPIDE install directory with the latest from the GIT repository, it worked like a charm! I also tweaked to pins used for the indicator LEDs a bit, since those onboard the WF32 are not the same as the uC32 (my latest code build will automatically detect which version and set the pinLedConnect and pinLedInitialized variables appropriately). One last thing I will do is solder some pins into the currently empty in-circuit debugger jumper at JP2 to provide power to the DS1302 daughterboard. I’ll then swap out my current, tethered Arduino and my sprinklers will be fully WiFi-enabled 🙂

I’m considering throwing together an Android app for viewing/controlling this guy too…check back later!

Posted in Technical | Tagged , , , , , , | 9 Comments

Cat Cam

A little while ago, I heard a piece about The Secret Life of Cats on NPR. This dude put a camera/GPS logger on a number of cats and mapped what they do throughout the day. There info and a cool interactive map here

Intrigued by the idea of figuring out where our damn cat, Rubio, disappears to every time we let him out, I decided to look into building my own. Turns out GPS loggers are still quite expensive – plus, the form factor of everything I saw that had a camera and GPS logger was pretty big. I don’t want my cat feeling like he’s lugging a keg of beer around under his neck. There are, however, a ton of inexpensive, battery operated “spy cams” out there though. I figured just seeing where he goes would be interesting.

Getting on Amazon, I looked around for cheap spy cams with a decent battery life, a form-factor compatible with attaching to a collar and not weighing my cat down too much. I settled for this one, which is disguised as a car remote: – under 10 bucks, good ratings and Prime delivery in two days – perfect!

Car Remote Spy Cam

One issue is that the camera points out what would be the bottom in this picture (so you can leave the remote flat on a table or whatever and catch whoever doing whatever). Originally, I had planned to glue on a little fragment of mirror at a 90˚ angle so that the dongle could hang from the collar and still “see” forward. That kind of worked, but just for the hell of it, I thought I’d open it up and see if I could re-orient the camera to face ‘forward’ when it’s dangling. It turned out quite easy to do so…

Opened up spy cam

Inside you a small lithium-ion battery, the circuit board with attached SD card and USB connectors, and a camera and microphone on the right.

Conveniently, the camera is attached to the circuit board via a short piece of ribbon cable with a little slack in it. It’s also just kind of wedged in there, not mechanically attached to anything – so it was relatively easy to pull it up over the circuit board and face it “up” when lying flat. I stuck it to the circuit board with some double-sided sticky tape.


Next I just drilled a hole in the housing at the right location with my Exacto, then closed it back up.

I didn’t want the thing to swing around a lot as it dangled from the collar, so I made a sort of custom connector ring that hugs the collar tightly to prevent a ton of swinging motion.

Nest, I put it on record, put the collar on Rubio, and sent him on patrol.

The results of the first run are mixed. This tiny camera produces a really decent image and I’m actually pretty pleased with the “Rubio’s eye view” I got. The only problem is, it didn’t last very long – only about 8 minutes. Here’s a clip from towards the end, where he begins rolling in dirt. I’m not sure if he managed to press the off button while rolling, or getting rubbed against the ground made it turn off, or what. Possibly, I just needed to charge the battery longer. I’ll try another run next weekend. And report back with an update.

Oh yeah – also the image came out upside-down, so I rotated it 180˚, so you’ll notice the timestamp is upside-down.

UPDATE (09/01/13):

Well, Rubio’s second expedition was a better success. Although he didn’t stray too far, he the recorder did last a little over an hour. I think that probably that is about the duration of the battery life, but will know better after another trial or two. He didn’t ravel far from home on this expedition, there are a couple of amusing moments. An edited version is here:  Rubio hands out under our car looking for birds for a while and, after seeing a car go by, heads for the front porch. From there he heads towards the neighbor’s house and encounters our other cat, Asia. He gets pretty vocal at about 6:15 as he heads to the back garden to terrorize a squirrel.

UPDATE (09/08/13):

One last update…we finally captured something a little more interesting – although there is still just a lot of sitting around looking at things. In this clip, Rubio encounters our neighbors’ cat, Nola Bell: Belle

The camera captured 3 segments of about 10 minutes each and it doesn’t end with any ‘violent’ movement, so we definitely seem to be getting under an hour of record time. I may try finding a small battery with superior life..for example, I might try stacking some lithium cells which could last longer, although they are not rechargeable.

Posted in Technical | Leave a comment

ASUS Transformer Prime antenna hack

I love my Transformer tablet, except for the well-documented crappy WifFi reception. Unfortunately, I was an early adopter and didn’t benefit from the wealth of community feedback regarding the problem this otherwise great tablet has with WiFi and GPS reception. The problem in brief seems to be that the antennas are sandwiched between the metal case on the back and the screen, and maybe more circuitry backing it, on the front.

I want to be able to use this thing at work, primarily in meetings, but our already poor WiFi signal in many conference rooms makes it almost useless. So, I finally got up the nerve to try some kind of hack.

Following the instructions here, I cracked this baby open. I didn’t have any kind of high-tensile strength plastic pry-tool, so I just used a jewelers screwdriver to get it started. This made my pretty nervous, since metal against glass has a much higher likelihood of chipping or cracking, but being as careful as possible, it worked OK. It did scratch the back-plate rim slightly, though.

I used aluminum foil backed by double-sided sticky tape, instead of a roll of specialized copper foil, since it’s all I had. I also made the antenna shorter. I don’t know if the guy in the video picked any particular length for his antennas – they’re pretty long…possibly he was going for a full-wave antenna – but I didn’t want anything that gaudy, so I went for 1/4-wave antenna, which for 2.4Ghz, works out to about 1.25 “. I left about an extra 1/4” of the aluminum foil exposed on both sides at one end and sandwiched that between what appears to be some spongy metal stuff that appears to be stuck to the back-plane with double-side sticky tape, and the exposed copper trace of the antenna on the front board. I’m not sure this is the ideal physical connection – I’m not an antenna guru, but I suspect that might be the “ground plane”, rather than the radiating connection.

However, I am definitely getting better reception, so I’m pretty please. It’s still not great, so I’ll probably crack it open again and at least do the other antenna, to improve antenna diversity, and maybe take another look at physical connection options.

Posted in Uncategorized | Leave a comment