Something new was on the horizon. Actually, the idea for a controller replacement I had was not new. Back when I built my last wattmeter hack, I was already thinking I'd like to sense the direction and speed of a rotating meter disc using an optical computer mouse. I had spent a good deal of time searching the internet for ideas or plans, and asked nearly everyone I knew who had computer or programming experience about the hardware and code needed to do such a project, but no workable solutions presented themselves.

A few months back I was explaining my solar power system to a visitor (John of the Polymecca Housetruck), and mentioned the mouse idea. John replied that "a lot of people are building things using Arduino microcontrollers". That sounded kind of exotic and probably expensive, so I didn't think much more about it.

A few weeks later, I tried searching again using the string mouse+control+stepper+motor. One of the results was a kid who built a controller for a toy robotic arm that used a mouse for the user input. One thing did jump off the page at me, he was using an Arduino to interface with the mouse and run the code needed to make it work. It didn't take much more searching to turn up as much information as I wanted about these small and ubiquitous processors. People were indeed building an amazing array of projects around the platform. Searching auction sites brought back results indicating that the complete circuit boards, ready for loading a completed program were available dirt cheap and from many suppliers.

For many years, I had thought about exploring microprocessors, but never quite made the leap. Basic Stamp, PIC, etc, although they were reasonably priced, by the time you bought the development kit, prototyping board, communications adapter, and all the other add-on accessories, it seemed to be a bit of an investment for something that might or might not catch on with my interest. The clincher for the Arduino was when I looked at the programming code, "C", it looks very like PHP, which I'm already familiar with, if not proficient in. Also, all of the code, etc is open source, and programs are freely distributed on the 'net. I ordered a unit from one of the auctions, $16.99, with a free bonus!, a USB interface cable.

While I was waiting delivery, I took more time to explore the world of Arduino, reading the "Getting Started" guide, downloading the development software interface (open source, "free"), and looking for suitable program examples I could integrate into a working mouse driver. To my surprise and satisfaction, there were program "sketches" (Arduino programs are called this before compiling) that interfaced a PS2-type mouse to the processor. There were even tutorials on ripping apart optical mice and soldering wires into their tiny brains to grab signals to use for motion control. Things were looking better, but whether or not I'd be able to actually control my big, heavy Variac with all this stuff was still open to question.

Once the processor had arrived, I realized that it was even smaller than I had imagined. I had opted to purchase the Adruino Duemilanove with an ATmega 328 processor chip. Duemilanove means "2009" in Italian, so I guess I was right in my first impression that this was somewhat exotic. The circuit board was simple to set up, easy to connect outside wiring to, powered itself from my computer's USB port, and accepted and ran all of the elementary sketches I fed it without complaining. I did all the basic stuff, making a blinky light, running a serial communications connection, and even controlled a small RC servo motor using a potentiometer as the input device.

Digging around in my storage of old computer parts, I found a PS2 mouse. "WTH", I thought, "if I burn this stuff up experimenting, I'm not out a lot of cash", so I made the indicated connections, loaded a simple sketch that would read the mouse and display output information on the serial terminal, and fired it up. Like everything else I tried, this simply worked, the serial display indicated the movements of the mouse in each direction, complete with velocity information, button presses, etc. This was a big step forward! Plugging in an optical PS2 mouse produced the same results, so things were looking even better.

Now that I had a method of reading the data coming off of the mouse, I needed a way to get this info off the Arduino board and out into the real world to do some work. One of the motion control web pages I found while researching was a description of an interface to control a simple remote control car by using mouse movements. The RC car was a very elementary design, with simple push buttons for forward, back, etc. The provided sketch of the code looked like it could be used to illuminate LED lamps when the mouse was moved, so I tried it out, using red and green LEDs for movements forward and back (Y-axis) on the mouse. This worked fine, and it also meant that I now had a way to see what the processor was doing with the mouse movements without having to have a USB cable connected to a computer and a terminal session open and running.

The two LEDs would blink, or pulse briefly, each in turn, depending on the direction the mouse moved. The pulses would be few and far apart when the mouse was moved very slowly, and would speed up as the mouse moved more quickly. This was great! Best of all, when the mouse was stationary, neither of the LEDs would illuminate. ~Exactly~ the behavior that I wanted for the Variac controller!!!

It didn't take more than a few clock cycles inside my head to figure out that the pulses put out by the Arduino were almost exactly like those my 555 timer board was making. Since the Variac already had optoisolated inputs, it was a simple matter to connect the wiring from the old 555 board directly in parallel with the two LEDs and try the new system out. Using the mouse on a surface would turn the Variac up and down reliably, and the variable rate of the pulses worked very well to "hurry up" the Variac when the mouse was moved quickly. In fact the pulses were so close together when the mouse was accelerated that the Variac drive motor ran as though it had been simply switched on! I was beginning to get a very good feeling about this!

Originally, I had thought that I'd need a different drive system for the Variac, a stepper motor, or a large servo motor, something with more muscle. This would complicate the project, as I don't have very sophisticated machining abilities or tools. As it turned out, the existing motor drive in the Variac was responding very favorably to the control signals from the Arduino. I decided to run with it and see how it turned out. Couldn't be a whole lot more kludged together than what I'd been using.

