Re-debugging my HVAC

A few weeks ago I posted about my air conditioning woes, that in the end were due to ants infiltrating my AC relay.

I went out of town for a few days recently, and returned home on a 95 degree day to find that my compressor was not running and my 2nd floor was a steamy 93 degrees! The thermostat indicated that it had been running for at least the past 36 hours straight.

I immediately examined the back of my compressor housing and found it covered with ants. Once I had the access panel that covered the relay off, I confirmed that the 3 week old relay was indeed no longer conducting 240V mains power, even though the solenoid in the relay was powered and engaged. Freakin ants!

Apparently 3 week's worth of ant biomass @240 Volts

I had to act fast, it was around 2 in the afternoon, and the parts store, which was at least 1/2 hours away, probably closer to an hour in rush hour, closed at 5. I wasn't about to give up on the part so easily. Uncharacteristically of me, I had thrown out the receipt for the relay, so I'd have to buy a new one. I wanted to see if I could get the existing realy working again. I got a can of compressed air, some isopropyl alcohol, q-tips and fine grit sandpaper. The contacts had a heavy coating of petrified caramelized ant biomass. I was able to remove 95% of it, and my multimeter confirmed reliable conduction through the relay.

With about an hour to spare, I got the relay back in, flipped the breaker, and the compressor purred back to life. I think proceeded to wage chemical warfare on the 6 legged minions wrecking my day and my wallet. I had assumed that the first time was a fluke, or possibly a build up of ant carcasses over time. The second incident made it clear it was all out war. Fool me twice, shame on me.

My second floor cooled about 1.5-2 degrees fahrenheit an hour (I think it did hit around 100F outside later in the day), so by the late evening it was finally quite comfortable again.

--P

Debugging my HVAC system

It's about that time of year in North Carolina where my Yankee Blood compels me to engage the modern marvel known as central air conditioning. High temperatures average in the mid 80's fahrenheit (~29C)  , but can sometime go above 90F(32C). It's also the time of year that you tend to discover something has gone wrong with your air conditioning hardware. Nothing stresses me more, it's one of the more expensive maintenance items facing a homeowner.

Last weekend, while my son was using one of our space heaters Xbox I noticed that the air conditioner didn't seem like it was keeping up. Heart-pounding, I sprinted through the 2nd floor of the house checking the air vents. Sure enough, they all seemed barely cool. We have independent air conditioning units, one cools our first floor, and the other cools our second floor, and the room on our third floor that serves as Anibit's central office.

The "evaporator" and blower part of the AC unit lives in an unfinished, uncooled, part of our third floor. You can usually feel that the ductwork leading from it is cold when running. It was warn. Bad news. Time to let the wife in on it so she can join me in the journey on the potential repair-bill coping process.

I went outside to where the compressor unit lives, and noticed that it was silent. Neither the fan nor the compressor motor was running. The coolant lines where exposed were slightly cool (everything had been working 30 minutes prior). Hmmm. This unit was relatively new. We had it installed about 4 years ago. The prior uint had, once or twice had its starter-capacitor die. The capacitor is only needed to handle the large current draw when the compressor motor first turns on. Last time we had it replaced by a service technician, it ran us about $250. I searched online and found the model capacitor used in my unit. $26 with express shipping.

I'm a genius! I saved ~90% (even more probably, since prices on service have probably grown since the last time). So we sweated it out for a couple days. Luckily, the weather changed mostly in our favor, going slightly below average. It did rain a lot, so the open windows and fans were bringing in a nice sticky-humidity you only really know about if you live in The South.

The capacitor eventually came, and I set upon swapping it out. The old one did have some rust on it, but not excessively. I love electronics, as you are well aware if you read this blog. But I avoid wall mains power as much as possible, because I'm clumsy, and make a mistake or two every once in while. The AC unit runs off the 220V appliance line, so I'm even more paranoid. There was a lot of voltage testing, and ground checking. I wore gloves and goggles, and used plastic-handled tools.

Then came the moment of truth. I had my wife on the phone, inside "Ok, go ahead and set it to 'cool'".

