Computing stuff tied to the physical world

Archive for August 2009

JeeNodes now with 328

In AVR, Hardware on Aug 31, 2009 at 00:01

Starting now, I will be replacing the ATmega168 by the ATmega328p in all future JeeNode kits:


Twice the memory: 32 Kb flash, 1 Kb EEPROM, and 2 Kb RAM – and twice the creative fun!

Memory Plug design

In Hardware on Aug 30, 2009 at 00:01

Got some ideas about storing a bit more data than the JeeNode can handle by itself, so here’s a little plug for EEPROM memory chips:

Picture 4.png

There’s room for up to four chips, i.e. 64 .. 512 Kbyte total. Plenty for a bit of data-logging and for storing compiled sketches / code for remote nodes. Or you could push for new limits with a flash-based O/S :)

This uses an I2C bus: the 6-pin male header on the right plugs into a port and is wired-through to the 6-pin female header on the left, just as with the Expander Plug described a few days ago. The width of this board has been increased so that it can’t be mistaken for a dual-port daughterboard.

Ok, so much for plugs… I need to re-check and finish each one and get a few prototype boards made!

Clock Plug design

In Hardware on Aug 29, 2009 at 00:01

The obvious plug, given that I2C is so easy to do now, is a real time clock based on the DS1307:

Picture 2.png

I’m using a small battery since a CR2032 coin cell is so… large. This board has a 12mm holder – with a 48 mAH BR1225 battery the RTC will run for some 10 years according to Maxim.

As with several of these plugs, boards like the above come a dime a dozen. It isn’t very hard to do – but once you’ve got a convention for pinouts and a physical layout that works, having such boards becomes a great time-saver. Particularly when daisy-chaining I2C plugs.

Thermo Plug design

In Hardware on Aug 28, 2009 at 00:01

The plug rage continues … this is a plug to measure temperature with either a thermocouple or an NTC resistor:

Picture 1.png

The chip is one of the AD594 .. AD597 series for use with J / K type thermocouples. With an NTC, the chip and 2 caps should be omitted, with a pull-up resistor added instead.

The other I/O pin is used for a piezo buzzer. It is driven via an NPN transistor with the positive lead connected to PWR to increase the volume. An alternate use for this pin + transistor is to control a relay or an opto-isolated triac.

Depending on the parts used, this might make a nice plug for a JeeNode-powered reflow controller. Or a temperature-controlled aquarium / soldering iron / 3D extruder / whatever. Or up to four overheating sensors, when used with multiple ports.

Expander Plug design

In Hardware on Aug 27, 2009 at 00:01

Here’s a design for a little 8-bit “Expander Plug”, based on I2C:

Picture 1.png

This uses the PCA9674 expander chip (PCA8574 would also work).

The connector on the left plugs into a port. The one on the right is wired-through to allow daisy-chaining a few of these plugs (or other I2C plugs). There are solder pads to assign one of four I2C address ranges to each plug.

The I/O lines are brought out on a 2×5-pin male header, including ground and optional PWR. This can be used with a standard 10-wire ribbon cable connector, though I’d place the plug near where it is needed and use a 6-wire connector between the JeeNode port and this plug in most cases.

This plug can also be used to attach a standard LCD module. There’s even a spare pin which could be used to drive the backlight on and off through a transistor. This plug will require a small change to the Arduino’s LiquidCrystal library to re-route the I/O through I2C.

It’s a tight fit, I’ll probably make the plug slightly wider. The added benefit is that it can then no longer be plugged into two ports by accident. I’m still undecided on the 2×5 header, but haven’t been able to come up with a more convenient choice. Suggestions?

As bonus, here’s a trivial plug with two LEDs and two push buttons:

Picture 3.png

By switching I/O pin directions briefly we can read out both button states, so this trick allows using a single port as 2 inputs plus 2 outputs.

Room Plug design

In Hardware on Aug 26, 2009 at 00:01

I’ve started work on a plug for the room sensor nodes, since it’s too tedious to wire up lots of them by hand.

Meet the 20x21mm “Room Plug”:

Picture 1.png

It has room for an SHT11/SHT15 type temperature / humidity sensor, an LDR as light sensor, and one of two types of PIR motion sensor. There are two positions for the LDR, depending on which type of motion sensor is being used.

