Homemade Security Camera based on Raspberry Pi

This is a great project!  http://www.instructables.com/id/Raspberry-Pi-as-low-cost-HD-surveillance-camera/?ALLSTEPS

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 – http://www.dx.com/p/31632 - 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: http://www.instructables.com/id/Solder-USB-power-c…

Image1

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.

Image1

Posted in Uncategorized | Leave a 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 dx.com 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 http://hacking.majenko.co.uk/node/33) 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: https://code.google.com/p/wifi-sprinkler

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 https://code.google.com/p/wifi-sprinkler – 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: https://github.com/chipKIT32/chipkit-core .  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 , , , , , , | 5 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 http://www.bbc.co.uk/news/science-environment-22567526

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: http://amzn.com/B005C0Y9N2 – 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.

20130811_094311

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. http://youtu.be/7Bi2Mb8-Bow

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: http://www.youtube.com/watch?v=cXfGlrITkSQ  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: http://www.youtube.com/watch?v=OQYQtSsLVHENola 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 http://www.youtube.com/watch?v=fsRqjG8i3Vw, 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

Repair the WiFi on Your Foscam FI8904, FI8905 or Maygion IP Camera

I have three different WFfi-connected network cameras; a Foscam FI8904, an FI8905, and a “Magion” Chinese knockoff I got on DealExtreme. These cameras are all pretty similar. There are anecdotal stories that the Maygion is really just an unbranded Foscam with custom software, but I haven’t really confirmed this. They’re fairly low-end (among the least expensive in terms of WiFi outdoor security cameras), which means the image quality is mediocre, especially in the brightness extremes of outdoors.

Also, the build quality is not great. Between the three of them, there’s always something going wrong; and AC adapter failing, IR emitters burning out, etc. Replacing the AC adapter is no big deal, and you can actually find replacement IR LED arrays on DealExtreme, so I’ve had some luck replacing those, as well. Twice, now, I’ve had a camera just stop working over WiFi.  You’d think this would be a situation where the only option is to toss it out and but a new one, but it turns out it’s not! In both cases I was able to repair the WiFi..for as little as $10!  To get that cheap, I had to do some more serious hacking (as I describe near the end of this post) but my first fix was quick, safe, and cost about $35.

I both cases where the wifi quite working, there was no obvious symptom..no errors in the log or anything…it just stopped reporting found wifi networks through the web admin page and no longer connected to my home hotspot.  It worked fine via 10baseT. When the first one died, on a whim I decided to crack open the case and see if it was anything obvious, but I had little optimism. The circuit boards inside consumer electronics like this tend to be a nearly incomprehensible array of surface-mounted components – impossible for an amateur like me to repair.  In this case, though, I discovered room for optimism.

Mother and Daughterboard inside Maygion camera

The rear of the camera can be removed by unscrewing four hex nuts, then carefully pulling the whole assembly out. Inside are a motherboard and a daughterboard mounted to it with a couple of stand-offs. The daughterboard is..you guessed it..the wifi board! Shown here already removed from the stand-offs. it is connected to the antenna and to the motherboard via a 4-wire jumper. These pictures are actually from my second repair (of my Maygion camera), but the two Foscams are almost identical.

Figuring it was still a long-shot, I started googling for identifying markings on the assembly. Turns out it’s relatively easy to find direct replacements for this board! The “model number” on the white sticker, “vnt6656g6a40″, turns up multiple hits.

Maygion identifying sticker

Interestingly, the identifying product information on the Maygion camera is almost the exact same sticker! They most likely stick one to the outside of the camera because it also shows the mac address.

Although I ordered my first replacement for about $35, I recently found one here for only $15 (may be a lot of shipping, though). As of this writing, they also seem to be available here and here.

The first time I made this repair, it was to one of the Foscams. As a stopgap measure to get the “better” (bigger IR emitter array), defective one working, I actually just cracked open the other one and swapped the boards. Bingo! It worked like a charm! I was now confident that a replacement board would do the trick and would be worth the $35. Sure enough, when the new one arrived, it was essentially identical to the original – even the jumper plug was the same. I plugged in the 4-wire jumper and antenna, powered it up, and presto!

