I beg to disagree.

One of the unspoken rules of open hardware clearly stated by Phillip Torrone states that “Cloning Ain’t Cool”  While on the surface he is correct, I think we must embrace cloning as a natural consequence of openness, and be flattered by the mimicry.   Now I am not talking about trademark violation which is also called counterfeiting in another post by Phil and is not protected by open licences and is clearly despicable.

I’m talking about legally manufacturing a design that was released under a permissible license.

Recently Makerbot Industries moved away from openness when they announced that their Replicator 2 design would not be released as open source.  Cloning was cited as a major contributor to this decision.  In an attempt to placate the open hardware community, CEO Bre Pettis, pointed out that the (now closed source) extruder modifications were only made to ease mass production.  I have two responses: 1. with 3D imaging growing as fast as 3D printing, the designs cannot be protected for long and 2. more importantly, this confuses open source with DIY.  If open source means DIY, then why does the CERN community release hardware designs?  Are we all expected to start tunneling a super conducting super collider from our basements?

The far more serious threat to open hardware is stealing.  That happens when a company modifies an open design but does not release the modifications when the original license requires it.

WyoLum members will meet for the first time at the Open Hardware Summit in New York City on September 27.

Anool is coming from India, David is coming from Australia, Brian is already in Manhattan, Grandmama is coming from Wyoming, Amy, Emily, Elizabeth, and I are coming from Northern Virginia and Angus is coming from Southern Virginia.

We are so excited to meet the folks we have been spending all of our “free” time with over the last three years.

NYC, here we come!

We’ve written a simple I2C interface for I2GPS (available for sale here). If you’ve ever combined GPS to Arduino you have probably used TinyGPS by Mikal Hart.  We use it too and we love it.

When you want to incorporate GPS into a larger project a couple of issues arise that I2GPS solves.  The first issue is that the GPS object must constantly be “fed” new data.  This leads to ubiquitous calls to gps.feed() throughout the code.  If you have other time critical functions (like updating an LED matrix), the juggling of tasks can get overly complex.  The second is the size of the code can cramp the size of your main program.  We ran into both of these problems with ClockTHREEjr.

I2GPS solves these problems with by offloading the memory and processing burden to a second processor.  The I2GPS slave code needs only to read the GPS, and respond to I2C requests to data.

I’ve modeled the interface after the DS3231, the real time clock included with I2GPS, the same clock as the Chronodot from Macetech.  So from the client side, things look a lot like reading the Chronodot.  Here is a snippet of client code (not updated).  The DS3231 is still available though the I2C interface.

// read 32 bytes from address 0, store in "gps_data" byte array
  gps_raw_read((uint8_t)0, (uint8_t)32, gps_data);

// Parse response
  Serial.print("UNIX TIME:");
  Serial.println(unserialize_ulong(gps_data+0));
  Serial.print("LAT:");
  Serial.print(unserialize_long(gps_data+4));
  Serial.println(" 1/1000th DEG");
  Serial.print("LON:");
  Serial.print(unserialize_long(gps_data+8));
  Serial.println(" 1/1000th DEG");
  Serial.print("ALT:");
  Serial.print(unserialize_long(gps_data+12));
  Serial.println(" CM");

Wall clock time is also available starting at address 0x1C.

gps_raw_read(0x1C, 6, ymdhms);

Serial.print("CALENDAR TIME:");
Serial.print(ymdhms[1], DEC); // Month
Serial.print("/");       
Serial.print(ymdhms[2], DEC); // Day
Serial.print("/");
Serial.print(ymdhms[0], DEC); // Year

Serial.print(" ");
Serial.print(ymdhms[3], DEC); // Hour
Serial.print(":");
Serial.print(ymdhms[4], DEC); // Minute
Serial.print(":");
Serial.print(ymdhms[5], DEC); // Second
Serial.println("");

The I2GPS has several physical interface options. Shown above is the “Buckler” (small shield) interface that plugs directly into the analog side of the Arduino.

The complete data structure memory map is available as a google spreadsheet (for the latest) or below in static html.  I’ve put a couple of field to log the state of analog and digital pins, but supporting code has not been implemented yet.  Available data include: unix time (and wall clock time), latitude, longitude, altitude, course, speed, fix age.

Arduino fans take a lot of flack from the “hard core” micro-controller crowd.  The main complaint is that many projects could be accomplished much more simply.  Take “blink” for example.  Why would you use and Arduino to blink an LED when you can accomplish the same with a 555 timer?  This criticism is eerily similar to complaints I’ve heard about the programming language Python.

Now, Python is a well accepted language that has proliferated into every aspect of computation form the Web, to scientific computing, to graphics to … you name it.  But this was not always the case.   I’ve experienced many eye-rolls and many doubters throughout my twelve year experience with Python.  But Python survived them all because of its massive utility.  Programmers are simply more productive with Python and the economics finally won out.  You can do more in less time with Python.

Arduino faces a similar challenge.  It is disruptive to the status quo and enables anyone with even a passing interest to get something working in electronics with no background and very little effort.  With effort, those same people can accomplish amazing things using Arduino.

To say that “Arduino is overkill” misses the point!  It is often a choice between getting something done or not.  The less time something takes, the more you can accomplish.  And, if Arduino is capable of a task then it is the fastest way to get it done (for me at least).

This brings me to à la mode.  If you have not heard, à la mode is an Arduino compatible board that mates with the Raspberry Pi single board computer.  The R. Pi is a computational powerhouse compared to the Arduino, but it lacks the analog interface to interact with the real world that Arduino has.  Better yet the Raspberry Pi à la mode combo will allow me to mix my two favorite programming languages: Python and Arduino!

I am planning to write a program for à la mode that provides an I2C interface to all of the functionality that the à la mode has to offer.  When both sides of the interface are complete, it will be very simple to read and write analog or digital pins, read the real time clock, and get GPS position (optional).

I can’t wait to get my hands on the hardware!

I recently purchased a car black box camera that records HD video and audio as you drive  along with a built-in GPS and accelerometer.  This model also has a parking mode that stays active while your car is parked.  Any motion in front of the car or vibrations trigger the event to be recorded.  Because I live on a narrow street it is only a matter of time till someone comes along and takes off my side mirror and this camera is meant to catch the incident on video.

Unfortuantely, a camera that is active while parked can drain the car’s battery leaving you stranded.  I wanted a device that would continiously monitor the car’s battery and shut off the camera if the voltage dropped too low.  I bought this product from the local electronics shop and installed it.  Three days later my car wouldn’t start. Back to the drawing board.

Introducing Carduino BatMon – the arduino for your car.

Kevin, Anool and I have been working on a little Arduino compatible board that can monitor two voltages (through a precision resister voltage divider) and shut off a solid state relay if the voltage falls below a selectable value. There’s also an optional display board (shown here displaying the supply voltage). If you don’t want to use the display, the row of pins is a handy breakout of many of the unused Arduino pins.

Requirements:
+ Switch a 12V 1A load (larger loads may be switched with a larger external relay)
+ Arduino compatible
+ Power supply compatible with a noisy car electrical environment (8 to 15V)
+ Dual inputs for an always on battery voltage and an ignition switched voltage
+ Ability for the user to easily switch between various low voltage cuttoff points
+ Optional real time battery voltage display
+ Optional timer mode (Switch off load after XX hours)

Drop by the forum for more information of this project as it evolves.