Jim's Projects | Projects I'm working on at home or at Workshop 88

GFCIs and Christmas lights

Posted on December 23, 2013 by Jim

OK, the battle has begun. That darned GFCI outlet has refused to let my Christmas lights run in rainy weather too many times. It’s time to understand this stuff and update my installation techniques so I stand a much better chance of not getting bitten by this again.

(Just to be clear: I’m NOT complaining about rainy weather at Christmas time. Snow is beautiful. Unless you have to drive in it. Or walk in it. Or shovel it. Which I do. So above freezing temps in the winter are OK by me.)

Understanding GFCIs isn’t hard. They just look for differences in current in the hot and neutral conductors, and if that difference is ~5mA or more, they figure someone might be getting electrocuted, so they shut the power off. I’m all for that.

What I don’t understand is exactly where at least the worst of that leakage current is happening in my holiday lights. Once I understand that, the goal is lengthening the short circuits so they don’t scare the GFCI into shutting the power off again. Woven into that is separating fact from myth about what matters when trying to make GFCI-friendly wiring for outdoor lights.

This project note is work in progress, and will be updated as progress occurs. Maybe a good way to manage that once it’s done and working (or failed or whatever) is to rewrite the final story, put it at the top, and keep all the historical ramblings at the end, after a well marked break. (Spoiler alert: There’s a way simpler solution at the end of this post.)

Boolean failure indications

Part of what makes troubleshooting something like this difficult is that the indication of the problem (a tripped GFCI) has only two states: No Problem and FAIL.

When I co-authored a troubleshooting manual at the last place I worked, I implored the wannabe troubleshooters to avoid getting stuck with a boolean failure indicator. Lie, cheat, steal – do whatever it takes to get your hands on the instantaneous value of whatever variable triggers the failure when it crosses a threshold. Get a private code version, use undocumented interfaces, run a debug kernel – but somehow get something that shows whether the changes you’re making are helping stay away from that dreaded threshold value.

(Update 3/20/17) In some cases when you really can’t get your hands into the trigger mechanism, maybe you can get more analog-y info by changing the input stimulus. This came up while investigating range of IR remote controls. While I couldn’t get into the black box TSOP-type 38KHz IR receiver, I could alter the amplitude of the IR signal I was sending (by changing LED current). This might let me sort of alter the trigger point in a way I could control.

Measuring leakage current

That advice obviously applies here – but how do I get my hands on the magnitude of the couple of mA of current leaking to the wet ground? How about the way the GFCIs do it? A classic error of beginners with an amprobe type clamp-on AC ammeter is to try to measure current by clamping it around say a piece of lamp cord. Of course that doesn’t work, since the current in the two conductors is exactly equal and opposite, and they exactly cancel each other out.

But in the GFCI leakage current case, the currents through the hot and neutral conductors are not quite equal. If we run both main conductors thru a current transformer, and if our transformer is sensitive enough, we can use it to measure the difference in the currents – which is exactly what we want. And if I could build it into a device with an AC plug and socket so I could plug it inline with the outdoor lights, I could measure the leakage – and more importantly, the changes in leakage as I did various tests!

If there were enough leakage to trip the GFCI on the outdoor outlet (a likely case if it’s wet enough out to do this testing), I’d have to resort to an extension cord from a non GFCI outlet. Yeah, I’d be outside standing on the wet ground doing unusual things with the light strings – the perfect recipe to get a shock or worse – so I’d better be extra careful with this non-protected setup.

My old current sense toroids might work with a suitable amp. I couldn’t easily create tiny current differences, but since I only care about the difference, if I run say 5mA of AC thru a turn or two through the toroid and if the amplified output is enough to work with, it might work. I can get one turn of a pair of most any conductors through the toroid, but if I cheat and use say 16 ga wire, I should be able to get several (2-conductor) turns thru the core, making the whole design easier. The total draw of the lights would almost certainly be within the ampacity of that #16 wire.

In initial play, I’ve been able to get ~0.5VAC out for 5mA thru the toroid core, though with a really distorted waveform. Hum has been a real nuisance. Maybe an isolated, battery powered design would make that less of a problem. That 10uF (!) across the toroid was to get rid of RF it was picking up from a local AM station.

Another approach would be to hack a real GFCI. (Spoiler alert: That’s probably the way it will be built!)

Possible improvements to test

The changes I’d like to observe the results of with my leakage indicator so far are:

Blow outlets and plugs out with compressed air.
Spray WD-40 in/on outlets and plugs.
Raise outlets/plugs off the ground.
Disconnect specific strings of lights.

It will also be interesting to compare the leakage at above v below freezing temperatures.

I expect the final wiring will have outlets on spikes off the ground, covered and with their holes pointing at the ground. But that won’t be something I can see immediate results from with the tester like lifting outlets off the wet ground.

Hacking a GFCI

I had a line cord cut-off – probably from a hair dryer – with a GFCI plug, so I opened it up to see how hackable it was. Interestingly, while there was a little PCB inside, the control circuitry had no active electronics (no amp after the current transformer). The mechanical latching relay that opened both line and neutral when it tripped was operated by a solenoid powered (presumably) by just the current from the transformer due to leakage. The contacts were spring loaded open, and the red Reset button and its (stronger) spring held the contacts closed until the solenoid released the latch and allowed the contacts to open.

As expected, both main conductors passed through the toroidal core of the current transformer. There were two interesting features. First, the main conductors made 4 turns around the core, making it more sensitive than a single turn. Second, there was a separate, much thinner primary winding (the thin blue wire). That must have been for the test current. A nice simple, robust bit of engineering.

When I put ~8mA through one conductor of the main winding (a 0.11uF cap across 120VAC), I measured about 59mVAC across the secondary (white wires). That should be plenty of signal to work with as input to an op-amp. And with the PCB and the solenoid removed, there’s a good chance I can squeeze a little PCB with my electronics inside the shell to make a reasonably robust test tool. (If I want audio output, that will almost certainly require another box, if only for the speaker.)

If this approach works out, I should tear some other common GFCIs (like ones built into outlets) apart to see if I can make a general recipe of how to make a tester starting with most any (probably defective/free) GFCI. Presumably all we’d need is the current transformer.

My tester

The main purpose of the tester is to provide real-time feedback on the leakage while I make changes in the wiring. A secondary purpose is to provide a snapshot measurement of the leakage to see how close it is to the 5mA trip level. Here are some requirements.

Must provide some analog indication of leakage current. (Sound would be convenient.)
Range: From <<5mA (far below GFCI trip) to maybe 20mA. (And don’t blow up if >> 20mA!)
Should provide a calibrated output probably readable with a voltmeter. Could be AC or DC. Decimal point doesn’t matter – could be say 0.5V for 5mA.
Should provide an audible output that varies with leakage. Likely is a single tone, probably higher for higher leakage. Others would be considered – like spoken values.
Give the guy on his knees under the bushes a quantitative indication of how much good that spray of WD-40 is doing. How about having the audible tone drop 1 octave for every factor of 2 change in leakage? With 10KHz as top, 4 or 5 octaves would give a range of 2^^4 or 2^^5. Four octaves and 20mA max would give good quantitative indication down to 1.25mA.
A range switch would be considered.
A reference tone for 5mA would be very nice. Maybe every 5 seconds have a 400ms silence, 200ms of the 5mA tone, silence, back to real time tone?
The droning tone would probably get very irritating pretty quickly. How about a mute mechanism that shuts the tone off if no change in leakage for say 5 sec? Any change turns tone back on, maybe automatically starting with a 5mA reference tone cycle. Might have sensitivity control for what constitutes “change”. Reference for “old” leakage remains until tone is on again. That is, a very slow change in leakage would always trigger the tone after while.
Maybe if no change for say 10 sec, would show how we’re doing with 1 sec of current tone split with above 5mA reference tone.
For leakage above the 20 mA max, the tone is audibly different – maybe on/off at 1Hz.
It would be very nice if it were robust and self-contained enough to be able to offer to lend it to others struggling with GFCI trips on outside lighting.

All that tone generation/change stuff would be pretty simple if the tone were generated by say, a Tiny85. If the leakage current were mapped by analog amp/rectifier to full scale of the 10 bit A/D at say 20mA leakage, at 2^^4 less (1.25mA) we’d still have 64 A/D bits to notice changes. That sounds like a pretty usable range. The analog section would probably have to have a trimmer to calibrate to the A/D full scale.

How to provide a power supply for both the op amp and the Tiny (and probably an audio amp!) is open. Before the Tiny, the plan was to use a past-service-life 9V battery. If the Tiny’s ratiometric A/D reference is used, Vcc would have to be regulated. Probably using the 2.56V internal reference would be better. And since the A/D input absolute max is Vcc, if I regulated the Tiny Vcc to say 5V and the op amp power supply were such that it could never put out > 5V, the requirement of not blowing up for leakage > 20mA would be ensured.

Hmm – I suppose if the design power input were ~7VDC (split for the op amp, regulated for the Tiny) it could use a new or used 9V or a 2S LiPo. (Yeah, or 6 NiMH AAs. But that’s pretty clunky.) Maybe just a 9V clip on a little pigtail and a rubber band to hold whatever battery on? That could serve as the power switch as well. Since a minor goal is being able to lend the device out, if I put together a 2S LiPo (with 9V style snaps), I’d need to provide a suitable charger to go with it. Yeah, I could do that. Or let the guy buy a 9V. Needs more thought.

Having my hand forced

The tester is only some wires and an op amp on a breadboard (plus some hot air) so far, but the darn lights have been out for a couple of days. I need to get them back on.

The first step of the attack has been getting the connections off the ground. Plastic containers have been the first approach. I also raised up outlets with no lights.

An additional step was to charge up the portable air tank and blow out all the plugs and sockets with compressed air. It really hurt to do that without being able to see if/how much it helps, but I really, really wanted to get the lights back on.

I think I’d tried resetting the GFCI earlier today, and it wouldn’t hold. After raising the connectors and blowing them out, the lights stayed on, so I accomplished the immediate goal. Unfortunately, it’s many hours after that initial test, it’s now below freezing, and I didn’t test before hauling out the air and cream cheese containers. Yeah, the goal was to get the dumb lights back on and it was dark and late and cold, but it wouldn’t have killed me to do a quick test first. 🙁