This was an easy and convenient fix, but when the wifi died on my Maygion, I started to think this could add up if wifi goes out on a camera every six months or so. Ultimately, I should probably look at a camera with slightly better build quality. There are some in the $200 price range which might be a little better, while still being affordable. Still, there’s no guarantee that these won’t use a similar cheap (and trouble-prone) wifi module. It could be that the power supplied to the daughter board by the motherboard and, indirectly, the AC adapter, is poorly regulated and may be contributing to early failure, but who knows!?

So as I mulled over spending another 35 bucks, I thought about something that had intrigued me the first time around…time for some AustinLightGuy hacking!

The description of the daughterboard on one or more sites is typically something similar to “VIA VNT6656  USB Wireless LAN Module”. Hmmm…USB… Clearly, the 4-wire jumper connecting these things to the motherboards is just a USB connection! Digging a little deeper into the specs, I also found this: “The VT6656 WLAN Controller chip on the VNT6656 USB WiFi Module supports all major Microsoft Windows and Linux operating systems.” If you examine the chip on the daughterboard, it is, in fact, a VIA VT6656, and apparently very common wifi chipset! So i got to thinking, ‘well, what if I just bought the cheapest USB wifi adapter I can find that sports the VT6656 chipset, and the tear it open?’

That’s what I did. I bought this USB stick on ebay (advertised as a “54Mbps Wireless USB Adapter For DELL Latitude, INSPIRON & XPS Laptops”, as an FYI, since I assume the link won’t last forever). It was $9.99 with free shipping. When it arrive a few days later, I immediately removed the one screw holding the case closed, and opened it up. The result is actually comical! Here are two photos showing the camera daughter board next to the wifi USB stick board.

Camera daughterboard (left) next to USB WiFi stick (right)

Camera daughterboard next to USB WiFi stick – reverse

As you can see, these boards are practically identical! Even then component layout is very, very similar. My guess would be that anyone who want to knock out a wifi module just implements one based on a “Typical Application” diagram supplied by then vendor, VIA, or something like that. Anyway, this is clearly hackable.

First, I figured out which wires were which on the camera jumper by testing voltages with my multimeter. I came up with this pinout:USB Jumper Pinout

Next, I figured out which were the corresponding pins on the USB stick by comparing the connector to a standard USB connector pinout.

USB module pins

USB_A_pinout

Piece of cake. Now I just removed the USB connector from the wifi stick, cut the connector of the jumper and soldered the wire right to the stick. (Actually, I first fooled with trying to transplant the micro connector from the original daughterboard, but this surface-mount stuff is really tiny and fragile and I eventually gave up in favor of the brute force approach : )

Antenna wire soldered to antenna trace on USB stick and ground.

Antenna wire soldered to antenna trace on USB stick and ground.

Cool, now just to connect the antenna…DOH! The connector on the original module is male and the one on the stick is female! Oh well..after abandoning another effort to to reuse the old one, I just cut off the connector and soldered the antenna wire right to the board.  Next, I did an experimental power-up and, sure enough, it immediately connected to my wifi – Sweet Success! By the way, when these things boot up correctly, there is a little LED on board which lights up…goes off for just a moment about 10 or 20 seconds in to boot, then turns back on. It also flashes when in ‘discovery’ mode. On dead boards, it’s just remained on all the time.

So, I am now confident that I can repair dead wifi on both Foscam and Maygion cameras for just $10. Not a bad deal.

Posted in Technical | 7 Comments

Kudos to Ernie Cline’s “Ready Player One”

A while back I saw the hardback (softback?) of “Ready Player One” on display at some big-box bookstore. I think the flashy cover drew my eye. At the time, it looked interesting, but I don’t really buy paper books anymore, plus I’m always suspicious of those books on those display tables – seems like they’re the ones the publishers want you to buy, which probably aren’t the ones I want to read. Turns out that was totally not the case with Ready Player One.