"Ok, it's flashing 'cool', flashing 'cool', ok it turned on"

CLICK! The relay in the outdoor unit engaged.

Nothing.

"Sonofa, I was so sure that was it! Hmm, wait keep it on, let me take some more measurements."


The fan and compressor motors are controlled via a large relay. Measuring the voltage on the output side of the relay revealed that it was not conducting.  "Ah, the relay is bad!'

Not wanting to wait for another part to ship, and having the luck of a little free time in my schedule, I tracked down a local supplier a half hour away for a new relay.

I installed the new relay, still with as much caution, but not quite as much pomp as the capacitor. I turned the unit on, and raced out to check the compressor(my wife wasn't around this time).

Success!

Mechanical relays are relatively simple devices, and this one wasn't very old. I wondered to myself about why it might have died, and why they don't use a solid state relay. Maybe the high current makes it unsuitable, maybe AC solid state relays are prohibitively expensive or complex.

I decided to take apart the old relay and take a gander. The root cause became obvious at once:

Do you see it?

How about a closer look at the contacts (click on the image for a larger view):

Oh the antmanity!

Encrusted at each contact was a mass of dead ants. I have heard that ants were attracted to electricity, especially fire ants. We have fire ants in our area, but I have never noticed them on my property. At the same time, we have ant's in our house 365 days a year. This winter was the first time in 10 years I went more than a week without finding an ant in my kitchen, but they were back in rotation by february. I'm not sure if these are fire ants. If so, they are a little smaller than I typically see them. I'm not a biologist, but it is possible that 220V might cause a drop in ant stature.

The ants were all clustered right at the contact. There were no ants elsewhere in the relay.  One thing I'm not sure is if the ants collected there in one event, eg they picked that fateful day last weekend to throw an electrofest, or, if it was a build up of individual ants that happened to by passing by right when the relay kicked in crushing them. Either way, it's hard to muster up any sympathy for them.

--P

I SPI with my little eye...

If you're trying to work with SD cards on a microcontroller setup you designed yourself, there's a good chance you have to write the low-level SPI drivers.

This page: http://bikealive.nl/sd-v2-initialization.html

Was indispensable for me recently when trying to figure out why I could not read an SD card. It turned out that an on-board regulator for one of my parts was expecting 5 Volts, so when supplied with 3.3 Volts,  it was supplying ~2.3 Volts to the SD card, and it was not operating reliably. Once I told the SD card to operate on 2.7-3.3V, it would stop responding.

I placed a serial print statement in my low-level "spi-send-byte" function that printed the byte transmitted and the byte received, and it let me follow along the initialization sequence outlined in the above link and see where things went screwy.

--P

Prototyping with EMW3162 "IoT" devices.

I've picked up a bunch of EMW3162 devices recently. I don't yet have any up on Anibit, I'm trying to figure out how many I want to keep and and many I could part with.

EMW3162 Overview

They are really neat little devices:

The Good

• Price: Runs in the neighborhood of $10 USD
• Wifi b/g/n, reportedly up to 54MBps
• On-board chip antenna, and UFL connector for an optional external antenna
• Included STM32F205 ARM Cortex-M3 120MHz CPU with 128kb SRAM and 1Mb of Flash
• About 20 available IO pins (+2 on board LEDs, and JTAG/SWD breakout)
• Uses Broadcom Wifi chipset, compatible (after some finagling) with their WICED sdk
• Broadcom has a lot of support for "IoT" in their SDK, with appliance samples, Access Point setup, and embedded web server support.
• Mostly (but not all!) 5V tolerant I/O pins. (I love that, level shifters are such a pain)

The Bad

• Documentation for the device itself, is almost non-existent. 
• You must rely on the documentation for the constituent parts, and the work of some industrious hackers, see this. 
• If you can read Chinese, you may have better luck.
• It's not straightforward on how to use it as simply a Wifi adapter for an external Microcontroller. I believe there are firmwares for this, but it will require a lot of research.

The Ugly

• 2.00 mm pitch headers on the breakout. Who does this, seriously! I think MxChip must have hired the person who came up with the XBee socket.
• The various SDK and libraries are a slight licensing minefield. If you want to use this for a closed source or proprietary application, read through all the licenses of all the sub-parts carefully. There are some "free for closed source commercial" library license options, but not all of them are. 

Prototyping

I have thrown together a quick and dirty adapter PCB to let you mount the EMW3162 on a breadboard. I'm considering possibly doing a run of kits for the adapters to get the cost down, we'll see. 

You can get your own adapter from OSH Park here. [Updated link to new version here] Use at your own risk, I have not received my boards yet to verify that it works, but a paper printout looked like it matched up, and the actual circuit is so simple. You will also need:

• 2 15-pin 2.54mm (0.1") pitch male headers for the breadboard part.
• 2 15-pin 2.00mm pitch male headers for the EMW3162 module, unless you already have them mounted.
• 2 15-pin 2.00 pitch female headers to receive the EMW3162 on the adapter.

Comparison to ESP8266

The main advantages of this over the popular with makers ESP8266 is that it has many more pins broken out, and they are 5V tolerant, making this device a better candidate for standing on it's own as an appliance vs acting as a peripheral for another Microcontroller. The CPU of the EMW is also faster (120 Mhz, vs 80Mhz), and has a lot more on board RAM and Flash space. Also, the WICED SDK from Broadcom is very sophisticated, with support for features such as OTA updates to the device. You can develop code to run directly on the ESP8266, but the support for that is more community built than officially supported. To be fair, WICED does not officially support the EMW3162, ether, but the board is close enough in design to other officially supported devices that it's not very hard to port.

Though the EMW3162 is about twice the price of the ESP8266, for some applications, it is worth it, especially if the extra capabilities allow you to remove external components form your design.

Resources to get you started

• Several folks have started an analysis as a Hackaday project, and they're adapting their own flavor of the WICED sdk for use with the board.
• The WICED SDK, which includes an Eclipse/CDT tailored to embedded devices using Broadcom chipsets.
• The Github Repo for the WICED fork specific to this board.
• Seeed studio sells a couple Development boards you can plug your 3162 into. This one has a JTAG port for an external JTAG, and this one has an on board JTAG built in.
• My breadboard adapter you can order in multiples of 3 for $8 per set (you'll need to find the headers separately)

--P

Reflow oven

I started a new project recently, a reflow oven. This time, I've started with the physical build, and the software side of it will lag behind. I've laser cut the case I designed in OpenSCAD, and I couldn't be more pleased with the results.

The case with the "human interface" components - a touch screen LCD a 1 watt speaker.

I have some projects in R&D for Anibit, and I'm going to need to whip up some PCB's. I need a reflow oven, and I'm going to recycle an old toaster-over. I was inspired by this project, which was in turn based on osPID. The touch-screen was something I've had lying around, waiting for a project. 

Traffic Light

[Editor's note. This is a post that I started almost 3 years ago, I'm making an effort to purge or polish some of the unfinished or unworthy posts on Bytecruft]

This is a traffic light I made for my kids. It's got a ATtiny 13 driving the leds. It also features a "soft" on-off circuit   driven by a tactile momentary push button.

I know, another AVR LED based project. They're so easy. I swear, I work on more than LEDS and with chips other than AVR's. It's just that the AVR ones tend to get 100% finished. Part of my hopes for this blog is to provide motivation to finish a couple of the unfinished projects I have. Actually, looking back, it's not so much a problem of motivation, but time. I usually "multithread" my projects, work on several at once, to keep form getting burned out or over-obsessed with one. Sometimes, before I know it, a project hasn't been touched in a couple months.

This is a project I did for my kids, it was another one of those "in between" projects, where my goal was to make a small project that would be lightweight after working on something big.

Present-day action shot, I finally replaced the 3+ year old batteries
during the teardown/photo shoot for this.

The real neat trick with this project, in my opinion, was the power management.

Complexity. Ambition. Progress.

What is the inclination many of us have to take on more than we can handle?

I have a really cool project I've been working on, that I'm not quite ready to reveal. It's turned out to be more ambitious that I originally thought, although I am making decent progress and achieving some things I doubted would be possible.

Is it that we overestimate our abilities, our speed, or that we have an inherent desire to avoid underachieving by aiming too low? My gut says.... well never mind what my gut says, it's always hungry, and rarely expresses anything appropriate for mixed company. My head says that we're simply just poor estimators, and there's probably tons of blogs and expert on the web that agree. What has really consumed a lot of the time on this project, were some of the mundane things that I didn't really consider, such as spending a week tracking down errors due improper CPU registers.

It seems that as some of my home hobby projects get more ambitious, and by definition more cool, I'm spending longer and long in between completed projects, with more time spent in the "this is going to be magical one day" phase. I definitely think after my current project I need a few short and sweet ones, to get that gratification of having achieved magic.

--P

CNC controller case.

Though I don't think I'll have Apple banging down my door to design their next iHip^TM device, I'm slightly proud of the fact that I turned this:

Into this:

Seeding the standard C random number generator on AVR chips.

The rand() function in C gives your a pseudo-random number generator. To purists, it's got a lot of flaws, but I'm glossing over that for this post. In many cases, it is "good enough" to get the job done. A lot of times, I don't care that the distribution is not strictly even when you do something like.

int foo = rand() % 10;

Many times, just a rough approximation like above is enough to make something "feel random".

The rand() function uses a formula that calculates new "random" numbers based on a formula that includes the previously generated value(s).

So where do you get the "starting point" for the first number in the formula?

The standard C library maintains an internal state for the random number generator, and you can "seed" this state with the "srand(unsigned int)" function.

So what do you pass to it?

Well for any given "seed", you will generate the same sequence of pseudo-random numbers. For instance:

srand(42);
int a = rand() % 10;
int b = rand() % 10;
int c = rand() % 10;

will yield the same sequence for a,b, and c every time it is run. What if that is undesirable? It's almost like you need a random number to seed the random number generator, a "catch 22".

On desktops, seed values are often taken from some system time register, on Linux systems, it's sometimes generated from a timer that measures the time between a user typing keys.

On microcontrollers, you often don't have inputs, and system up-time timers don't work because the time will likely have the same value in the power up initialization sequence.

It can be difficult to get these miracle computing machines to be non-deterministic when you want them to.

A trick you may be able to use, depending on your setup is to use the ADC (analog digital convert) built in to most AVR's (on other brand) micros to read a voltage level on a pin that is "floating" or otherwise not tied well to a particular voltage. Here's a short example of how that looks on an AtTiny85:

#include <avr/io.h>
#include <stdlib.h>


void setup_seed()
{
unsigned char oldADMUX = ADMUX;
ADMUX |=  _BV(MUX0); //choose ADC1 on PB2
ADCSRA |= _BV(ADPS2) |_BV(ADPS1) |_BV(ADPS0); //set prescaler to max value, 128

ADCSRA |= _BV(ADEN); //enable the ADC
ADCSRA |= _BV(ADSC);//start conversion

while (ADCSRA & _BV(ADSC)); //wait until the hardware clears the flag. Note semicolon!

unsigned char byte1 = ADCL;

ADCSRA |= _BV(ADSC);//start conversion

while (ADCSRA & _BV(ADSC)); //wait again note semicolon!

unsigned char byte2 = ADCL;

unsigned int seed = byte1 << 8 | byte2;

srand(seed);

ADCSRA &= ~_BV(ADEN); //disable ADC

ADMUX = oldADMUX;
}

In my case, PB2 was connected to a resistor, which was then connected through an LED to ground. When the pin is in a "high z" state (eg, not driven by the CPU), this approximates "floating" close enough to give me nice erratic values. Notice that I use the "low bits" of the ADC. The low bits represent smaller voltage differences, and exhibit greater variance, so they're more likly to swing a lot on a floating pin.

I'm not sure if it was really needed to scale the IO clock down by 128x, I just added it for flourish, thinking more time would mean more variance. I have no scientific evidence that is true though.

Enjoy!

--P

CNC update

I hit a milestone with my CNC project tonight, I made my first cut!

Here's the current state of it configured for milling:

I'm using the Zen Toolworks 12x12 , F8 edition. The F8 edition has an extended Z-axis travel on the gantry, which is needed to be able to use the device for 3D printing. One thing I didn't realize initially were that: 1) configured as a milling machine, the spindle will not reach down to the bed, and 2) the extra Z axis travel does not benefit milling as much, because the gantry clearance is one of the limiting factors. The two possible approaches to address the first issues are to either re-work(ie invent your own) the spindle mount to lower it close to the bed, or to build an elevated platform as your new work area. I decided to do that because it reportedly reduces error due to frame torsional forces. I could always build a new mount and remove the table. The Zen is pretty flexible in that way, a good deal of the design can be up to you.

CNC progress pic.

Just a quick shot of my cnc build in progress, I'll post more about it later. I had a slow start waiting for all the parts, I think I'll avoid ordering big stuff around Christmas next year.
Tonight I'm working on end stops and the y-axis of thr Zen Toolworks chassis.

New Project - CNC/3D printing

While physical computing has captured my fancy the past few years, one thing that seems to have frustrated me is the physical construction for my projects. I have a degree in Mechanical Engineering, though I went into Software Engineering professionally, so that struck me as odd. I think I've grown accustomed, spoiled even, on the fantastic availability of free and low cost tools available in the software world. I'm used to having as powerful tools to develop software as a hobby as the professionals use. Not so with hardware. Things are getting better though.

I've decided to take it to the next level, and I'm investing in a small CNC that will also be capable of 3D printing. I'll document my progress on ByteCruft. (My robot project is not stalled, but I'm putting the CNC project first, since there's a long lead time with getting up to speed.) I currently know very little about milling beyond what I remember from school almost 20 years ago. I expect my progress to go faster than my typical  'epic' level project, since I'm focusing less on trying to do lot of design myself. I'm mostly cherry picking various kits and packages and making them work together.

Zaethira Progress.

I've been doing a lot lately. Often, when I've had a choice between posting something, and working on something, I've chosen the latter. I noticed recently that I missed the month of November entirely, my bad! To top it off, my last post was a bit of a crotchety vent about haters, and we all know haters are gonna hate.

I've been working a lot on my robot autonomous vehicle, Zaethera. I've also got a ton of other projects in various stages of planning, that I'm keeping mum about for now.

In my last post, I posted a color-coded high level view of the architecture. There's a lot more green now, I'll post an updated chart in my next post. I don't think I dropped any subsystem from the original, and much of the left-hand side is built assembled, and ~50% coded.

I'm beginning to enjoy this electronics hobby thing.
The parts in the Sparkfun box in the back are the rear/side
IR proximity sensors, and the compass module. Near the top,
on the red, black, and blue wires is the IR remote control receiver.

Robot update.

I haven't posted in a while. The lulls usually happen when I'm busy. I've failed you, my adoring fans, and for that I blame... um squirrels..

I have been happily jamming away for the past couple months on my robot, Zaethira. (Which is a concatenation of my kids' and wife's names, and happens to sound geek awesome, the geekiness of the whole is greater than the geek sum of the parts).

Anyway, I could have written a 20 page blog post about how things are coming along, but I think a diagram does a much better job. I made the below because I needed to get a handle on where I needed to focus and what I planned to do. This diagram made me realize how flipping complex this project is.

Seeeduino Stalker Waterproof Solar kit review PART 2

In my last post, I covered the Seeeduino Stalker board itself, I wanted to get into some of the other aspects of the kit.

The hardware (continued)

Bench Power Supply

I decided to mothball my power supply project. I may come back to it one day, I may not. I sort of had a rage-quit moment this week-end, when I blew one of the channel's regulator circuits. The thing is, I didn't do anything I didn't think it could handle. Now, the voltage output is always 2 volts higher than what I set it for, and the current-limiting seems to never kick in, it goes to 1 full amp (or at least that's the max I'm capable of measuring) when I short it. Meh. I thought it was more robust than it appeared to be, and I didn't want to spend more time to complete it, only to run into more issues. It needs some re-design.

The Bench Power Supply (Powerbug 6000), in its
open casket, the mothballs are in my head.... and my heart.

So as a wrap up, I'm just going to post some pictures I (and my wife, player with an in-law's camera) took of the project.