Update 2/24/14: After having been buried in a foot of snow for weeks, a melt uncovered the wiring for the Christmas lights. On a whim, on a day when temps were maybe 20F, I tried the lights. Despite cords having been knocked off their plastic perches, the lights lit and didn’t trip the breaker. Not particularly relevant, but it’s another data point on a well-below freezing day. I think GFCI trips are a lot less likely when it’s below freezing.

I might not need/get to build this!

1/14/21: The lighting season started with a lot of rain – and GFCI trips. After more reading and head scratching, I realized/reasoned that a very likely source of leakage was outlets (female) that water had gotten inside. (Ron Sea proposed precisely this solution in the comments below. Thanks, Ron!) Unless the outlet is specifically designed to prevent it, there’s a nice short possible path for water to create leakage from hot to green wire ground inside the outlet. That’s certainly not the only possible path, but it is an obvious one.

While it seems heretical to step away from the conventional wisdom of “Always use 3-wire extension cords outside!”, I think it’s the enemy here. That third wire is there to allow for example the metal case of a tool to be grounded to protect against a hot-to-case fault in the tool. But if the only purpose of the extension cord is for 2-wire lights, that case does not come up, and in fact nothing useful is ever even connected to that third ground wire. (Sure – if you’re using the cord for the lights to run your old metal-case electric drill while putting up the lights, you want that third wire! But not for just the lights.)

I argue there is no typical case where the third wire provides any additional protection in the pure 2-wire lights case. But there is a clear and present possibility of inappropriate GFCI trips when the 3rd wire is present and connected (and wet!).

So I suggest a valid and potent ally in the GFCI battle is a ‘cheater’ adapter – to disconnect that third wire. (Of course, just using 2-wire extension cords provides the same effect.) I put one in front of all my Christmas lighting wiring and saw no more GFCI trips for the rest of the season. I plan to continue the practice going forward. (In my case, I have some custom, semi-permanently installed 3-wire extensions for lighting, so 2-wire extensions are an awkward solution.) Of course I’ll still arrange all exposed outlets to be off the ground.

It would be interesting if all the clever design above was for naught, made unnecessary by simply disconnecting one wire.

Posted in Holiday Lights | Tagged Christmas lights, GFCI, GFI ground fault | 10 Comments

Wire bender

Posted on December 21, 2013 by Jim

I’ve wanted a wire bender for quite a while. (Not one of those little jewelry wire benders – I can do most of what that does with a pair of needle nose pliers.) Ever since I’ve been stocking that nice #7 (.014″) steel wire I’ve needed something to form tight > 90 degree bends in it to make custom hangers for stuff.

One of the first benders I found was the $83 big honker at Harbor Freight. But after I saw how big it was (in a review on YouTube – who reviews HF stuff??), it was clear it was overkill. I did almost get one for the space, but it would hardly earn its real estate keep with the limited space there.

Then there’s that nice $100 bender at MicroMark that would probably do about anything I’d ever need, but even on sale that’s a lot to pay for something I’d only use occasionally.

There are other cheaper ones – like the classic K&S. The eye opener was that you used a vise to hold one part. Ah – that makes sense! That was tempting, but I never got around to ordering one. And then I found the elegant Harry Higley benders (in 3 sizes). Effective and inexpensive, I almost got some. But they were so simple, I thought I could probably make something like that myself.

It took most of a year to get around to it, but I finally made one. It’s a chunk of 1/4″ steel bar with two 1/4″ holes, plus a couple of pins cut from an old 1/4″ drill bit. It’s not as nice as Harry’s, but it was all from scrap and it works for the heavy wire I needed it for. Together with some simple operations in the vise, it should let me make about anything I need. And the bar is big enough that there’s room for some additional pins if I need them some day.

Here’s the first eye I bent with it in some of that #7 wire, used for a parts hanger. (There was a little vise work to get it to that size, but it was all easy.)

And now that it’s made, I gave it its own little home near the vise where it can watch out over the shop until the next time it’s needed. This one is a winner. It knocks something off the “someday” list, does just what I wanted, and it was free!

Posted in Miscellaneous | Tagged wire bender | 1 Comment

Protected: Flash memory sound playback

Posted on December 18, 2013 by Jim

Posted in Rf starter's gun | Tagged 4040, audio, Gold Wave, illegal MEGA 2560 clone, playback, SD card, sound, SST39VF010, starter's gun | Enter your password to view comments.

Humidifier hack

Posted on December 17, 2013 by Jim

I’ve had an Aprilaire 600 humidifier on my furnace for several years, but only recently paid enough attention to notice that it was on all the time. It’s a dribble-water-down-an-aluminum-pad type, with whatever doesn’t get evaporated by the airflow being collected at the bottom and draining through the furnace drain.

The problem

Obviously, if the heat’s not on, not a lot of the water will evaporate, and most of it will just go down the drain. That’s what I wanted to fix. I only want it on when the heat/blower are on. Maybe the installer just hooked it up wrong?

I took a look at it, and the installation is pretty half-assed with the transformer hanging by its leads. But the transformer primary goes to the HUM terminal on the ST9162 fan timer control board (and neutral), so it looks like it’s wired sensibly.

The manuals for both the furnace and the fan timer control board indicate the HUM terminal should be live only if the furnace is fired and the blower is on “heat speed” – which sounds just like what I want. Unfortunately, that’s not how it is behaving.

Part of the problem is that I have the fan on continuously to circulate air in the house. The variable speed DC blower motor runs the fan fairly slowly all the time, and kicks it up to circulate more air when the burner is fired. (I think it goes even faster when stage 2 heat is called for.) If I leave the fan in “Auto” mode – only on when the furnace is fired – the humidifier comes on appropriately. It’s when the fan is in the ON mode that the humidifier is always on.

The first hack

The fan timer board will control either a variable speed DC motor like I have (via an external blower control box) or a multi-speed PSC (Permanent Split Capacitor) AC blower motor. Maybe I could just connect the humidifier transformer to the unused PSC motor terminals. (Yeah, despite the Aprilaire manual saying “IMPORTANT: DO NOT WIRE TRANSFORMER INTO FURNACE BLOWER CIRCUIT.” But they don’t say why, so it must not be that important.)

I brought leads from HEAT LOW and HEAT HIGH terminals outside the furnace, closed the furnace back up, and looked at them with a voltmeter under various conditions. It looked like the HEAT HIGH terminal went active when I wanted. Now the manual shows that this terminal goes straight to the PSC motor, supplying run current. Surely it can handle the humidifier transformer. (Full disclosure: The other end of the voltmeter was to ground, not neutral. Surely that can’t matter…)

So I moved the transformer input from HUM to HEAT HIGH, closed up the furnace, and thought I’d be home free. But no. It didn’t ever really seem to come on. (Later observations with that configuration made it look like it might have come on briefly when heat was called for, but didn’t stay on during the heating/blower cycle.)

Back in the furnace air handler cabinet – this time with the interlock cheater in place. The PSC terminals continued to be weird. If I just touched a voltmeter lead to the HEAT LOW terminal (with the other lead to neutral) when that terminal was hot (which was when the blower was at low/circulate speed), the furnace would shut down for several seconds. Fortunately, it then restarted. When I put a meter lead on the HEAT HIGH terminal when that was high (which was when the blower was up to normal heat speed because the furnace was fired), the blower would speed up – perhaps to stage 2 heat/high fire speed?

Both those reactions to a meter lead are a complete mystery. How can a terminal expecting to provide 120V run current to a blower motor even detect that there’s a voltmeter lead connected to it? OK, the fan timer board clearly knows it’s running a DC motor, so I suppose it could alter its behavior on the PSC terminals. That still doesn’t explain why.

The PSC terminals were still able to supply some current. I tested with a 10W light bulb, and during some observations saw HEAT HIGH actually run the humidifier’s 24V water solenoid. I’m really baffled.

Second hack

OK, that didn’t work. (Though I haven’t a clue why not or what it was actually doing.) How can I control 120VAC to a transformer to the humidifier when the furnace is heating/blowing?

Well, how about W1 from the thermostat? That provides 24VAC when the thermostat is calling for heat. That’s almost exactly when I want the humidifier on. (Yeah, it would be on for the minute or two after initial call for heat while the inducer spins up, the burner fires, and it gets hot enough to actually run the blower up to heat speed, and it would turn off before the post-call-for-heat fan delay sucks the last heat from the heat exchanger. But I can live with that.)

I could use one of my cheap opto-coupled solid state relays to control power (from HUM or a CONTINUOUS terminal) to the transformer. If I ran a full wave bridge and a cap, that should power the SSR’s input LED OK. Maybe a series resistor would decrease the peak LED current and let me use a smaller cap.

Circuit design

The relay I grabbed needed 1.95V and 3.5mA to its LED to just switch on reliably (both half cycles). Additional points of reference are that it drew 14.5mA with 24VDC across its terminals and 2.24V at 5mA. The 5mA should be a good minimal but conservative current.

I tried it out, and it looks like it would work OK with a 10uF cap and 2200 ohms in series. And while that would probably draw not unreasonable current in steady state, I’m really uncomfortable with initial inrush current with a 10uF cap straight across the (diodes from the) thermostat leads. I’m still struggling with that. Seems like a smarter circuit should be able to give me 5mA without a huge inrush.

OK – new design. How about a nice series resistor to limit inrush, and a more efficient circuit to discharge the cap slower? A current regulator should give me a nice constant 5mA and let the filter cap survive despite the input resistor. The classic quick and dirty constant current sink is a transistor with its base 2 diode drops above ground and an emitter resistor that raises the emitter to 0.7V at the desired current.

Hmm – but in order to get pretty constant voltage across the diodes we need some current thru them. Say 5mA should do it. But that doubles the current draw of the circuit that I’m trying to make efficient! Boo.

OK, how about an LM317 and a resistor as a current source? If we need 1.25V across the resistor and want 5mA, R should be ~250 ohms. If we make it 220, that provides a slightly more conservative 5.7mA (at which the voltage across the SSR input is 2.73V).

If we need to supply 6mA, let’s limit the max current to say 20mA. The cap should charge up in a few cycles and we should get good DC out. Yeah, the transformer will bounce a few cycles with a less than full-ON LED, but I’m guessing that won’t hurt anybody. On 24VAC, our full wave bridge should give a peak of ~33V. If the current regulator and SSR LED drop 1.25+2.37+1.5=5.1V, we have ~28V peak trying to charge the cap. (That 1.5V is 317 dropout at low current.) WRONG – we have 33V trying to charge the cap if it turns on at the peak of a cycle. To limit the current to 20mA, we need ~1400 ohms in series with the rectifier. Let’s call it 1500. 6mA will go to the LED, but all that does is charge the filter cap a little slower.