The last task was to see if the optical mouse could read the rotating disc inside the electric meter. Since balancing the whole mouse on top of the exposed disc was not going to work, I shredded up the mouse case, removing the small circuit board inside and leaving behind the buttons, wheel, etc. Applying a couple of tabs of cellophane tape to the bottom of the circuit board held the clear plastic lens assembly in the proper position, as it was needed to focus the light and image for the optical sensor on the board.

I threw together a couple of thin aluminum strips, screwed them to the face of the meter where the old "cyclometer" dials had once been and secured the circuit board with a couple of binder clips. This allowed me to adjust the position and distance of the mouse optics in relation to the disc.

(McCleod Creek P&L is my own moniker for my personal PV and Hydro generation
facilities here at home, it has nothing to do with any "real" utility company)

This actually worked!! Amazing!!!! The mouse was able to sense the disc rotation, and since I had already proofed the concept and connected the Arduino board to the Variac, the system was now fully operational. Just like that! I was astounded!

Turning the circuitry loose in a production environment produced no disappointments. When solar generation exceeded the household loads, the disc would try to spin to the left, but the Arduino would turn the Variac up, quickly at first if the load change was sudden and large (refrigerator turning off), then slowly drop to only a few pulses, then a single pulse every second or so until the disc in the meter movement was nearly stationary. Loads turning on produced the opposite reaction, the Variac was turned down until power parity was reached, then the system went idle until the next change was needed. I had achieved the exact results I had wanted for so long, a fast reacting, but ultimately sensitive dump load controller.

At the end of the day, when the sun got weak and insufficient PV power was being produced, the controller turned the Variac down until the limit switch turned the transformer off, putting the system to bed until the next morning. The disc continued to rotate to the right, the red LED pulsing, but no action being taken, as the system was "asleep".

Not only did it look like this was going to work, it was already working very well, and I hadn't even begun to refine the system.

Although the controller seemed to be working well, I did notice that there was some "creep" in the disc that wasn't being detected by the optical mouse. When the power level running through the meter was very small, the disc would turn very slowly and the mouse would "wake up", turning it's internal LED on to full brightness, but the controller would not indicate that there was any movement, and the Variac would not be adjusted. Checking the data coming off the mouse using a terminal session showed that in spite of being awake due to the motion, it wasn't putting out any motion coordinates. Nothing for the Arduino to work with.

Assuming that perhaps the smooth aluminum disc inside the meter was too shiny or featureless to stimulate an output from the mouse, I covered the rim of it with painter's masking tape, postulating that the crepe texture of the tape would make the mouse more sensitive to movement. This did increase the sensitivity, but not enough to keep the important feedback loop to the Arduino informed of any and all disc movements.

Time for more research. I read up on optical mice, learning that they are essentially small cameras with embedded memory and processing that compares the past and present images in the lens, and then uses this to create the data corresponding to movement. Like other optical devices, mice have a resolution specification, expressed in d.p.i. (dots-per-inch), and sometimes c.p.i (?-per-inch). Low budget mice were nearly all of the 400 dpi sort, but graphics designers and gamers who needed more sensitivity usually purchased higher-end mice, ones with 800, 1000, or even 2,000 dpi. Laser mice are capable of a staggering 5,700 dpi. It was beginning to look like my made-in-china junk box mouse wasn't going to cut it. I cruised through some auction sites and found laser mice for not too much money, maybe I'd have to bite and buy one of those...

Before succumbing to purchase impulse, I dug a little deeper into my junk box and found a "fancy" A-Open mouse that I had gotten some years earlier with the expectation that it's four buttons and two wheels would make navigation in my recording studio software easier. It didn't and the numerous buttons and bulky running-shoe shape of the mouse left me cold, so I pitched it.

However - a quick search online showed that it was an 800 dpi optical system. Could this improve my disc-reading abilities?

As before, a phillips screwdriver stripped the rodent bare, and I only had to make some adjustments to the temporary aluminum mounts on the meter to put it into place.

The increased resolution was more than enough to solve the issue at hand even without the coating of tape on the disc. The disc in the meter was now incapable of making any motion at all without sending the Arduino into immediate action. Even opening and shutting the garage door next to the meter set up enough vibration to send the Variac skittering to compensate for the disturbance.

It was now time to begin making plans to assemble this prototype into a permanent enclosure. Since I had gutted the electric meter, I reasoned that building it all inside the glass dome that used to house a collection of gears and dials would be fitting. But would it all fit? The Arduino could squeeze into the area above the disc, taking up only a small amount of depth, but with close tolerances to the top and sides. Then I remembered that this was the Duemilinove, and that smaller boards were available. Got online and ordered up a Nano, that would take up less space.

The other concern was what I was going to do with the mouse guts. The optical chipset itself wasn't very big, but the circuit board it was mounted on took up a lot of space. I didn't need the five microswitches for the buttons, nor did I need the two optical encoders for the wheels. Hmm, some circuit tracing here and there, maybe I could hacksaw off parts of the board that I didn't need, sloppy, but more compact.

