I know, it has been a pain to compile OpenSprinkler 1.x source code, mainly because the firmware has grown to the point that you can only compile it successfully (i.e. within 32KB size) under a particular version of avr-gcc (4.5.3) in a particular version of Linux. This is very annoying for users who want to modify the source code and experiment with new features. That’s why I have decided to create a VirtualBox image with all the necessary software and settings that you need to easily compile it, without having to install a separate Linux system yourself.

Wait, What?
VirtualBox is a free software that you can use to install and run a virtual operating system (OS) on your existing OS. Let’s say your computer runs Windows (i.e. the host OS). With VirtualBox, you can run a virtual OS (e.g. Linux) under the host OS, as if it is a Windows application but it’s a fully functional Linux system. This makes it easy to switch between different OS without having to restart your computer. VirtualBox is quite mature now. It makes use of hardware virtualization features available on most modern CPUs to provide fast speed. So even though you are running a virtual OS, it feels just as fast as a native OS.

One of the benefits of virtual OS is that the entire OS and all settings are stored in a single file — the VirtualBox Image — on your host system. So you can easily replicate the same virtual OS on different hosts by a simple copy-paste of the image file.

Download
To make it easy to compile OpenSprinkler code, I created a VirtualBox Image for Linux Mint 13 with all the necessary software installed. You can download the virtual image file from here:

• Linux Mint 13 VirtualBox Image (updated Jun 20, 2013, adding OpenSprinkler 2.0 code)

Warning: the file size is 2.1GB, so it will take some time to download. Meanwhile, you can read the instructions below.
User and Password: the virtual OS has a default sudo user opensprinkler and the password is the same as the user name.
VMWare Users: check this forum post for instructions of converting VirtualBox image to VMWare image.
Unzip in Windows: do not use the built-in zip/unzip tool of Windows because it seems unable to recognize the correct file size. Use a third-party software such as 7-Zip or WinRAR.

Instructions
Step 1. Install VirtualBox

Download and install the latest version of VirtualBox from its official website. You should install the version corresponding to your host OS (Windows, Mac etc.). In the following I will use Windows as an example. After installing the software, you also need to install the VirtualBox Extension Pack. This is platform independent.

Step 2. Add a New Virtual OS
Unzip the file you downloaded to a local folder. I recommend creating a folder named VirtualBox VMs in your home directory, and unzip everything there. Next, run VirtualBox you just installed, and click on menu Machine -> Add. Navigate to the folder VirtualBox VMs \ LinuxMint13 and select the LinuxMint13.vbox file. Then click on Open to add the file. Now you should see an item named LinuxMint13 in the virtual OS list.

Click on Settings and make sure the default settings are compatible with your system. In particular, you should check if the Base Memory allocated to your virtual OS is not too large (it defaults to 2GB but depending on how much physical memory you have you may need to reduce it to 1GB).

Now you can click on Start to start the virtual OS. There will be a bunch of dialog boxes popping up with various information. If this is the first time you are using VirtualBox, you should read them thoroughly. Once the virtual OS boots up, you should see the desktop as shown in the following. If you want, you can press Ctrl-F to quit full screen mode, so the virtual OS will look like a normal Windows application running alongside with other applications.

Step 3. Compile OpenSprinkler Code
Arduino 0023 is pre-installed in the virtual OS. So you can just double click on the desktop icon to run it. Also, firmware 1.8.3 source code is pre-installed. So all you need to do to get started is to go to menu File -> Examples -> OpenSprinkler -> interval_program and then you can compile the code directly. If you need to change and file, or update to new firmware source code, everything is located in the arduino-0023/libraries/OpenSprinkler folder on the desktop.

Note: the following two steps are revelent:

• Specify your hardware version by opening file arduino-0023/libraries/OpenSprinkler/defines.h, and uncomment one of the lines #define SVC_HW_VERSION that corresponds to your hardware version. To identify your hardware version, check the version number printed at the top of your OpenSprinkler circuit board. The current version is 1.4.
• If you own OpenSprinkler v1.0 or 1.1, you can no longer upload a program through FTDI. Instead, you need an external ISP programmer. An inexpensive USBtiny programmer is available at Rayshobby Shop.

Step 4. Upload Compiled Code
To upload the compiled code to your OpenSprinkler controller, first connect OpenSprinkler to your computer through the USB port. Then go to the VirtualBox software, and click (in the menu) Devices -> USB Devices -> USBtinySPI. This will allow the OpenSprinkler’s built-in USBtiny programmer to pass through directly to the virtual Linux and appear as a native device. Finally, click on the Upload button in Arduino and you are all set.

That’s all. Hope my effort is helpful for those who want to compile OpenSprinkler source code. Feel free to leave comments, and enjoy playing with the virtual Linux!

Hi All, OpenSprinkler will have a booth at the Bay Area Maker Faire again this year. Due to a number of reasons, I cannot make it myself, but Aaron Newcomb from California has generously volunteered to host the booth for me. He will be showing demonstrations with the OpenSprinkler controller. There will also be flyers and promotional materials distributed there.

In order to make this a success, we would like to have a few more people to help. If you are going or planning to go to the Maker Faire and can help at the booth even for just a couple of hours, that would be great and much appreciated. I am happy to send free gifts to you. Anyone who can help at the booth for at least 4 hours either Saturday or Sunday will additionally get a free Maker entry pass. This is covered by the exhibit.