So how big does the filter cap need to be so discharging it at constant 6mA will never drop it below 5.1V? Google found this nice reference which shows the linearly decreasing voltage on a cap with constant current drain as V=Vmax-(it/C). Allowing 33-5=28V of drop, we get it/C=28. At 6mA for say 0.01sec (conservative for 1/120 sec), the formula says we should be good with ~2 uF. So for an SSR, a 317, a 1500 ohm resistor and a couple of uF, I should be able to turn the humidifier transformer on reliably and never draw more than 20mA from W1! (That was more arithmetic than I’ve done for a circuit in quite a while.) I suppose if one were thinking too hard about all this, one could describe it as a sort of digital 24VAC current amp. We draw 20mA from the thermostat, and provide probably quite a bit more to the humidifier and its solenoid. <goes off to breadboard circuit>

Success

It works! The 10W bulb the SSR is driving on the bench comes on solid at ~19VAC into the bridge rectifier. And (reassuringly) the visible DC indicator LED in the SSR doesn’t change brightness as I crank the AC input voltage up. I didn’t have a suitable 2uF cap, so I used 4.7uF. Should be fine. I guess it’s time to house it in a manner suitable for mounting inside a furnace that I don’t want to start the house on fire.

<whine> Housing and mounting the parts was a lot of darn trouble. I needed spacers to mount the little perfboard circuit, but the nice plastic 1/4″ long ones I had were too long. I had ground the required two down to the right length on the belt sander, but while trimming the excess, dropped one into the big waste basket – where it remains unfound. The next one caught in the sander belt, got ripped out of my hand, and is probably still buried somewhere inside the sander. After that, I tried to cut the next one down instead of sanding, but broke it in the process. The fifth one made it. I didn’t have the right length 6-32 screws to mount the SSR and the perfboard so I had to cut long ones down. The unusual mount for the transformer required an asymmetric hand-trimmed cardboard template to get the shape right, tracing the shape on the steel box, and the never-fun drilling a bunch of holes, breaking the center out and filing until it was the right shape. I did all that – and then realized I’d traced it upside down so it would be impossible to tighten the mounting screw! Fortunately, I was able to re-file the asymmetric shape on the other end of the hole and get it fit in the right way. And of course the 120V leads needed wire I don’t stock, and when I found some, it had to have connectors crimped and heat-shrinked. Yes, I have the ability to do every one of those steps, but it just seemed like I had to hand make and hand fit every darn piece. </whine>

Final product

I found a steel box to house the parts, and got everything inside. I’d never seen a mounting like the transformer had, but after I cut a suitable hole, it mounted securely. I found some small spiral-cut wire protector stuff and made the solid green/white Cat5 pair going to the thermostat screws a little more robust.

Here’s the box mounted in the furnace (complete with the zip ties that will hold the top on). When I closed it all up and turned the furnace back on, after a few seconds the usual relay clicks sounded, but the blower didn’t come on. Damn. I opened it back up, rechecked everything, wiggled wires, and finally pulled the 120VAC wires to the new control and closed it back up. Still no blower. But as I waited a little longer, the inducer spun up and the burner fired. That was going to be bad without a fan! I shut it off.

I opened it up again, convinced myself I hadn’t screwed anything up, reconnected the 120V leads, closed it back up and turned it on again. I figured there should be an override that would shut it down if the heat exchanger got too hot with no fan, and I was standing right there to watch it. Still no constant blower. Inducer spun up, and the burner fired. And then – the blower came on to heat speed! That was very reassuring. I looked at the LED I’d recently added to the humidifier solenoid, and it was on – just like it should be. I waited for the call for heat to end, and glory be! – the blower reverted to low circulate speed! And the humidifier LED was off. I watched through a couple more cycles, and it looks like everything is finally working as it should.

Well, that was a lot of trouble for what I think should have worked right in the first place. But it’s done, I feel pretty good about the parts and construction, and the humidity in the house is coming up!

Posted in Home Repair | Tagged aprilaire 600, humidifier, ssr, ST9162 | 3 Comments

Laser level teardown

Posted on November 28, 2013 by Jim

Workshop 88 was given a box (maybe 100?) of as-is laser levels. I tore one apart for the goodies inside (as I expect several others will do). Here’s what I learned.

The levels were pretty high quality Keson LL150 commercial units, manufactured ~2003. They ran off 3 AA cells, and provided spot beams up, down, left and right, and a vertical line out the front. In addition to normal stuff like a lockdown for transport, switches and a 1/4-20 mount on the bottom, they contained 5 lasers and a really nice weighted, gimballed suspension to keep the lasers pointing true. There’s also a clever mechanism that disables the lasers if the case is not level enough to allow the laser carriage to hang freely. While they’d been discarded as old or dead or out of calibration, if they still work, they’re still probably very usable for their original purposes. Of course they don’t all seem to work.

Disassembly

Disassembly begins by removing a small Phillips screw in the top of the battery compartment. This allows the cover to be pulled straight off. Removing the bottom two will let you scavenge the battery holder later on.

Looking down on it with the cover off, we see the small PCB with the push-on/push-off switches, one for the left/right beams, the other for up/down/front line lasers. It also has a 3.0V regulator that protects the lasers, as well as mounting for the 3 very fine (read: flexible!) wires that power the lasers while allowing them to move very freely. To power the unit bypassing the power switch on the bottom and the sometimes annoying hang-free sensor, put positive on the place marked B+ and negative on the place marked AGO. That power will still go thru the red buttons and the voltage regulator.

If you’re just inside to look around or troubleshoot with hopes of using it as a level, stop here, and be careful with those wires!

The next step is removing the four black 3/32″ allen cap screws holding the gimbal assembly down. This allows the gimbal/laser carriage to be removed. Yeah, you’ll have to rip off those really nice fine wires. You’re probably going to do a lot more damage to precision stuff than that before you’re through, so come to terms with it.

At this point, you’ll probably just play with the gimbals for a while because they’re so nice and smooth. But they’re in the way, so you’re probably going to have to tear them off. A couple of people have tried doing so gracefully – like by carefully driving the shafts out of the bearings, but we’ve failed. I ended up doing a combination of breaking and sawing them off. It hurt, but I couldn’t really envision needing gimbals with such limited motion.

Other stuff in the case

In the bottom of the case frame is the big, hulking blue plastic “on/off switch”. While it operates a small microswitch that is the main power switch, that large lever and its over-center spring does something even more critical: It wedges the carriage against a rubber block in the back so it can’t swing around and get banged up when you throw the unit in your tool box.

Also in the bottom of the case – at the opposite end from the switch, and now visible with the laser carriage removed – is the little optical sensor that disables the lasers unless they’re hanging near the center of their travel. The double lumps look like a typical reflectance sensor. Just above it, on the bottom of the carriage, is a small mirror (maybe a bit of aluminized mylar?) that must be right above the sensor for it to be satisfied and allow power to the lasers.

Lasers!

At this point, you’ll probably just start taking the lasers out. You can easily identify the front laser with its cylindrical glass rod lens for making that nice vertical line. Each laser is in a little cast holder that’s attached with up to 4 small Phillips screws. With those removed, the casting comes out fairly easily. There are wires attached to the back, so be careful not to rip them out as happened to one of the wires on the one on the right. There’s a bunch of wire and Y-connects crammed into the cavity in the middle of the carriage. There’s probably one laser that’s best to start with so you can get it out with leads intact and maybe do some surgical cutting of the newly exposed wires. I didn’t pick the right one, and don’t know which would have been better.

The actual laser diodes seem to have been put in position and aimed with a couple of set screws through those castings. But then they were epoxied in place, so removing the set screws won’t get you very far. Paul set up a screw press to press them out, but he had a tough time doing it. Given his experience, I just left the lasers in the castings. They provide nice mounting holes, and it’s much easier just to leave them on.

The little PCB on the back of the laser is potted in soft silicone rubber, like RTV. Here’s one with that mostly peeled off and with the terminals marked, in case you have to solder some new leads on. (The negative lead still has some stranded wire attached.)

Power

While Paul and I were playing with some of the diodes on the bench at the space, we ran them up to maybe 5 volts, and watched them draw over 100 mA, and I don’t think we burned any out. But as I was looking at the little PCB in the case (not on the back of the laser), I saw what looked like it might be a voltage regulator. I powered it up and checked – and sure enough there was 3.0V on the laser power leads, even as I cranked the bench supply up and down. That makes a lot of sense for a battery powered device.

Here are some observations of current draw on a complete, functioning unit:

Batt term V  Current, mA, all 5 lasers on
5.0          128
4.0          120
3.5          116
3.2          110
3.0          105
2.5          72

Here's current draw with 4.5V at battery terminals, power on:
No lasers  Side only  Top, bot, line  All
37 mA      67 mA      95 mA           124 mA

The current measurements in the top table are pretty consistent with a low dropout regulator at 3.0V. I’d take all that to indicate that it would run happily on a LiPo . I’m surprised at that 37 mA with no lasers on.

Paul reported seeing a battery life of 20 hours in the manual. With alkaline capacity of say 2000 mA-hr, that’s 100 mA – just about what I saw.

So it looks like we can drive the diodes safely at 3.0 V, and each draws 15-20 mA.

Da loot

That’s about it. Here are all the bits I managed/bothered to pull out. I couldn’t get the top laser out, so it’s still in the carriage. It took a couple of judicious cuts to get a usable battery holder. All 5 of the lasers in this one work, although it had been marked “B” for bad.

(Well, that’s almost all the bits. I did retrieve the PCB from the garbage, jumper across the removed switches, solder some wires on, and will use that as the regulator to safely power one of the diodes as a rafter-mounted, downward shining “where to stop” parking indicator in the garage. I’ve wanted one of those for years!)

Posted in Workshop 88 Stuff | Tagged keson, laser level, LL150, teardown, Workshop 88 | 7 Comments

New conical “light box”

Posted on November 25, 2013 by Jim

The standard way to get nice “professional” uniform lighting for technical photos is to use a “light box” with all white insides so light comes pretty uniformly from all directions. My plan for some time has been to build some kind of light box, and I finally got around to a first prototype. Turns out to be a cone rather than a box.

The setup