On an impulse (I get those a lot), I searched up the component designation on the optical chipset. One of the first results was a complete datasheet for that very IC, and I didn't have to wade through a bunch of "datasheet-online" scrum, it was posted right on the manufacturers web site! Most helpful of all was the "typical PS2 application" schematic diagram contained in the PDF file:

Since the circuit board used all through-the-hole components, it would be simple matter, using this schematic, to desolder the components and mount them on a compact, custom perforated project board. Everything I'd need is already mounted on the mouse circuit board, the capacitors, the resonator, everything. This would allow me more freedom in placing the optical sensor inside the meter, perphaps reading the edge of the disc instead of the flat face (still have to test that).

To get DC power for the Arduino and the mouse, I tore open an old 5VDC, 1A switching power supply from an IOmega zip drive. Very compact, very efficient, and it can run from 240 VAC, already available inside the utility watthour meter. It might just be time to begin building this project....

...or not....

The hardware was working fine. Each night, I'd remove the Arduino from the system so that I could noodle around with it in the IDE (development software). Once the Nano that I'd ordered had arrived, I'd put it into the production system and have the Duemilnove for testing and other possible projects.

One small problem that I had noticed was that with the increased sensitivity the new mouse provided, the Variac was going nuts when I ran the washing machine. The washer is a horizontal-axis unit, it agitates by running the drum one direction for a minute or so, then stops for a few seconds, then runs the drum in the opposite direction, repeating this cycle over and over. The Variac would frantically turn up and down in response to these cycles, and was really getting on my nerves. The controller would even try to adjust the dump power in response to water and clothes tumbling in the washer drum, the loading and unloading of the washer motor was evident in the wattmeter disc motion.

I would be fine if it was a bit more relaxed during washing, and so I needed to now decrease the mouse sensitivity. That's easy in software. I chose a digital port as an input, and altered the program so that when a voltage was applied to the port, the program would hold off doing anything until the mouse data was one integer higher than the minimum threshold (from anything greater than zero to anything greater than one). This allowed small variation in current to go through without activating the Variac, but larger load changes would make the system react pretty much as normal.

Because having an electromechanical device (the Variac) as a integral part of the power control circuit was obviously causing some noise and concerns about wear-and-tear on the bearings, gears, brushes, etc, a solid-state solution would be much more preferable. It didn't take much programming to insert some code to provide a PWM output on one of digital ports that could ultimately be used to control a triac device. Once this triac was installed, instantaneous response to current changes would be possible, and rather then being a concern, it would be a desirable feature.

The triac control takes the movement data from the mouse and keeps a running total of the values, from 0 to 255, turning that into the PWM signal on the Arduino output pin. This total is calculated not only from the simple movement of the mouse, but is a product of the speed at which the meter disc is spinning. When the disc spins in the "down" direction, the negative value numbers generated in the mouse data are added to the total, bringing it down (a negative number and a positive number added together is the same as subtracting one positive number from another).

Since this project is taking on a modular aspect, I left the code in the program, and simply put an amber LED on the output pin for now. Once it's all built and installed in the wattmeter body, I'll do some testing and prototyping on the triac drivers. Obviously, I'll leave room for the small circuit board that will be needed to integrate the triac driver into the whole.

So, now for some code. This is the program as it's running right now.

#include <ps2.h>

// an arduino sketch to interface with a ps/2 mouse and a hacked watthour meter
// Raises variac when mouse is moved forward, lowers when moved back
// Also provides PWM output for eventually driving a traic device

// Pins 8 - 9 are the optoisolated variac controller pins
// Pin2 is the low sensitivity switch input.
const int raisePin = 8, lowerPin = 9, switchPin = 2;
int raiseLower = 0,  switchState = 0,  triac = 0,  disc_velocity = 0;

// Pin 6 is the clock, pin 5 is data
PS2 mouse(6, 5);

// initialize the mouse. Reset it, and place it into remote
// mode so we can get the encoder data on demand
void mouse_init() {
  mouse.write(0xff);   // reset
  mouse.read();        // ack byte
  mouse.read();        // blank */
  mouse.read();        // blank */
  mouse.write(0xf0);   // remote mode
  mouse.read();        // ack
  delayMicroseconds(100);
}

void controller_init() {
  pinMode(raisePin, OUTPUT);      // Green LED indicator
  pinMode(lowerPin, OUTPUT);      // Red LED indicator
  pinMode(switchPin, INPUT);     // initialize High sensitivity pin as an input:
  pinMode(10, OUTPUT);            // pin 10 feeds the triac controller chip
}

void setup() {
//  Serial.begin(9600);  // Serial connection commented out until needed for testing
  mouse_init();
  controller_init();
}

void controller_loop() {
  if (raiseLower > 0) {            // Lower
    digitalWrite(lowerPin, HIGH);
    digitalWrite(raisePin, LOW);
  } else if (raiseLower < 0) {     // Raise
    digitalWrite(lowerPin, LOW);
    digitalWrite(raisePin, HIGH);
  } else {                         // Do nothing
    digitalWrite(lowerPin, LOW);
    digitalWrite(raisePin, LOW);
  }
}

