Just a quick note to with all our fantastic customers a Merry Christmas and Happy New Year. Also to let you all know our holiday operating times for the 2012 holiday season.

We are a family business and think it's important to spend the holidays with family. Our office will be closed from this Friday 21st of December, the website will of course still be accepting orders but dispatch will be delayed until we reopen on Monday 7th January.

If you have any urgent requirements feel free to email. I (Hadley) will be sporadically checking emails and may be able to respond during the holidays.

All the best to you and yours for the holidays, enjoy yourselves, stay safe, and try not to eat too much!

Cheers!

I (Hadley) do a little work with solar powered installations. Lately I've had a few people ask how to work out what size solar panel they need to run some electronics so I thought I would take the time to note down how to calculate it here. Solar dimensioning is pretty straight forward once you know what equations you need to work out. One thing you'll probably notice is that you need a lot bigger solar panels and batteries than you think, especially if you want to run something 24 hours a day.

First for this theoretical example we'll make a few assumptions.

• The load we want to run is 10W
• We want to run the load 24 hours a day
• We get an average of 4 hours of peak sun each day.
• We want to size the system large enough to handle four rainy/cloudy days without sun.
• We'll be using lead acid (car) batteries.

Now to the actual calculations you need. To start with we work out what sized batteries we need and then what size solar panels we need to charge them.

Lets work out the Watt-Hours we'll be using, our load is 10W and it's running all day and night so: 24 hours 10 x 24 = 240 Watt-Hours

Once we have the Watt-Hours and the type of battery we're using we can work out the Amp-Hours, 240 Watt-Hours divided by 12 Volts: 240 / 12 = 20 Amp-Hours. That's only for one day though and we wanted to withstand four days of bad weather (autonomy). Let's multiply: 20 x 4 = 80 Amp-Hours

With a lead acid battery you really only want to discharge the battery to 50% at the most, any more and the battery will wear out quickly. So double the Amp-Hours needed and we get a battery size of 160 Amp-Hours - quite a lot bigger than you would think, also that's quite a big battery, it will be about 30kg!

Now that we have our battery size we can move on to working out what size solar panel we need to charge it. Remember from our first calculation three paragraphs above our daily use is 240 Watt-Hours. Our assumed daily sunshine is 4 hours. To recharge the battery for one days worth of usage in one day charging, we need a solar panel that is: 240 Watt-Hours / 4 hours = 60 Watts.

The charging system isn't 100% efficient, a good rule of thumb is to allow for 20% losses. You might also want to add some solar panel capacity to allow for a quicker recovery from extended periods of bad weather, perhaps another 20%. So your panel choice may by up to: 60 Watts x 140% = 84 Watts. A standard panel sizes are 60W and 90W, depending on your exact usage and the level of autonomy you want somewhere between those would be a good choice.

I hope that gives some insight into how you go about sizing up a solar and battery system. There are some web based solar calculators out there which may do some of this work for you. Have a search around the web. Just beware that a lot of them aren't fantastic quality and it's not all that difficult to do the calculations yourself on a plain old calculator.

To calculate the actual sun hours for places around New Zealand, including the differences between summer and winter, check out SolarView from the good folks at NIWA

While we don't sell large solar system components talked about here we do have a range of small solar modules and components which you might like to check out. If you've got any neat projects you're doing please do let us know in the comments below. Cheers!

Last week some guy came around and switched out our old meters for new ones. Not "smart" meters, just new dumb meters, which is fine as the current crop of "smart" meters don't seem to benefit the customer, rather just the company.

A couple years back we used to have a Currentcost device which I had hacked with an Arduino to put data on the network but I always had issues with phantom loads so the transmitter stopped working I never did anything about sorting it out.

Anyway, the new meters have a red LED impulse output that flashes 1600 times per kWh used. These are just about the perfect way to hack into your meter - no dangerous (and potentially illegal) connections required and super easy to do. It should also be very accurate since the meters are certified correct.

Here's a photo of the meter box showing the new meters and the sensors (with black tape over them). The two meters are on the outside and the ripple control in the middle. The Arduino and enclosure are just outside the photo to the right mounted on the wall, I thought it best to keep "odd looking things" out of way of the power company.

