Tuesday, September 18, 2012

More Bugs Solved and Meter Reading Program Performance              


There were a lot of little bugs to work out of the program. It tended to crash at like 3 in the morning when I was not around. Occasionally the program misreads an image digit to give a nonsensical result. There are two types of misreads. Because of the fish-eye camera distortion, the meter’s end digits are squished and they required some serious tweaking to get consistent reads. Almost none of these types of misreads occur now. Also, I check each of the meter’s ID images and Test images (“151- -” and “88888”) to see that they decoded correctly. If there is an error in decoding either of these images then a repeat calibration is performed.


The other kind of misread occurs when an image is taken just as the LCD segments are changing from one display to the next.  The camera is so fast that it can catch the segments in mid change. It would sometimes catch the Blank image with a little of the previous Test image’s ghost. Since the Blank image is subtracted from all the other images it would really screw up the decoded  values. This problem was solved by quickly taking another image of the Blank before it disappears in five seconds. The second image is always good. The rest of the following four meter images are shot at sequenced five second internals and shouldn’t catch the segments changing, except that it turns out the power usage Rate is displayed in real-time and updates about once a second. So there is no way around a rare misread of the Rate image; about one misread an hour, out of a total of 144 reads an hour. The solution is to just not record the misread Rate result. The graphing software easily handles missing data because it is essentially an X-Y plot where Y is the rate and X is the time. Any missing data goes completely unnoticed. 

Here are a couple of graphs of the first few days of collected data.



The compiled VB6 program is a measly 60K in size and runs in the background with no tab in the taskbar using less than 2% of my modest CPU’s resources. During calibrations, (a few times per hour), the CPU usage increases to about 15% for less than a second.











The finished meter reading program's code is a bit gangly and I may spend some time cleaning it up to make it more structured. Sometimes this causes more problems than it is worth. I will probably let the program run for a couple of months first, to flush out any other bugs.

=====================================================

I am starting to think about new projects:
I am interested in taking the doghouse off the power grid (I would need to produce about 200 watts 24/7) or...
a solar run spa project or ...
use a trained artificial intelligence program rather than this algorithm based program to read the electric meter or...
making an electric vehicle or...
start a new robotic project (a 6 legged dandelion flower seeker and destroyer) or...
document and finish a micro-controller animatronic samurai project I started last winter or...
who knows what.