In normal use the plug will be fully populated and placed as a bridge over ports 1 + 4 (or 2 + 3) of a JeeNode or JeeLink, but it’s also possible to only mount one or two sensors and – depending on which sensors – to plug the board into a single port, pointing upwards. Or even to use it as breakout board for a standard Arduino, or any other setup you like for that matter.

I’m going to look into a few more plug ideas before having prototypes made, to reduce cost a bit since these plugs are so tiny. Many sensors are not really worth a custom-made board, since the generic JeePlug will let you hook up most of them yourself. But having said that… if you’ve got suggestions for a hookup which would be really cool to have as ready-made plugs, let me know!

Sensor data coming in

In Software on Aug 25, 2009 at 00:01

There are now a few sensors installed around the house. The only inconvenience is having to run a low-voltage power line to these units. I’ve reduced the number of wall plugs (and the number of wall outlets “consumed” by them) by putting two sensors on a single power supply and placing them close to each other where possible, i.e. on two sides of a wall, overlooking adjacent rooms.

Also added a new graph page to the JeeMon web server to view all readings added to the database:

Picture 4.png

To give you an idea of what’s involved in producing this graph, here’s the “try-rooms.html” definition file for it:

Picture 3.png

It’s written in the Tcl language, using my own “rig” template mechanism to generate HTML pages. The actual graph is drawn in JavaScript by the “Flot” package.

RJ11 daughterboard

In Hardware on Aug 24, 2009 at 00:01

For connecting the JeeNode to a bunch of opto-sensors to track energy, gas, and water consumption, I’m thinking of using RJ11 telephone cables. Not only is the 4-wire version of these cables easy to get and cheap, you can in fact get two cables by cutting them in half and connecting the loose wires to whatever you like.

Here’s a daughterboard idea which would make it very easy to use JeeNodes for such a setup:


This is a mockup – the pin distances do not fit the 0.1″ proto-board grid, but you get the idea. Should probably add a power-on LED as well.

The power jack makes it easy to attach any standard 4..12 V power adapter. The 6-pin FTDI connector on the side is only for re-programming the unit – it can be omitted if you flash the ATmega with the proper code before inserting it into its socket.

I’m not sure what to do about mounting such a unit, though…

Update – The term “RJ11” is not quite accurate. It’s a 6-pin socket (RJ12), which could be used either with 2 (RJ11), 4 (RJ14), or 6 (RJ25) wires connected, as described on this page, for example. So it’s more like an RJ12 daughterboard, for use with RJ14 or RG25 cables.

JeeLink issues solved

In AVR, Hardware on Aug 23, 2009 at 00:01

It turns out that there were two problems with the new JeeLink boards, one major and one minor.

The reason why my assembled JeeLinks wouldn’t show up as USB devices is that the FTDI chip’s TEST pin was left floating instead of being tied to ground. It’s trivial to fix: a small dab of solder between pins 25 and 26 of the FTDI chip does the trick. Now all but one of my 6 JeeLinks show up as USB devices – yeay!

The second problem is not as critical: the +3.3V pin of all ports isn’t actually connected to anything… whoops. But this too is relatively easy to fix – a small wire from the VR output to the +3V pin on port 2 will fix it.

Thanks to Paul Badger of Modern Device and Marius Kintel for helping out and coming up with suggestions. I’m regaining my sanity now…


In the coming week, I’ll send out new JeeLinks to everyone who pre-ordered these units. I’ve run out of SMD LEDs, so I have to replenish my (limited) supplies before assembling and testing more boards.

But rest assured, they work and pass all tests. There are several JeeLinks on my desk right now, each of them running as intended.

To celebrate this milestone, all JeeLinks will be shipped with ATmega328’s instead of 168’s – including all the pre-ordered units.

Update – the above two issues and their fixes have been documented here.

Lots of nodes

In AVR, Hardware on Aug 22, 2009 at 00:01

I’m gearing up to install over half a dozen nodes around the house to monitor temperature, humidity, light levels, and to detect motion:


The plug at the bottom is a one-off to check out the connections for the EPIR version.

These are my last JeeNode v2 boards, salvaged from various experiments, with all their port headers replaced by the new 6-pin-female-up standard.