For the controller I used a Freetronics EtherTen which is an Arduino Uno compatible with built in Ethernet, these are great boards that we use a lot of here. The sensor is just a Photocell on the end of a small twin core wire connected back to a Prototyping Shield with a resistor.

The sensors are covered in black duct tape to keep out ambient light and connected up to the two interrupt digital input pins on the Arduino to make counting the pulses really easy (see the code below).

I already use MQTT (which is a simple network publish/subscribe system, great for machine to machine (M2M) communication) for some home automation around the house so publishing the electricity usage there made perfect sense. The EtherTen publishes the data on the network and any number of clients can subscribe to this and receive updates. Currently there's just a Python server which logs the data into a redis db for historic graphing. Here's an example graphs;

You can see that our house and its young family has a long way to go with saving energy. The blue graph is the standard meter and the red graph is the water heater circuit. This graph is actually higher than normal, it was a cold day but not cold enough to have the log burner on which heats up the entire house. You can see overnight the electric heaters in the children's bedrooms cycling on and off and at 6am the heat pump (air conditioner) ramping up to heat up the living area.

Of course you could also add any other network device and have it subscribe to the electricity usage MQTT topic. Perhaps I'll build a little RGB LCD display and have it show the current usage with a colour that reflects how well (or badly) we're doing at saving energy.

Here's the code I've been playing around with, suitable for Arduino 1.0+ and the not quite latest Arduino MQTT client (there was an update released this weekend which I has a small API change - easy fix).

/*
* By Hadley Rich 
* Released under the MIT license.
* Some ideas taken from arduino.cc example code.
*/

#include <stdio.h>
#include <SPI.h>
#include <Ethernet.h>
#include <PubSubClient.h>

byte mac[6] = { 0x90, 0xA2, 0xDA, 0x44, 0x34, 0x28 };
char macstr[18];

const int chan1_pin = 2;
const int chan2_pin = 3;
const float w_per_pulse = 0.625;
const unsigned long ms_per_hour = 3600000UL;

unsigned int chan1_count = 0;
unsigned int chan2_count = 0;
unsigned long report_time = 0;
unsigned long chan1_first_pulse = 0;
unsigned long chan1_last_pulse = 0;
volatile byte chan1_pulse = 0;
unsigned long chan2_first_pulse = 0;
unsigned long chan2_last_pulse = 0;
volatile byte chan2_pulse = 0;

PubSubClient client("sodium.nice.net.nz", 1883, callback);

void callback(char* topic, byte* payload, unsigned int length) {
}

void chan1_isr() {
  chan1_pulse = 1;
}

void chan2_isr() {
  chan2_pulse = 1;
}

boolean connect_mqtt() {
  Serial.print("MQTT...");
  if (client.connect(macstr)) {
    Serial.println("connected");
    char topic[35];
    snprintf(topic, 35, "house/node/%s/state", macstr);
    client.publish(topic, "start");
    return true;
  }
  Serial.println("Failed.");
  return false;
}