Seeeduino Stalker Waterproof Solar kit review

I had a little extra scratch recently, so I decided to geek out on some new toys without  a specific purpose in mind. One of the nuggets I picked up was the Seeeduino Stalker waterproof solar kit. From Seeed Studios in Shenzhen, China.

At the time of writing the kits go for $59.50 US, which, as you'll see in minute, is a pretty good deal, for what you get. I live in North Carolina, and the free shipping via Hong Kong post/registered airmail took about two weeks, give or take a day or two. As an aside, it boggles my mind that I can get something shipped out of Shenzhen *for free*, (my package was several pounds too), and I order something that ships out of a neighboring state and get socked with a $10 shipping fee.

I'm going to take a stab at doing a proper review for the kit, maybe it will inspire me to figure out what to actually do with the thing.

Slowly I turned...

It's been a slow summer. I'm still making progress on the bench power supply. It's in the "just get it done so I can move on" phase.

I've got the regulator part of the circuit finalized. I don't think it's perfect, but I think if I ever want to work on something else, I need to move ahead. Since the powersupply has three channels, I plan to have 3 discrete boards.

Here is one of the boards, pre-soldering:

One channel regulator board.

On the left side of the board, there are two PWM'ed input for the voltage and current settings, and two "Vsense" and "Isense" analog outputs that will run directly to ADC inputs on the Atmega 644. The top of the board will have inputs from the ATX power supply at 12 and 5 volts. A variable 0-9V output will come form the bottom-right side.