Cheap, simple and effective have been the requirements for this (as they most always are). I’d pictured a sort of hemisphere of maybe gauzy white cloth supported by maybe some kind of wire frame, with lights outside. I got as far as getting the lights a year or two ago, with two large metal reflector lamps with 100W-equivalent CFLs clamped on to a shelf above my workbench. The location was a compromise: I didn’t have room for the dedicated setup I would have liked, and the stuff I was photographing was often on the bench, and there was a shelf right there, so that’s (grudgingly) where the lamps went for the first pictures.

But I found myself also turning the lamps on when I was working on delicate stuff on the bench and liking the additional light, so I slowly stopped begrudging their presence. They’re not pretty, but they’re functional, and they’re always right there for a quick picture. (And sticking the UV CFL in one for PCB exposures is really easy, too.) You can see them clamped on above the awful mess of my bench. The cutaway of the cone shows where the subject goes. The small hole for the camera lens shows up better in the top picture.

Cheap or cheaper?

I recently ran across a post about using some LED rings from Deal Extreme (here and here at this writing) as ring lights for a camera. He used a sanded top from a cylindrical CD case for a diffuser. Looked great, and I could get the two 12V LED rings for about $13. Here was a no-brainer for getting the uniform light of a light box, right? Some assembly required (oh great – another project), and it requires 12V (but that’s easy to come by in the shop), and the extent of the light isn’t as large as a light box. Still pretty good. Go for it?

OK, I guess first I should do a quick revisit of possible implementations of an actual light box, using the actual lights I already have. The big bulbous hemisphere idea came up again, but in addition to not having a plan how to make it, storing and deploying/re-storing it came up, making it (once again) not a great solution.

I don’t remember how the tracing paper came up, but it seemed like a cone of translucent paper might work about as well as a box or sphere. I made up a quickie of three 9″x12″ sheets of tracing paper scotch taped together, with the bottom edge trimmed to about a circle. A line from apex to edge is 9″. I cut the apex off for a circular hole just big enough for the lens of my workhorse Canon SD600. Pretty flimsy, and that bottom edge might need a loop of wire attached to make it a little more stable (if less easy to fold up!), but it was quick and free. How well would it work?

Initial results

One of the perennial problems with pictures of PCBs (which I make a lot of!) is reflections of the traces. The copper is pretty, but it’s really hard to get uniform reflection off all areas of the board. (And getting no reflections is tricky as well.) My effective, but unwieldy solution is to use the great outdoors as a humongous light box. I take the board outside, find a place with a good view of uniform sky, stand so the board isn’t in direct sun, and move the board and camera until it gives good reflection of the large sky in the copper traces. A good light box should do even better. A populated PCB would be a great first test subject.

Here are pictures with the two bare lights and under the cone. Four differences jumped out at me:

The cover of the micro SD socket (green) gives a much more pleasant, uniform reflection in the cone (bottom) picture.

The PCB traces (pink) also give a nice reflection with the cone.

The reflections off the solder joints of the ribbon cable (blue) are pleasantly less harsh with the cone than with direct lights. I often have to mess with exposure to tone down such reflections.

Specular highlights on a piece of wire and the LED (yellow) are lost with the cone. The results are not too bad, but we lose the shininess of the wire and the LED. I like to have good, full-range pictures, but I like some sparkle, too.

So the cone gives noticeably nicer – I guess better – pictures, though maybe with a little loss of sizzle. I suppose if somebody were paying me for beautiful pictures I might poke a white LED or two through the paper for a couple of bright highlights, but they’re not, so I probably won’t.

So while I hate to lose the opportunity to justify some new toys (I sometimes wonder if the postman asks “Who is this guy and why does he keep getting all these little padded envelopes from China?”), I guess the tracing paper cone gives me the lighting improvement I wanted. And I owe the guy who did the light rings a thank you for forcing my hand and making me come up with an effective, free solution.

Posted in Photography/Camera stuff | Tagged light box, light ring, photography, tracing paper | 1 Comment

Supply voltage brinksmanship for sound modules

Posted on November 14, 2013 by Jim

I’ve been working on two “3 volt” sound modules – a micro SD card module for the dollhouse and a from-scratch flash memory sampled sound playback device for the starter’s gun. Neither one actually works on 3.3V. So begins the tale.

The Noisemakers

It started with the $4 cheap Chinese WTV020 micro SD based player module. The Ebay ad says it’s 5V compatible, but it isn’t. The details deserve their own separate post, but the bottom line is that I got it working on a fairly fully charged Li-ion battery.

(Li-ions and Lipos have become my bench supply of choice. They’re small and portable, and Arduinos and most other stuff run happily on them. A favorite is this pair of 18650s (2P) from an old laptop battery. It’s over 3 amp-hours at 3.6V! But even a 300 mA-hr Lipo recycled from a Sansa recorder is very useful. Of course they’re nominally 3.6V, and up to 4.2V fully charged, so they’re really sometimes out of spec for many 3.3V devices.)

After some pass-fail testing with a real bench supply, I decided the module would run happily on 3.8 or 3.9V. But this was for the dollhouse, whose main power bus is 5V, so I’d need some kind of regulator. Unfortunately, 3.8V isn’t a common value. But I can make something.

The second noisemaker was a 1Mbit SST39VF010 flash memory playing straight sound samples thru an R-2R ladder D/A. (Thanks to Workshop 88 for the donation of a strip of 4.7K 0805 SMT resistors off a reel of 6 zillion or something.) The chip is a 3.3V part to fit in with other 3V parts (like an XBee) in its device. While that also deserves its own post, I got the first player board up with a Diavolino (Duemilanove clone) running on 3.3V. I’ve had enough things that needed 3.3V that I have a couple of cheapie CP2102 USB-serial adapters wired to deliver 3.3V from their internal regulators to the 6-pin serial connector for Diavolinos. That all worked fine.

But to program the chip I needed more I/O lines than my 328Ps could provide. So I got a (clone) Mega2560, and made up a mini-shield for the memory chip. (Picture at the end.) To get the sound samples to write to the memory, I made up a very simple SD card adapter (to plug into the ICSP header for SPI, plus a loose Chip Select). SD cards run on 3.3V, so that should all be good.

Unfortunately I had no way to run the Mega on 3.3V. Its on-board regulator properly provided 5V for this 16MHz device, so I couldn’t go in the barrel jack. The simplest way in was a USB-B cable with 3.3V on the power leads. I’ve built up a lot of strange adapters over the years, but not one of those. Fine – I can cut the cable and insert a regulator in line. Ugly, but it should work, and then I’ll have a way to run the Mega on 3.3V for future projects as well.

Two regulators

OK, I need two 3.xV regulators. I had some low dropout 3.3 volt LM1117-3.3 regulators. It’s a kludge, but putting a normal silicon diode (1N4148) in series with the ground lead to the regulator will boost the output voltage by 0.6-0.7V – just what I needed for the micro SD module. I made two copies of the diode-kludge PCB and jumpered across the diode on one for the Mega. The one with the diode measured about 3.9V, so it should work with the micro SD player; the one without measured 3.3V, as it should.

I cut a USB-B cable open, cut the red (+) wire, and got a tap off the black (-). I patched the new little 3.3V (no diode) regulator board inline, and sure enough it put out 3.3V. But understandably, the cable was really fragile feeling. So I reinforced the whole stretch of cable around the regulator by gluing a “splint” of heavy sheet brass angle under the board. That’s at least sturdy enough to do some testing with. I plugged it into the Mega.

The power LED came on and it even seemed to load code, but it failed the code verify step. Now every 328P based Arduino I’ve tried runs fine on 3.3V – even though at 16MHz that supply voltage is out of spec. But this 2560 (or at least some part of its USB connection) wouldn’t. Yeah, I know it’s out of spec, but boo anyway. Now what?

I disconnected the two 3V parts (SD card and memory shield) from the Mega and plugged in a regular 5V USB cable. Of course it worked and loaded code fine. I unplugged the 5V cable, reconnected the 3V parts, and plugged in my 3.3V regulator USB cable. (The order matters!) It seemed to work. But my code, or the new hardware, or both didn’t work. While I could do the onerous connect/disconnect 3V/5V dance each time I wanted to load new code, even more worrying was that I wasn’t 100% sure the Mega was working perfectly. And that’s a horrible way to have to debug new code and hardware. Ugh. I wondered – might just a little more voltage help?

Well, there’s still a place laid out for a diode on the regulator board. While I wasn’t willing to go to the 3.9V a regular diode would produce, if I put a Shottky diode in maybe that extra couple of tenths of a volt would do the trick without blowing anything up. The Shottkys I had didn’t really fit, but I removed the jumper and finessed one in. It produced 3.5V. It’s worth a try.

And it worked! After some more adventures (including the fact that the Mega uses pins 50-52 for SPI while I was using them for memory address lines, making it impossible to use the SD card and memory at the same time), I got both the code and the hardware working. Here’s the whole setup, including its hacked regulated cable.

Now that I can actually program sounds into the memory chips, I have to be able to get them out of that funny socket to move them to the player board. But now I have a tool for that 🙂 .

Posted in Dollhouse, Rf starter's gun, Uncategorized | Tagged 3.3V, Arduino, li-ion, Lipo, SST39VF010, Workshop 88, WTV020 | Leave a comment

Chip lifter with Shapelock handle

Posted on November 13, 2013 by Jim

Now that the sound record and playback stuff for the starter’s gun is working, I actually have to pull and replace the PLCC memory chips. The smallest screwdriver that lives where I do this is a little too big, so I thought I’d make a quickie chip lifter.

It’s pretty dead simple – a nail bent for a handle and ground flat at the end. (Yeah, it got a little too hot. Meh.) This is the second one. The first was a little smaller, and I was afraid it would get lost on the bench. I would have included a picture of it, but it seems to be lost.

To make it a little nicer and help keep it from getting lost, a Shapelock handle seemed like a good idea. When I started pouring out the beads, I found a random scrap from some previous play (at right) just waiting to be recycled. It felt a little too big at 2.9g, so I cut it down with a kitchen scissors to 1.9g. That was about right. That helps understand how many little projects I may get out of my 250g bag.

Some hot water and smushing later, I had something that would pass for a handle. Here it is fresh from the hot water and after cooling down.

It’s completely functional, but very clearly home made. The nail is way too visible (shoulda made the nail more coplanar and flattened its head), and it’s kind of lumpy. I suppose some others could see some kind of charm in that.

Anyway, it didn’t take long to make, cost almost nothing, works perfectly, and it’s probably big enough to not get lost, so it’s a winner.

