Feed on
Posts
Comments

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!

IMG_2704ds1307_recommended_layout

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:

pcbtrace20pcbtrace14

pcbtrace20_new

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:

pcbtrace20_alpha

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!

The Cost of Development

During the process of cleaning up my workshop today, I collected all the OpenSprinkler prototype boards that have had design mistakes or were built and failed in the past, and looks at this whole box of lovely PCBs:

IMG_2671

Probably no less than 30 boards in the box. It’s quite shocking to realize how many there are. By far getting prototype PCBs has been the most time-consuming and costly part of the development process. First of all, each round of prototype PCBs costs about $50 and takes 9 to 12 days of lead time (using the fastest shipping option), from places like SeeedStudio or Smart-Prototyping. The cost is not dramatic, but the lead time is quite significant unless if I am willing to pay hundreds of dollars to order from US-based services. Also, these boards are unfortunately complex enough that home DIY PCBs are no longer a viable solution.

Then, no matter how careful I am in designing the PCB, there are always a couple of unforeseen issues that had to be discovered when I actually start assembling. For example, a component might be too far away from the enclosure cutout, a component footprint might be wrong, two components might be too close to each other, the pin headers were placed in the wrong orientation, and sometimes I forget to add a ground plane. Because these issues are only discovered after one round of PCBs have arrived (then I will fix the issues, refine the design, and order another round), they make the development process sequential and cause the overall time and cost to quickly add up. The good thing is that over time I learn from lessons and accumulate tips to help me maximally avoid potential mistakes. Still, it’s inevitable to produce design issues, which can only be fixed by putting in more money and time.

When I get the finalized PCB, however, I often feel proud, as if it’s a work of art which has been refined and polished and is ready to be seen by the public. Then I get a sense of achievement. That’s the joy of working on electronic circuits 🙂

I’ve made a minor update to OpenSprinkler Pi (OSPi), and the new version v1.02 has improved design of the separation pillars in order to make use of the screw holes available on Raspberry Pi rev. 2. See the picture below:
IMG_2669_a
This way, the Raspberry Pi rev. 2 can be more securely attached to the OSPi even with just two screws.

If you own a Raspberry Pi rev. 1 instead, don’t worry, you can still attach it to OSPi using the two edge screws (see the picture on the right below), in the same way as the original OSPi. To do so, you will need to move one of the separation pillars. See the picture on the left below (sorry, the arrow is pointing in the reverse direction).

IMG_2670_aIMG_2666_a

So in sum, the updated version OSPi v1.02 allows you to make better use of the screws holes available on RPi rev. 2 while still being compatible with RPi rev. 1.

Tags: , ,

OpenSprinkler Orders Delayed

There has been an unexpected delay in the enclosure processing: the order was supposed to arrive by Monday this week but is now pushed back to Friday next week. As a result, all orders that include an OpenSprinkler enclosure will be delayed. I am really sorry about the delay. It is unfortunate and unexpected. The way we currently order enclosures is through Electronic Precepts (http://electronicprecepts.com/): they order in bulk from Serpac and machine custom cutouts for us. While on vacation last week, I sent an inquiry email and learned that there will be a delay due to machine down time. Initially I was told it would come today, but the latest status is that it’s more likely to come Friday next week. I know the folks who have ordered OpenSprinkler / OpenSprinkler Pi have been waiting eagerly for their orders to arrive. Sorry about that! I wish I had control over the enclosure processing. Meanwhile if you want to cancel the order, or want to receive the board first and enclosure later in a separate package, feel free to let me know. Thanks for understanding!

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!

Machu_Picchu

« Newer Posts - Older Posts »