Given that these are v2 boards, I’m hand assembling the plugs to match the “old” port pinout. Beyond these, I’ll use the new v3 boards with a little pcb “room plug” to be created later.

Back to soldering a few more of these little sensor critters!

JeeLink status

In AVR, Hardware on Aug 21, 2009 at 00:01

The plot thickens… and I’m pulling my hairs out along the way.

The good news is that I have assembled 6 boards now, and they all behave in (nearly) the same way. The on-board ATmega is working and correctly running the blink test sketch installed when setting up the boot loader via ISP.

So the basics work. The voltage regulator is probably also ok.

The bad news is that none of these 6 boards is showing up as USB device. Whoops.

I’ve gone through a couple of build techniques, from reflow to hand-soldering, as well as various combinations. But after some obvious solder bridge removals and a few loose connections after hand-soldering, at least 5 of these boards exhibit identical behavior. I’m either getting it right or consistently doing something wrong.

Also found a problem in the PCB traces, i.e. a trace between 3.3V power and the 3.3V pins on all 4 ports is missing. But this is relatively minor – a tiny extra wire should fix that.

I’m at the point where I really need to step back to re-think what else could possibly be wrong. It must be some silly / stupid oversight… I’m still hopeful that the aha-slap-on-the-head-erlebnis will come soon.

Meanwhile, I’m also exploring some alternatives. Today, I visited a nearby “Fab Lab”, which has laser cutters, CNC routers, 3D-printers, and more such mind-blowing geek stuff. Absolutely fascinating – I’ll never look at an object in the same way again. Any object.

One of the things I wanted to try out is to create SMD stencils like the big boys do. A first trial on cardboard, paper, and 0.5mm polystrol came out as follows:


The layer on top was my first attempt, using thin cardboard. As you can see, it’s not quite perfect since the holes are too large – there is no vector adjustment for the 0.1mm laser beam overhead. Then again, the plain paper example in the middle shows decent separation, and having paste overlap is not necessarily a problem.

I’ll try some more adjustments next time and will get a bottle of paste with squeegee to play around with this stuff. Who knows, maybe even a 1-time use plain paper sheet can work?

CD drive as X/Y table?

In Hardware on Aug 20, 2009 at 00:01

(Warning: this post is a digression into robotic tools…)