Posted in Miscellaneous, Shapelock stuff | Tagged chip lifter, Shapelock | Leave a comment

Dollhouse net with ATtiny85s

Posted on September 2, 2013 by Jim

(This is one of a pair of unrelated Tiny projects that seem to be going on in parallel. I don’t think I could have chosen two more confusable projects if I’d tried.)

These are the first steps in implementing a little I2C (oops, Two-Wire Interface) network with simple, cheap Tiny85 nodes for automating a dollhouse. This is all from scratch, and in small steps – since I don’t really know if it will work. (Update: it works. I really should distill a nice post from this cron history.)

The vision is a dollhouse wired with 4 conductor cable – +5, Gnd, and 2 for a TWI network – so little slave nodes can be installed where ever inputs or “actuators” are desired. An Arduino is the bus master and logic host for the system. Open a door and a switch on a slave notices. Maybe that causes the audio slave to play a creaky door noise, or maybe it turns the fireplace on, or maybe it only turns the fireplace on if the slave with the photo sensor has noticed it’s dark out. And if something in the house just needs (5V) power, the cabling has that covered as well. Should be pretty powerful.

Tiny85 slave node

At ~$1.30 each for about five I/O lines, Tiny85s are about perfect for the slave nodes. The power+network connection is a bit of ribbon cable and a 4 pin 0.1″ male header. The DH is to be wired with a bunch of 4 pin females. Power and ground are on adjacent pins 1 and 2, so if you plug the unpolarized plugs in backwards there should be no damage.

Here’s the very first prototype slave node. Nothing there but the Tiny, an LED (and resistor), a pullup for Reset, and a small cap across the supply pins, plus the power/network connection and pads for the three I/O pins to connect to the slave’s target inputs/outputs. No crystal – the internal 8MHz oscillator should be fine.

To save space, I omitted the ICSP header by taking advantage of the fact that the “network” cable already had 4 of the 6 needed pins. I added two pads for the other lines needed for programming, figuring I’d just hold the extra two wires in place for the 10 seconds needed to program the node. Holding the wires down let me download a Blink sketch first try. It works! A little more fiddling let me run avrdude in interactive (-t) mode and set LFUSE to 0xE2 instead of 0x62 to let it run at 8MHz instead of the factor default of 1MHz.

I brought out 5 pads for the I/O, including +5 and Gnd. For the first tests, I figured I didn’t need +5, so I just used 4 pads. Confusion #1 struck: I was going to have two identical ribbon cables coming out with identical 4 pin connectors. Bad idea. Fortunately, I had some black ribbon cable, so that visual difference will probably save me from doing something dumb. One mine sidestepped.

Too many N-wire interfaces

To keep me on my toes, this project – and a Tiny84 sister that happens to be underway at the same time – use all three of the simple few-wire serial interfaces. For programming, both use SPI (with its Gnd, MOSI, MISO, SCK), as do most all the AVR chips. The dollhouse network is I2C (with its Gnd, SDA and SCL). Of course, since Philips has imposed licensing costs for “I2C”, many implementations sidestep the licensing by calling it the “Two Wire Interface”, or TWI. And the Tiny84 datalogger in development at the same time as this also uses the “1-Wire” interface Dallas (now Maxim) introduced, with its Gnd and data/power lines. The 1-wire slave device may extract “parasitic power” from the mostly-high data line with its pullup resistor, making it possible to connect a slave with only 2 wires.

The AVR ATmega chips – like the classic Arduino ATmega328P – have special hardware in the chip to directly support I2C/TWI. The “Wire” and “TWI” libraries that ship with Arduino distributions are written to use that hardware. That’s in addition to the also built-in hardware to support SPI, used for programming. The Arduino distribution also includes a library to talk to other SPI devices. We’ve come to take for granted that Arduino can talk to most any devices with those protocols with no problems.

But to add to the fun, while the Tiny family chips do support SPI in hardware (they have to be programmed, after all), they don’t have the same I2C/TWI support hardware on chip, so the standard Arduino libs can’t work. Tinys do, however, have hardware support for the simpler Universal Serial Interface – USI. That hardware can also be convinced to do most of the work for I2C/TWI – though not all. Fortunately, the open source community has written (several!) libraries to (ab)use the USI hardware in Tinys to support I2C/TWI. There’s a USIi2c lib (gotta keep all them letters straight!) available on the Arduino site, as well as others in various github projects. Of course the library names are different, so code that works fine with the “real” Wire/TWI libs must be modified to use the Tiny libs.

Oops # 1

Because there are limited pins (especially on Tinys!), each pin can perform any of several functions:Trying to be careful and clever, I noticed pin 5 was used for both SPI MOSI and TWI (USI) SDA, and 7 was both SPI SCK and TWI SCL. If I brought those 2 out along with +5 and Gnd to make up the 4 wire power/network connection, I’d have 4 of the 6 wires for the SPI programming interface right there on a nice 4 pin connector! I’d just have to cope with separate pads for MISO and RST when I wanted to program the Tiny. Sold.

But even more cleverness (not): MOSI and SCK and +5 and Gnd were already brought out on the Arduino’s often overlooked ICSP header. I could just make up a ribbon cable with a 2×3 pin connector for that header and a 4 pin female with those 4 wires laid out in the same order as the DH “network” connector and I’d have the pigtail I needed for the bus master Arduino to talk to the slaves. For the first prototype, I could just plug them together. For larger prototypes, I could make a “hub” with one 4 pin male and a few females all in parallel that I could also plug into that same pigtail. Great!

I marked one side of the slave’s and master’s connectors with whiteout to make it easier to plug them together correctly. Here it all is, as plugged together for the very first actual TWI network test. Unfortunately, it didn’t work. A little head scratching later it hit me: The I2C/TWI interface on the Arduino is on A4 and A5, not the MOSI and SCK on the ICSP header. The whole (not so) clever approach of using the ICSP header was just wrong. I’d completely confused the SPI and I2C interfaces. Rats.

So I took off the 6 pin female and wired the 4 relevant wires to two 2-pin 0.1″ males (for +5/Gnd and A4/A5). If I’d been thinking straight, I could have used a 4 wire ribbon in the first place. Hmpf. But just before gluing them to a piece of plastic so they just fit the right holes, I realized I’d forgotten the pullups! Added a small 3.3K resistor from each I2C line to +5, glued it all up and tried again. It works! I can now officially talk from an Arduino master to the first Tiny85 slave. (Yeah, yeah – that connector’s really ugly. But it works.)

Initial software

Ignoring various missteps involving further confusing the serial interfaces and trying to find libs that work on Tiny 84 instead of Tiny 85, here’s what I ended up with. There are two parts to the puzzle so far: an I2C/TWI implementation for Tiny85, and some master and slave sketches that talk to each other using the TWI lib(s).

AlphaNerd put a nice TinyWire package on github marked as his changes to BroHogan’s USIi2c libraries. It includes a slave sketch attiny85_i2c_slave that provides four read/write “registers” (0-3), initialized with the classic 0xDE, 0xAD, 0xBE, 0xEF. As is the custom with I2C devices, it maintains a “current register” pointer that automatically increments after each read, so a series of reads walks through the registers (and wraps). Writing to the slave alters the contents of the addressed register. I hacked it a little so if you write to non-existent register 5, the value written is used for an AnalogWrite() to the output pin the slave’s LED is on. (That pin was cleverly chosen as one that supports PWM.) Makes for an easy visual check that I can talk to the slave.

AlphaNerd’s package also contains a very useful master tool, i2crepl, which includes a scan through all 0x7F addresses on the bus, showing which addresses have devices that responded. Using a simple language with ‘[‘ as an I2C Start and ‘]’ as a Stop, you can manually enter most any read or write command you choose, and the sketch will attempt to send it on the bus. Each byte it tries to send is echoed, along with the return status from the lib trying to send it (and of course any bytes read from the slave). Obviously this requires some understanding of I2C protocol, but that’s not very complex. The tool is hugely valuable in the early steps of setting up and troubleshooting an I2C bus – which is exactly where I am. Thanks, AlphaNerd!

The I2C/TWI implementation I seem to be using on the master is rambo’s I2C package on github, based on Wayne Truchsess’s work. I think it was somehow claimed to be better than the standard Wire/TWI lib. Rambo’s package also includes an i2crepl sketch, which is probably related to AlphaNerd’s. There’s a lot of cross pollination here, and I’ve mostly given up trying to keep all it straight.

It looks like there’s a USIi2c based Tiny TWI implementation in AlphaNerd’s package as well. The slave sketch includes “TinyWireS”. That seems to be what I’m using.

There are a LOT of libraries I’ve tried or planned to try in my Arduino download directory. I remember being frustrated because some package had a TinyWireS (slave) lib, but no TinyWireM. I did finally find a package with both, but by that time I had realized it didn’t matter, since my master was on a real Arduino, not a Tiny. Part of why I’m recording all this is that I never want to have to go through it again. Part is probably just whining about how much it makes my head hurt.

It’s a network!

Encouraged by the ability to talk to the first slave, I populated 2 more slave boards (as one reflow job) and made up a “hub” to connect them. The hub is just some 4 pin females all in parallel – like the DH will be wired with. I marked the “white” side of all the connectors. This one has a 4 pin male as its “input” connector from the master, and has 4 more pads that will allow expanding it by daisy chaining it to another hub. I’m not sure yet how the wiring in a real DH will be implemented.

I burned the same slave code – obviously with different addresses – in each of the two new slaves. Of course I had to do the drill of holding the other two ICSP wires down for each one to program it. Although the new nodes don’t have pigtails to talk to the outside world yet, I used the i2crepl master tool to verify that I could read and write to each of them. It’s officially a network!

Update 9/3/13: I made up two more slaves with my last two SMT Tiny85s. I also laid out the board to be a little smaller. Here they are with one of the originals. I loaded the attiny85_i2c_slave sketch in both – with unique addresses, of course. Since there are now more slaves than fit in the hub, I made another hub, too. That plus some phone wire will give me a chance to see how it works over a much longer run.

One big surprise with these as well as the second and third slaves is that they ran fine with the fuses still set for 1MHz. (8MHz internal oscillator, div by 8 on.) I’ll run avrdude and change them to 8MHz, but I’m surprised they even ran.