A few days ago, it came up as “recommended” while I was cruising for new Kindle books. A quick read of the reviews and I was all over it. I’m not a book reviewer, and this blog isn’t about reviewing that kind of thing, but in this case, I just need to gush! Turns out Ernie Cline is a huge fan of 80’s era geek stuff – plus he lives in Austin AND drives a Delorian! Just driving a Delorian makes him cool in my eyes. He’s also got a bunch of Ghost Buster stuff that makes the arguably pretty decent costumes I made (back in the 80’s, I should add :−) look like amateur hour.

Who ya Gonna Call?!

Who ya Gonna Call?!

In “Ready Player One, Ernie concocts a future (2044) where deep knowledge of all things 80’s, especially geeky things, becomes suddenly very relevant. Things I geeked out over in the 80’s, like role playing games, early console games,  early PC’s, dial-up BBS’s, 80’s geek movies like Wargames and Monty Python and the Holy Grail, dorky 80’s music like Oingo Boing and Duran Duran…all these things and myriads of other details feature front and center in the plot.

I played D&D! I played those dorky Atari 2600 games! I spent man-weeks  and hundreds of dollars of allowance at Aladan’s Castle playing video games! I had a Tandy Color Computer (still do :−), a Sinclair 1000, a TI-99/4, and an Apple II! (Sadly, I detected no reference to the Commodore Amiga computer line…COME ON, Ernie! ;−) And of course, I’ve seen every movie referenced in the book. While I wasn’t quite as into the esoterica of console games, anime & manga and music as the book’s characters, 90% of the references totally struck home.

I don’t want to spend a long time reviewing the book here – you can read much more comprehensive and well-written reviews on Amazon, but I’ll try to some up the plot briefly, in case reading this can prompt you to buy the book, which you should. Basically, a fictional computer game genius/mogel, James Halliday (now super-rich), has created the worlds most pervasive MMO, the OASIS. Sort of a combination of Second Life, plus every MMO game your can name (World of Warcraft, Everquest, Eve Online, etc., etc.) the OASIS is so pervasive that it has essentially replaced the internet. Play, business, entertainment – it’s all conducted online in OASIS.  Well, when Halliday dies of old age, his will stipulates that the first player to complete a quest wins his fortune ($250B or something like that) and control of the OASIS and it’s parent company. These stakes are huge, so millions of people are hunting for the keys to the quest and brushing up on 80’s esoterica – not to mention some giant clans and at least one powerful, greedy, and downright evil multinational. Since, like the author, Halliday was weened on 80’s geekdom, completing the quest requires substantial knowledge of all things 80’s or geeky, not to mention deep skilz in 80’s console and PC games. The quest is also not without “real-world” jeopardy.

As I’m reading this book, I’m thinking, “man, if done right, this would be a freaking awesome movie.”  Hurrah! – in the afterword, Ernie mentions there was already a big bidding war between some studios over the rights and it looks like Warner Brothers is actually going to make it! The producer seems to be Donald De Line, who also produced Green Lantern, which is a big warning flag, as far as I’m concerned, but at least he has some experience with heavy CG, which would be critical. Also, Ernie wrote the first couple of drafts of the screen play (he also wrote Fan Boys, by the way – you gotta love this guy!) so maybe there is hope. There’s a pretty cool interview with Ernie here. He cops to being a huge Snow Crash fan, by the way – probably my all-time favorite book, and one I would really like to see done well as a movie. Here’s to hoping they don’t make a mess of this one!

Posted in Uncategorized | 2 Comments

GE G35 ColorEffects Christmas Tree (part 2)

I pretty much have the “Mini Mega Tree” and sequencer enhancements all wrapped up. I only got my hands on five 50 bulb strings of G35’s, so my tree isn’t as big as the “original” Mega Tree, but I was able to get 20 lengths of 12 bulbs out of the setup, which made for a decent tree almost 12 feet tall.