void triac_loop() {
  // set the output of pin 10:
  analogWrite(10, triac);
//  triac = triac + disc_velocity;     // change the output for next time through the loop:
  triac = triac - raiseLower;        // change the output for next time through the loop:
  triac = constrain(triac, 0, 255);  // Don't loop back to the beginning or end
  }

// get a reading from the mouse and report it back to the host via the serial line.
 
void loop() {
  char mstat;
  char mx;
  char my;
  
  switchState = digitalRead(switchPin);  // Low sensitivity

  // get a reading from the mouse
  mouse.write(0xeb);  // give me data!
  mouse.read();      // ignore ack
  mstat = mouse.read();
  mx = mouse.read();
  my = mouse.read();

  disc_velocity = -my;
  
 if (switchState == HIGH){ // Low sensitivity
    if (my == 0){
      raiseLower = 0;
    } else if (my < -1) {
      raiseLower = -1;
    } else if (my > 1){
      raiseLower = 1;
    }  
  }
  else {            // High sensitivity
     if (my == 0){
      raiseLower = 0;
    } else if (my < 0) {
      raiseLower = -1;
    } else if (my > 0){
      raiseLower = 1;
    }  
  }
/*    // Serial connection commented out until needed for testing  
  // send the data back up
  Serial.print("Y=");
  Serial.print(my, DEC);
  Serial.print("\tr/l=");
  Serial.print(raiseLower, DEC);
  Serial.print("\ttriac=");
  Serial.print(triac, DEC);
  Serial.println();
*/    
  controller_loop();
  triac_loop();
 }

A good C programmer would probably bury his face in his hands after looking at this code, but it compiles and works, what more do I need?

That's about it for this part of the project, but there's more, once I got started, I discovered several other interesting things I could include as "add-ons" to make this even more functional.

One of the basic sketches and associated libraries in the Arduino IDE tutorial is LCD (Liquid Crystal Display), which allows information from the processor to be indicated on a readout for the user to view. I've always considered displays to be PFM (Pure Freakin' Magic), so I copped a small display from a derelict satellite receiver at the radio station and decided to play around with that for an evening or two.

Research showed that most small non-proprietary LCD displays use a generic protocol and can be addressed using a pre-determined set of instructions which were contained in the Arduino library. The rest was pretty simple, although it involved connecting what seemed like a lot of wires to a small connector on the back of the display and a fair amount of finger crossing, as I was not able to find an exact pinout of the particular display I was using. Never the less, after jiggling a few loose connections, I had it working.

I found out fairly quickly that it was just as easy to make the display say rude things as it was to use the insipid "Hello World" example that is shown in so many of the tutorials. While this was momentarily amusing, it didn't really make my project any better.

The default example of LCD display use includes indicating a rolling number representing the number of seconds since the processor was rebooted. This showed me that it was not only possible to pass text to the display, but to use variable strings inside the running program to output readable data. But which particular data was useful to me? I tried using the display to show the direction of rotation of the meter disc, or whether it was standing still, but the rapid changes in disc rotation detection made this value difficult to read, it flittered around so quickly so as to be undecipherable. In reality, the read and green LEDs did a better job of telling me what the disc was doing.

For a while, I tried displaying the triac PWM value (0 - 255), but because the system was still running on the Variac, this had little meaning, the triac value wasn't always in sync with the actual state of dumping power into the water heater. Even if the triac had been in use, the value of the PWM driving it wouldn't have a useful meaning, as the power passed through a thyristor isn't linear in relation to the phase angle triggering it.

No, something else needed to be displayed before it was worth integrating a display into this project. Something that had real-world meaning. Something that could be tabulated at the end of the day.

The one useful piece of information I could think of was how many watts of power were being diverted to the water heater. In order to calculate this, I'd need to know how much current was being supplied to the heating element from the Variac. A quick dive into the parts junk box turned up a current sensor that was designed to supply a 0 - 5 volt DC voltage in response to a 0 - 10 ampere AC current passing through it's center. Installing this was easy enough, as I have access to the wiring. A few lines of code in the Adruino sketch and I had it working.

Unfortunately, the readings displayed on the LCD were not encouraging. Back when this system was first installed, I made up a chart and posted it on the wall above the Variac. By reading the analog volt meter on the Stabiline (Variac) front panel, then cross-referencing that number on the chart, I could determine the exact power going into the water heater at any given time.

The current and wattage readings on the LCD weren't even close. I used a serial connection to check the string variables running in the program, and checked them against the DC voltage presented at the analog input pin. Everything checked out. Time for more investigation.

What I found was that the current sensor didn't even begin to put out any voltage until the current was close to 1 ampere, and even then the voltage wasn't proportional to the actual current. I set up a test and logged the results, running 1, 2, 3, etc amperes through the current sensor and writing down the results. Although the sensor did indeed put out 5 volts DC at 10 amperes, it didn't put out 2.5 VDC at 5 amperes, or 1.25 VDC at 2.5 amperes. The current-to-voltage relationship wasn't linear, or at least linear enough for my liking.

No, not good enough. Time to try something different...