We have colors! Here’s a slave with one WS2812 RGB LED. (Thanks, Bill!) The Adafruit lib coexists happily with the USI TWI slave lib, and I can talk to this node from the i2crepl tool. Values 1-255 written to now standard register 5 walk around the color wheel; value 0 turns the LED off. I had to make up a little breakout to connect wires to the LED first, but thankfully that’s pretty easy now.

And we have sound! Here’s a slave that talks to a SparkFun MP3 Trigger board I happened to have from another project. In addition to the 18 dedicated trigger pins, the board accepts normal TTL serial in to control most everything, and even has holes laid out for the standard 6 pin connector from an FTDI cable. The cable here is just +5, Gnd, and Tx from Tiny SerialDebug. Default on the board is 38400, but since it’s not running a crystal oscillator, I opted for a more conservative 9600, taking advantage of the convenient feature of a MP3TRIGR.INI text file on the micro SD card. I dropped several sound effect clips on the card, so it’s pretty much ready to go. At $50, this board is pretty pricey for a dollhouse. I just ordered a cheaper programmable player, so I’ll try to integrate that when it comes.

As has become the custom, writing a value to register 5 plays the track with that prefix number. The network is coming along!

The bad news is that I fried one of the slaves. While trying to program it, I plugged its 4 pin connector into the programming breadboard off by one pin. (Never use a black breadboard!) The Tiny is clearly not completely dead, as it still blinks the LED with code in setup(). But apparently at least one of the pins needed to program it is blown. It won’t respond either to the programmer or to avrdude. Down to 4 slaves. 🙁 But that’s still enough for a good demo. 🙂

Getting a servo to work has been harder. The standard Servo lib uses a 16 bit timer – which the Tiny85 doesn’t have. I have a lib directory called TinyServo, but as far as I can tell it’s just the standard stuff (and doesn’t work on a Tiny). I tried SoftwareServo, but it didn’t work very well. Unfortunately, it requires calling SoftwareServo::refresh() very frequently in the main loop. But the Tiny TWI stuff also requires calling one of its functions in a tight loop in the main loop. I didn’t try removing the TWI call, but the servo just kept oscillating.

I finally just wrote my own pulse width code, calling the TWI call while waiting for the hi and lo pulse durations. Fortunately, micros() seems to work on the Tiny85. There’s almost no traffic on the network yet, so I don’t know whether my approach will work when the master is banging polls out about as fast as it can. Anyway, it’s a start.

I didn’t wire up a servo header like I did with the WS2812 and the SparkFun serial cable, figuring I’d just just use the slave with that nice black ribbon that brought out all the I/O pins. I’d gotten all the way down to wiring a servo header on the breadboard when I realized I’d decided not to bring +5 out on that cable. Grumble, grumble… So I pulled out my trusty 5V battery and used that to power the servo.

Of course there is no such thing as a 5V battery, but I got a little boost converter from SparkFun years ago that gives 5V from one AA. It was kind of pricey – 10 bucks? – but I use it all the time. It’s posing here with some friends.

Update from ~9/4/13: Fireplace LEDs “LED flickering candles”are available from lots of places. I found just the LEDs at Lighthouse LEDs and ordered some. The chip embedded in the 5mm LED runs from 3-6V without a resistor (despite what the web site says).

But one flickering yellow LED is kind of boring. Multiple LEDs, flickering asynchronously would be better. And it would be nice if there were some red ones, too. Gee – the current thru a flickering yellow must flicker, too. What if there was a red one in series with it?

By masking the yellows that were just being used as current modulators with some heat shrink, their reds flicker all by themselves. The 5V supply in the DH should be enough for the forward drop of 2 LEDs in series. I tried it with 2 of each color, and it worked out really well. The yellow LEDs (clear packages) had pretty tightly focused lenses, so I hit the tops with a Dremel cutoff wheel to diffuse the light a little more. That helped, but there’s still a circular artifact. I think grinding the sides down would fix that, but didn’t bother on this one.

It’s now embedded in a fireplace in the DH. Some nice printed flames on clear plastic from from the castle props makes it even nicer. This one was a real win. I should get a little video clip of it.

Update 9/6/13: A Tiny84 slave? We may need quite a few photosensors for the dollhouse. Since I/O is really limited on Tiny85, and it looks like the Tiny84 with its 14 pins has 8 analog inputs, I wanted to see if I could get an ’84 on the I2C network. I made up a little ’84 breakout with 0.1″ header spacing so I could stick it on a breadboard and play with it.

Unfortunately, I walked away from the reflow hotplate for too long and the board got really cooked. 🙁 The controller even beeps when it’s time to turn power off and again (2 beeps) when it’s about reflow temp so it warns me to take the PCB off (if I can hear it!). On the good side, I’ll probably never walk out of the room during a reflow again!

A little later… Wow. Just on the off chance the chip wasn’t really roasted, I put the 6 pin ICSP header in and ran avrdude. It responded!

OK – next step. I peeled off the bottom delaminated layer of the board, poked the blackened material out of the holes, scraped and fluxed the pads, and put the two 7 pin headers in. Would I actually be so lucky as to have it work?

Well, no. When I tried to plug the module into a breadboard, it didn’t fit. Apparently when I laid the board out I failed to make sure the two rows of 0.1″ headers were in fact a multiple of 0.1″ apart so they’d fit in a breadboard. Measuring in Eagle, the rows were 0.449″ apart. Rats. So close.

But then there’s always cheating. There are no rules about how far apart two breadboards can be! I wrote a little one-at-a-time blink code and stuck a couple of the nice little 5 LED boards that are set up for pins 8-AREF on a regular Arduino. Not perfect, but that put LEDs on about 8 of the pins. (And ground even lined up on one side!) After a couple of tries (even though pin1 is marked) I got them in a sensible orientation – but it didn’t work. It took a little while, but I finally realized that one of the LEDs was on the Reset pin. That was holding it to(ward) ground thru the LED and resistor, and it was enough to hold the chip in Reset. A wire from that pin to +5 fixed that (with that LED always on), and all the pins that were connected to LEDs worked! I can hardly believe it. Guess I better stop saying “Wow!” and see if I can get it on the I2C net like I wanted to do in the first place.

A little later… I’m using up all my luck here. I used avrdude to turn off the div by 8 fuse so it’s running at 8MHz and loaded the stock attiny85_i2c_slave sketch and the ’84 came up on the network. I couldn’t find specific mapping of the Arduino analog “Ax” pins to physical ’84 pins, but making the educated guess that ADC0-ADC7 from the datasheet would be mapped to A0-A7, I tested (almost) each one with a pot to that pin, and that mapping worked. (And the pins worked for analog in!) That was all using Tiny DebugSerial to see what values I was getting.

I couldn’t try A4 (pin4, PA4, SCL) or A6 (pin7, PA6, SDA) as they were the I2C bus, but I did try referencing A7 as “(A6+1)” and it worked. I take that to mean that the mapping is there in the code somewhere. Of course I still can’t test those two pins with a slave on the network, but the pattern looks pretty clear.

I still can’t believe that blackened board works and works well enough to do meaningful testing with. And it’s very nice that the ’84 hardware is close enough to the ’85 that the I2C stuff worked without a hitch. I guess it’s worth laying out a Tiny84 slave board!

Update from ~9/10/13: Color sensor fail There was strong interest in a “monster sensor” – so a colored monster held up to a window could be recognized by its color, perhaps triggering some corny spoken line referring to the monster’s color. I tried to get the Adafruit Flora color sensor integrated into the network (but failed). Because this is already an I2C device, it won’t talk to a slave, but rather be directly on the I2C network.

Since the TCS34725 chip the sensor is based on is a 3.3V part and the DH network is 5V, I needed level shifters as well as a 3V power source. There’s an elegant level shifter using a MOSFET and a resistor (which I still don’t understand) that looked like just what I needed. (Adafruit has another version of the sensor with a 3.3V regulator and level shifters, but the one I had was the 3V-only e-textiles version.)

I laid out an adapter board with 2 channels of level shifter for the I2C lines plus a 3.3V regulator. The cheap MOSFETs I stock are bizzarely in an 8 pin SOIC, with 1 pin for gate, 3 for source and 4 for drain. Fine. The nice 5 pin LDO regulator I put on the board just didn’t work, and had to be replaced with a TO92. I didn’t want to clog Rachel’s color sensor thread holes up with solder, so I put some wires up that I could just tack solder to the pads next to the holes on the sensor.

But when I put it all together, although power and signal levels looked good, I just couldn’t talk to it from the master. Trying to simplify for troubleshooting, I wanted to run the sensor direct from an Arduino. I tacked the 4 network wires directly to the sensor for the test.

To my chagrin, I didn’t have a way to power an Arduino with 3.3V. Here’s the unholy hack I used to get 3V power to the whole system. Patching 5V into the power pins of the network connector on the color sensor adapter got 3V for the sensor. A 4 pin network cable tacked to SDA, SCL, VCC and GND on the sensor patched thru a hub (not needed – duh!) not only connected the I2C bus (and ground) to the Arduino, but fed 3V power to it. The green circle is the usual serial/power Arduino connection – not used. I used some other adapter to get the TTL serial signals to the PC to see what was going on.

I could never get that to work, either. I suspect at some point I fried the TCS34725. I had to give up on this sensor to work on other critical parts. Boo.

Update from ~9/11/13: First Tiny84 slave To support several photo transistor sensors, I laid out a slave for Tiny 84. It has pads for the now standard 4 pin network ribbon cable plus small pads for the last 2 programming leads. Since I knew the analog inputs would be used for photo transistors, I included their pullups on the board. And since I realized the photo transistors would each be connected with a bit of 2 conductor speaker wire, I put a ground pad adjacent to each I/O line – an excellent idea. Here it is with the first 4 sensors. There’s also a discrete LED on another output pin.

The actual photo transistors were tiny surface mount gems from Electronic Goldmine. At only a couple of mm wide, they were about perfect to peek thru nearly invisible holes in the DH walls. Their downside is that they were old stock, and their leads were badly tarnished, making soldering a challenge. Even my magic Sal-Met flux barely worked. Scraping each tiny lead with an Exacto knife did seem to help.

Here’s that slave mounted to the back of one of two walls it’s controlling. Each wall has one of the photo sensors (green). Another output pin is driving a pair of red LEDs providing glowing eyes that sometimes peek into a grated window (red). The unconnected wire to the fireplace LEDs comes out a hole in the left wall in the picture. It’s driven by another slave in the basement.

More power! FET driver