If you are interested in helping, please respond to this forum post by Aaron, or email me. Thanks!

Recently a random crashing issue has surfaced on the forum regarding some of the OpenSprinkler 2.0 development boards that we sent out a few weeks ago. The background is that we have started shipping a development version of 2.0 for any recent order of the assembled OpenSprinkler. The symptom is that some of the units started crashing and losing network connection, and this seems to be always correlated with the timing running crazy off the charts. Initially I thought this issue may have been caused by a bad RTC crystal, which leads to incorrect timing, and which in turn causes the controller to get stuck. Then at some point I realized all the problematic cases happened on a particular PCB version dated Nov 2012. This helped me narrow down the search range. After a thorough comparison to the more recent version, I discovered that the problem is actually caused by a noise coupling issue with DS1307 RTC. Specifically, according to the datasheet (right image below), the region around traces between the 32.768kHz crystal and DS1307 should be shielded by a ground trace. If this is not implemented, the crystal may pick up noise from nearby traces and cause the clock to run significantly off the charts. When I designed OpenSprinkler PCBs, I had not paid attention to this recommended layout at all. Jeese, why did’t I read the datasheet carefully!

After discovering the issue, I panicked a little bit. Since I didn’t know about the issue previously, and there are hundreds of boards in production at SeeedStudios, am I screwed? It turns out that the situation is not as bad as I thought. First of all, I usually add a ground plane to fill the empty spaces between traces. As a result, on most PCB versions, there is indeed a ground plane around the traces from the crystal to the RTC. Below are examples of the traces on OpenSprinkler 1.4s, the more recent version 2.0, and the version in production at SeeedStudios:

Although they don’t match the recommended layout exactly, they are pretty good at shielding the crystal pins from picking up noise. You know, I have always questioned about those ground planes and wondered whether it’s worth my effort of adding them. Well, in this case it did save me from potentially deep trouble.

Now, in comparison, on the Nov 2012 version of 2.0, the ground plane is missing around that region (probably because there is not enough space between the traces to allow a ground plane). As a result, here is the PCB image:

Not only it is missing the ground plane in that region, but also there are all kinds of signal traces nearby, which makes is extra easy to pick up noise. This is bad, bad, bad. Now, that being said, even with the careless design, it’s not like you are guaranteed to have the problem. It more of a reliability thing: it increase the chance of noise coupling, but in many cases the issue probably doesn’t show up. In fact I was trying to reproduce the problem today on a particular PCB version that has no ground plane. After testing 8 of these, one showed a problem of extremely fast clock (5x faster than normal). And it turned out that I forgot to cut the crystal leads, which make them act like antenna to happily pick up noise. After cutting the leads, the clock went back to normal speed. This probably explains why the problem didn’t surface earlier even though I have never paid attention to the PCB trace around RTC previously.

The DIY version 1.42u is also missing the ground traces around that region. So I won’t be surprised if users have encountered a clock speed problem (although so far I have not received any report of it). In case this happens, an easy thing to try is to re-solder the 32.768kHz crystal and try to push it down to the PCB holes as much as you can. This will help reduce the length of the crystal pins and in turn reduce the chance of picking up noise. Another possibility is to simply solder the crystal directly onto the IC pins,

So overall this is a very valuable learning experience for me. I am grateful to those who reported the issue on the forum, and helped me figure out the problem as quickly as I can. There are about 10 of those Nov 2012 assembled boards out there, and I am happy to replace them for free. With that, it’s now time for me to revisit the datasheets. Never overlook them again!

Tomorrow we will be flying south to Peru for a one-week spring vacation (yes, that’s right!) I am very excited about the trip, and am looking forward to visiting Machu Picchu 🙂 Before I go off and get lost in exploring the ancient world, some quick updates about what’s happening recently:

• OpenSprinkler Pi is back in stock as of last week, and about 50 have already been shipped out. One user on the Rayshobby forum, Ric, pointed out that the original Python demo code only worked for RPi rev. 1. It turns out, as Ric discovered, that RPi rev. 2 has changes the pin numbers of a few GPIO. So if you own a rev. 2, you should update your code from GitHub, and follow the instructions in README.txt to modify a pin number in your Python code. Thanks Ric for finding this out!.
• OpenSprinkler 1.4u will be the last DIY, all through-hole version. As soon as it sells out (there are only a couple of them left in stock), we will discontinue the DIY kits. The main reason is that the support overhead for DIY kits has gradually become too high for me. Although we don’t officially provide any assembly support for DIY kits, when users get into trouble and can’t fix problems themselves, I hate to see them go and have to jump in to help, sometimes even asking them to send the kits back to me so I can fix soldering mistakes for them. This is simply not sustainable any more. One way to solve the issue is to have a community of people to help each other, but i don’t see that happening on OpenSprinkler any time soon. So the only solution is to let go the DIY version. Sorry folks!
• We will be going to the Bay Area Maker Faire again this year. I’ve just submitted the proposal to Maker Faire and hopefully it will be accepted. If you are planning to be there too, feel free to come by, hang out with us and watch demos 🙂
• Since we are going off for vacation, we won’t be shipping packages until Monday March 25. Meanwhile I will still be checking emails, although probably no more than once a day.

All right, time to pack and prepare for the trip tomorrow. Thanks for reading this post!