I’m still struggling with the assembly of JeeLinks: after 4 attempts, none of my boards work and each with different results – not good :(

The answer is probably to have SMD stencils made to apply the solder paste evenly and in precisely the right spot. Manual parts placement with a tweezer is tricky but it seems to work ok for me.

But I’m hesitant. Stencils add a considerable cost overhead to each pcb run, and I’d like to be able to do lots of prototype runs in the future.

The other way to do this is to automate. Unfortunately, SMD machines are expensive – even the manual-assist or “semi-automated” ones are in the multi-$1000 range. And I don’t really need a CNC router with extreme precision or a 50x50cm work area plus a full 3D Z-axis. I just need to deal with printed circuit boards of say 3x12cm and position them within 0.2mm or so. Plus a reasonably accurate automated solder paste dispenser.

Hm. Wait a minute. That’s essentially the range of a CD/DVD drive: the tray comes out about 12 cm, and the laser inside moves about 3 cm. Why not take apart an old CD drive and mount the laser motion system on top of the tray and perpendicular to it?

Here is an old Philips drive I still had, disassembled:


Here is the drive, “reorganized” to perform X/Y positioning, with both actuators at the opposite ends of their respective travel:


Here’s another one from AOpen:


A close-up with the laser platform turned and on top of the tray:


The motors in both drives create a smooth and not overly fast motion when driven by 1.5 .. 3V, but the tray motor from AOpen draws much more power (about 250 mA).

The main idea is that such a setup can move the laser platform over an area of 3x12cm. But instead of turning on the laser, some sort of pcb holder could be attached to it so that the board is positioned. Then, all I need is a syringe mounted in a fixed spot over this X/Y table and some move-down-and-dispense mechanism.

Voilá – a dirt cheap automated solder paste applicator for small PCBs!

Given that there is no sideways strain, I hope that the tray/X-axis positioner (which has some slack) can be made accurate enough for solder paste by spring-loading it. The laser/Y-axis accuracy should be ample without much effort.

One problem with both drives is that they use linear motors instead of stepping motors, so there is no easy way of figuring out the current X/Y position.

Hm again. Could we somehow accurately measure the position of the X/Y table? Adding quadrature encoders to both rotating shafts would solve it, but that means hacking the mechanism – which I’d rather not alter. Not to mention getting suitably small encoders.

So here’s a second idea: the X/Y table positions the pcb, but perhaps it could also move around a bit of graph paper, attached alongside the board. And then… maybe an optical mouse could be hacked to detect the changes? Though I don’t know how hackable optical mice are. Another option might be to use IR proximity sensors, but that’s pushing it and would require precise calibration.

The third issue is the solder paste dispenser. Some sort of syringe, with the plunger tied to a servo, perhaps?

There’s a second, simpler, use for such a system: a PCB inspection system. Just place a loupe or microscope on top and meander the board underneath it.

I’ve even got an old Ikea drawer to fit the entire thing into:



I know, I know, it’s crazy. But still… ideas are cheap, and so far my materials cost is zero!

New home sensor setup

In Hardware on Aug 19, 2009 at 00:01

Here’s my new prototype for sensor nodes in the house:


It has an SHT11 temperature/hunidity sensor, an LDR, and a PIR motion sensor. Prototyped using a JeePlug, of course. Ports 2 and 3 are still unused. Note that this little board can also be plugged into ports 2/3 or even turned around – all configurations will work (by adjusting the port numbers accordingly).

Here’s a silly mounting option, which will have to do for now:


This setup is attached inside a bookshelf under the top panel, roughly pointed so the motion sensor covers the room. Not shown is the power connection from a 5..12V wall-wart (I’ll look into battery mode at a later date).

Totally crude, but it works and lets me easily detach the unit between tests.

Here’s another prototype based on old “plugs” I had lying around and a JeeNode v2:


The source code for this is called “rooms” and replaces the older “pulse” sketch. It’s available here. It handles both configurations, i.e. the ELV PIR and the ZDOT SBC.

This setup will be used instead of the earlier “pulse” design described in these posts. If there is interest, I can design a little board for it handling either PIR module.

FS20 developments

In Hardware on Aug 18, 2009 at 00:01

Looks like the FS20 remote-controlled system from Conrad and ELV has gained a few new units. Here’s a 60-euro 2-channel power-strip, controlled from 868 MHz, hence also from a JeeNode:


Also a 42-euro repeater to get through multiple layers of reinforced concrete.

Great options to avoid having to deal with line voltages. Not ultra-cheap, but still.

The one drawback worth noting with FS20 is that’s it’s not replay-safe. If someone picks up these signals, they can re-send them at a later time, even from outside the house. This means there is essentially no security at all with this approach. But for things like lighting and office equipment, that’s probably not an issue.

LED polarity

In AVR, Hardware on Aug 17, 2009 at 00:01

Ok, first puzzle solved. I had the two 0603 LEDs reversed.

The silly part is that I had actually built a test rig to make sure this wouldn’t happen:


As trivial as it gets: a battery with a series resistor. By holding the SMD LED against two copper contacts it’s easy to check which side is which. Here’s a green LED lighting up:


Then I got confused and placed all the LEDs exactly the wrong way around – doh!

There are three copper pads. The middle one is PLUS, the other two are GROUND.

Ok, now the RX+TX LEDs blink a few times when plugged in. Onwards!

JeeLink build woes

In AVR, Hardware on Aug 16, 2009 at 00:01

Ok, I’m back. The Jee Labs blog resumes…

This first post is a progress report on the JeeLinks. Here are three partial builds (the bottom one has some hand-soldered parts, the rest use reflow soldering):


I had to remove some solder bridges from the FTDI chips, but apart from that everything looks pretty tidy now. The JeeNode-based reflow controller is working very nicely.

Here are a couple of extreme close-ups:





Unfortunately, I’ve not been able to get any of these boards working so far. The FTDI chip ought to be visible as a serial USB port, even if the MPU isn’t working properly, but it isn’t showing up.

I’m probably missing something but for now it’s bad news. I’ll continue debugging this, of course…