The I/O pins on the Atmel chips are great for an LED or two, but are limited to a few tens of mA. For more power-hungry devices (like the fireplace LEDs, or the 100mA 5-chip UV LED that lights the ghost) we need more power.

The cheap, weirdly-packaged MOSFETs are perfect for the job. They’re good for 30V and several amps, with extremely low forward resistance. And since the gate is insulated, you can drive them with a logic level without even a series resistor like a bipolar transistor base would require. Here’s a little breakout with +5, gnd and a gate signal in on one side, and +5 and switched ground on the other. This one’s fitted with a 2 pin 0.1″ female on the output (color coded, of course).

More slaves!

The order of Tiny85s came in from Digikey (now $1.18 quantity 25), so I replaced the fried chip on one slave (plus another I subsequently blew out). I made up a second Tiny84 slave board, but I walked away from the reflow plate again! Fortunately, this one wasn’t as carbonized as the first, and works OK. One trace did delaminate later, requiring an emergency repair. After that was done, I potted the whole area in hot melt to reduce future problems with it.

Less noise! dumb servo…

A central part of the haunted dollhouse was having the door open magically. Bill hooked up a small servo in the basement right below the door with a piece of spring wire coaxial with both the door hinge pins and the servo shaft, and anchored to the servo horn and the door. The wire was thinner than ideal, but it basically worked.

To drive the servo from a slave, I tried a couple of servo libs. None worked well, so I ended up bit-banging the pulse width servo signal. The I2C lib TinyWireS_stop_check() function needs to be called continuously and frequently, so I put it in a loop using micros() to decide when to flip the output bit. That worked well, at least from a software perspective.

Update 9/17/13: On the road Rachel’s on the way to the NYC Maker Faire and I think a hardware symposium with the dollhouse. It’s not working very well (yet). 🙁

There are 3 photo transistors, but only one works. That one doesn’t trigger well with a flashlight from the outside (the design requirement), but sometimes triggers when it shouldn’t – probably from other lights in the dollhouse. Better aiming/shading would probably fix that. A second used to work, but somehow doesn’t any more. And the third registers with the icrepl tool, but I can’t see it from DH code. That one’s a total mystery.

The MOSFET drivers and fireplace and ghost UV LEDs work fine. There was another MOSFET driving a 12V boost converter to run Bill’s nice little chandelier, but that converter generated too much electrical noise and had to be abandoned.

The two WS2812 NeoPixel RGB LEDs light up their sconces nicely and do just what they should.

The Sparkfun MP3 Trigger board works, but is somehow flaky. It doesn’t always play the correct MP3 files. I can’t imagine how that can happen, and earlier on it worked perfectly. But its main problem was just locking up and refusing to honor further commands. I think that was primarily triggered by electrical noise from the servo.

While the servo had worked in unit testing, once the whole dollhouse was assembled, when the servo was triggered bad things happened on the network. The sound module lockup was a critical one, but other slaves did unexpected things as well. I put 10 or 20 uF caps at various places to quiet it down. First try was directly across the +5, gnd pins on the servo connector. Another was just plugged into one of the hubs to quiet the whole supply line. And another was soldered directly across the power pins on the Sparkfun module. None made significant difference. I don’t know (yet) whether the noise is on the supply lines or on the I2C bus. But it screwed things up big time.

It was with great regret that I unplugged the servo before handing the house over. No door opener! But at least the sound worked, and the rest of the house was more stable. I look forward to having enough time to troubleshoot that noise and fix it once the dollhouse comes back home.

Here’s the basement. There are five Tiny85 slaves there, plus network wires disappearing into the walls for two more Tiny84 slaves (green). The MOSFET drivers for the fireplace and UV ghost LED, covered in heat shrink, are circled in pink. The red SparkFun MP3 trigger’s 3.5mm output jack is accessible through the back wall (top of picture). The blue door servo sits glumly on the left under the door, with its cable disconnected. An ultrasonic distance sensor looks thru holes in the front wall (bottom of picture). And of course there’s the Duemilanove, with a little breakout to pick up the I2C lines on A4, A5 (with pullups) and power for the network hubs, and power in from a 2.1mm barrel connector in the back wall from a 5V wall wart.

Master software

Since the system is really controlled by the master, I tried to make its code as easy to work with as I could. I suspect there are C++ approaches that would be cleaner, but they’re not my friends yet.

There are 4 parts to the code:
– definitions of the inputs
– functions to operate the various output actions
– “rules” that define the input->action behaviors
– the main loop

The input section abstracts all the details of I2C addresses and physical I/O pin to register mappings. It provides an array of slave identities to be queried, and how to read each one’s input(s). It provides names to refer to each node with inputs. Example names are “doorbell”, “light1”. This code must be written with intimate knowledge of the slaves and what is physically wired to what.

The action functions abstract all the details of I2C addresses and registers for each output. They provide nice boolean options like “on” and “off” to whatever bizzare hardware implementation may be wired to the output. An action function may operate one or many physical output devices. These are the only code that writes to slave nodes. Examples are “rgbled1(color)” and “sound(trackName)”. Like the input section, writing this code requires intimate knowledge of the hardware.

The rules section consists of a function for each desired behavior. That code may look at one or more inputs on named slaves, global variables set by other rules or internal data, including timers. With logic based on the above, it can call one or more action functions or set internal or global variables. While complex functions require clever coding, adding new rules by copying and pasting simple rules like “if input 2 on slave “light1” is above 100, call “sound(HOWL)” requires only basic skills.

The main loop walks thru the array of slaves with inputs, reading and storing every input. It then runs every rule function, so the rules can operate on the latest input information. Then it loops – at a rate of many cycles/second.

Essentially there will be a unique master program for every physical implementation of the network.

There is of course work to be done. The inputs could be further abstracted for individual input pins. The rules might be simpler, and perhaps object oriented. The main loop needs to automagically know the names of all the rules instead of having each rule function manually added. While functional, it is still a work in progress.

Dollhouse doc

Since the dollhouse is going out in public, it should have a little one-page ‘about’ doc available. I wrote up the basics – with a link back to this post for gory details. The latest pdf and Word versions are here.

still lots more to do…

Posted in Tiny 85 stuff, Workshop 88 Stuff | Tagged dollhouse, I2C, SparkFun MP3 Trigger, Tiny85, TWI, Workshop 88, WS2812 | 7 Comments

AtTiny84 data logger

Posted on August 31, 2013 by Jim

(This is one of a pair of unrelated Tiny projects that seem to be going on in parallel. I don’t think I could have chosen two more confusable projects if I’d tried.)

From time to time I’ve wished I had a dedicated data logger. I limped by with various lash-ups, including using DTR on the serial port of a Windows 95 laptop (they had actual serial ports back then!) to sense current to the ejector pump over weeks to spot a leaky toilet.

The desire to log daily output from a small solar panel I hope to use in a tree-mounted security camera almost got me to make a logger, but it was the need to investigate the wind at the top of the Workshop 88 sign post (to see if a wind turbine there would work for a light for the sign) that finally tipped the scales.

I laid out a Tiny84-based logger. Of course it has a standard 6 pin ICSP programming header and a couple of input pins brought out. But for something that may be running for days or weeks at a time, it’s good to know what time it is. The “Tiny RTC” module with its DS1307 clock chip takes most of the board space. It’s held on 1/4″ off the board with stiff wires in a few of its various I/O pin positions. Looks funny but it should work.

RTC Module

The RTC module had been sitting around since long before I’d gotten around to making the logger. I tacked a couple of wires on for the I2C interface, found the “RealTimeClockDS1307” lib for Arduino, verified that I could talk to the module and that it worked, so I anticipated no problems. Wrong.

One interesting feature – that I didn’t expect on a Chinese cheapie – is the battery. Yeah, it’s a 2032, but not the usual kind: It’s a Li-ion rechargeable! The board has a crude charging circuit – a diode and 200 ohms to the 5V power rail. The sheet says it should run for a year on a full charge. Interesting.

Also interesting is that the battery is only to keep the chip running – not to allow any I/O. It needs 5V for that. I knew that by the time I laid out the board, so it gets power OK. What I didn’t anticipate is that 5V is a problem: To run a long time unattended, a couple of 18650 Li-ion cells is the battery of choice. But the module won’t run on that, so I can’t actually read the time from it – which was why it was there in the first place! Yeah, yeah, I could use a boost converter. But the next cheap RTC module I get will have a DS3231 – which will run on 3.3V – for a couple bucks more.

The DS1307 can provide a 1 Hz square wave output. I’ll try to use that on the ’84’s INT0 to at least get an accurate 1 sec interrupt. Of course even that output doesn’t really work without 5V to the module. Fortunately, part of the square wave output circuitry seems to be an open collector transistor to ground. With a 47K pullup, it seems to produce a useable logic level. Completely out of spec, but it might work.

The nice DS1307 lib I found for Arduino provides lots of features – including interactively setting the time and date. When I hooked it up initially, I set those, and thought I was done. Unfortunately, while rapping the module on the bench to knock solder out of the holes, the battery popped out. It didn’t occur to me until later that since the Tiny84’s TinyDebug Serial doesn’t provide any input, setting the clock now that it was soldered to the logger board could be a challenge! Not resolved yet. (It is now – see update.)

Oops – you wanted a debug output with that?

While I did bring a couple of ’84 input pins out to pads, I failed to consider that I’d need some debug output. The Tiny cores now contain the very nice (meaning small) output-only TinyDebug Serial lib – aliased in as Serial for chips like the 84/85 with no UART so it’s transparent! Unfortunately, the pin it uses is hard coded to PB0 (pin 2), and of course I hadn’t brought that one out. Fortunately there were a couple of unused pads under the RTC module, so I tacked a bit of #30 wire wrap wire over to one of those pads and ran an external wire from it (the brown/white one). If I were motivated, I’d replace the ribbon cable that brings out the I/O pins with another just 1 wire wider, but what I hacked in works. Of course it’s output only, so the nice clock-set stuff in the DS1307 lib won’t work, but I can probably get around that.

I2C/TWI on a Tiny

When I tried to load the DS1307 sketch on the Tiny, it wouldn’t compile. That was the first of lots of learning opportunities about “wire” libs for Tiny. The DS1307 talks I2C, which for real Arduinos is handled by the “Wire” library. The DS1307 lib I found hides that, and makes calls to Wire internally. Unfortunately, whatever Wire-like lib there is in the Tiny core isn’t completely compatible with the original Wire.