Bench Power Supply - Point of no return

Just  a quick(not really) update.

I've got a lot of the code side of things worked out. I had a lot of "fun" doing software debouncing for my rotary encoders. After hooking up a logic analyzer, I realized that using the I2C IO expander for the encoders was not going to work. The I2C chip I'm using, an MCP23018, has a couple interrupt lines, one of which I used to alert my ATmega that the expander needed attention. Since the expander is an I2C "slave", this is the only way it can initiate communication with the microcontroller. An interrupt handler in my code would set a flag and exit. When my "main update loop" got around to checking that flag it would then issue a series of I2C commands to query the expander for the encoder line change that triggered the original interrupt. All of this turned out to be way too slow to process encoder input. The main culprit was the fact that it depended on the main code loop getting around to checking that flag. From my logic captures, I could see that encoder edge transitions could happen sometimes 5ms apart. When there was a lot going on, such as heavy LCD updates, my main loop could sometimes take 20-30ms to complete one loop. Ouch.

You can't easily, if at all do I2C in an interrupt handler, you can not be sure of what state the I2C line is in when the interrupt fires. In the end, rather than figuring out a way to do I2C in an interrupt, or doing more flag checking (which would have been a hack, sometimes most of the CPU time is spent deep in the LCD bit bang code), the simpler solution was to move the encoders to the AVR itself. I had to give up UART functionality that I was planning, since I'm tight on allocated pins, but I was leaning toward doign that anyways.

Bench Power Supply: Power Control

In this truly awful video, you can see my bench power supply at work.

For testing, I coded a function to cycle the voltage between 0-5.0V.  In reality, 0-100% duty cycle is the parameter the code changes. A "PWM'ed"  square wave(yellow trace) is fed to an RC filter, which is then buffered with an op-amp(the op amp output is the blue trace).

You can also see the LCD updating in realtime. The voltage reading is coming from the ADC on the ATmega 644. It's has a hard time keeping up with the displayed "SET" value, but there probably several factors, the biggest of which purely software related, I simply don't refresh the "widget" that displays the voltage reading any faster than 3Hz. 

(Ignore the Amperage settings/reading, they're not coded yet, the analog portions of that have me the most intimidated)

Anyways, crappy quality aside, this is a great demonstration of how PWM signals can be used to generate analog voltages from a digital MCU pin, and how "duty cycle" affects what comes out of a simple low-pass RC filter.

--P