I figured it would be a challenge erecting it, so to simplify things a bit, I bought a collapsible painting pole from Lowes for about $15 bucks and screwed a bent-up paint roller onto the end of it to hook the strings over.  

Just for the hell of it, I also got a PVC end cap to keep the pole from sinking into the yard. Since I plan on actually using it to paint with too, I don’t want the handle to fill with dirt and mud.

To get a sense of the circumference the base would have to be, I first laid a string out in a circle. I marked the location of each bulb with a stake. I bought the stakes in the garden center at Lowes and bent the tops in such a way that I could slip the flat wire of the strands into the slot.

I drilled a hole in the handle end, drove a 36″ piece of rebar into the dirt, then slid the handle end of the pole down over it. The rebar kept it upright (in collapsed position) while I looped the strings over the roller bard on the top end.

 I roughly positioned the ground-side ends of the strand lengths and secured them with the stakes I described previously.  Then I got in the middle of the collapsed tree and simply expanded the pole, raising the whole thing to its full height.

Since Part 1, I’ve done quite a bit more coding and worked a number of bugs out of the new plugin for my sequencer which supports driving grids of G35’s. Though not perfect, it’s working pretty well.  There is still a limit to how much data I can pump across the serial port to the Digilent Uno32 Arduino clone (which was necessary to get any speed at all).  If I use bitmaps that require updates to many LEDs, for example, when multiple rows or columns (depending on which way the bitmap is scrolling), it gets bogged down and falls behind.  Nevertheless, I can achieve some really nice patterns and don’t have to custom program each one in “C-like” code or whatever. I think perhaps next year’s project will be to change the way the plugin works. I think I could just download the bitmap to a buffer on the Arduino clone along with some instructions on what to do with it (i.e., scroll in and loop 5 times). This would require a burst of serial data, but less overall. Too much refactoring to do this year, though..it’s going to have to wait!

UPDATE: (11/25/2013) I recently realized I’ll never get high frame rates with several G35 strings running on the current platform…read more here.

Anyway, here’s this year’s final product: “Mini Mega Tree”  If you want to try out this latest version of the sequencer, which includes the G35 Grid plugin, you can download it here:  http://practical-apps.com/misc/Sequencer3.4.zip

Posted in Christmas, Technical | Leave a comment

GE G35 ColorEffects Christmas Tree (part 1)

In a reply to a preview post, Jim pointed out this video of a cool project another guy did using G35 strings and a microcontroller: http://www.youtube.com/watch?v=bPgqNXjf-MY

I’ve been kind of dreading the effort of setting pulling out the scores of strings of lights I normally set up and sequence with my custom relay box. I did a Halloween setup and just finished taking it down. What with having to go out to the piney woods of East Texas for the Thanksgiving holiday and subsequent AustinLightGuy appearances around town in Austin, I just don’t have the energy this year! I was already thinking about doing something that was “big bang, low-effort”, so that post got me thinking.

Now, that MegaTree looks like it would involve a whole lot of micro-controller code, which is pretty time consuming to write, debug, etc.  In fact, writing custom code for all those patterns seems likely to be time-consuming in any language, so I started thinking about whether I could leverage my existing home-grown sequencer. In one respect, it’s not a great fit: it’s basically designed to turn individual “channels” (aka, light strings) on and off, not render what is essentially raster graphics on a grid of bubs. I though about a way to do that easier and maybe still leverage my sequencer in some way.

I came up with something pretty easy..I’m kind of going to “cheat”.  When you think about it, most of those patterns can be achieved by essentially rendering very-lo-res bitmaps to a display grid composed of bulbs. So, if I write some software that just takes bitmaps, “renders” them as commands to individual bulbs, and provides for scrolling the bitmaps in and out, rotating them up, down, left, right, etc., that – when combined with some simple bitmaps I can whip up in a paint program – would come come pretty close.  So that’s what I did.