(The AtMega series of processors have full hardware support in the chip for I2C – and the Wire lib is written to use that. The Tinys don’t have the same internal hardware, so Wire won’t work. Tiny chips do however have USI hardware support – which can do most of the work for I2C. So Wire replacement libs for Tiny are written for that hardware. At least one version is called USII2C – an ugly name, but meaningful if you understand some of what’s going on under the covers. Of course there are lots of Tinys, and they don’t all have identical hardware, so what works on one… Ugh.)

OK – so I found a TWI lib for Tiny. (Two Wire Interface is the workaround name for what is essentially I2C – but Philips is fussy about that name.) That still didn’t work, because the DS1307 lib I was using makes calls directly to Wire. I can probably hack up a new version of the 1307 lib with calls renamed for the TWI lib. Or just find some 1307 code with more accessible library calls.

Serial EEPROM

The plan for storage for this round of data logger was to use some 8 pin serial EEPROMs I’ve had sitting around for some time. Unfortunately, I misremembered their packaging: I thought they were ordinary 300 mil wide DIPs, and laid the board out for those. After I couldn’t find the chips in my DIP collection, I eventually figured out that they were in fact SOIC SMD parts.

I found the chips in the SMD collection, but while the pinout is the same, the footprint isn’t. I’m hoping with some fancy soldering and bending of wires in the DIP holes, I can connect the the SMD parts and support them in mid-air. On the plus side, that hovering-style mounting echos the mounting of the RTC module, so at least it will all look like it goes together. Or look equally dumb.

Update 8/21/14: I finally got around to trying to use the SOIC-8 AT24C512s (probably for a future datalogger with a 3V RTC). Unfortunately, the EEPROMs only have a house number, so I don’t know what voltage they run on. I figured the easiest way to talk to one to try it out would be to mount it up to this old logger. Then I can see how low a voltage it will work at. (The ~3.0V bottom range of a Li-ion would be nice.) That will also let me make sure I can talk to it with a Tiny84. (That last part turned out to be hard.)

I followed the original air wire mounting plan. Thankfully, there was no mention of “pretty” in the requirement spec. From the Eagle layout, it looks like the bottom left EEPROM (right under the Tiny) I used is address zero.

I found an AT24C library that should talk to the EEPROMs, but it’s based on the Wire lib. Initial efforts to port it to use the TinyWireM lib that uses the USI hardware in the Tiny84 have been frustrating (read: unsuccessful). After running into the dreaded “relocation truncated to fit: R_AVR_13_PCREL against symbol `exit’” problem, at least I got it to compile and load by using E Reid’s Arduino 1.0.5 ERW version. Thanks Erwin! (I bought him a Pepsi.) But it still doesn’t work right. Now I get to figure out whether it’s something funny with a 24C512 (which I vaguely remember as an issue), or the board layout, or the chip, or the weird soldering…

Troubleshooting

I’m running a slightly modified version of the EEPROM test program (AT24c_cpp.pde – very similar to the lib name!) and getting Tiny Serial Debug output from the added brown/white wire to a TTL/RS232 board to a serial port on the PC. I see output, so that part works. (Latest – and working – version is AT24C_cppT2.)

I looked at the board layout, and SDA and SCL seem to be correct. Of course they also go to the RTC (and the ICSP header!). How about pullups? The RTC module shows 3.3K pullups on both lines, which should work for the DS1307, AT24C32 and all other devices on the I2C bus.

How about device addressing? Looks like all 2-wire serial EEPROMS use an 8 bit address like this: 1 0 1 0 0 A1 A0 R/W. Hmm – the RTC module has a 24C32 at address A1/A0=00. Since I chose the same address, those 2 will crash. Of course they should both behave the same, but that’s risky. Ah – but if the new 24C512 were just completely not working, the test program should at least work with the onboard 24C.

I soldered a couple of short wires to an unused serial EEPROM spot to bring out SDA/SCL and hooked it up to the USBeeSX logic analyzer. After some some struggles with the 2-wire serial decoder (SDA and SCL must both be high at the start of the window) I got it to decode the I2C bus going to the EEPROM. Powering the logger board from the ICSP was a bad idea – it messed with SDA/SCL (aka MOSI/SCK) enough that the EEPROM didn’t work (except once !?).

Bad hardware?

Fearing that somehow the 24C32 on the RTC board was confusing things, I wanted to set the ‘512 to address 01. Murphy was right in there though: If left unconnected, the address pins default low, so I couldn’t just disconnect one. I had to actually tie A0 (pin 1) high. Fine – I can use the pin1 pad from the next (unpopulated) chip spot. I could talk to it, but it still didn’t work right.

Bad software?

The USBeeSX has a nice ‘pulse width’ cursor feature, and while looking around with that turned on, I discovered the hi clock pulses were only about 1μs, for a clock freq of ~500KHz. The default/conservative I2C clock frequency is 100KHz, so I went looking around. Down in USI_TWI_Master.h (the lib BELOW TinyWireM) there was a line #define SYS_CLK 1000.0 // [kHz] Default for ATtiny2313 .
I changed it to 8000 for my 8MHz Tiny, but it didn’t help. Then finally in USI_TWI_Master.cpp, I found a hard coded CPU speed (F_CPU) set for 1MHz. Changing that to 8MHz slowed the clock down to 100KHz. (Since F_CPU is also in boards.txt for this board, maybe bracketing that with #ifndef F_CPU/#endif might make it work automatically. Or just removing the #define?) But it still didn’t work right.

I gave up on the original AT24C lib and made a modified version specifically to run on TinyWireM. I eventually abandoned the library completely and went with some local functions that write directly to Wire (modified, of course to use TinyWireM). I stared at USBeeSX waveforms a lot, learned more than I wanted about the details of I2C hardware protocol and probably other stuff I’ve blocked out. Blew DAYS on what I figured would be a one-hour test.

The problem

I finally learned that at least this chip needs a 2ms delay between writes. It works for a while without the delay, but then fails. Failure is just NACKs on writes. I spotted those NACKs with the USBeeSX’s decoded display. I’d even tried putting a 1ms delay in (maybe a day before I got it working), but it needs at least 2ms. So close…

So now the write/readback test sketch works with this chip at addr 01. I’ve run a couple of cycles of writing/reading all 64KB successfully. Now I can actually do the lower voltage limit test I started out to do days ago! Needs a way to show success/failure without a terminal (since there isn’t one near the bench supply). Made up a nice reset button with an LED that plugs on to the ICSP header, added a little code to blink once if OK, twice if readback error. Test time!

Results!

Running 5 or 10 cycles of writing 600 consecutive bytes and reading them back, I saw no errors down to 2.5V. At 2.4V the test reported errors maybe 1/3 of the time. Now this is only a sample of one, and could have been the best one of the lot, but these results give me pretty good confidence in the chips I have at least down to the very bottom of a Li-ion cell’s life. I’ll probably run a series of tests writing and reading back all 256KB of the final 4-chip logger at reduced voltages, but now at least I think if I build it it will work.

Using the DS1307-based RTC

I guess I learned my lesson with the serial EEPROM when I gave up on libraries and just used local functions writing to TinyWireM. After the first couple of DS1307 libs (written to Wire) wouldn’t work, I gave up and used local funcs writing to TinyWireM. Probably saved a couple of days doing it that way.

It’s a real violation/disappointment from the standard Arduino approach of “Just go find a lib somebody has already written for your chip and use it!” But I guess that’s the price we pay for using $1 chips that aren’t really supported.

Anyway, I got what I needed: A one-time sketch that sets the RTC, turns it on, and turns on the Square Wave output at 1Hz. Year, month, date, hour, minute are all just hard coded and will need to be changed each time the sketch is run. But that shouldn’t be often if the LIR2032 actually runs the clock for a year.

I’ve verified that the 1Hz square wave is available even if the DS1307 isn’t getting sufficient power (like < 5V), and that it goes to INT0 (pin 5) on the Tiny84. (While I put a 47K pullup on my board, it looks like there’s already a 3.3K pullup on the RTC module!) I haven’t tried to write anything that uses that interrupt yet. I can also confirm that you can’t talk to the DS1307 via I2C with just a Li-ion cell for power – you really need 5V.

So with its 64K of EEPROM and working 1Hz square wave, (and working – but useless at 3.7V – real time clock) this first datalogger is hardware complete and (with some suitable code) could actually be used for something. Yeah, that EEPROM is pretty fragile. Hmm – I wonder if I should just pot it in hotmelt glue?

Next version

This should become a new post, but from things I’ve learned recently, here are some thoughts/requirements for the next (the “real”) datalogger:

Tiny84 is fine – has lots of I/O
MUST run on 3V (bottom end of Li-ion discharge curve) including RTC (DS3231)
Use some of the nice new 0.1″ screw terminals I got recently
How about some female header pins for a daughterboard for some feature not yet imagined?
While the “standard” 0.1″ male pins would be an OK power-in connection, how about just putting a 2×3 female header on the battery leads that would plug directly into the ICSP header? (Or, I suppose, an adapter from a 2-pin 0.1″ male.)
Be sure to bring the TinyDebugSerial pin out. Probably a pair of pins with out and gnd.
Put a couple of LEDs on. Nice for poll indication, other stuff.
Include a switch/jumper for Enable Logging. After you’ve got the data, you don’t want to start overwriting it while you load the data dump sketch! Maybe alternatively have a one-time ‘armed’ flag in EEPROM.

Posted in Tiny 85 stuff | Tagged 24C512, AT24C512, data logger, DS1307, DS3231, Tiny84, TinyWireM, TWI, USI_TWI | Leave a comment

Boolean failure indications

Measuring leakage current

Possible improvements to test

Hacking a GFCI

My tester

Having my hand forced

I might not need/get to build this!

The problem

The first hack

Second hack

Circuit design

Success

Final product

Disassembly

Other stuff in the case

Lasers!

Power

Da loot

The setup

Cheap or cheaper?

Initial results

The Noisemakers

Two regulators

Tiny85 slave node

Too many N-wire interfaces

Oops # 1

Initial software

It’s a network!

More power! FET driver

More slaves!

Less noise! dumb servo…

Master software

Dollhouse doc

RTC Module

Oops – you wanted a debug output with that?

I2C/TWI on a Tiny

Serial EEPROM

Troubleshooting

Bad hardware?

Bad software?

The problem

Results!

Using the DS1307-based RTC

Next version

Recent Posts

Projects

Meta

Blogroll

Links