Very early in my research for this project, I happened upon the Open Energy Monitor project, a group of people who had come together to explore the hardware, software and philosophy of monitoring one's own energy use, including electricity, gas, water and whatever else (wonder if I could put an Arduino to work on my wood stove?). The site included examples of whole-house energy monitoring, rather like an all-inclusive "Kill-a-Watt" meter. The hardware needed to do this was actually very basic, schematics and part descriptions were supplied, as were the Arduino sketches needed to make it all work and return results. There were even users who were using the Arduino to control excess solar production by dumping power into water heaters!

I guess if I had discovered this site before I had invested as much time and energy into the optical mouse project, I probably would have simply built a monitor as described on that site and modified it to do what I needed, there was no reason that the designs there couldn't have done exactly what I was proposing, perhaps more accurately. All of the electric utility metering projects used current transformers (CTs) to sense what the load was on the utility lines. These transformers were clip-on jobs, which meant that no modification to the wiring was necessary. Several different models of CTs were discussed, and resources for purchasing them given. All of the CTs discussed had known specifications that could be plugged into the sketches to make them operate properly.

Since I have a copious "junk box" (a whole building of the stuff, really), I decided to try out a couple of CTs that I had on hand. Here's the two CTs and the AC current sensor that I had tried previously:

The large Simpson CT was a 150 ampere metering unit, meant to drive a 5 ampere meter movement. I was hoping to not have to use it, as it was so large. The smaller CT on the left was my first choice, but I had no information about it whatsoever, it was a take-off part from my rebuilding of the Lestronic battery charger project.

The first thing to do was to determe the value of the needed "burden resistor". (A note: I'm leaving out a lot of theory in these posts, if the reader is actually interested in learning more, a wealth of information awaits a patient search of the rest of the web, I'm not attempting to come off as the font of all knowledge) Usually, the burden resistor is chosen on the amount of current being measured in conjunction to the turns ratio of the CT. Since I didn't know the turns ratio, but had seen the value of 100Ω used quite a lot, so I decided to start there.

Since linearity was a big issue, I decided to run my current test and measure the resulting voltage across the burden resistor, which is what the Arduino would be doing to determine the operating current in the circuit. Things went pretty well up to a point, then at a certain amount of current, the numbers stopped getting larger as fast as they should. I had obviously hit some kind of "knee" in the CT/burden resistor circuit. Maybe a larger resistance was called for. I increased the burden resistance to 270Ω , which made the descrepancy quite a lot worse. I was going the wrong direction, the resistance needed to be less.

Since adjusting the current and writing down the results, doing mental tabulations along the way was time consuming and not all that much fun, I decided there must be a better way to observe the effects of changing the burden resistor value. Out came the oscilloscope. Since the voltage I was measuring was isolated from the utility line, and the voltages involved were low (below 2 volts), the scope could be connected directly across the burden resistor, and the current then adjusted up until I saw some anomaly in the waveform.

At first, I wasn't sure what I was looking for, clipping of the waveform peaks I assumed. What I found was the opposite, the zero-crossing was getting messed up with the higher resistances. Here's three photos of the scope traces at 10 amperes, showing what I found:

The first photo is with the burden resistor at 100Ω. The waveform had been fine up until about six amps, then distortion started setting in and worsened as the current increased. The second photo is with a 270Ω resistor which started to distort much earlier, and the last is using a 30Ω resistor. Basically, I kept lowering the resistance until I stopped seeing distortion at ten amps, which was my upper limit of measuring. If I had needed this CT to measure more current, it would have required an even lower value of the burden resistor.

Running a complete set of current-vs.-voltage measurements and writing them down showed that the voltage induced across the burden resistor was absolutely linear from 1 to 10 amperes. Exactly what I had hoped for, but I still didn't have what I needed to know to plug these values into the Arduino sketch. Fortunately, the Open Energy Monitor site contains some equations for determining the current in the burden resistor which also allowed me to calculate the turns ratio for the CT that I wanted to use. The end result was that my CT had a ratio of 200:1.

Plugging these values into the "basic energy monitor" Arduino sketch supplied on the site and doing a few code modifications resulted in the current sensing value running inside the program to be exactly correct while using a simulated CT voltage as indicated by my current/voltage graphs. I threw the Adruino running this program on the system (by now the Nano had arrived and it was doing duty on the Variac controller), connected it up to the CT and let it fly. A few calibration tweaks were necessary with the real world current sample voltages, but nothing that a few minutes of editing code didn't correct.

Now that the accurate current values were running inside the program, it was a simple matter to use them and a given constant to calculate power in watts being sent to the dump load. Notice that I have never made reference to measuring or sensing voltage in this system, other than voltage values needed to determine operating values. The Open Energy Monitor programs all use line voltage, either measured or stated to calculate power, but my situation is different, the voltage on the heater element varies from 0 - 129 volts. Since the load on the system is constant and given - a water heater element - I was able to measure the ohmic value of that element and use that in my calculation of power. Basically, ohms Law states that power (P) equals Current (I) squared times Resistance (R), or P=I²R. In the Arduino sketch, this is expressed as:

watts = (Irms * Irms) * 12.3; // 12.3 = load resistance in ohms

The next (and final) item on the clipboard was that now that I could read watts, I could also accumulate watthours for display. A post over at the openenergymonitor.com site brought a response from a seasoned user, and I inserted some additional code to keep a running total of the watthours, to be reset at the end of each day.

Bringing it all together, the current measurement, the wattage calculation, the watthour total and my new knowledge of LCD PFM resulted in a display that suited my expectations:

The display is showing current, wattage into the water heater load, and total dump load consumption for the day, which isn't much in this photo, as I took the image fairly early in the morning.

Yes, I'm still working on a partial sheet of plywood perched on top of the clothes dryer. All that's left to do now is actually build this project. That's never the most fun part for me, but there's a fairly large amount of satisfaction once it's done.

Oh, and to finish up, here's some code to keep you interested until I have some actual construction photos to share. Sorry for the brevity of some of the code and comments, I tend to be a bit of a minimalist when it comes to writing this stuff:

#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

const int resetPin =  6;      // the number of the Wh reset pin

//Setup variables
int  inPinI = 1, numberOfSamples = 3000, lastSampleI, sampleI, resetState = 0;
double watts = 0.0, whTotal = 0.0;  //watts up?
double I_RATIO = 0.0354;  //calibration variable
double lastFilteredI, filteredI, sqI, sumI, Irms;      // current things
unsigned long ltmillis, tmillis, timems, startmillis;  //time stuff

void setup()
{
  lcd.begin(16, 2);  // set up the LCD's number of columns and rows: 
  //  Serial.begin(9600);
  tmillis = millis();
  startmillis=tmillis;
  pinMode(resetPin, INPUT); // reset Wh display
}

void loop()
{ 

  for (int n=0; n<numberOfSamples; n++)
  {

    //Used for offset removal
    lastSampleI = sampleI;

    //Read in current samples.   
    sampleI = analogRead(inPinI);

    //Used for offset removal
    lastFilteredI = filteredI;

    //Digital high pass filters to remove 2.5V DC offset.
    filteredI = 0.996*(lastFilteredI+sampleI-lastSampleI);

    //Root-mean-square method current
    //1) square current values
    sqI = filteredI * filteredI;
    //2) sum 
    sumI += sqI;
  }

  //Calculation of the root of the mean of the voltage and current squared (rms)
  Irms = I_RATIO*sqrt(sumI / numberOfSamples);
  watts = (Irms * Irms) * 12.3;  // 12.3 = load resistance in ohms
  
  //Calculate amount of time since last realpower measurment.
  ltmillis = tmillis;
  tmillis = millis();
  timems = tmillis - ltmillis;

  //Calculate todays number of kwh consumed.
  whTotal = whTotal + (watts * 1.0/3600.0 * (timems/1000.0));

  // reset Wh display?
  resetState = digitalRead(resetPin);
  if (resetState == HIGH) {
    whTotal = 0.0;
  }

  /*
  //Output to serial
   Serial.print("Amps=");
   Serial.print(Irms);
   Serial.print("   Watts=");
   Serial.println(watts);
   */

  lcd.setCursor(0, 0);
  lcd.print(Irms, 1);
  lcd.print(" A   ");

  if (watts >= 1) {
    lcd.setCursor(9, 0);
    lcd.print(watts, 0);
    lcd.print(" W    ");
  }
  else {
    lcd.setCursor(7, 0);
    lcd.print("<1 Watt");
  }

  lcd.setCursor(0, 1);
  lcd.print(whTotal, 1);
  lcd.print(" Watthours   ");

  //Reset accumulator
  sumI = 0;
}

Although I thought I was close to actually constructing this project, it turns out that I've stuck myself into more development before getting that far.

Early in the experimentation around the Watthour calculator, I realized that I would need a second processor. Since the current sensing code in the Watthour calculator samples the current 3,000 times before using mathematical calculations to average out the current, the circuit runs a bit on the slow side. This isn't a problem for the display, but I could foresee problems if the controller itself had so much delay when it should be busy adjusting the Variac. I tried lowering the number of samples, but this quickly resulted in jittery and inaccurate readings and calculations.

For the price of a second Nano, I wouldn't have to be concerned how many clock cycles the display used up, so I ordered a second one from the auction site.

While waiting for that processor board to arrive, I discovered an excellent site that offered quite good tutorials on Adruino. Getting Started with Arduino presently has 44 chapters on a variety of useful small projects designed to teach the basics of microprocessor development. I know that I really learned a lot, even though I kind of glossed-over the deeper technical aspects of some of the stuff I wan't sure I had an immediate use for.

One of the tutorials had a quick description of using an Amtel ATMega328 chip without an Arduino board. I had seen some references to this elsewhere, but no real examples were given. Since I was assembling an order of parts for the meter construction, I included a couple of the chips and the 16 MHz ceramic resonators needed to make them run. The end result is supposed to be that the 28 pin chips can do any and everything that a full Arduino board can do (with a few small limitations), and the ATMega328 is even smaller by itself than the Nano board.