void setup() {
  pinMode(chan1_pin, INPUT);
  pinMode(chan2_pin, INPUT);
  attachInterrupt(0, chan1_isr, RISING);
  attachInterrupt(1, chan2_isr, RISING);
  Serial.begin(9600);
  delay(1000);
  snprintf(macstr, 18, "%02x:%02x:%02x:%02x:%02x:%02x",
    mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
  Serial.print("DHCP (");
  Serial.print(macstr);
  Serial.print(")...");
  if (Ethernet.begin(mac) == 0) {
    Serial.println("Failed.");
    while(true);
  }
  Serial.println(Ethernet.localIP());
}

void loop() {
  char topic[35];
  char value[6];
  static unsigned int chan1_watts;
  unsigned long chan1_delta; // Time since last pulse
  static unsigned int chan2_watts;
  unsigned long chan2_delta; // Time since last pulse

  if (!client.connected() && !connect_mqtt()) {
    return;
  }
  client.loop();

  if (millis() - chan1_last_pulse > 60000) {
    chan1_watts = 0;
  }
  if (millis() - chan2_last_pulse > 60000) {
    chan2_watts = 0;
  }

  if (millis() - report_time > 5000) {
    chan1_delta = chan1_last_pulse - chan1_first_pulse;
    if (chan1_delta && chan1_count) {
      chan1_watts = (chan1_count - 1) * w_per_pulse * ms_per_hour / chan1_delta;
      chan1_count = 0;
    }
    chan2_delta = chan2_last_pulse - chan2_first_pulse;
    if (chan2_delta && chan2_count) {
      chan2_watts = (chan2_count - 1) * w_per_pulse * ms_per_hour / chan2_delta;
      chan2_count = 0;
    }
    if (!(report_time == 0 && chan1_watts == 0 && chan2_watts == 0)) {
      snprintf(topic, 35, "house/power/meter/1/current");
      snprintf(value, 6, "%d", chan1_watts);
      client.publish(topic, value);
      snprintf(topic, 35, "house/power/meter/2/current");
      snprintf(value, 6, "%d", chan2_watts);
      client.publish(topic, value);
      Serial.print("Chan1 ");
      Serial.println(chan1_watts);
      Serial.print("Chan2 ");
      Serial.println(chan2_watts);
      report_time = millis();
    }
  }

  if (chan1_pulse == 1) {
    chan1_count++;
    chan1_pulse = 0;

    chan1_last_pulse = millis();
    if (chan1_count == 1) { // was reset
      chan1_first_pulse = chan1_last_pulse;
    }

    snprintf(topic, 35, "house/power/meter/1/usage");
    client.publish(topic, "0.625");
  }
  if (chan2_pulse == 1) {
    chan2_count++;
    chan2_pulse = 0;

    chan2_last_pulse = millis();
    if (chan2_count == 1) { // was reset
      chan2_first_pulse = chan2_last_pulse;
    }

    snprintf(topic, 35, "house/power/meter/2/usage");
    dtostrf(w_per_pulse, 4, 1, value);
    client.publish(topic, "0.625");
  }

  int dhcp_status = Ethernet.maintain();
  /*
    returns:
    0: nothing happened
    1: renew failed
    2: renew success
    3: rebind fail
    4: rebind success
  */
  if (dhcp_status) {
    long now = millis();
    Serial.println("DHCP Lease");
  }
}

All that's left to do now is tidy up the Ethernet cable... Any questions or comments please feel free to leave a comment below.

We've got a few Raspberry Pi accessories available in the store now and we've been doing a few things with the Rapsberry Pi ourselves too. Currently I (Hadley) am working on a solar powered remote webcam and weather monitor using 3G to upload data to the Internet.

Since we've got a few of the new 512MB Raspberry Pi units here I thought it would be fun to give one away too. All you need to do to enter is follow and mention us on twitter - use the #nicegear hashtag or if you don't do that Twitter thing post a comment on this blog entry.

A winner will be selected at random tomorrow (Friday 9th November) at around 4pm using random.org. Good luck!

A common question we get is the default web interface password for phones and other gear that we sell. Most people try admin/admin admin/password and various other common combinations. That won't get you very far with Polycom IP Phones, they chose the username "Polycom" and the default password "456". That password also works through the phone interface too.

Check out what the folks over at Clandestine Laboratories are up to with an Arduino, a stack of Freetronics Relay Driver Shields and a pile of relays controlling solenoid valves.

This is the third and final instalment in a series, part 1, the introduction, is here. This post will talk about the custom Arduino shield we designed and built, and the installation.

We left off last time having sent the second PCB revision to Hackvana for a prototype run of 10 boards. These arrived in good time. I built up one of the boards and took it down to the farm to test. Plugged it in to the 24V shed power supply to test the new regulator set up, wired it up and everything worked as expected. I then went ahead and ordered the full production run of 50 boards. With the prototype run that gave 60 boards total, we needed 54 so that left a margin of 6 spares.

While I was waiting for the production boards to arrive I assembled a couple of boards to get a head start. This is when the reality hit me of how long the build was going to take. I timed one of the builds and it took 20 minutes, some quick maths leads us to 55 x 20 minutes = 1100 minutes, or, 18 and a half hours! Second lesson learnt, do a time budget before you start. A multiplication factor of 50 makes even the smallest job much bigger than you think.

The production boards and parts arrived, a few late nights and lots of solder later, this was the result (well most of it, I couldn't fit all 55 boards in the picture);

After my experience building that number of boards I've started working with surface mount components to allow for more automation in assembly.

Next up was the installation, despite never having worked with PCB manufacturing before, and learning a huge amount there, I think I learnt nearly as much from the installation.

To keep the cost down for the farmer we re-used an IP66 rated enclosure from part of the previous electronics. While the Arduino and shield fitted well in this, by the time all the cables (eight double insulated cables) were put through glands it was a very tight fit. Small lesson learnt - you need a much bigger enclosure than you think when you're dealing with more than a couple cables.

Partly due to the enclosure size but also just due to the general amount of work required the installation proved to take quite some time. I timed it at about 30 minutes per board. As this was going to be too much time for me alone I employed the help of another local consultant. He normally does residential and commercial audio visual installations so this was a bit of a change for him but he was well suited to the job - wiring is wiring.

Another one of the things I discovered while installing the boards was that screw terminals are stronger when they are all clipped together in a long row. Having them spaced apart (as you can see in the picture) doesn't give them all the torsional strength that they could have which leads to some movement when tightening down the screws. Not a big deal but something to consider for a new revision.

After installing a few of the boards we decided to switch things on for a test. This is where things went a bit wrong and I learnt my biggest lesson of the project - do better testing. Although we tested with the actual load (the vacuum solenoid valves), we didn't test for an extended period of time. Turns out that we had an error in the board which was causing the MOSFET to not switch completely on. This resulted in heating and eventually, the destruction of the board.

So at the end of the first day things didn't seem to be going very well, we were taking longer than we thought to install the boards and the ones we had installed were trying to catch on fire. After a bit of a stressful afternoon I discovered the problem and had a patch fix. One of the traces on the PCB was not quite going to the right place, this was causing the solenoid to look like a resistor which created a voltage divider, this in nturn lowered the voltage to the gate of the MOSFET so it didn't turn fully on. Cutting one of the PCB traces and soldering a resistor in its place fixed the issue.

Although I had a fix, at this point in time we didn't have enough time to create a new set of boards, wait for them to be delivered and build them up. Instead we patched all the boards and installed them as they were. Not completely ideal but the fix was solid and there really wasn't any other choice.

I'm pleased to say that the cowshed has been running perfectly for the last few months with no failures. The farmer is happy with his system, which is running better than it ever has, and saved a bunch of money too. If anyone has any questions feel free to ask in the comments below or get in touch through the contact page.

This is a follow up to part 1, the introduction. This post will talk about the electronics we designed and built. To the right you can see a picture of one of the air solenoids that we needed to drive.

First things first I built up a prototype controller. To get going as quickly as possible I used some off the shelf breakout boards from the store. Paired with a Freetronics Eleven I used a Prototyping shield, four Freetronics N-MOSFET Driver Modules, a couple of rectifier diodes and a birds nest of Hook Up Wire. I didn't get a picture of the set up but you're not missing much - it wasn't that pretty anyway.

I took the prototype electronics down to the dairy shed, plugged it in to a power supply, wired up a couple of buttons to act as inputs and wired up the vacuum solenoids to the MOSFETs. It worked - a good start! The next stage was back home, designing the actual PCB to use in the installation.

Although I am competent with basic electronics theory and know how to draw a circuit I've never designed or built a PCB before, so everything was a little new to me at this point. I opened up Eagle CAD - a PCB design program - and quickly decided that I was out of my depth. With no experience and a 2 month time frame for completion now was not the time to be learning how to design a PCB.

As I mentioned last time I enlisted the help of hairy.geek.nz, after he agreed to help I sent through a photo of a rough drawing I made with a pen and paper. Quickly I received back a picture of a PCB ready to be sent off to a board factory to be made. A couple of emails back and forth later and I did just that - sent the boards off to Mitch from hackvana.com.

There are loads of prototype PCB services out there to choose from but Mitch at Hackvana does a lot to support people creating open source hardware, his prices are great, and the turn around is good and quick. About 10 days after sending the design through to Hackvana I had a set of 5 prototype boards in my hand. I built a couple up and took them down to the farm (about 30 minutes drive).

When I got down to the farm ready to hook up my shiny new board I was quite excited. I pulled out my multimeter to check there was power before wiring things up to the shed's power supply and that is where I ran into the first issue - the shed runs on 24 volts, which the Arduino can't handle as a direct input. Originally when I talked to the farmer he had told me it was all 12 volts. First lesson learnt - don't rely on provided information, test things yourself.

We worked around that for the moment to see if the everything else with the electronics (basic program, inputs and MOSFET outputs) was working - which it was. So at the end of the day, some good points and some bad. Back home to work on a new board revision.

I talked to hairy.geek.nz again and decided that the best solution considering the time frame we had to work with was adding an off the shelf switching regulator to the existing design. It was rated to convert 24V to 9V, and then let the Arduino regulator convert the 9V to 5V as it normally does. He quickly sent through a new board layout which I sent through to Hackvana for another set of prototypes.

I think that's enough for this instalment so I'll leave it there. Next time I'll talk about the production of the boards which I didn't manage to get to this time and hopefully the installation. Any questions so far? Please feel free to ask in the comments.

Part 3 is available here.

I'm going to break this up into a couple of shorter posts, starting with a general introduction here. Please feel free to let me know in the comments if there is anything specific you would like me to cover.

Over the past couple of years I've been working with some local farmers building an automated calf feeder (that's a topic for another post). Over the winter one of the farmers involved in that project came to me asking if I could tackle another project, this time in his milking shed with grown up cows.

While his cowshed (a rotary with 54 milking bales/stalls) is only a few years old, the electronics in it were failing, and unfortunately the company who installed it were offering no support. A replacement system from one of the traditional dairy companies was going to run up to $50,000 or more, and the one he had his eye on wasn't ready to install for this season (marketing departments are often ahead of R&D).

The electronics in question are relatively simple, each milking bale has a few inputs - buttons and switches - and a few outputs - air solenoids for switching vacuum on and off. Sounds like something perfect for an Arduino to do, but remember as there's one for each bale anything we do we're going to need to do 54 times over.

Photo: Cgoodwin Wikipedia

The proposal he came to me with was to see whether we could come up with something low cost to use in the interim, to get him through a few seasons until he decides what he would like to do about a commercial solution. The kicker was that we only had a couple of months over winter to design and implement the solution, it needed to be ready for July when cows start to calve and need to be milked. No milk on a dairy farm is a big problem.

Some specifics about the electronics: There are 4 main digital inputs and outputs - easy for an Arduino to do, but the shed's electronics all run at 24 volts so dedicated drivers need to be switched from the Arduino logic for the outputs.

The four inputs are; 1) A button which starts and stops the milking process for each stall. 2) A switch which detects when the user lifts the cups and automatically starts the milking process. 3) A milk flow meter so we can tell when the cow has finished being milked. and 4) A voltage input to tell us that the plant is being washed. 1 and 2 are basic inputs, 3 and 4 come from an external voltage source so need to be isolated from the Arduino.

The four outputs are air solenoids switching vacuum pressure. One controls the main vacuum for taking the milk from the cows udder back to the tank, two control the pulsators which actually milk the cow, and the final one controls an air ram which removes the cups once the cow is finished milking.

I looked for a while at off the shelf solutions, there are loads of Arduino Shields around these days and even some which offer similar functionality to what I needed, but nothing quite fitted perfectly. In the end I decided to go down the route of creating a custom shield - a big step considering it's not something I had done before. I enlisted the help of hairy.geek.nz, who I knew had experience designing PCBs as we sell one of his products. This worked out great and he was really helpful throughout the project.

That's all for this instalment, next time I'll go into the board and electronics and putting things together.

Part 2 is available here.

A good customer and now friend Mark Beckett has been doing great work passing on his experience with electronics and Arduino to some 10-12 year olds from Swannanoa School up north of Christchurch.

We (along with Ponoko and The Shed Magazine helped out with the hardware while Mark donated his own time and money to give the kids some great education during the holidays. The course was very well received and a majority of the students have now purchased their own kits to continue to experiment with.

Great work Mark! We're really pleased to be involved.

If you've got a project that you would like to chat about, feel free to drop us a line.