My sequencer already accommodates dropping a variety of controls onto a sequence channel; on/off spans (which can also be G35 ramp up/down commands for channels mapped to G35 strings), pauses, loops, wave players and X10/Insteon controls.  I made a new one with a property sheet that looks like this:

G35 Sequence Property Sheet

I can specify the bitmap to display, cause it to scroll in or just appear, rotate up/down/left/right any number of times, then scroll out or just disappear. I can drop multiple grid controls back-to-back on a channel and, since I can carefully control the start times, I should be able to keep them pretty well synced with music from a WavePlayer control. Like my single-string G35 driver, this is a tethered solution – EverSequence is written in C# and it talks to an Arduin-compatible microcontroller over a USB serial port. The microcontroller runs a simple program that basically just acts as a protocol converter.

Now having spent a couple of man-days on it, I think it’s working pretty great. I have the same problem I have driving one G35 string with an Arduino…the sketch seems to wind up having timing glitches when it’s reading lots of data from serial and toggling the digital-out pin. This results in “glitchiness”, with bulbs left on..state changes cropped..etc.  But, as with the single-string driver, the screamin-fast chipKit Uno32 from Digilent seems to be totally up to the task. I can drive it at 230,400 baud and it seems to miss nary a command. I think at that rate, it’ll be capable of really decent “frame rates”, even with a 12X24 grid (yeah, my tree will be smaller than that other guy’s – only 24 lengths of 12 lights..or 6 strings). Stay tuned for a follow-up describing the build and final product and a link to the Sequencer.

Posted in Christmas, Technical | 1 Comment

Driving GE G-35 Light String with Digilent Uno32

Well, Christmas is approaching, so I guess it’s the time of year when I start revisiting projects that abruptly paused around Dec 26th last year.

I guess the thing that has been nagging me the most has been that I never really got my light sequencing software working very well with the GE G-35 light strings, as described a couple posts ago.  It continued to be kind of glitchy, especially when sending a lot of commands in rapid succession, like when doing ramps, fades, etc. Sometimes certain bulbs would be left on when they should have been off, some commands seemed to get ‘dropped’, etc.  I’ve had a suspicion that the cause is one or both of: (a) the signal timing generated by the Arduino “protocol converter” sketch not being perfect, or (b) The Arduino processor speed not being able to keep up with the rate that commands are sent.

Recently, an Arduino-compatible board by Digilent, the Uno32, came to my attention. It claimed to be fully Arduino-compatible, but runs a PIC32 processor at closer to 80MHz. It aslo has more IO pins and memory, but the speed is what interested me. I’m all about spending a few paltry bucks to save time on this accursed hobby, so I ordered one, hoping that just have a faster processor would produce positive results…

…BINGO! The board did have one compatibility problem with my sketch – I guess it doesn’t support the same serial registers, including the one for tweaking the handshaking, but I included that line is desperation, not because I had any evidence it would help.  I commented out the offending line, loaded the sketch (using Digilent’s custom IDE) fired up EverSequence and – sure enough – it works WAY better! Ramps and fades are pretty consistent and there is generally much less ‘glitchiness’.

That said, I still could an occasional bulb left in an inappropriate state. At this point, I still think (a) may be an issue.  I’ve seen a thread or two about the Arduino serial library not being very accurate and people linking more accurate timing libraries (delay_x) to get better results, so I might investigate that.  I kind of suspect I might have trouble getting the delay_x library to work on the Uno32 given the incompatibility I already ran into, so there’s some investigation there that may cause me to put it off indefinitely :-)

You can download the Digilent Uno32 version of EverSequence here.

UPDATE: (11/25/2013) I’ve continued to be plagued with a problem where the string refreshes get bogged down when sending lots of commands to multiple strings – like when trying to ‘fade’ a grid made out of five strings of bulbs. I recently realized I will likely never get high frame rates with several G35 strings running on this platform…read more here.

Posted in Christmas, Technical | 3 Comments