One of the construction aspects that I hadn't worked out yet was what I was going to do about the couple of external switches I needed for mouse sensitivity and Watthour total reset. I had thought I'd use a polycarbonate dome that could be drilled for switches, but none of those I have will fit the old, analog meter base that I'll be building on. This means that I'll need to fit the heavy glass dome on the base when I'm finished, effectively sealing myself out of the environment. I assumed that I'd have to run some wiring out the back of the meter and build a small switch panel next to the meter base.

Continuing to read the Arduino tutorials, I came upon chapter 32, Infra-red control. This clever bit described how to use a common TV or DVD remote control and a tiny, $1 sensor to get control signals into an Arduino sketch! It didn't take long for me to recognize that this was the way to get through that glass dome!

I had already sent in my parts order, and didn't want to make another so soon for a single part, so I began thinking about what I might have on hand that I could cannibalize for this sensor. The answer was as close as my storage shed, an old Sharp DVD player that worked fine, except it would frequently "stick" at 23 minutes into any interesting movie that it decided I shouldn't see. A couple of minutes with a screwdriver and a soldering iron got me the component I needed to begin experimenting:

The Arduino library for reading the sensor was available, so I set up a simple sketch to read the output of the Sharp remote control. Well, it didn't work, every button I pressed returned a "0" (zero) on the serial monitor. More research provided the fact that Sharp uses a non-standard protocol for encoding the IR data. There were some code examples that I could plug into the Arduino IR library to possibly fix this issue, but I really didn't want to mess with it. Instead, I grabbed the remotes from my new DVD, VCR, and an old Radio Shack "universal" remote. These did return data codes that I could decipher, and the Radio Shack remote had the additional bonuses of being small, programmable for a variety of code regimes, and not currently needed to control any of my home entertainment equipment.

Not every button on the control is active, and some return duplicate codes when pressed, but there were enough useful buttons that I thought I could do something with it.

Integrating the IR library into the controller sketch wasn't difficult, and after changing the code a bit, I was easily able to control the sensitivity (high/low) of the mouse by pressing the volume up/down buttons on the remote. Once that was working, my mind starting wrapping around exactly what this meant, I could control the behavior of the program while it was running by pressing buttons from across the room! I immediately started thinking up other functions for the remaining buttons on the remote:

• (Play button), Set the controller to adjust the Variac level according to the data returned by the optical mouse.
• (Pause button), Make the controller ignore the mouse, but allow me to adjust the Variac using the Channel up/down buttons.
• (Stop button), "Park", Ignore all outside inputs and send the Variac to "full off" position (useful for shutting down the system for maintenance)

The one remaining function I wanted was to be able to reset the Watthour total on the display, but because that data was on the other microprocessor board, I was going to have to send a signal from the controller board to the display board. I assumed that I'd use a free pin on the Arduino and use digitalWrite() to send a voltage to the other board and decode it with a spare pin on that end. Then I remembered that these processors have a built-in serial UART port. Could these be made to communicate between the two processors?

A quick search brought up a library called EasyTransfer which allowed a simple one-way, or two-way transfer of data between Arduino boards. I set up a simple test, and it worked as described, a variable string from one board could be transferred to the other, where it could be used to alter the programming on that board.

I still had a lot of buttons left on the remote, but other than the reset I wanted, I couldn't think of much to do with the additional abilities that the serial connection afforded. For a while, that is, then I started rolling out ideas, eventually adding five more screens to the display, each controlled by the numeric buttons on the remote:

• (#1 button), main display, Amps, Watts, and Watthours
• (#2 button), A status display, Mode auto/manual/parked, and Sensitivity high/low.
• (#3 button), Since it's not possible to tell what sketch is loaded on a processor, I include a variable string with the version number in each update of the sketch which displays in this mode, Controller v2.55, Display v2.31 as of this writing. This makes it much easier to know what is actually running in the program.
• (#4 button), A display of the days, hours, minutes, and seconds that the processor has been running.
• (#5 button), Contrast. Since the LCD display needs a voltage between 0-5 volts to set the contrast of the display, I needed a way to set this. The "easy" way is usually to use a potentiometer on the circuit board, but that means having an adjustment under the glass dome, so I wrote a variable into the program to use one of the pins on the display board to set the voltage using PWM, adjusted with a context-sensitive use of the volume up/down buttons. These change the digital value of the contrast variable from 0-255, and output the result using analogWrite(). The volume buttons only control the value of this variable when the display is in mode 5, other times, the volume buttons control the sensitivity of the mouse.
• (#6 button), Reset Watthour Total. I found that once in a while, the serial connection would miss a beat, and when it did, the display would blank out for an instant, and at the same time, the Watthour total would reset to 0.0. This was abhorrent behavior, and not acceptable. I could deal with the display going blank for 5 seconds every few hours, but resetting the Wh was not OK. I wrote a switch into the program that allows resetting the Wh only from display mode 6 when the "DSPLY" button on the remote was pressed. Since the display normally sits in mode 1, main display, any glitches in the data shouldn't emulate the combination of conditions necessary to reset the Wh total.

At this point, that's it. Unless I can think of any more button functions I can include, or I suddenly decide to put in a shoe-shine library or teach the dual Arduino processors to roll and smoke cigarettes, I'm ready to get the construction under way. Oh, well, I guess there is that little matter of teaching myself how to install a bootloader on those raw ATMega328 chips I bought, but that should be easy.

(update, Oct, 2012) More as the project progresses, I'll be putting some time into it over the winter...

Time out to put some punctuation at the finish of this project.

First, an admission: I was Solar Guerrilla #6, back in Home Power magazine issue 73.

For 14 years, I had been selling my solar generated electricity to the utility by spinning the electric meter backwards during sunny days, effectively offsetting my consumption overnight. Nobody ever noticed, and with the modern electronic inverter that I was using there was no hazard to line crews, etc.

There was a hitch along the way when the utility installed a digital watt-hour meter, this is described in the first of the pages in this series, and was the seed that the load control project grew from.

Then the utility started installing "smart" meters. My experiments on the meter that they installed on my house showed that it reacted to my power production exactly like the previous digital meter, so I just left it alone and continued to build a final, permanent version of the controller, one without all of the loose wires and clip leads.

In early 2013, I got a call from a representative of my electric utility (it's a PUD) telling me that they had detected "reverse energy" on the new smart meter that they had installed the previous summer. When they asked if I knew of a reason for this, like "did I have solar panels," I saw no point in trying to hide, the PV's are mounted out in the yard and all that, so I said, "Yes, but my charge controller was supposed to prevent that from happening."

The caller, who turned out to be the energy services manager, asked if he could come see the installation the next afternoon, and drop off a net metering application. I agreed, expecting that he'd turn around and get back in his car when he found out that it wasn't a county-permitted, licensed-electrician installed, inspected, brand-new-out-of-the-box system.

During his visit he asked about the system generation capacity and anti-islanding protections, and dropped off the six page application, all the while talking like it was a done-deal, just fill out the forms and send them in and he'd rubber stamp them.

I downloaded a PDF of the application, filled it out in Acrobat, drew up a one-line system diagram and a layout drawing showing the spatial relationship of the ground-mounted panels, house, utility meter and service drop, and sent it in via email the day after his visit.

The next afternoon, I got an email back from him telling me the application was approved, and included a copy of the contract signed by them as an attachment.

Crap! It's done!, I'm legal! All I can figure is that the last 14 years wore them down. I ran out the clock and now that they have all these damned smart meters that are ringing bells and flashing red lights down at the administration building, they are bringing everyone they can into the fold so that they can concentrate on more important stuff, like non-payers who are jimmying the meters to cheat.

Amazing! No permits, no inspections, no electricians, and most mind-blowing, no lockable disconnect!

Exactly one week from the inital phone contact, a crew of two workers from the utility's meter shop installed a new smart meter that can recognize reverse energy as net production, Afterwards, I turned off my Frankenstein dump load controller and just let their meter sort it all out. I was catching 99% of the PV excess before, so I didn't expect see a big advantage. Soon, I was in the fourth month of zero-consumption net metering with a 38 kWh surplus.

Of course, I've also spent a fair bit of time since fiddling with my hydro project. If I'm going to get paid for stuffing electrons back into the grid, I'm going to get good at doing it. (they pay wholesale rate for any production over parity at the year-end even-up time)

Because the utilities "smart" meter doesn't calculate the accumulating credit from production-vs.-consumption, I built my own "smarter" meter (known as a "sub-meter because it's on my side of the utilitie's meter) that can track that as well as show an instantaneous readout of the power being consumed or fed back into the grid.

There are six registers:

Daily Production (resettable)
Monthly Production (resettable)
Total Production (accumulating, non-resettable)
Daily Consumption (resettable)
Monthly Consumption (resettable)
Total Consumption (accumulating, non-resettable)

Daily values are displayed as Watthours, Monthly as kiloWatthours to the first decimal, and Total as kiloWatthours.

Additionally, it uses the register values to calculate Net values for Daily, Monthly, and Credit, and displays the results in color-coded numbers, green for Net Production, and red for Net Consumption.

All six registers are stored in non-volatile memory, so they come back after a power failure.

Average Production/Consumption wattage for the last one-Watthour is prominently displayed in either red or green at the top of the display.

The meter has a real-time clock and records power fail and restore times. The yellow area at the bottom of the display is the "messages" area, and is used when resetting the registers, setting the clock, or acknowledging power failures.

The whole thing is designed to be a snap-in "personality module" for an Itron/Schlumberger Centron revenue-grade utility meter base, so it has absolute accuracy and UL listing.

The example above was an earlier version, 5.13, I'm now pretty much finished at v5.21. I built a one-off for my own use now that I'm a legal Owner-Generator, but I fantasize about designing up a printed circuit board and going into production, assuming that others might have some interest in such a device.

If I get bored (it's always possible...), I think about adding WiFi connectivity and writing an app to make the display show up on PC's and mobile devices, or upload data to a server for accumulation and display. It's nuts what's available in the way of modern electronics these days.

So, back in 1999, I was Solar Guerrilla #6, and in 2013, I'm Owner-Generator #19 for the local PUD.