Computing stuff tied to the physical world

Posts Tagged ‘JeePlug’

Small Gravity Plug update

In Hardware on Sep 25, 2013 at 00:01

The Gravity Plug contains a BMA020 3-axis accelerometer from Bosch Sensortec, which is being replaced by a newer BMA150 chip. Luckily, it’s fully compatible in both hardware and software, so the GravityPlug implementation in JeeLib will continue to work just fine with either one.

But the new chip does have more features: you can override its calibration parameters and defaults, by changing values in a new EEPROM area added to the chip. That in itself is probably not too useful for simple setups, but the new chip also offers access to its built-in temperature sensor, so I’ve added some extra code and expanded the gravity_demo sketch to take advantage of that:

#include <JeeLib.h>

PortI2C myBus (1);
GravityPlug sensor (myBus);
MilliTimer measureTimer;

struct {
  int axes[3];
  int temp;
} payload;

void setup () {

    if (sensor.isPresent()) {
      Serial.print("sensor version ");
      Serial.println(, HEX);

    rf12_initialize(7, RF12_868MHZ, 42);

void loop () {
    if (measureTimer.poll(1000)) {
        memcpy(payload.axes, sensor.getAxes(), sizeof payload.axes);
        payload.temp = sensor.temperature();

        rf12_sendNow(0, &payload, sizeof payload);

        Serial.print("GRAV ");
        Serial.print(' ');
        Serial.print(' ');
        Serial.print(' ');

Here is some sample output:

GRAV 2 -10 130 41
GRAV 0 -9 133 41
GRAV 4 -14 127 41
GRAV 0 -12 134 41
GRAV 4 -15 130 41
GRAV 4 -13 129 42
GRAV 3 -8 128 41

The reported temperature is in units of 0.5°C, so the above is reporting 20.5 .. 21.0 °C.

Unfortunately, the old chip isn’t reporting anything consistent as temperature:

GRAV 51 -31 -225 2
GRAV 50 -29 -225 0
GRAV 51 -30 -224 1
GRAV 52 -30 -227 1
GRAV 51 -30 -229 1
GRAV 52 -31 -223 2
GRAV 51 -31 -225 1

I have not found a way to distinguish these two chips at runtime – both report 0x02 in register 0 and 0x12 in register 1. Makes you wonder what the point is of having a chip “ID” register in the first place…

Anyway – in the near future, the Gravity Plug will be shipped with the new BMA150 chips. It should have no impact on your projects if you use these accelerometers, but at least you’ll be able to “sort of” tell which is which from the temperature readout. Note that the boards will probably still be marked as “BMA020” on the silkscreen for a while – there’s little point in replacing them, given that the change is so totally compatible either way…

Meet the Color Plug

In Hardware on Dec 4, 2012 at 00:01

Yet another plug designed by Lennart Herlaar:

DSC 4291

It contains the TAOS TCS3414 color sensor. JeeLib now includes a new ColorPlug class which simplifies reading out this chip, as well as a colorDemo.ino sketch:

Screen Shot 2012 12 03 at 15 17 47

Sample output:

Screen Shot 2012 12 03 at 14 03 40

One nice use for this sensor and code is to determine the color temperature of white light sources, such as incandescent lamps, CFL’s, and LED’s. I’m trying to find a pleasant replacement for a few remaining warm white halogen lights around the house here and such a unit (especially portable) could be very handy when shopping for alternatives.

Hardware description in the Café to follow soon, as well as in the JeeLabs shop.


Meet the Precision RTC Plug

In Hardware on Dec 3, 2012 at 00:01

Here’s another new board, the Precision RTC Plug – this is is a revision of a design by Lennart Herlaar from almost a year ago – my, my, this year sure went by quickly:

DSC 4292

The current RTC Plug from JeeLabs will be kept as low-end option, but this one reduces drift by an order of magnitude if you need it: that’s at most ≈ 1 second per week off over a temperature range of 0 .. 40°C. Or one minute per year.

Drift can go up to twice that for the full -40 .. +85°C range, but that’s still one sixth of the crystal used in the original RTC Plug. Considerably better than this, in fact, if you need the extended temperature range. Here’s a comparison between both plugs, from the datasheet:

Screen Shot 2012 12 02 at 12 58 23

The way the Precision RTC works is with a Temperature Compensated Crystal Oscillator (TCXO): once a minute, the approximate temperature is determined and the capacitance used by the crystal oscillator is adjusted ever so slightly to try and keep the 32,768 Hz frequency right on the dot. Since the chip also knows how long it has been running, it can even apply an “aging” correction to compensate this small effect in every crystal.

The temperature can be read out, but it’s only specified as accurate to ± 3°C.

No need to use any special software for this, all the normal clock functions are available through the same code as used with the original RTC Plug. If you want to use fancy functions, or perhaps calibrate things further for an even lower drift, you can access all the registers via normal I2C read and write comands.

The board will be added to the shop in a few days, and the wiki page on the Café updated.

Gravity + Pressure + GLCD

In Software on Jun 2, 2012 at 00:01

For those interested in the above combination, I’ve added a little demo combining the Gravity Plug, Pressure Plug, and Graphics Board – oh and a JeeNode of course (it’s actually an experimental JeeNode USB v4 …):

DSC 3310

The display shows the current X, Y, and Z accelerometer values as raw readings, plus temperature and pressure:

DSC 3313

Both plugs use I2C, and could have been combined on one port. Note that the backlight is off in this example.

The sketch is called – somewhat presumptuouslyglcd_imu.ino. And it’s now on GitHub, as part of GLCDlib:

Screen Shot 2012 05 29 at 13 33 02

The GraphicsBoard class extends the GLCD_ST7565 class with print(…) calls and could be useful in general.

Get the GitHub version to see the details – omitted here for brevity.

Analog Plug readout

In Software on Apr 13, 2012 at 00:01

The analog plug contains an MCP3424 4-channel ADC which has up to 18 bits of resolution and a programmable gain up to 8x. This can measure microvolts, and it works in the range of ± 2.048 V (or ± 0.256 V for 8x gain).

However, the analog_demo example sketch was a bit limited, reading out just a single fixed channel, so I’ve added a new AnalogPlug class to JeeLib to simplify using the Analog Plug hardware. An example:

Screen Shot 2012 04 01 at 21 10 25

This interfaces to an Analog Plug on port 1, and uses 0x69 as default I2C device address. There are a number of ways to use this, but if you want to read out multiple channels, you have to select the proper channel and then wait for at least one conversion to complete. Since conversions take time, especially at 18-bit resolution, a delay() is needed to get proper results.

Sample output:

Screen Shot 2012 04 01 at 21 18 18

I tied a 1.5V battery to channel 1 and left the rest of the pins unconnected. Touching both battery pins lowers the voltage briefly, as you can see.

These results are in microvolts, due to this expression in the code:

    long uvolts = ((adc.reading() >> 8) * 1000) / 64;

Here’s the reasoning behind this formula:

  • the reading() call returns 32 bits of I2C data, but we only need the first 24 bits
  • of these 24 bits, the first 6 will simply be a sign-extended copy of bit 18
  • the top of the measurement range is 2.047 Volts, i.e. 2047 millivolts
  • but we want to report in terms of microvolts, so we multiply by 1000
  • only 11 bits are needed to represent 0 .. 2047 mV, the remaining 6 bits are fractional
  • so we shift right by 6 bits (i.e. divide by 64) to get the actual result

It’s a bit convoluted, but as you can see, the measured value comes out as about 1.477 Volts, with a few more digits of resolution. If you do the math, you’ll see that the actual “step” size of these measurements is 1000 / 64 = 15.625 µV – and it drops to under 2 µV when used with 8x gain!

With this sort of precision, electrical noise can easily creep in. But it’s pretty neat: 5 digits of precision for 4 channels, with nothing more than one teeny little I2C chip.

Latching relays

In Hardware on Jun 22, 2011 at 00:01

The traditional relay looks like this (thank you Wikipedia):


A spring pulls on the vertical lever on the right (above its pivot), keeping the contact pushed agains the “NC” contact – hence the name: normally closed.

An electromagnet can pull the (iron) lever towards the left, against the “NO” contact – i.e. normally open, but closed once the electromagnet is powered.

Great invention. Perhaps the first example of electric amplification: using a small amount of electricity to switch a potentially much larger voltage or current.

For ultra-low power devices, ordinary relays have a drawback: you have to keep them energized as long as you want to keep the “NO” contact closed. With the Relay Plug, things are no different – the latest relays used on it have a coil resistance of about 125 Ω, and each of the two requires 40 mA @ 5V to stay “on”:

Dsc 2591

That amount of current consumption is not so convenient with batteries – when turned on, they wouldn’t last more than a day or two on a bunch of AA batteries.

Fortunately there’s an alternative, called a “bi-stable” or latching relay. It uses two coils to move that lever back and forth, with weak magnets in the relay set up in such a way that they’ll stay in place without using a spring as counter-force.

The benefit is that latching relays don’t need any power to stay in their current state (be it open or closed), you only need to give them a pulse to change their state from ON to OFF or from OFF to ON.

There are actually two types of latching relays:

  • dual coil, usually with a common pin which should be tied to ground
  • single coil, where changing the state is done by applying reverse voltages

Most dual coil latching relays can also be used in single-coil mode, by simply leaving that common pin floating.

In principle, the circuitry for a dual-coil latching relay is simple: you just need two relay drivers and then turn one or the other on briefly to make the relay change its state. The point being that you only need to pulse them very briefly, 10..100 msec should be enough.

Unfortunately, the Relay Plug isn’t usable for bi-stable relays, because it assumes a common PWR pin, not GND. It turns out that these relays are polarized. Thinking about this a bit more, this is actually quite logical: the force of the little latching magnet(s) need to be overcome with a magnetic field with a specific opposite orientation.

But there’s a surprising way out…

With single-coil plugs, the trick is to let current flow in different directions to set or reset the relay. IOW, either connect one pin to PWR and the other to GND (briefly), or vice versa. Hm, that sounds awfully like running an electric motor forwards or backward…

Now here’s the trick: instead of a Relay Plug, use the DC Motor Plug!

Dsc 2310 Large

It contains two H-Bridges which are intended to control two small DC motors (or one stepper motor), allowing them to run in either direction.

You even get 4 additional general-purpose I/O pins thrown in…

Now, instead of hooking up a motor, just hook up a relay, and only pulse the power briefly (by making both sides GND or PWR the rest of the time). With as added benefit that the DC Motor Plug will support two latching relays, and being an I2C device, it’ll also allow daisy-chaining with other I2C plugs.

Note that the chips used on the DC Motor Plug require at least 4.5V to operate, according to the data sheet. Maybe a slightly lower voltage will work – I haven’t tried it.

Update – DC Motor Plug is confirmed to work. The 5V relays I was testing this with appear to switch reliably with pulses down to 4 ms, using this test code (modified from the dcmotor_demo.pde) sketch:

Screen Shot 2011 06 22 at 16.33.58

Controlling the Dimmer Plug

In Hardware, Software on Jun 11, 2011 at 00:01

The Dimmer Plug contains an I2C chip which can control the brightness of up to 16 individual LEDs using hardware PWM. The advantage over the ATmega’s PWM is that there is no limitation to use only the DIO2, DIO3, or IRQ pin (the only ones which support hardware PWM), and of course that 16 individual LEDs can be controlled. In fact, since there are 3 solder jumpers, up to 128 LEDs can be controlled from a single I2C port (by daisy-chaining eight Dimmer Plugs).

Note that the output of the Dimmer Plug is only suited for driving single low-power LEDs with a series resistor. The default setup assumes that these LEDs are tied to 3.3V or 5V. For higher voltages and higher power, additional driver circuitry must be added (transistors, MOSFETs, or the ULN2803 8-wide driver, for example).

Here’s a demo setup:

Dsc 2559

(it’s not visible here, but the test LED has a 470 Ω resistor in series)

Although software PWM can handle more I/O pins, that does place a fairly high load on the ATmega, and the dimming takes place at a much lower frequency, which can be visible to the naked eye (and quite annoying).

The disadvantage of the Dimmer Plug is that it’s based on a fairly complex chip, the PCA9635. I’ve extended the DimmerPlug class in the Ports library a bit further to make it somewhat easier to use.

There’s also an updated dimmer_demo.pde sketch:

It exercises several of the PCA9635’s features:

  • all 16 output are set to maximum brightness
  • the “group blink” mode is enabled, using a specified blink frequency and blink duty cycle
  • the sketch waits 10 seconds, while blinking
  • the chip is reset to its default “group dimming” mode
  • then gradually make all channels dim at the same time
  • and lastly enter a loop, which illustrates how to do per-channel dimming

The setMulti() call takes a start register number, then a variable of arguments 0..255, and then a “-1” value to mark the end. It is shorthand for calling setReg() with successive register values, but more efficient.

The code in loop() does some tricky bit fiddling. Figuring out what it does is left as exercise for the reader, but you can simply ignore it if you don’t care about such trickery. The main thing to note is that indiviudal LEDs can be controlled by setting their corresponding register: dimmer.PWM0, dimmer.PWM1, …, up to dimmer.PWM15.

As you can see, the PCA9635 can control individual outputs, but also several outputs combined via the “group” modes. There are other options, i.e. only controlling a subset of the outputs in group mode, inverting the output signal, using open-collector mode instead of the default totem-pole configuration, and more. You will need to go through the datasheet (PDF) to take full advantage of all this. All registers in the PCA9635 can bet read and written using the getReg() and setReg() calls, respectively.

But for simple uses, the above should be sufficient!

Funky plug

In Hardware on May 27, 2011 at 00:01

What is this thing?

Dsc 2533

Maybe you can guess from the other side?

Dsc 2534

Simple – it’s a funny kind of DIP switch, to manually configure 4 input pins as needed:

Screen Shot 2011 05 25 at 13.17.43

When used with internal pull-ups, this causes each switch to pull an I/O pin down when latched in the top position (as indicated in parentheses).

Works on any pair of ports and in any orientation, of course – but then the pin assignments will be different.

Relays at last

In Hardware on May 2, 2011 at 00:01

It has taken months to settle this issue, but I’m happy to report that the supply problems are all over now… the Relay Plug board has been redesigned to accommodate a slightly different model:

Dsc 2488

Still fits, still same size. And still rated 5A @ 250 VAC.

The coil resistance is 125 Ω, which means each of the two relays will draw 40 mA @ 5V when closed. Slightly more than the previous model, but well with the specs of the on-board relay drivers.

The point of it all is that these new relays have a major distinguishing feature: I’ve got them in stock, at last :)

For the record: first an order for the original units was postponed from January to May, then a second order with another supplier was pushed back to June when they told me the stock listed on their website was grabbed by someone else moments before me…

All is well again now. End of story. Well… until the next supply issue pops up, anyway!

OOK fix

In Hardware on Feb 10, 2011 at 00:01

Here’s a great suggestion from Stefan Schulze (“kami” on the forum) for getting that wrong 433 MHz transmitter working with the OOK 433 Plug:

Img 5951


Img 5950

It requires some pin-bending, and you can attach an optional antenna, as he did.

I’m currently discussing option with the supplier to find a more “official” solution, but if you want to use the OOK plug right now, the above is definitely an option.

Thanks, Stefan!

Update – For everyone who received the OOK 433 Plug in its current form: I will send a solution out to everyone once it has been worked out. If you don’t need the TX side immediately, it might be an option to postpone soldering it until that solution is available.

Update #2 – Problem has been resolved, the OOK Plug is now supplied with the correct 3-pin transmitter.

OOK Murphy

In Hardware on Feb 8, 2011 at 00:01

Looks like there is a problem with the OOK 433 Plug

Here’s the transmitter I started out with:

Dsc 2455 2

Here’s the print layout I designed, based on that:

Screen Shot 2011 02 07 at 20.36.25

Everything worked fine. So I ordered larger quantities, to be ready for production. Here’s what I got in that new batch order:

Dsc 2455 3

Whoops… different unit!

Worse still, the original board had +, Gnd, Data as pins (as seen on the board layout), whereas the new boards have Data, Gnd, +, Antenna. It would be possible to cut the antenna pin off, but that’s not enough since the pinout is in fact reversed!

I’ve contacted the supplier. Let’s see how this goes. For the time being, I’m forced to take the OOK 433 Plug “off the shelf”. Sorry about that – please hang in there, also if you’ve already ordered this plug. Note that this only affects the 433 MHz transmitter – the 433 MHz receiver should work just fine.

New OOK and DCF relay

In Hardware on Jan 29, 2011 at 00:01

With all the pieces finally in place, and now that I’m getting a little bit more time to hack around again, this seemed like a good time to reconsider the OOKrelay.

So I combined a JeeNode USB, the new OOK 433 Plug, a Carrier Board with box, and half a Carrier Card:

Dsc 2429

In the top left I also added a DCF77 receiver from Conrad, attached to the Carrier Card prototyping board. It’s a bit hard to see, because the little receiver board is actually mounted upright. Here’s a better view:

Dsc 2430

A JeeNode USB was selected, because this thing will be powered permanently, and I chose to hide the connector inside the box to make it more robust. So all this needs is a little USB charger. The LiPo charge option might be useful if I decide to make this thing more autonomous one day (i.e. to record accurate power outage times).

Note that this is a modded JeeNode, as described here, to be able to receive 868 MHz OOK signals.

So what this thing can do – as far as the hardware goes – is listen for both 433 MHz and 868 MHz OOK signals at the same time, as well as pick up the DCF77 atomic clock signals from Frankfurt. Sending out 433/868 MHz OOK is possible too, but since the unit isn’t constantly listening for OOK packets, it’ll have to poll for such commands, which will introduce a small delay.

That’s the hardware, i.e. the easy part…

The software will be a lot more work. I’m going to adapt / re-implement the functionality from the OOKrelay sketch, i.e. this unit will decode and re-transmit all incoming data as RF12 packets, so that they can be picked up by a JeeLink hooked up to my PC/Mac. The clock signal will be useful to accurately time-stamp all receptions, and is really of more general use.

So far, the following I/O pins have been used:

  • one port for the OOK 433 Plug, i.e. one DIO and one AIO pin
  • one input pin for the modded JeeNode, to receive 868 MHz OOK signals
  • one input pin for the DCF77 signal

There is still lots of room left for expansion. A Pressure Plug perhaps, to track barometric pressure. Or a Memory Plug to save up the last data while the central receiver is unavailable. Or both, since these can combined on a single I2C port.

Absent from all this, is a display. First of all, squeezing a 2×16 LCD in there would have been very tight, but more importantly, now that there is a JeePU, there really is no need. I’m already sending the info out by wireless, so a remote graphical display is definitely an option – without PC – or I could use a central server to get this info to the right place(s). This box is intended to be hidden out of sight, somewhere centrally in the house.

Only thing I might consider is a small LED near the USB cable, to indicate that all is well. Maybe… I’m not too fond of blinking LEDs everywhere in the house :)

Meet the OOK 433 Plug

In Hardware on Jan 28, 2011 at 00:01

After yesterday’s post about modding the RFM12B to receive OOK RF data, here’s a new option which goes the other way: add-on hardware for 433 MHz.

Meet the OOK 433 Plug:

This plug can probably be used without antenna, but adding one is bound to increase the maximum reception range (I haven’t done any range tests yet).

The receiver output is tied to the AIO pin, which must be configured as input on the JeeNode. The transmitter is tied to the DIO pin, to be used as output pin.

Both receiver and transmitter can be operated from 3..12V (I’ve only tested with 3.3V and 5V, so far). For the transmitter, I would expect the power output and range to increase with voltage, but even at 3.3V things seem to work quite well in both directions. There is a jumper to select between PWR and +3V as power supply, and there is an optional series resistor for the receiver output, which may be needed at higher voltages (normally, it can be omitted by closing that second jumper).

The reason for creating a separate plug is that it allows a single JeeNode to operate simultaneously on the 433 MHz and 868 MHz frequency bands. As suggested in the comments on yesterday’s post, a modded 868 MHz RFM12B can probably be made to receive 433 MHz OOK signals, but the receiver sensitivity is bound to be fairly low since the RF circuitry is really dimensioned for 868 MHz. Haven’t tried this, though.

There are several sketches which can be used with the OOK 433 Plug. To use the receiver on this board with little or no adjustment, try recv433_test.pde or ookRelay.pde. For tranmission, there is the send433_test.pde sketch.

I expect to combine and integrate code from the different OOK and relaying sketches in the near future, now that this plug has been created, but for now you’ll have to tinker with what’s available.

If you have suggestions (of better still: code or docs) for new protocol handlers to add and implement on a JeeNode, please let me know or share it on the discussion forum. It will interesting to see how many OOK protocols on 433 and 868 MHz we can figure out and implement, to make this all truly versatile for lots of different RF devices out there.

All code and docs are in the Café, with the OOK 433 Plug available from the shop, as usual.


Note – This server was down on Jan 28, from about 1:00 to 10:00 (CET). I’m investigating what happened.

Thermo Plug fix (v2)

In Hardware on Jan 26, 2011 at 00:01

Another day, another fix.

The Thermo Plug also had a problem with layout, as described in this weblog post a while back.

I’ve had a new batch of boards made which moves the thermocouple screw terminal slightly outwards to get it out of the way of the AD597 chip:

Screen Shot 2011 01 25 at 16.54.26

The sharp edges come from the fact that new plug designs are now placed differently on a panel, using routing along the longer side of the plugs.

All plug PCBs and all JeeNode types have boards using a “standard” 21.1 mm width. The new approach simply means that these widths are now more accurate – “across the board” one could say :)

I’ve also addressed the transistor pinout confusion by adding a “C” label next to where the collector pin is.

Again, small tweaks, but good to have them resolved. All Thermo Plugs sent out from now on will be this new “tp2” version (the old board has “tp1” on it).

Onwards, again!

Thermo Murphy

In Hardware on Jan 4, 2011 at 00:01

Mr. Murphy strikes again in the new year…

A post a while back, mentioned that the NPN transistor footprint on the Thermo Plug was wrong. I should have tracked this down earlier, but due to all the supply issues I only found some time just now (with thanks to Lennart for helping figure this one out).

Here’s the board footprint:

Screen Shot 2011 01 03 at 12.08.50

It’s not hard to see that from left to right, the pinout is emitter-base-collector.

Guess what… NPN TO-92 transistor footprints are not standardized!

Here’s the one from the BC549 I’ve been shipping in a few recent units:

Screen Shot 2011 01 03 at 12.06.16

Bzzzt… you have to mount it the other way around to make it work!

To give you an example of the mess w.r.t. orientation, here’s a diagram I found on Solarbotics:


And here’s the one from the 2N4401 I’m going to use for the Thermo Plug from now on:

Screen Shot 2011 01 03 at 12.05.37

Well, at least it’s just mirrored, with the base always in the middle. Not quite as bad as with voltage regulators (such as with MCP1702 vs LM2940, where the order is completely different).

If you’ve got a kit with the BC549, please make sure to mount that transistor 180° rotated w.r.t. what’s shown on the pcb. All units sent out from now on will have an NPN transistor which matches what’s on the board.

New wire jumpers

In Hardware on Jan 3, 2011 at 00:01

Just a quick note that the current Wire Jumpers in the shop are going to be replaced with new ones very soon:

Dsc 2407

Instead of 50 wires, the new pack will have 70 wire jumpers, consisting of the following length, in various colors:

  • 50x 80 mm
  • 10x 125 mm
  • 5x 165 mm
  • 5x 205 mm

Same flexible wire as before, with the same easy-to-insert pins on both ends.

No downsides, no compromises. Just more wires and more variations!

Meet the DC Motor Plug

In Hardware on Nov 30, 2010 at 00:01

Here’s a new I2C plug to drive two small DC motors. The DC Motor Plug has 2 H-bridges on board, which can drive each motor in forward or reverse. An additional 4 I/O pins are available, for limit switches, quadrature encoders, whatever:

Dsc 2310

Here is a test setup with a couple of (different) geared motors, driven from a 4x AA battery pack, plus the usual AA Power Board for the JeeNode itself (these could also have been combined):

Dsc 2309

All I/O is done via I2C, using the MCP23008 expander chip (same as used on the EP, LP, and OP plugs).

Here is a sample sketch called dcmotor_demo.pde which briefly drives each of the motors in both directions:

Screen Shot 2010 11 29 at 13.02.38

One notable detail about this plug is that it uses TC4424 chips which are in fact not DC motor drivers at all but MOSFET drivers… it turns out that these are also well suited for small DC motors, and should be able to handle up to 1.5A @ 4.5..18V.

A small bipolar stepper will probably also work, but I haven’t tried that yet. This board has a jumper to select between I2C addresses 0x26 and 0x27, so two of these can be daisy-chained on a single port.

Speed control should be possible using software PWM, but not at very high rates, since the I2C bus will be the limiting factor.

One use for this in the context of home automation would be to drive small highly-geared 12V motors to adjust the position and raising/lowering blinds.


Docs added to the café and kit in the shop, as usual.

Indoor temperature, etc.

In Hardware, Software on Nov 20, 2010 at 00:01

Here’s a fun little project…

A Graphics Board with a JeeSMD and two plugs: a Pressure Plug and a partially-populated Room Board.

The result is a geeky little indoor environmental monitoring station:

Dsc 2293

Couple of notes here:

  • I took the lazy way out and merely display the info as text, graphics would be so much nicer!
  • Both sensors can read the temperature, but as you can see, they don’t fully agree…
  • I added the FTDI hookup and used it to power this thing via an AA Power Board.
  • The AA board does double duty, as a little stand to hold this thing slanted upwards.

Adding FTDI was very useful in this case, since it also makes it possible to re-program the JeeSMD, which has no FTDI connector on board. All it needs is a 0.1 µF cap and the 6-pin header:

Dsc 2298

But there’s more to it than that, alas: to be able to upload to the JeeSMD, you need to hook up all the headers on the JeeSMD, i.e. also the PSI and the SPI/ISP headers. Adding those after the fact is very tricky, since you can’t reach the back of the Graphics Board pcb anymore if you soldered the LCD on permanently – as I did.

I had to solder the female headers slightly higher, to just barely reach the pins from the top with a very fine soldering iron tip (I use 0.4 mm). It worked, but as a result, the JeeSMD sits a bit higher on its pins than usual:

Dsc 2297

Here’s the indoor.pde sketch, also added to the Ports library:

Screen Shot 2010 11 17 at 22.47.37


Thermo Plug mismatch

In Hardware on Nov 18, 2010 at 00:01

The Thermo Plug was recently updated as a kit with a thermocouple for use as Reflow Controller, for example.

It uses screw terminals to connect the K-type thermocouple, because that wire can’t be soldered – I tried, really hard! Besides, you don’t want to add too many weird amalgamated cold metal junctions in this setup, which is all about the tiny voltage potential between different metals.

The whole thermocouple works nicely, but I goofed a bit on the connector: the screw terminal I got for this plug is slightly too big to fit on there in the intended position:

Dsc 2289

Yuck … two solutions:

  • solder it on anyway, and just ignore that tower-of-pisa effect…
  • solder it on the other way, and insert the thermocouple wires from the board side

Here’s how that will look:

Dsc 2290

Slightly odd, but it’ll work just fine of course.

Note that the back side of this screw terminal has two holes, but they cannot be used to insert wires, because those will end up too high and wouldn’t be held tight by the screws:

Dsc 2291

I’ll look around for a slimmer form-factor 3.5 mm screw terminal. If I can’t find any, then I’ll plan a board revision – but for now, it’ll have to do.

With a small nod to Mr. Murphy…

Meet the Infrared Plug

In Hardware, Software on Nov 12, 2010 at 00:01

The new Infrared Plug needed a small adjustment to work, but now it’s working properly. Here’s my hand-soldered prototype:

Dsc 2243

Fits on any of the JeeNode ports, of course. The DIO pin controls the IR output, which is pulsed at 38 KHz (38.28 KHz on my unit, more than close enough). The light is generated with one or two IR LEDs. With one LED, the peak current is ≈ 50 mA (a bit high for the AA Power board) – with two LEDs, the current is ≈ 10 mA. That will no doubt have a lower range, but you could tape one of the LEDs onto a specific appliance, while still letting the other one shine into the room (or a second device).

The input is a 38 KHz detector, with its signal available on the AIO pin.

The “InfraredPlug class” in the Ports library makes it easy to interface to this plug, as described in recent posts.

I’ve also added an “ir_repeater.pde” demo sketch, which repeats any NEC command it receives three times, at 1-second intervals. When I press “Forward” on my Apple Remote, it’ll end up skipping 3 extra songs forward. Can’t quite think of a use for that, but it helped me flesh out the bugs:

Screen Shot 2010 11 11 at 18.16.58

There is a bit of logic in there to convert the incoming slot count to a bit pattern.

Sample output:

Screen Shot 2010 11 11 at 18.16.51

The Infrared Plug is now in the café and the shop.

Almost, but not quite

In Hardware on Nov 9, 2010 at 00:01

There’s a new Infrared Plug in the works – it’s almost ready. The IR transmitter uses the venerable 555 chip:

Screen Shot 2010 11 08 at 20.36.42

I used the formulas from the datasheet to calculate the different resistor and capacitor values to arrive at 38 KHz, which is the most common IR frequency (and which most 36 and 40 KHz systems will pick up as well).

To check things out, I hooked the plug up for constant oscillation (DIO to +3V):

Dsc 2235

Despite using 1% parts for all the timing critical components, the output isn’t quite what it should be:

Screen Shot 2010 11 08 at 20.33.12

That’s 35.5 KHz … i.e. almost 10% off target!

(note that I measured the signal across the transistor – the IR current is actually the opposite, i.e. fast rise time)

I’ll have to tweak one of the resistors empirically (16.0 kΩ i.s.o 17.4 kΩ seems to fix it) and order some new SMD values. And then I need to check that the frequency across multiple plug builds will remain within bounds.

Not quite back to the drawing board (the PCB seems to be ok), but still: back to the soldering iron!

Better panels

In Hardware on Nov 6, 2010 at 00:01

While we’re on the subject of PCB panels…

All new plug panels are now made with a mix of V-scoring and routed slots:

Dsc 2194

The vertical lines are “V-scores” – small sharp cuts on both sides of the boards which makes it easy to break off the board at that point. Adds a few strips of waste, but the result is much cleaner.

The reason for this is that the sides come out better (and much more accurate) when routed, but you don’t want to route all four sides, because then you have to leave little break-off tabs to hold the boards. The problem is that these tend to break off with a very rough edge, requiring extra cutting or sanding to clean up.


Conquering the thermocouple

In Hardware, Software on Nov 1, 2010 at 00:01

(No Halloween stuff on this side of the pond – I’ll defer to Seth Godin for some comments on that…)

A while back, I had to shelve my experiments with the reflow controller, because I couldn’t get a reliable temperature reading from the Thermo Plug when using a thermcouple.

Or rather, sometimes it worked, sometimes it didn’t: the physical computerer’s equivalent of a nightmare!

The thermocouple circuit is very sensitive to ground currents, apparently. The effect was that my setup would work fine on batteries, but jump all over the place when attached to the USB port. Not very convenient for development, obviously.

It still has some unexplained behavior, but I’ve been able to narrow it down, so there are two new pieces of good news: 1) it only works badly while data is being transferred over the USB port, and 2) with some averaging, the readout is actually rock solid, both on batteries and on USB. I still see a difference in readout when data is transferred over USB, but since this is a JeeNode, I can work around that in the final version: go wireless!.

Here’s the readout code which produces good readings – all remaining jitter is now in 1/10’s of degrees Celsius:

Screen Shot 2010 10 31 at 18.48.10

The output is in 1/100’s of °C, because I’m trying to avoid floating point math in this sketch.

And here is the measuring side of my new reflow setup:

Dsc 2200

The thermocouple is taped to the thin aluminium insert in the grill using heat-resistant Kapton tape. When I turn on the heater, I now see a clear rise in temperature within seconds – perfect!

Note that I’m using a 4x AA pack i.s.o. 3x AA, because the AD597 needs at least 2V more on its supply line than the highest output voltage it is going to report. With 4x 1.2V (worst case, i.e. near-empty eneloops), the range will be at least 4.8 – 2 / 0.010 = 280°C, i.e. plenty!

And indeed, I’ve verified that at 250°, it reports valid temperatures on the attached LCD Plug w/ display.

The other plug you see in the lower left is a Blink Plug, with two pushbuttons and two LEDs.

Let’s see if this time around we can get the whole thing going properly!

Meet the new Opto-coupler Plug

In Hardware on Oct 29, 2010 at 00:01

The plug barrage continues…

This time it’s an update of the flawed Opto-coupler Plug, which only worked properly on one channel (unless you patched it up). So here’s the new Opto-coupler Plug v2:

Dsc 2185

Wait! There’s more! It’s actually two plugs in one now:

Dsc 2186

(note: the solder jumpers need to be shorted out to use this as an output board)

Since there was enough room on this board, I decided to make it more versatile: it can now be used as dual Opto-coupled input (as before) or as dual Opto-coupled output plug. In the latter case, the JeeNode drives the IR LEDs and the output is a phototransistor which can be used as low-power (polarized) switch for some external device. The choice is determined by how the IC socket and Opto-coupler are hooked up.

The connectors are the same as before: detachable screw terminals, these are very convenient because you can prepare the wiring elsewhere and then plug / unplug / swap channels as needed.

I have no immediate use for these plugs right now, but of course I had to make sure that everything is working properly, so I hooked both of them up:

Dsc 2190

On the back you can see how things were connected together:

Dsc 2191

Here’s the updated opto_demo.pde test sketch for that – I decided to send the results by wireless for a change:

Screen Shot 2010 10 28 at 18.11.23

Sample output on my central JeeLink:

Opto Output

Yippie – looks like it’s working exactly as intended! Note the inverted signals, BTW.

Docs and shop have been updated for this new plug version. If you have version 1, please let me know and I’ll send out an updated board to you.

Meet the Current Source Plug

In Hardware on Oct 28, 2010 at 00:01

Here’s another new plug, firmly in the realm of home automation: the Current Source Plug drives two independent channels of Power LEDs with either 350 mA or 700 mA current:

Dsc 2183

As you can see, this plug was a very tight fit. These are based on high-efficiency AP8803 switching power supply chips, which also explains the two hefty inductors on the board. The 2 I/O pins are used to control both channels, and can use PWM to dim the LEDs.

The connector on the bottom is for the LED power supply (sorry for the tight fit!), and can be 8..30V. According to the specs, you can have up to 5 power LEDs in series at 30V, so the highest power this plug can theoretically switch is 5x 3W-LEDs @ 700 mA per channel!

There are some thermal limits though, due to the high amount of power involved in this small board. It is best to keep the voltage differential between what the LED needs and the input voltage fairly low. The two 3.7V LEDs I tried worked fine at 6..12V, but the board started heating up quickly with more than 12V (at full power).

Here’s the test setup I used:

Dsc 2182

The big LED is set to 700 mA, the small one to 350 mA – for a total of 1050 mA output. The nice part is the efficiency of this thing: the board draws less than 1050 mA due to the “buck” switching design. I measured roughly 960 mA @ 6V and 490 mA at 12V. At 18V it heated up a lot, I did not dare take it any higher. The main use I see for this board is two channels, each with 1 or 2 power LEDs in series, driven from a 12V supply.

At full power, the board temperature rose about 40°C above ambient after an hour, i.e. roughly 60..70°C. Hot to the touch, but not scorching hot. When dimmed, temperatures immediately went down. Note that the LED lights themselves were hotter than the board. Power LEDs need cooling!

For PWM dimming up to 500 Hz, just use the I/O pins. I haven’t tried it yet, but this could be done with the same rgbRemote.pde sketch as used for the MOSFET plugs.

The documentation and shop have been updated with this new plug.

More goodies coming, stay tuned…

Meet the Heading Board

In Hardware, Software on Oct 26, 2010 at 00:01

Here’s another plug which didn’t work initially, but as always it was a simple mistake in the software (and a not-so-clear datasheet) which prevented me from using this thing:

Dsc 2157

The Heading Board is based on a somewhat unusual HDPM01 combination sensor by HopeRF, containing a 2-axis compass / magnetometer and a … temperature + pressure sensor. My interest in this thing was the compass, which is relatively low-cost compared to most other options out there.

There’s now a HeadingBoard class in the Ports library to make this thing sing. Note that it’s called a “board” and not a “plug” because it requires two ports and sits as a mini-board on top of a JeeNode (same as the Room Board):

Screen Shot 2010 10 24 at 17.39.20

This board is a somewhat awkward match for the ports concept, because it needs a 32 KHz clock to function. I’ve hooked that up to the IRQ pin, which is reprogrammed by HeadingBoard::begin() to generate that clock using Timer 2, so you may have to jump through some hoops to use this if other ports use the IRQ pin for a different purpose. A more general approach would be to generate the required 32 KHz on-board with an NE555, as is done in an upcoming Infrared Plug – but that requires extra board space (or components on both sides of the pcb).

Here is the “heading_demo.pde” sketch, now added to the Ports library as example:

Screen Shot 2010 10 24 at 17.40.20

Sample output:

Screen Shot 2010 10 24 at 17.17.02

I haven’t figured out the conversion from X-/Y-axis values to compass heading yet. There is some sensitivity to how the board is positioned horizontally – this could be compensated by detecting the angular position using a Gravity Plug. But as you can see, there is a clear variation in readings as I turned the JeeNode + Heading Board around the Z axis.

So if you’re into robots: a Heading Board plus a Gravity Plug is all you need to determine your absolute orientation in all the 3 axes in space, i.e. X, Y, and Z.


PS. Here’s a crazy idea: we could use the Heading Board to create a door-open sensor. Simply attach this thing to a door, and track the Z-axis orientation!

Meet the Proximity Plug

In Hardware, Software on Oct 25, 2010 at 00:01

The Proximity Plug was created a while back, but at the time I couldn’t get the chip to respond properly. Turns out that this was just some silly mistake in the code, so now all is well and ready for use:


This plug uses an MPR084 to support up to 8 capacitive touch sensors. These can be created in any shape you like, using some conductive board, film, or tape. There’s a solder jumper to set one of two I2C addresses, so up to 16 sensors can be hooked up to a single port.

Here’s a little test setup:

Dsc 2154

Capacitive sensing can be fairly tricky to get right – the sensors may respond slightly differently, cross-talk between each sensor, electromagnetic noise pick-up, etc. But this chip does a lot of the work for us.

There are many configurations settings, and I’ve only started to scratch the surface so far. The current setup is configured to only report a single touch at a time, and does auto-calibration on startup. I’m still seeing some cases where things lock up and may have to be reset (in software), so the interface class for this thing is very basic for now – simply giving acces to the individual registers from I2C.

Screen Shot 2010 10 24 at 13.01.33

I’ve added a “proximity_demo.pde” sketch to the Ports library to demonstrate the use of this plug:

Screen Shot 2010 10 24 at 13.10.36

It will print a message whenever a “key-press” is detected. The commented-out code prints out the following ID string extracted from the chip:


Note that the MPR084 chip wants a 100 KHz I2C bus.

One thing I’d like to try with this thing, is to create some input buttons with it using the Carrier Board box. It would be nice if the sensors can be made sensitive enough to reliably work with a bit of copper on the inside of the box, then you wouldn’t even have to drill holes or make any cutouts to be able to control what’s inside. Otherwise, perhaps a slit for adhesive / conductive copper tape, covered up with plastic foil?

More detective work needed…

Modular nodes, revisited

In Software on Oct 16, 2010 at 00:01

As pointed out in the comments yesterday, “nodes” in a WSN should to be more parametrized. With ports, it’s very easy to mix and match different sensors – creating nodes which are not all the same should be equally easy.

I’ve touched on a related topic before in a post titled Modular nodes.

Ideally, you want to write interface code for say a PIR motion sensor once, and then re-use it in different nodes. Same for an SHT11 temperature/humidity sensor, an IR send/receive sensor, a barometer, door switches, an OOK receiver, and so on – the list is bound to grow considerably over time.

Even “more ideally” (heh), you probably would like someone else to already have written that interface code, so you can just fill in the parameters and incorporate it into your own room-or-other node.

In fact, the whole (modular!) Plugs & Ports concept of JeeNodes is yearning for this type of modularity to be carried through to the software.

To achieve such modularity all the way through, several questions need to be answered:

  • are these interface code “snippets” always very small and self-contained, or do they need additional C/C++ source files?
  • can interfaces depend on other interfaces / is a class hierarchy the best way to modularize such dependencies and derivations?
  • can we have multiple instances of the same interface in a single node? (answer: yes, for example multiple door-open sensors, attached to different I/O pins)
  • how do we deal with a mix of interfaces which use different timing periods for readout?
  • how do we compose packets to send, if the information types vary?

One way to implement this modularity, is what I’ve been doing in the Ports library until now: define and implement C++ classes for each interface, and then create (static) instances of each interface needed in a particular node.

This is an extract of the Ports.h library header file:

Screen Shot 2010 10 15 at 21.54.25

It works – and I think it’s a decent start – but it doesn’t go far enough:

  • Many configuration parameters are variables (and data members inside C++ objects), even though they are essentially contant (the port number, an I2C device ID, I/O pin choices, etc). This eats up scarce RAM space, and prevents the compiler from fully optimizing the code. The “heavy” solution to this is C++ templates, as I’ve written about in threeolderposts. Trouble is: C++ templates are “viral”, once you start on that path, everything tends to become a template. Not my idea of simplicity…

  • I want to figure out what a good set of reporting periods is, to minimize the number of packets sent, for example. This task comes back with every type of node, so having some automated tool to help with that effort would be useful.

  • There can be severe resource constraints in low-power nodes. I’d like to see what the RAM and EEPROM (and FLASH) usage is when choosing a specific mix of interfaces. I’d also like to find out whether the interrupts can co-exist and still service everything sufficiently quickly. And I’d like to get estimates for battery life. None of this is impossible, even if unnecessary for a first implementation.

  • Implementing pin-change interrupt handlers is not easy to fit into C++ as run-time mechanism, even though for any given interface mix it is very simple to generate the interrupt handler code for it.

  • The result of a choice of interfaces is not just a sketch – it also implies specific packet structures, as used for getting data across. And indirectly, it also means there has to be something node-specific at the central node (not necessarily in that receiving node, it could be code that runs on an attached PC).

  • If the number of interfaces grows considerably, and if more people were to start implementing such interfaces, then the management and versioning of all these interface definitions (code, data, docs) needs to be addressed.

What this points to IMO, is the need for a “configurator” or “wizard” type tool, which knows about a large number of interfaces, and which produces a sketch when given a bunch of configuration choices. An even more convenient tool would let me manage my entire collection of nodes, so I can make most configuration choices once, and then manage all node definitions together. It’d let me add and update interfaces and nodes as needed, over time:

Screen Shot 2010 10 15 at 22.30.14

What comes out is still a C/C++ coded sketch, since that’s what needs to be uploaded to the node.

What should also come out (not included in the above diagram), are one or more packet structure definitions, as well as the code (or data definitions) needed to decode those packets again.

With this approach, you can pick the hardware needed for a specific node, enter your choices into the configurator, and be done with it. Upload the sketch it generated, turn the node on, and launch the central server with the information it needs to understand the new incoming data packets. For other nodes, or to make changes, simply rinse and repeat…

I haven’t decided yet whether I’ll actually go for this. It’s fairly ambitious, even for a simple first implementation. But it sure would scratch an itch of mine…

Relay Plug stocks

In Hardware on Sep 30, 2010 at 00:01

As it turns out, this slim-line relay (Conrad #504286, PCN-105D3MHZ) is not available until April 2011 (gasp!) … no matter where in the world I look:

Dsc 1813 2

Fortunately, there is an equally-slim replacement with the same footprint (thanks, Lennart!):

Dsc 2007

It’s a bit higher, and it handles a bit more current (up to 5A):

Dsc 2008

I’ve ordered a bunch of these, but I also need to get a new batch of PCB’s – didn’t want to order them without a chance of getting suitable relays (Conrad #502047). The new plugs won’t be here before mid-October. And the new relays are a bit pricier, so I’ve had to raise the price of the kit a bit.

Atoms, oh atoms … why can’t you be more like bits? As in: no stocks to worry about?

Opto-coupler doesn’t couple

In Hardware on Sep 27, 2010 at 00:01

It’s that time of year again… a mistake, courtesy Mr. Murphy: the recently-added Opto-Coupler Plug this time.

Triggered by a post on the forum, I created a little test setup. The idea is to feed some outputs in on one end of the plug, and then read them back out. First the outputs, using ports 3 and 4:

Dsc 2000

The plug itself is hooked up to port 1:

Dsc 2001

Here’s the test sketch (see opto_demo.pde):

Screen Shot 2010 09 26 at 15.55.52

What it does is toggle the ouput in all possible combinations, and then report the input signals it’s reading. Here is the correct output:

Screen Shot 2010 09 26 at 15.32.33

I had to create the EAGLE component for the MCT62, since it wasn’t available. Here’s what I made, using some existing part and modifying it:

Screen Shot 2010 09 26 at 16.29.27

Now if it were correct, then the Opto-coupler Plug would be fine. But it’s way off. Here is the datasheet pinout:

Screen Shot 2010 09 26 at 16.30.20

Silly me. The emitter is attached to “+”! – and the cap is also useless… there is no + on the chip, it doesn’t need a power supply.

I don’t know what I was thinking at the time, but it clearly doesn’t make any sense. The test setup I had on the breadboard worked fine, of course. It’s just that I went completely astray on the EAGLE design side of things. And then during the pcb test, I must have made a mistake and only tested one side.

Oh well. Fortunately there is a way to fix these plugs, but it ain’t pretty:

Dsc 2003

One copper trace from pin 8 on the bottom has to be cut, and a short wire has to be connected between pins 8 and 5 to attach the photo-transistor’s emitter to ground.

I’ll be fixing the (luckily small) batch of opto-coupler plug kits currently in stock here. And I’ll get new PCBs made ASAP – but this will take a few weeks, as usual.

AA power options

In Hardware on Sep 19, 2010 at 00:01

The new AA Power board is a pretty darn flexible little board, if I may say so myself. Its switch regulator draws very little current itself, 7..30 µA depending on the input voltage. The input voltage range is approx 1.0 .. 5.5V, to be able to start up, but it will drain the power source all the way down to 0.4V if it can, pulling every last bit of juice out of regular AA batteries.

But the AA Power board is also capable of providing a pretty decent amount of current when needed. This is essential for the on-board wireless radio of the JeeNode, but it even works with heavier loads than that:

Dsc 1942

That’s an Arduino-compatible JeeNode with an LCD Plug and a 2×16 character LCD with backlight – all running off a single 1.2V AA NiMH battery!

The maximum current depends on the input voltage. It is guaranteed to be at least 60 mA from a 1V supply, going up to 140 mA from a 1.8V supply. Note that the input current can be much more than that – drawing 60 mA at 3.3V means the battery may have to deliver about 200 mA at 1V to make it happen. A clever little power regulator it is – a producer of energy it is not!

There a several ways to connect the AA Power board with a JeeNode:

  • inline, feeding the PWR pin with 3.3V (this will be dropped some 30..50 mV by the on-board regulator of the JeeNode itself, with no ill effects)
  • in piggy-back mode, with an AA cell inserted in the battery clips (alkaline or NiMh)
  • as a shield on top of the JeeNode, again with an AA cell inserted

There’s also a fourth way to use this board: leave off the battery clips, and connect a battery between any PWR and GND pins on the JeeNode itself (or use the battery holes) – this requires a solder jumper on the AA Power board.

The flexibility of the regulator means that you can connect any power source between 1.0 and 5.5V to PWR and GND, just as you would with a stand-alone JeeNode. Whatever it is, the +3V pin will carry the essential 3.3V level.

There is one issue to beware of: when PWR is connected to BAT+ via the solder jumper, then do not hook up a second power source at the same time. The most common case is probably: when a battery is connected to PWR, do not connect an FTDI adapter such as the BUB, because it’ll put 5V on the PWR pin … and the battery (or the BUB!) probably won’t like it.

The PWR pin can in fact be used in four different modes:

  • normal – it’s higher than 3.3V and the on-board regulator brings it down to 3.3V for the +3V pin – this would be the case with 3 to 8 AA’s, for example (no need for an AA Power board)
  • boosted – it’s lower than 3.3V and it’s used to feed the AA Power board – in this case the on-board regulator does nothing (and could be omitted)
  • parallel – the PWR pin is connected directly to the +3V pin – this can be used with the AA Power board to make sure the PWR pin also carries power (always 3.3V), in case some plugs expect a supply voltage on the PWR pin
  • floating – the PWR carries no power – this is the case when the AA Power board is used without solder jumper (default case)

The important point here is that the PWR pins do not necessarily carry a higher voltage than the +3V pins. It might be more (normal), less (boosted), the same (parallel), or none (floating). Not every JeePlug can be used with each mode of operation, so be careful to check.

Tomorrow, I’m going to fool around with a bunch of batteries :)

AA mounting options

In Hardware on Sep 18, 2010 at 00:01

As promised yesterday, here is some more info on how to use the new AA Power board.

You’ve already seen the “inline” mode, using an Alkaline cell this time:

Dsc 1932

The second main mounting option is in piggy-back mode, flipped over and mounted on the back of a JeeNode:

Dsc 1939

This can be done either with regular male header pins (1×6 and 2×4, or 3×4), or with extra long pins which will stick out the front of the JeeNode as normal header pins:

Dsc 1938

Doing so requires some care, because once these two boards are soldered back-to-back, you can’t reach everything anymore. Disassembling such a sandwich later is tricky.

Note that you can stand the whole assembly on empty AA battery clips, but once a battery is inserted, this becomes unstable because the round battery sticks out:

Dsc 1940

With AAA clips and the much thinner (and weaker) AAA battery, it turns out that the whole construction does stand upright, but the size and position of the clips gives it limited stability when adding plugs on top.

There is a third option – use the AA Power board on top of a JeeNode with stacking headers, i.e. like a “shield”:

Dsc 1953

There is not that much room, but the 4 port headers can still be used. Note that the AA Power board needs to be mounted upside down in this case, i.e. with the SMD components and the silk screen facing down towards the JeeNode. Here’s another view of this shield-style option:

Dsc 1951

Coming up… a description of the full range of power connections supported by this little magician.

RGB strips, revisited

In Hardware on Sep 8, 2010 at 00:01

A while back, I reported about hooking up an RGB strip. That was then.

Now there is the MOSFET Plug to make such hookups a lot simpler. So it’s time to revisit that experiment, because I want to find out how well RGB strips would work for < w a r m > white lighting in the house. Theoretically, RGB can generate any color, so that would include any “temperature” of white, right? Trouble is, I’m not convinced that LED strips are color matched well enough across their entire length to accomplish such lighting conditions over a few meters. The other concern is that RGB LEDs have the Red, Green, and Blue LEDs sitting next to each other, so there may be some fringe colorization – maybe diffusers will be needed.

Then again, I do have one LED lamp of 1 meter long which generates an abolutely great tint of white (“white tint” – interesting concept, eh?).

Time to find out:

Dsc 1912

I obtained some samples of “5050” RGB self-adhesive LED strip, one with 30 LEDs per meter, the other with 60 LEDs. They are mounted on nice white flexible strips, and the whole thing was tacked onto my all-time favorite material: foam board!

Since 2 x 3 is 3 x 2, I used 3 MOSFET plugs to connect this together, these are in turn plugged into a Carrier Board with a JeeNode on its back, and the whole kaboodle is placed in half a box. Since the plan is to later attach this unit to much longer LED strips, I don’t really want to close that box – the MOSFETs will no doubt generate too much heat once they drive several amps each.

Here is how everything is wired together:

Screen Shot 2010 09 07 at 22.31.09

Oh, there’s one more wire: on the photo you can see a red jumper wire running from +12V to a PWR pin on the Carrier Board (I used the FTDI connector) – so the same 12V supply is used to power the JeeNode itself.

That’s it. Six output lines to control the on-off state of two independent strips of RGB LEDs.

Tomorrow – the software…

Pogo pogo

In Hardware on Sep 7, 2010 at 00:01

Until now, I’ve always been testing plugs with an Extension Cable:

Dsc 1903

Works ok, but with two hands, it’s a bit limiting for more complex cases, such as this Input Plug test rig.

Looks like people seem to be using spring-loaded “pogo” test pins more and more. Here’s one, which comes as a small 6-pin wide SMD “header”:

Dsc 1902

I mounted it on an obsolete I2C plug, simply to have a better grip on it. Not a big step up from the Extension Cables, but it’s slightly better because of the spring-loaded pins. No need to press as hard.

But to really make it simpler, you need to place the pins in all the places you want to test at once. Here’s one adapter which works for several plugs:

Dsc 1900

Once soldered on both sides, it’s actually quite sturdy.

Now, all you need to do is place the board under test on top, and press down slightly:

Dsc 1901

This was the trivial part. It’ll be a bit more work to create custom pin arrangements for the different plugs with I/O headers on the side. But it’s a great step forwards, and will let me do a better job of testing the more elaborate plugs as well.

Right now, all I2C-type plugs are verified to work from the bus side, but connections to other headers are a matter of visual inspection still. There’s “room for improvement” as they say…

Utility Plug pack

In Hardware on Sep 5, 2010 at 00:01

The recently announced Utility Plugs have room on board to add some resistors, diodes, transistors, LEDs, etc. but that’s not always needed. Sometimes, you just want a way to bring a cable out with a decent connector.

The way to do that is to solder these 4 jumpers to connect everything straight through:

Dsc 1907

Now, all you need is a cable. But beware – this one isn’t what it seems:

Dsc 1906

It only has the middle two wires connected:

Dsc 1911

Not much we can do with those: they are +3V and GND on the Utility Plug!

The way to spot them before cutting the wire, is to look carefully at the connector:

Dsc 1908

As you can see: 4 gold-plated pins on the outside (i.e. RJ-11), but only 2 wires have acually been pushed into the connector. Here’s one I made myself, using modular plugs and flat telephone cable from a local DIY shop:

Dsc 1909

Now I get DIO and AIO as well (possibly altered by the circuits added to the Utility Plug):

Dsc 1910

To better support wired-through scenarios, I’ve added a “Pack of 4” variant of the Utility Plug to the shop:

Dsc 1904

It omits the extra components, so you just need to close those 4 solder jumpers. Note that there was no room on these boards for mounting holes – best way is probably to hot-glue them to a stable base plate of some kind.

Making 6-wire cables

In Hardware on Aug 31, 2010 at 00:01

I’ve been making cables for the Utility Plug recently. They come with the kit, but the reason for choosing these “modular” jacks and connectors, is that they are very easy to make yourself.

FYI, the 26 AWG wires in this type of cabling are rated for 360 mA current. Plenty for signaling and powering electronic stuff, but not suited for high power or high voltages.

I use the following low-cost crimp tool for most of my 4-. 6-. and 8-core cables:

Dsc 1851

Actually, I have a second one for 8-core cables (i.e. RJ-45 network cables) – it’s sturdier but also more expensive:

Dsc 1862

Here’s how the cable is made, from start to finish. First, make a clean straight cut:

Dsc 1852

Then you have to strip the outer mantle, without damaging the inner wires:

Dsc 1853

This is what comes out:

Dsc 1854

It fits perfectly into a “6P6C” RJ-12 modular plug (6 positions, 6 connections):

Dsc 1855

Now the magic part:

Dsc 1856

Seen from the other side, with the plug ready to be crimped on:

Dsc 1857

Here’s a before-and-after picture, you can see the metal pushed into the cable (and the cable jacket clamped for strain relief):

Dsc 1858

Another view:

Dsc 1859

How does it work? Well, here’s the crimp tool, in released state:

Dsc 1860

And here it is again, squeezed tight (it has a stop, ya can’t squeeze too far):

Dsc 1861

If you keep goin’ at it for a while, you get this:

Dsc 1863

And that’s where they end up at Jee Labs:

Dsc 1864

Easy. And if you don’t want to go through all this: just cut up a telephone cable instead (note that such cables will work fine, but most of them only connect the inner 4 wires, i.e. AIO, DIO, +3V, and GND, not PWR & IRQ).


In Hardware on Aug 25, 2010 at 00:01

I’m always looking for new ways to fit stuff together. JeeStuff ain’t no Lego, but that sure won’t stop me from trying to make it as modular as possible…

Here’s an idea:

Dsc 1842

I just used a pair of Proto Boards and inserted a bunch of plugs into them. Just to see what it would lead to, not as “the” actual design.

Would probably have to invent another type of “backplane” for this approach, but what surprised me was how sturdy the resulting object was.

Would probably need to have 15 to 25 possible slots to place headers in (perhaps even allow soldering the plugs in for good?). And some way to select which AIO and DIO pins go to which port. With I2C, they could be connected in parallel, with dedicated plugs you’d have to reserve a port for them of course.

The reason this could work is that everything in the JeeFamily has the same 21.1 mm width. That was quite deliberate, although I didn’t have this particular path in mind at the time.

Hmm… mounting? Power options? Ethernet? Breadboard area?

Just doodling… ideas are cheap – and plentiful, here at Jee Labs!

Simplified button interface

In AVR, Software on Aug 24, 2010 at 00:01

The Blink Plug has two pushbuttons and two LEDs. The buttons are simple miniature switches, but nothing is ever simple in microcontroller-land: reading out the state of a pushbutton reliably can be deceptively hard, due to mechanical bounce issues.

The Ports library has had a BlinkPlug class for some time now, including a “pushed()” function to do all the debouncing. Unfortunately, that function turned out to be a bit harder to use than I originally intended.

Time to add some more code to the BlinkPlug class!

I’ve added a new “buttonCheck()” member, which returns events instead of state. That makes it a lot easier to detect when people press a button, which is usually all you’re after anyway.

Here’s a new button_demo.pde example sketch, which illustrates the new functionality:

Screen Shot 2010 08 23 at 17.44.21

Sample output:

Screen Shot 2010 08 23 at 17.44.39

As you can see, it’s now a lot simpler to detect when people press or release one of the two buttons on a Blink Plug. Each time you call buttonCheck(), you’ll get one of the following events:


You have to keep calling “buttonCheck()” reasonably often, at least 10 times per second, if you don’t want to miss any events. Calling it all the time in the main loop is fine. Keep in mind that ON1, etc. will be returned only once for each actual button press.

You can still call “state()” whenever you want, to check the position of either button. But when you use buttonCheck(), you should not call the old – now deprecated – “pushed()” function, as these two will interfere with each other.

This code is now part of the Ports library (subversion and ZIP). Gory details are in Ports.cpp, near line 230.

Meet the Utility Plug

In Hardware on Aug 23, 2010 at 00:01

To end the current series of new plug announcements, here’s one which is a bit of everything and nothing, called the Utility Plug:

Dsc 1834

It comes as a kit:

Dsc 1837

It brings out 6 pins to a modular jack, the same kind as used by fixed-line telephone sets around the world.

In its simplest form, you can just put a dab of solder on each of the 4 solder jumpers, and you’ll end up with a connector that brings out the 6 pins of any of the ports on a JeeNode. This plug kit includes a 1-meter length of flat white cable with a connector attached to one end. The other end is … up to you!

Modular plugs and jacks were chosen because they are very easy to get and crimp on (there are cheap plastic tools for it). If you don’t need the PWR and IRQ pins, i.e. if you only need to use AIO, DIO, +3V, and GND, then you can even take a spare telephone cable, cut it in half, and end up with… not one, but two pieces of cable which fit this connector! That’s because most telephone cables only connect to the inner 4 wires, but they still use this same 6-pin connector.

As far as I understand it, the 6-pin variant is called RJ-12, and the 4-pin variant RJ-11. They can be mixed because they have the same physical dimensions.

One reason I’ve wanted this Utility Plug for some time, is simply to have a more solid connector to plug and unplug stuff from, without having to mess with 6-pin headers. Unlike the headers, modular jacks are polarized, so there’s never a chance of connecting stuff the wrong way around – quite important once you’ve built a project and finished it by putting it inside a box, for example.

But that’s just the first half of the story…

As you can see, there’s a bit more going on with this plug. There are some places to add resistors, transistors, and diodes. The reason for this is that you often have to put a resistor in series (for say an LED), or to “pull up” the voltage on a pin, or even a small transistor to handle a little more current than a ATmega pin can by itself. Other uses would be to adjust the level of input signals, or to add reverse-polarity protection to an input pin.

The Utility Plug has 2 identical areas to handle such simple modifications:

Dsc 1840

Each of those dotted areas has the following circuit traces laid out for it:

Screen Shot 2010 08 22 at 19.55.15

(this is the DIO side, the AIO side is virtually identical)

This won’t be sufficient to deal with every scenario you might encounter, but my calculations tell me that it will deal with 27.183 ± 0.0002 different cases :)

To make this practical, a few extra components are included in the kit:

  • 2x 100 Ω, 1 kΩ, and 10 kΩ resistors (1/6 watt)
  • 2x 1N4004 diodes, for AC to DC conversion and to drive inductive loads
  • 2x 2N4401 transistors which can switch up to 500 mA @ 40V

One word of advice when using this plug, is that you should really do some back-of-the-envelope calculations, to make sure things will work within the range you’re designing your circuit for. The resistors will let you keep currents down, and the transistor will let you generate a slightly more powerful output signal.

Remember: “E = I x R” is your friend!

Other components than those supplied can also be used, of course. Each section on this Utility Plug is nothing more than a miniature breadboard area with some pre-defined circuit connections.

See the café and shop pages for further info.

Now I’ve got to fire up some projects to use this thing. I’ll keep you posted when I get to that.

Meet the Opto-coupler Plug

In Hardware on Aug 20, 2010 at 00:01

After two new output plugs, here’s one for input – a dual Opto-coupler:

Dsc 1841

The idea is simple: feed it 5..50 mA of the proper polarity, and the other side can be read out by a JeeNode without any electrical contact. As the name says: light is used to remove the need for a galvanic connection.

This can be used for more than just high voltages: there are many cases where two different low-voltage circuits have independent ground levels, and where you want to keep it that way.

Electricity always takes the path of least resistance (literally!), and with high-current loads (or inductive spikes), you never know when some piece of equipment decides that it would love to send 5A through the GND pins across a JeeNode. There’s no danger involved here, but some traces on the JN print will go up in smoke (literally!).

A simple example is when you’re dealing with two power sources, and hook them up – accidentally or on purpose. Nothing will usually guarantee that the ground pins get connnected first. You might just briefly get the positive high-current supply hooked up in such a way that it finds another ground loop…

As with the Relay Plug, I’ll mention that you can use this Opto-coupler Plug to sense AC mains voltages (well not directly… more on that in a moment). But the risk is all yours.

The terminals on this plug are also detachable, but smaller: they use a 3.5 mm pin separation, and can handle a bit less current. The reason for this distinction is that you don’t want to accidentally put a high-power connector from the Relay Plug into this low-power Opto-coupler Plug. Since the connectors don’t match, this risk is avoided.

So what can you use as input source with this Opto-coupler Plug? Well… that depends – on the resistors soldered onto this plug, to be precise. Each resistor is in series with a LED contained inside the opto-coupler:

Screen Shot 2010 08 19 at 18.11.47

The dual opto-coupler used here will operate with roughly 4 .. 55 mA of current through the LED. The series resistors included with the kit are 1 kΩ @ 1/8W – this translates to a DC input voltage range of about 5 .. 12V. Any higher, and the resistor will get too hot – any lower, and the opto-coupler won’t trigger.

For higher voltages, you can replace these resistors with a higher value. Try to keep current consumption minimal, say 5 mA. Here’s the calculation to make it work with a 24V input: 23 V (roughly 1V gets taken up by the LED) with 0.005 A is … scribble, scribble, scratch, scratch … E=I*R … R=E/I … R = 23 / 0.005 = 4600 Ω!

So you should be good with a 4.7 kΩ resistor. Now let’s calculate the power consumption of that resistor … ponder, ponder … P=I*E … E = I*R … P = I*I*R = 0.005 * 0.005 * 4700 = 0.1175 W. Phew, a 1/8W (0.125W) resistor will work, but with little slack. Not surprising, really: the resistor is eating up 23 of the 24 V sent into the plug. Meaning: heat. That’s why low current use is best: current has a quadratic impact on the power consumption.

The trouble is that with 4.7 kΩ, you can only use the plug with 24V: any lower, and the current through the opto-coupler will be too low, any higher and the resistor will deliver its final puff, in the form of smoke…

So there you have it, with some free electricity calculations thrown in: this plug will work as is on a 5 .. 12V input source, and with the proper resistor value you can also make it work @ 12 .. 24V. The two inputs are fully independent, so different resistor values are possible.

If you happen to have a current-limited source in the 4 .. 55 mA range, then simply omit the resistors and put a dab of solder to close the jumper on the pcb. That’s 0 Ω, if you really want to know :)

On the JeeNode side, first enable the pull-up resistors on AIO and DIO, and then read them out as digital inputs. If you wanted to get maximum sensitivity, you could even use the AIO pin in analog input mode, and place the threshold a bit lower. That’s going to require a bit of experimentation (and it only works on the AIO side).

New café and shop pages have been added, as usual.

There’s one more new plug on the menu, a few days from now … that one will be a bit different from the rest. Even simpler, yet fairly versatile. Stay tuned!

Meet the Relay Plug

In Hardware on Aug 18, 2010 at 00:01

Here’s another plug, useful for various applications around the house – the Relay Plug:

Dsc 1812

This one uses miniature relays to control two independent contacts. It has two MDC3105 relay drivers on board, and uses the same detachable terminals for connection to the outside world as the MOSFET Plug.

Unlike MOSFETs, relays provide a fully isolated switching capability. There is no electrical connection between the switched out pins on the terminal block and the JeeNode. The traces on the PCB were in fact laid out with a wide separation between switched pins and the rest of the circuit.

These plugs have just the right size for the Carrier Board + Box, by the way:

Dsc 1823

The relays currently used for this board are rated up to 3A @ 250V (both AC and DC). This means that you could use them for controlling up to 750W worth of devices connected to the mains on each output. Just keep in mind that messing around with the mains voltage is dangerous and can be lethal. Note also that neither the pins on the underside, nor the screws on the terminal blocks are isolated, so you’ll have to consider really carefully how to physically mount everything to prevent shock hazard. I definitely wouldn’t use these plugs for mains power in the box as shown above – such a box can easily open when dropped.

Did I mention that AC mains can be lethal? Ah, yes, I think I did…

Then again, if you know what you’re doing: sure, go right ahead.

For the rest of us, these relays are probably more suitable for controlling low-voltage lights, motors, fans, and… larger relays. One item on my (infinitely long) to-do list is to use these relays to control the power of a couple of external hard disks. Not just to save on electricity when not in use, but also because disks which are not powered up and hence don’t rotate are pretty safe from software mishaps, both accidental or malicious.

The relays are driven from the PWR line, which has to have a supply voltage between 4 and 6V to operate properly. Less, and the relays won’t turn on – more, and the relays + relay drivers will be damaged. Each relay draws about 30 mA of current while turned on. They are not latching: power loss will switch them off.

Controlling the relays in software couldn’t be simpler: use the Port class in the Ports library to set both DIO and AIO as outputs, and then use digiWrite() and digiWrite2() to control DIO and AIO, respectively. Since each relay uses up one port, you can have up to 4 Relay Plugs, i.e. 8 relays hooked up to a single JeeNode.

Here’s an example which listens for incoming radio packets to control a Relay Plug on port 1 (this example is included in the Ports library as “relay_demo.pde”):

Screen Shot 2010 08 15 at 23.18.02

Sending “1,1,17s” via another JeeNode or JeeLink turns both relays on. Sending “0,0,17s” turns them off again.

Documentation for the new Relay Plug is in the Wiki, and there’s an order page in the shop for them now.

Meet the MOSFET Plug

In Hardware on Aug 16, 2010 at 00:01

There’s a new plug at Jee Labs – one I’ve been waiting to use myself for quite some time – a dual MOSFET plug:

Dsc 1807

The IRLZ34N’s used here should be able to drive over 5A @ 50V, but this will require a heatsink. For use without heatsink, a maximum currrent of 1 .. 3 amps should work fine. Just keep in mind that MOSFETs can generate a few watts of heat when used continuously at 2A or more. You can tie the MOSFETs in parallel for larger currents. You’ll need to add protection diodes to switch inductive loads, such as DC motors, relays, and solenoids.

This plug was designed for driving LED strips, but other loads can be driven as well. With two MOSFET Plugs, there are 4 individually controllable switches – to drive an RGB strip and a white strip, for example.

The terminal blocks used on this plug are heavy duty and detachable and use a standard 0.2″ grid (5.08 mm). They are much more convenient than fixed terminal block, particularly if the plug is mounted high or in some remote spot behind a book case or curtain. The two outputs have separate connectors.

The traces on this board have been made extra wide to be able to handle large currents flowing through the terminal block pins. The pins are laid out as two pairs: one side must be tied to ground, the other side (+A or +D) is then tied to the load, which in turn gets connected to a positive supply voltage (3..50V). Note that the positive supply voltage used by the load is not connected to the plug. A pulldown resistor is used to keep the MOSFETs switched off when the I/O pins are not connected, or not set up as outputs. Also, keep in mind that this plug ties the plug signal ground and the load ground together – it is not isolated from the load power supply.

The length of the plugs is 34 mm, making them a perfect fit for the Carrier Board + Box:

Dsc 1815

Note that a closed box provides little airflow to cool the MOSFETs, so this setup is not recommended for high-current use. Having said that, I’ve been driving a few meters of RGB LEDs with these MOSFETs without them even getting warm. See this earlier weblog post.

For dimmer use, there’s example code for a remote-controlled JN and 4 MOSFETs using software PWM.

I’ve set up a documentation page in the café and an order page in the shop. Since the prototypes worked on first try, these MOSFET Plugs are available as simple through-hole part kits right away.

A Murphy-less plug, so to speak :)

Input Plug, oh my

In Hardware, Software on Jun 19, 2010 at 00:01

More fallout from the bad ISP programmer. As reported on the forum, there is a problem with the Input Plug. Fortunately, it’s fixable in software.

The problem is that the ISP programming of the ATTiny45 chip on the Input Plug had the same problem as the recent, ehm, Murphy debácle: the fuses weren’t always set properly.

So the ATTiny starts up running at 1 MHz i.s.o. 8. And hence the timing is off when driving pulses to it to control the analog multiplexer.

The solution was to add a “fix” parameter to the InputPlug class in the Ports library. It defaults to 0 (no fix needed), but when set to non-zero, the timing is adjusted to slow down by a factor 8. That way, channel selection will take a bit longer – but at least it’ll work:

InputPlug myPlug (3, 1); // plug on port 3, slow down for wrong ATTiny fuse

This code has been added to the Ports library. There is a downside: the fix means that channel slection now takes roughly 900 µs, instead of the intended 100 µs.

Next question is: how to make sure this won’t happen again? – Answer: build a test jig, so all plugs can be tested fully before shipping. Trouble is, all Input Plugs ship as follows (this is an early hand-soldered unit):

Dsc 1732

Without headers!

My mistake was of course that I would wing it, and avoid the testing. Bzzzt. Time to build a little test contraption:

Dsc 1733

The other side is filled with 17 tiny 1 kΩ SMD resistors, creating a voltage divider with 16 different voltage levels. Soldering this was quite a challenge, btw:

Dsc 1737

And now I can take advantage of the fact that everything is gold-plated. So the following will make contact, just with the pins being pushed in and pressing lightly against the board:

Dsc 1735

I’ve been using the same trick for some time now, to test other plugs. Here’s how to connect the whole thing to one of the ports:

Dsc 1736

Below is a little readout test – a better test setup would be to simply perform the check and display a go / no go signal, but for now I’m just reporting the 16 values:

Screen Shot 2010 06 16 at 19.00.21

Sample output:

Screen Shot 2010 06 16 at 20.24.30

As you can see, the selection is now working reliably (once connected).

So that proves the bug and gives me a new tool to test Input Plugs before shipping. And of course I’ll re-flash the ATtiny45 chips on all remaining Input Plugs in stock at Jee Labs. For those already out there: you can either use the software fix, or send your Input Plug(s) back to me and I’ll fix the fuse settings to make selection snappier, as originally intended.

Problem solved. Phew.

Does it feel good to have to confess to another goof-up on my end? Of course not. But worse than that would be to keep quiet on this – and I won’t. I’m human, I make humiliating mistakes (LOTS!), I occasionally cut corners, but I do my best to learn and deal with it all. There is no doubt whatsoever in my mind that every person and company goes through these sorts of mishaps. It’s just usually not out in the open for everyone to see. Well, at Jee Labs, it doesn’t work that way – this is open source: software, hardware, goofs … e v e r y t h i n g !

RGB via the Dimmer Plug

In Hardware on Jun 17, 2010 at 00:01

As someone pointed out in the comments a few days ago (see? that’s what weblog comments are for!), there’s Jee Labs’ own Dimmer Plug to unload the ATmega of all PWM duties:

Dsc 1729

Hm, I really forgot all about that one… doh.

It’s a great suggestion, of course. And fortunately, it can easily be swapped into the RGB strip controller series. All I need is a slightly different JeePlug to tie things together:

Dsc 1730

The result has a 2×3 pin header which matches the one on my previous interface, so now it’s just a matter of swapping cables.

And new software, of course. Here’s a test sketch which cycles brightness and colors similar to the first test sketch:

Screen Shot 2010 06 15 at 18.42.36

Except that this no longer requires any processor attention once set. And there are a few extras: it’ll work with up to four independent sets of RGBW LED strips, and it has a “global” brightness control (currently set to max), making it easy to set up the color once, and then dim the whole shebang while keeping that setting.

Also – because it’s hardware now – the PWM happens much faster. I can’t tell the difference, but I have this hunch that our cat probably can. There’s got to be a difference between blinking at 120 Hz and 100 KHz!

I’m not sure yet which approach I’ll keep. Both software and hardware PWM work fine. Decisions, decisions…

LCD display voltages

In Hardware on Jun 4, 2010 at 00:01

As of this month, the 2×16 character LCDs from Jee Labs are 100% suitable for 3.3V use. The previous batch was made for 5V, although the backlight can always be used at a lower voltage: it’s just a few LEDs with a current-limiting resistor after all.

But the logic level officially had to be 5V. Then again, in practice, I’ve used those LCDs with a LiPo battery without any noticeable problems.

The new LCD units are specifically for 3.3V, so both voltage jumpers on the LCD Plug should be set to +3V.

To see which unit you’re using, look on the back. These are the new 3.3V units:

Dsc 1522

Note the “33V33” suffix.

I suspect that the difference is only in a few on-board resistors. I haven’t tried running these new LCDs at 5V logic levels – they may not be up to it.

But for LiPo and 3x AA battery use, the new units will be perfect.

BMP085 in high-resolution mode

In Software on May 27, 2010 at 00:01

The BMP085 is a pressure sensor, as used on the Pressure Plug:

Dsc 0735

It’s quite popular. Some people get more than one – I can only assume it’s for some sort of altitude application.

By popular demand, I’ve updated the BMP085 code to support all 4 resolution modes. There is now an optional second argument to set the oversampling:

Screen Shot 2010 05 22 at 11.45.55

Allowed values are 0..3 – the default is the same as before, i.e. 0 (no oversampling).

Sample output from the bmp085demo.pde sketch in the Ports library, adjusted to use maximum oversampling:

Screen Shot 2010 05 22 at 11.42.09

Note that the return values of some intermediate routines have been changed from 16-bit to 32-bit. The calculated results are the same as before: temperature in units of 0.1°C and pressure in Pascal (i.e. x 0.01 hPa).

Meet the Carrier Board

In Hardware on May 21, 2010 at 00:01

Finally, all the pieces have arrived to be able to announce the Carrier Board !

Dsc 1434

It fits into a plastic box of about 70 x 125 x 30 mm, made of two identical ABS shells which click together:

Dsc 1310

The JeeNode, JeeNode USB, and JeeSMD can all be used, they are “carried” by this board, so to speak:

Dsc 1311

Tons of ways to hook up plugs to this thing. There’s a diagram with all the pinouts (PDF).

Here’s a version which has all headers soldered in – not very useful, but I had to test everything anyway:

Dsc 1315

Note that only the port headers use male pins on the Carrier Board (towards the JeeNode, that is). The PWR/SER/I2C and the SPI/ISP headers both use pins with the opposite orientation. This was done because the ISP header is more useful as pins on the JeeNode, and to avoid confusing the PWR/SER/I2C header with ports, since both types use 6 pins.

More related news tomorrow…

Meet the Input Plug

In Hardware on Apr 28, 2010 at 00:01

After yesterday’s exploration into sending 4 bits over one I/O pin, it was easy to complete the Input Plug:

Dsc 1364

I got the silkscreen labels completely wrong, but once that was clear it all went more or less as intended.

A new “InputPlug” class has been added to the Ports library. It’s essentially still a Port, but with one extra “select(channel)” member to set the input channel from 0..15.

Note that this is called an input plug, but it’s really an analog 16-channel multiplexer in front of the AIO pin of a port. It can be used for analog input as well as digital input (just use digiRead2() i.s.o. anaRead()).

But it can also be used as output demultiplexer, even for analog (i.e. PWM) output when connected to port 2 or 3! Just keep in mind that as output, the usefulness is limited since there is no latching going on: the pin goes to high impedance, i.e. disconnects, when the channel is not selected.

One possible use as output, is to drive a set of transistors – one at a time, e.g. to multiplex a 7-segment or matrix display. By setting the AIO pin permanently to 0 (or 1), you could use the channel selection to pull one of the 16 pins down (or up).

The Input Plug is not an I2C plug – it requires a dedicated port and can’t be daisy-chained.

The following “input_demo.pde” example sketch has been added to the Ports library:

Screen Shot 2010 04 19 at 23.26.41

Sample output:

Screen Shot 2010 04 19 at 23.10.33

All inputs read out as 1023 because of the pull-up in this demo, except for one pin which I was manually connecting to a 1.5V battery in rapid succession.

Will be adding this plug to the shop shortly. See the documentation page for further details.

Decoding a pulse train

In AVR, Hardware, Software on Apr 27, 2010 at 00:01

The (planned) Input Plug uses an ATtiny chip to decode a 16-channel selection code using a single I/O pin.

Here is the relevant part of the schematic:

Screen Shot 2010 04 19 at 19.50.37

The DIO pin is connected to PB4 of the ATtiny. The ATtiny PB0..PB3 pins in turn are hooked up to the A..D select inputs of the analog multiplexer. So all the ATtiny needs to do is decode an incoming “pulse train” on its PB4 pin, and send out the decoded value on its PB0..PB3 output pins.

My first attempt used a simple serial protocol: a start bit and 4 data bits, clocked at a fixed rate:

Screen Shot 2010 04 19 at 19.52.59

This worked, but it was a bit flakey because the internal clock of the ATtiny is not accurate enough to ensure everything stays in sync for the entire duration of the transmission, i.e. across 5 bit periods. This is clearly explained in the following image (from here):


It’s better to use a self-clocking format, for example 5 pulses of varying width, because then only the length of each individual pulse matters. Above a certain threshold = 1, below = 0. And we can reset when there are no pulses.

Here’s the a transmit test sketch, which sends a 0..15 counter every 100 ms:

Screen Shot 2010 04 19 at 19.57.36

As you can see, the pulses are 4 or 8 µs wide, with one pulse every 12 µs. Roughly.

Note that interrupts have to be disabled during each “transmission”, since these pulses are very short and need to be fairly strictly controlled.

The decoder on the ATtiny (ATtiny85 in this test) is also quite simple. It waits for a pulse start and then counts in a loop until the signal drops to zero again. Counts above a certain value are treated as “1”. Missing pulses and pulses which are way too long cause the decoder to be reset and start from scratch:

Screen Shot 2010 04 19 at 20.01.21

This can be compiled with avr-gcc, and it’s of course just a few bytes (even an ATtiny is overkill here):

Screen Shot 2010 04 19 at 20.02.44

I’m using yesterday’s Flash Board for ISP programming. Makes a good test that it also works with ATtiny MPUs.

Here’s the test setup (with the ISP programmer disconnected):

Dsc 1362

And sure enough, the LEDs display a little running 4-bit counter, driven by data sent over a single DIO pin.

Should be good to go for the Input Plug!

ISP plug

In AVR, Hardware, Software on Apr 24, 2010 at 00:01

For one of my projects, I needed a quick way to reflash an AVR via ISP. Didn’t want to have to use any of the several ISP programmers around here, so I made my own “ISP plug” for use on a JeeNode:

Dsc 1353

The pins are connected as follows:

  • ISP pin 1 = MISO = DIO1
  • ISP pin 2 = VCC (+3.3V)
  • ISP pin 3 = SCK = AIO1
  • ISP pin 4 = MOSI = AIO4
  • ISP pin 5 = RESET = DIO4
  • ISP pin 6 = GND

Here the top view, made from a little JeePlug board:

Dsc 1354

Bottom side:

Dsc 1355

Note that this ISP setup draws 3.3V from the JeeNode and uses it to power the target, so the target board should not have its own power and it should not draw more than say 100 mA of current @ 3.3V.

The code for this is called “isp_flash.pde” and is derived from the “ArduinoISP” sketch. I added software-based (bit-banged) SPI communication for use with the above I/O pins, and did a fair bit of cleanup of the source code.

The nice thing about this ISP programmer is that it works out of the box with Arduino IDE 0018:

  • upload the ISP_flash.pde sketch to the JeeNode
  • insert the ISP plug and hook it up to the test circuit (or one of these …)
  • burn the boot loader using the Arduino IDE:

Screen Shot 2010 04 18 at 18.04.06

The result will be a properly initialized ATmega, with protected bootloader and the default blink demo pre-loaded.

It’s not terribly fast because it uses a 19200 baud connection, but it’s simple and can be a life-saver if you ever damage the bootloader on an ATmega, or want to prepare blank ATmega’s for use with a JeeNode.

This plug can in fact be used as ISP programmer for any type of ATmega or ATtiny with “avrdude”:

Screen Shot 2010 04 18 at 18.14.42

You’ll need to adjust the serial / USB port, fuse settings, and sketch as needed, of course.

OOK plugs

In Hardware on Apr 12, 2010 at 00:01

I’d like to get some more weather sensors etc. connected to JeeNodes, so I made some “OOK plugs” by hand:

Dsc 1332

  • top: 433 MHz receiver and transmitter, by Conrad
  • bottom left: 868 MHz receiver by ELV
  • bottom right: 433 Mhz receiver (also by ELV?)

The top two units need an external 17 cm wire antenna, the bottom two have built-in PCB antennas.

Here’s my OOK test unit, using a JeeNode USB v3 and the new Carrier Board & box:

Dsc 1334

And here a first test setup:

Dsc 1335

One of the things I’d like to establish is to what extent these units can be combined in one box. A previous attempt with the OOK relay seems to indicate that there can be severe interference between these units. Even “receivers” tend to emit quite a bit of RF power from their tuned circuits over short distances.

Haven’t wired up these units yet The plan is to tie receivers to the AIO pin and transmitters to the DIO pin, so that a pair of them can be used on a single port.

Update – Here is a detailed view of the different receivers and how they were hooked up:

Dsc 1513

Dsc 1514

Closing in …

In Hardware on Apr 11, 2010 at 00:01

The first Carrier Boards and Carrier Cards have come in, as described a few weeks ago on this weblog:

Dsc 1309

The Carrier Board is sort of a chameleon, given all the options it has for connecting stuff together:

Dsc 1329

You’re not supposed to use all those options at the same time, although you could if you really want to:

Dsc 1313

On the back you can plug in either a JeeNode, a JeeNode USB, or a JeeSMD as “processing engine”. Here’s a JeeNode USB:

Dsc 1315

As you can see, the USB connector will fall inside the case when plugged in this way, e.g. when you don’t use it, or to hook up a cable permanently.

Or… you can turn the board around, and make a cutout in the case to access the USB jack from the outside:

Dsc 1316

Wanna see how much you can cram into a box? Here’s a first attempt, with still some room to spare:

Dsc 1323

One more feature worth mentioning, is that there are pads and holes for an SMD-type DC jack. Here’s the jack soldered on, with a JeeSMD plugged in (the “+” end needs to be wired up manually):

Dsc 1325

Lots of options with all this. Great, now I can start working out some projects which need an enclosure.

There is one issue with the Carrier Board, alas … It turns out that the RX/TX pins on the FTDI connector (top right, first picture) were accidentally reversed. So this board doesn’t work with a USB-BUB out of the box.

That’s ok, though. I only had five of these prototypes made – just enough to try them out. Will fix it before ordering more boards for the shop.

It’ll take some time, but it’ll all work out nicely in the end, I expect.

Gravity Plugs

In Hardware on Apr 5, 2010 at 00:01

Ok, some panelized boards and components are starting to trickle in. Here’s the first production batch:


(no, I don’t reflow ’em as a triangle, it just looks pretty this way…)

You’re looking at 15 brand new Gravity Plugs, i.e. 3-axis accelerometers. This is by far the smallest SMD chip ever soldered here at Jee Labs. The pads are too small for a soldering iron, even with a 0.4 mm tip.

Out of a panel of 20, some 18 appear to be working properly, but I did have to wick away some solder (i.e. fix solder bridges) to get several of these units working.

I’ll be adding this and a few other new plugs to the shop in the next few days.

Now, if I only had some time to play with these sensors…

Stencil Jigs

In Hardware on Apr 4, 2010 at 00:01

Ok, I’ve prepared a couple more Stencil Jigs for applying solder paste:


Here’s one in more detail:


Basic idea is that a couple of scrap PCB pieces are hot-glued to an A5-sized piece of foam board to keep the panel in a fixed spot. Then add the stencil and fix it to the jig in exactly the right spot.

The placement of components is still a manual task, and quite a precision job for some of the latest boards, but by now my daughter and I are starting to get quite good at it – yep, it’s become a family thing :)

The new jigs will speed up production of the ever-growing Jee Labs collection of JeePlugs and other boards!

Improved carrier board

In Hardware on Mar 28, 2010 at 00:01

Two weeks ago, I posted a note about a new enclosure and carrier board design to mount a JeeNode inside.

This led to several (virtual) experiments, to figure out how it would work out in different usage scenarios. One of the main problems remaining was that the design was not suited for a JeeNode USB, because the USB connector would have been inside the case – not perfect…

Here’s an improved design, which has been sent off to create a first prototype:

Screen shot 2010-03-27 at 21.23.13.png

The main change is that this allows using either a JeeNode with FTDI connector or a JeeNode USB. This was accomplished by moving the connectors around a bit, which urned out to be fairly tricky due to the huge number of interconnections.

The new trick is that this carrier board can now be used with two different JeeNode orientations. By attaching it one way, the FTDI or USB connector will end up inside the box, while turning it around 180° will put those connectors on the left side, almost sticking out. Just right to access it through a cutout.

Two other improvements over the previous design are that the carrier board includes connectors positioned in such a way that they will accept a Room Board, and the presence of an extra FTDI connector.

As before the bottom row of five 6-pin headers gives access to all signals of the JeeNode. Plugs can be attached in many different ways, supporting lots of combinations, with room for a variety of other components.

Not quite a compass, yet

In Software on Mar 25, 2010 at 00:01

This is an attempt to read out the magnetometer / compass of the Heading Board introduced yesterday.

The demo sketch has been extended, and is still deceptively trivial:

Screen shot 2010-03-23 at 17.30.23.png

The meat of the code is in the HeadingPort class implementation in the Ports.cpp source file.

Trouble is – it doesn’t work :(

Sample run #1:

Screen shot 2010-03-23 at 16.28.33.png

Sample run #2, using another sensor:

Screen shot 2010-03-23 at 16.29.04.png

The barometer readings are more or less consistent, but probably both wrong. The local weather station and my Pressure Plug in the ookRelay both report that the current air pressure is currently around 1017 hPa.

As for the temperature readings, well … the temperature sensor in the Pressure Plug reports 20.9°C, and it’s about one meter away, also on my desk.

What’s worse is that the magnetometer readings are missing, and both come out as zero.

Trying again with a different setup, I get this third sample output:

Screen shot 2010-03-23 at 17.25.11.png

The values don’t change when I rotate the sensor. I can’t make anything of this right now, best guess is that the I2C bus transactions are perhaps flakey. Not impossible – this is a pretty simplistic software-based bit-banging I2C implementation after all, which doesn’t support things like clock stretching. I could try it out on a real hardware I2C bus via the Plug Shield. Another day…

The code has been added to the Ports library, as usual.

Gravity Plug

In Hardware, Software on Mar 22, 2010 at 00:01

The plug story continues…

The Gravity Plug contains a 3-axis accelerometer with 2..8g settable range:


As before, a new GravityPlug class has been added to the Ports library, along with a “gravity_demo” sketch to illustrate its use:

Screen shot 2010-03-19 at 13.08.33.png

Sample output:

Screen shot 2010-03-19 at 13.26.31.png

Values are X, Y, and Z, in that order.

I’m not sure about the high bit readout with the current code, maybe this needs some tweaking to get the ranges right, but you can see the effect of moving the plug around a bit.

The Y axis wraparound may be due to the chip not being completely flat on the board. This is a minute chip, which can’t be soldered by hand because the pads are too small and on the bottom side of the chip. I applied solder paste manually and then used the reflow grill – but even that is tricky, it’s very difficult to get an even-yet-small amount of paste on there! A solder paste stencil will no doubt solve this.

Lux Plug

In Hardware, Software on Mar 21, 2010 at 00:01

Here’s a second simple plug which works:


(the silkscreen markings are incorrect, this plug responds to I2C addresses 0x29, 0x39, or 0x49)

The Lux Plug measures incident light intensity which can be converted to a 16-bit Lux value in the range 1 .. 65535. A 16x multiplier can be used to increase the dynamic range to 20 bits.

A class named – surprise! – “LuxPlug” has been added to the Ports library, as well as a “lux_demo” sketch:

Screen shot 2010-03-19 at 01.31.30.png

Sample output:

Screen shot 2010-03-19 at 01.29.01.png

The two first values are the raw readings from two internal sensors. The TAOS datasheet explains how to derive the Lux value from them. This calculation is included as the “calcLux” member in the class (to be called after getData() has obtained a reading).


Dimmer Plug

In Hardware, Software on Mar 20, 2010 at 00:01

Looks like the Dimmer Plug is working as intended – yippie!


I connected a LED with series resistor between the L1 output and PWR (i.e. 5V in this case).

Added a new “DimmerPlug” support class in the Ports library, and a “dimmer_demo” example sketch:

Screen shot 2010-03-18 at 22.42.06.png

The result is a LED which blinks briefly 4 times per second, with increasing intensity. When the maximum intensity has been reached, it restarts from off. Note that the blinking and brightness control is done by the plug – the sketch just keeps feeding it new settings.

There are 16 independent channels, the outputs can be either open-collector or totem-pole, and by adding a MOSFET, transistor, or darlington stage, much larger currents and voltages can be controlled by this plug.

Another fun application would be to connect up to 5 RGB LEDs, for full 24-bit color control of each one of them.

The above code has been added to the Ports library.

Carrier Board

In Hardware on Mar 14, 2010 at 00:01

Yesterday’s enclosure has started a new ball rolling…

I’ve decided to support a mix of plugs with room for prototyping. A first mockup:


This will be made possible by a new Carrier Board with tons of different ways to connect to:


Ports 1 and 4 each have four positions for adding plugs. All connected in parallel, so you can hook up more than one if you’re using a bus such as I2C on that port. Note the big dots, identifying the PWR pins for orientation.

Ports 2 and 3 can be plugged in, but their pins are also brought out to a series of 6-pin headers in the bottom right. These 18 pins bring out everything else, including full SPI, hardware I2C, and the serial I/O lines.

Lastly, the SPI/ISP and the PWR/SER/I2C connectors from the JeeNode have been duplicated.

Note that you can also ignore all that plug stuff and just insert your own board into the entire bottom row, using five 6-pin headers. That gives you access to all the pins on a JeeNode. Here’s a board I’m going to try out:


There’s a split down that board, to allowing breaking off and using either side independently. The left side is essentially a dual JeePlug and will fit in all the 2-port positions on the Carrier Board.

These boards will be included in the next round of PCBs. We’re back to the “Patience, grasshopper!” part…

JeeNode enclosure

In Hardware on Mar 13, 2010 at 00:01

At last! – Here’s a fantastic enclosure for the JeeNode:


The plugs are just one possible orientation, they will also fit sideways, i.e. stacked on their side like the JeeNode in there. No screws, no glue – this just needs a PCB of the right size – or as in this case: perf-board with some male headers to connect to the JeeNode ports.

The whole box clicks together with the other side, which has exactly the same shape:


Available in light gray and in black from Dick Best in the Netherlands.

I’ll look into adding this enclosure option to the shop.

New board summary

In Hardware on Mar 7, 2010 at 00:01

Here is a summary of the boards which are currently being, eh … prepared? etched? sprayed? drilled?

First of all, a new JeeNode USB with improved voltage regulator setup:

Screen shot 2010-03-07 at 00.53.02.png

The Dimmer Plug contains a 16-channel LED dimmer with independent PWM brightness control, using I2C:

Screen shot 2010-03-07 at 00.53.25.png

The Lux Plug contains a sensitive light meter with high dynamic range, using I2C:

Screen shot 2010-03-07 at 00.53.36.png

The Gravity Plug contains a 3-axis accelerometer with 2..8G range, using I2C:

Screen shot 2010-03-07 at 00.53.45.png

The Proximity Plug connects up to 8 contacts as capacitive sensing switches, using I2C:

Screen shot 2010-03-07 at 00.53.58.png

The Input Plug supports 16 inputs, as either analog or digital inputs (not I2C):

Screen shot 2010-03-07 at 00.54.09.png

And three more boards. One of them is a mystery sensor – I’ve masked out its name for now :)

Screen shot 2010-03-07 at 00.56.00.png

The other two boards are experimental boards of a different kind – I’ll describe ’em when they work.

I’ve started setting up documentation pages for these new PCBs, but so far that’s just the EAGLE files. Will add more info in the coming week – with luck they’ll be back here for testing within the next 10 days.

I guess the best tactic for me now, is to just forget about this and work on some other stuff for a while. Drat.

Patience, patience, patience. I hope it pays off!

Output and Expander plug fixes

In Software on Feb 25, 2010 at 00:01

While testing an Output Plug, I found a little mess-up: the documentation pinout is wrong, all even and odd I/O pins on the 2×6 output connector were swapped. Here is the correct pinout:


I’ve updated the documentation.

The “expander” sketch is also very confusing, it was still for the PCA8574A, whereas the current Expander Plug uses an MCP23008.

Here’s an improved sketch, with a little running-light demo:

Screen shot 2010-02-22 at 12.38.18.png

This code has been checked in to replace the “expander.pde” sketch in the Ports examples.

New Dimmer Plug

In Hardware on Feb 17, 2010 at 00:01

One last plug… who knows, with a bit of luck, some of them might just work on first try?

The Dimmer Plug controls up to 16 LEDs or other lamps, and is based on the PCA9635 chip:

Screen shot 2010-02-16 at 21.29.21.png

It’s driven from the I2C bus, with a couple of jumpers to allow daisy-chaining up to 8 plugs on a single port:

Screen shot 2010-02-16 at 21.46.19.png

Here’s an extract of the datasheet, showing the different ways to hook up LEDs:

Screen shot 2010-02-16 at 02.04.23.png

Basically, you can drive one LED directly per pin, or add a transistor to drive many more in parallel or in series. The chip just does the PWM part, with various blinking options and more, all from an I2C bus.

To drive high-power displays, the outputs can be tied to darlington arrays such as the ULN2803, or to MOSFETs. There are no drivers on the plug because there are too many different usage scenarios. It all depends!

Originally, I wanted to make this plug also fit on a the back of a display such as this one:


That pressure plug on the photo was added for size comparison. It’s the same size as this Dimmer Plug, which happens to allow daisy-chaining two such displays tightly next to each other when you include the headers.

But I can’t make it fit without widening the plug and mounting components on both sides. So I’ll leave it as is – it could still be mounted on the back by adding lots of little wires and 16 resistors, but it will take some more work. Or one could add a little board to sit in between, with 16 resistors and pins to stick into the 3×6 headers.

Now I’ll stop with this plug madness. Need to finalize all the layouts and traces, send the designs off, and then the waiting starts. Luckily, there’s still enough other stuff left to do around here :)

Update – there are some errors in the schematic. I’ll fix them before sending off this board.

New Input Plug

In Hardware on Feb 16, 2010 at 00:01

The plug rage continues. Sixteen inputs, analog and digital in any mix:

Screen shot 2010-02-15 at 12.58.04.png

I haven’t routed the connections yet so the layout and dimensions might still need to change.

This plug is an experiment. It does not use I2C, so it will need a dedicated port. The trick is that an on-board ATTiny45 is used to decode a pulse train of four pin selection bits from just the DIO pin.

Here’s the schematic:

Screen shot 2010-02-15 at 13.08.55.png

The 16 inputs are multiplexed into the AIO pin. By defining this as an analog input, you can have up to 16 analog pins, using the 10-bit ADC built into the ATmega. But defining AIO as a digital input, you can use it as a digital pin. Even works with pull-up, but the pull-up will only be active as long as the same input remains selected. Unselected inputs return to a high-impedance state.

Needs some more work though, including some firmware for the ATtiny.

New Proximity Plug

In Hardware on Feb 15, 2010 at 00:01

Yet another plug! This time it’s a proximity capacitive sensor based on the MPR084:

Screen shot 2010-02-14 at 22.01.08.png

This one has 8 inputs which can be connected to various surfaces to create capacitive touch sensors. There’s also a pin for a piezo sound unit to produce key clicks.

Slightly more elaborate schematic this time, with an extra 8-resistor array for pull-up:

Screen shot 2010-02-14 at 12.05.27.png

Yet again: connected via I2C, and supports no more than 3.6V as power source. There’s a solder jumper to choose between two I2C addresses, so you can use two of these for a total of 16 inputs on one port (or Plug Shield).

Haven’t tried this chip out yet, but it will be fun to see what it can do – once I get some prototype boards ready.

New Gravity Plug

In Hardware on Feb 14, 2010 at 00:01

Another plug coming up – based on the BMA020? 3-axis accelerometer:

Screen shot 2010-02-12 at 23.07.28.png

Again an awfully tiny chip, with even smaller pads. This chip has a programmable ±2g/4g/8g range with 10 bit resolution. As with yesterday’s plug, this chip communicates over I2C and supports up to 3.6V.

The schematic is obviously very simple again:

Screen shot 2010-02-12 at 23.07.59.png

The Gravity Plug will also work with an Arduino, through the Plug Shield.

It’ll take at least a few weeks before I can test these new plugs and make them available.


New Lux Plug

In Hardware on Feb 13, 2010 at 00:01

There’s a new plug in the works, with a really neat TSL2561 light sensor:

Screen shot 2010-02-12 at 21.06.49.png

The chip is even smaller than what I’ve been working with until now. The nice thing about the TSL2561 is that it has six orders of magnitude dynamic range and that it’s interfaced via I2C.

The JeePlug port headers are in fact perfect for sensor chips like these, which often only tolerate up to 3.6V:

Screen shot 2010-02-12 at 21.08.28.png

The Lux Plug will also work with an Arduino, through the Plug Shield.

Stay tuned. There’s more coming…

Plug shield on Arduino Mega

In AVR, Hardware on Feb 7, 2010 at 00:01

The Plug Shield can also be used on an Arduino Mega:


Note the two extra wire jumpers, since the I2C interface is on pins 20 and 21 on the Mega board.

The above has an RTC plug and an LCD plug hooked up, so let’s to set up a simple clock with this – and use it to demonstrate the brand-new RTClib along the way:

Screen shot 2010-02-05 at 17.22.01.png

I’ve omitted the details of the Wire coding, but you can get the full sketch here.

RTC battery fix

In Hardware on Feb 1, 2010 at 00:01

I’ve been getting some email about the RTC Plugs not retaining their clock. It turns out that there is a problem:


The center contact of the battery “holder” is the PCB itself, and being gold-plated, I thought it’d be best to keep it as is.

The problem is that the solder mask layer can be slightly thicker than the gold-plated pad, causing the battery to not make contact – despite the pressure of the metal clip.

This can be fixed by adding a small dab of solder:


This will cause the coin cell to press more against both contacts, so a good connection is virtually guaranteed.

Needless to say, I’ve updated all RTC plugs here and will ship this improved version from now on.

Better UART code and GPS

In Software on Jan 3, 2010 at 00:01

The UartPlug class which was recently implemented used per-byte access via I2C to retrieve each received character.

This isn’t terribly efficient, since it requires sending several bytes back and forth for each received character: first we address the UART to check its status, then we access it again to get one character from the FIFO. That’s six bytes of data for each received character.

It didn’t work well enough at 38400 baud, so I added a small buffer as optimization. The UartClass API hasn’t changed. The code which does this is:

Screen shot 2009-12-29 at 15.36.49.png

Nothing fancy, just a small buffer (10 bytes currently) to speed things up. The essence is that when lots of data is coming in, we get 10 bytes at a time, for a total I2C overhead of 15 bytes. That’s a 4-fold reduction in bandwidth.

The setup I’m experimenting with is this FV-M8 GPS receiver:


The hookup looks daunting, but that’s because the connector is a bit small so I made a little breakout board for it:

Screen shot 2009-12-29 at 15.44.56.png

Here’s some sample output:

Screen shot 2009-12-29 at 16.05.09.png

The “gpsdemo” sketch is simply a serial pass-through, converting 38400 baud to 57600 along the way:

Screen shot 2009-12-29 at 15.46.40.png

But it still loses character along the way, as seen in this snippet:

Screen shot 2009-12-29 at 15.17.26.png

The RMC line has a partial line at the end, after the “*7B” checksum.

My guess is that this isn’t the UARTs fault, nor the I2C bus. What seems to be happening is that the Serial class does not buffer its output, so all output causes the sketch to become unresponsive for input. In theory the 57600 baud link should be able to get data out fast enough, but I suspect that in practice there is an occasional hickup.

If this is indeed the cause, then it’s another example of how wasting time can lead to problems.

Back to the GPS. After a few minutes it finds its position in 3D. The following info comes in 5 x per second:

Screen shot 2009-12-30 at 01.54.08.png

Some additional details are reported once a second:

Screen shot 2009-12-30 at 01.53.35.png

(ignore the last few garbled lines, I really need to lower that baud rate a bit)

Here’s an even more accurate fix I found in the data stream:


So that’s up to 8 satellites – indoors, with stone/concrete walls and coated double-glazing windows. Impressive… older units I tried never even got a fix indoors!

To interpret this GPS data, check out Mikal Hart’s TinyGPS library, it can easily be hooked up to the UART plug – just use this code at the top of his test_with_gps example:

Screen shot 2009-12-31 at 00.58.36.png

… and init nss to match the baud rate of your GPS unit.

JeeNodes and complexity

In Hardware, Software on Dec 29, 2009 at 00:01

In yesterday’s post, I commented on a couple of aspects of the Arduino world which are giving me some trouble.

Now it’s time to do the same for all this “JeeNode” and “JeePlug” stuff I’ve been working on in 2009. Because there too, there are some ugly edges, uncomfortable trade-offs, and unsolved issues.

Let me start by pointing out the obvious: the Arduino world and Jee Labs are totally and utterly incomparable in scale. In terms of number of people involved, money involved, business interests, variety, maturity, promotion, reach, ambition, … they really differ in every aspect you can think of.

Except technology: Arduino’s and JeeNodes both live in the space of Physical Computing. And JeeNodes are compatible to Arduino’s in terms of software and PC interfacing. That’s not so surprising, since I designed JN’s to get going as fast as possible with as few key changes as possible.

These key changes were:

  • Voltage levels – run at 3.3V to support more sensors and wireless
  • Hardware ports – multiple identical interface connectors
  • Hardware extension – I2C buses which allow daisy-chaining
  • Software – connector-independence through the “Ports” library
  • Physical shape – a much smaller RBBB-like form factor

Two key additions driving some of this were:

  • Wireless – built-in bi-directional wireless link
  • Low power – selecting all hardware so it can run off batteries

Because one major use for all this is remote battery-powered operation, a minimal PC interface was chosen (3.3V signals for use with an FTDI adapter).

So is all this Jee stuff merely about creating wireless nodes? Not really. That just happens to be my area of interest. Staying focused is good, and I definitely intend to stick to this for quite some time.

So far so good. I thought I had it all figured out.

Then reality – and complexity – set in. Here are a number of issues:

  • Connector choices – ports use 6-pin 0.1″ headers as connectors: cheap and widely available. Not polarized, so you can plug things in the wrong way (and you will) – it took a while, but it has been standardized, and the POF approach solves polarization where it matters most: during experimentation.
  • Library dependencies – the “Ports” and “RF12” (wireless) libraries have become inter-dependent, so you now have to include both of them all the time. As far as I can tell, this is not a software modularity issue but an Arduino IDE problem. This is starting to become a major inconvenience for small projects.
  • Class dependencies – classes such as “MilliTimer” are very small and self-contained but the more they get used, the more they lead to the above library dependency troubles. If adding modular and useful code leads to headaches, then something is definitely wrong.
  • Wireless functionality – a small driver takes care of packet reception and transmission in the background. It’s very low level but an easy transmission layer on top now adds robust communication for sensor networks. More convenience functions like these need to be added.
  • Multi-node development – it’s tedious to deal with multiple interfaces when more than one JN is plugged in, because USB interface names are meaningless. There is currently no way to auto-detect when a JN is plugged in or removed, let alone do something specific depending on what sketch that JN is running.
  • I2C ≠ I2C – ports support a software (bit-banged) I2C bus, but the ATmega also has pins which support hardware I2C. The underlying driver code is completely different. There is no generalized layer yet to hide these differences, so right now code written to use I2C plugs via the Ports library needs to be changed to work with hardware I2C and the Arduino’s “Wire” library. This must be fixed.
  • Ports vs. Plug Shield – due to the I2C differences described in the previous item, code written for ports on a JN needs to be adapted to work with the Plug Shield on an Arduino, and vice-versa. Tedious.
  • External power – the various power pins on a JN are all tied together, because the voltage drop of diodes would hamper ultra-low power use. That means you can’t hook up a JN to FTDI while a battery is tied to one of the other power pins (unless the battery has an on/off switch and you’re careful).

Some of the above issues have already been sorted out. Others can be addressed in future hardware designs. Some, such as “external power” are likely to remain as is for now. And some just need more or better software.

Adding or modifying software is easy. The hard part is avoiding restrictive decisions which have long-term consequences. Here’s the most challenging one: should I maintain 100% software compatibility with the Arduino world and benefit from all the shared knowledge already built up, or should I start off on a new journey and redo whatever is needed from scratch to reach a workable level again? I haven’t decided.

Screen shot 2009-12-28 at 00.33.52.png

When you hit a wall, do you look for a way around it or do you tear it down? Depends on the wall, I s’pose.

Idiot plug

In Hardware on Dec 23, 2009 at 00:01

Sometimes (far more often than I dare to admit, actually) – I mess up…

Such as the reversed pins on a recent plug.

Here’s the solution:


I’ll call it my “idiot plug”. Saved my day on the power consumption tracker:


Onwards. Quickly, please :)

Power tracker – software

In AVR, Software on Dec 22, 2009 at 00:01

Yesterday’s post described a small circuit to track power consumption of JeeNodes to help optimize sketches for minimal power consumption.

Let’s put that circuit to use, with a bit of software to measure actual power consumption. The basic idea is to continuously measure current and then integrate these measurements to determine the sum of all power consumption intervals, regardless of levels.

The reason for this is that we’re not really interested in current draw but in the amount of charge consumed by the JeeNode. As far as the battery is concerned, drawing 1 mA for 1 hour is the same as drawing 100 µA for 10 hours (in the ideal case, anyway). The fancy way to say this is that we need to measure Coulombs, not Amps. Or rather micro-Coulombs, i.e. µC. That’s really easy once you realize that 1 µA is the same as 1 µC per second. Or to put it differently again: 1 mAh = 3600 mC. So a 1000 mAh battery is really nothing but a 3600 C charge.

Ok, back to the problem at hand: measuring average current draw per second.

Here is a simple sketch which does all the auto-ranging and integration:

Screen shot 2009-12-19 at 19.34.25.png

It reports averaged power drain in µA/sec (the second value is the number of samples per second). The 10% correction which I had to apply in my setup could be due to a number of factors – most likely it’s due to resistor tolerances (they are all 5%).

Here’s an interesting case with the latest rooms node:

Screen shot 2009-12-19 at 20.01.21.png

As you can see, the baseline power drain is a fantastically low 56 µA/sec in this case, but once or twice a minute it goes up to 14 mA/sec for several seconds. Not sure what’s going in here – need to investigate (now that I can!).

It would be nice to automatically detect the baseline, i.e. the average low-level sleep consumption, and things like the peak current and the percentage of the total consumption caused by such peaks. Extending the software to handle this is more work.

With slightly more elaborate software, it will be possible to place the power measurement plug between the measuring JeeNode and the JeeNode under test, and then leave it alone. A 1-day or 1-week average should give an excellent estimate of battery lifetimes.

Power consumption tracker

In Hardware on Dec 21, 2009 at 00:01

After the recent battery life estimation and refinement posts, I wanted to create a more permanent and more automated setup for monitoring the total power consumption of JeeNodes. I expect to be repeating these power usage optimizations regularly, with new sketches.

Here’s the idea. A little interface to let one JeeNode (or Arduino, whatever) monitor the power consumption of another. This ought to provide a fairly accurate measurement within a day or so.

First the schematic:

Screen shot 2009-12-19 at 16.27.09.png

This is a “low-side” current meter. In fact there are two of them in series, one with a 60 mA range, the other with a maximum range of about 1 mA. So this setup can measure up to 60 mA with approximately 1 µA resolution at the lower end. These ranges could easily be changed by adjusting the 5 Ω (2x 10 Ω) and 270 Ω resistors.

The low range resistor has a forward-biased diode, which limits the total voltage drop over it to under about 0.6V. This means that the total voltage drop over the measurement circuit will stay under 1V for currents up to 60 mA. With a 5V supply, that leaves about 4V to be supplied to the JeeNode being tested – more than enough headroom for the 3.3v regulator to do its thing.

Note that there is a drawback to low-side current sensing: the “ground” level supplied to the test circuit isn’t really ground. It’s floating “somewhere” above zero, and what’s worse is that the actual level will depend on the amount of current drawn. But in this case it doesn’t really matter, since the test circuit isn’t connected to anything else anyway (we’re doing all this to measure a battery-power wireless system, after all).

Two op-amps are used to amplify the 0 .. 0.3V signals 10 times. A neat trick: the low range op-amp (on the right) nicely compensates for the floating reference level from the high-range resistor by using that as reference for its negative input. So basically, these two op-amps generate two analog voltages in the total range of 0 .. 3.3V. I picked the OPA2340 CMOS op-amps because they can operate at 3.3V and can output rail-to-rail voltages. They also happen to draw very little current.

Here’s a custom-made JeePlug with all the above components:

DSC_0867.jpg DSC_0872.jpg

Note: I don’t know what got into me while building this plug, but the pins on the port connector are all reversed. So I’m forced to plug this thing in the other way around. Doh!

This is only half the story. Tomorrow: the software side of power tracking.

Update – for a very nice current metering setup, see also David Jones’ µCurrent adapter.

UartPlug class

In AVR, Hardware, Software on Dec 20, 2009 at 00:01

Here is a utility class for the UART Plug:

Screen shot 2009-12-18 at 13.42.26.png

The interface is exactly the same as the Serial class, so it can be used interchangeably. Here is the updated “uart_demo” example in the Ports library:

Screen shot 2009-12-18 at 13.38.44.png

Here’s a test setup with a second JeeNode running RF12demo plugged in:


Sample output:

Screen shot 2009-12-18 at 13.38.29.png

Both input and output are supported by this UartPlug class – this demo is essentially a serial pass-through.

The UART supports accurate baud rates all the way up to 230400, which is in fact beyond the current I2C rates of the Ports library. Even at 57600 baud, I’ve seen several serious overruns with the above demo. One reason is that it’s only reading out one byte at the time, going through a multi-byte I2C bus sequence for each one (!). Note also that the Serial class does not buffer its output, so it can easily bog down everything else.

The UART hardware can support both hardware handshaking and XON/XOFF throttling, so this would be another way to avoid buffer overruns.

Up to say 9600 baud the UartPlug class should work fine, even with several UART plugs on the same I2C bus.


In Hardware on Dec 17, 2009 at 00:01

Some things I just can’t seem to do without are these:


… and these:


Great for all those Projects On Foam in various stages of incubation here at Jee Labs:


Since I’m too lazy to always dismantle and re-use everything – especially POFs – I decided to get some more and also add these mini breadboards and wire jumpers to the web shop.

Pretty low tech stuff, but these just work so well that they’ve become timeless.

Serial datalogger

In Software on Dec 13, 2009 at 00:01

Two new classes have been added to the Ports library:

  • MemoryPlug – provides access to the EEPROM(s) via PortI2C
  • MemoryStream – access one or more pages as a byte stream

Here is a little serial port datalogger, using a Memory Plug on port 4 and a Blink Plug on port 3:

Screen shot 2009-12-11 at 17.00.58.png

This code is now included as “memory_demo” example in the Ports Library.

It collects all incoming data from the serial / USB port, as much as will fit on the Memory Plug’s EEPROM chips that is (512 Kb if all four M24M01’s have been installed).

Pressing button 1 (green LED on my setup) replays all stored data back to that same serial port (this process is interrupted if anything is received).

Pressing button 2 (red LED for me) resets the stream and clears all data stored so far.

Here is some sample output:

Screen shot 2009-12-11 at 16.25.03.png

What I did was: 1) send “aaa”, 2) press button 2, 3) send “bbb”, 4) send “ccc”, and 5) press button 1. As you can see, everything sent after pressing button 2 is echoed back when button 1 is pressed.

The first line of the sample output illustrates random access to the Memory Plug without using streams. Multiple memory chips will be addressed as if they were one, i.e. the MemoryPlug class automatically selects the proper 0x50..0x70 I2C device address.

The public interface to these two classes is as follows:

Screen shot 2009-12-11 at 17.05.36.png

You can define multiple streams at the same time on a single memory plug, by picking different starting pages, and they can fill additional pages in increasing (dir=1) or decreasing (dir=-1) order.

BlinkPlug class

In Software on Dec 12, 2009 at 00:01

A new “BlinkPlug” class has been added to the Ports library. The public interface is:

Screen shot 2009-12-10 at 20.36.51.png

Here is the new “blink_demo” sketch, using a Blink Plug attached to port 3:

Screen shot 2009-12-10 at 20.34.08.png

This code demonstrates how to turn LEDs 1 and 2 on or off, and how to access buttons 1 and 2 – pushed() will detect a transition from released to pressed (with proper de-bouncing), whereas state() returns the current button state (no de-bouncing logic).

There is some special logic in this class, because each LED/button pair on the Blink Plug is connected to the same I/O line. Reading out the button requires briefly turning the LED off, and the I/O line should never be set to drive the output high. These details are conveniently hidden in the above class.

An updated Ports library has been checked into the source code repository.

Note: the repository location has changed, see the CODE page for details.

JeeNode clock

In Hardware, Software on Dec 4, 2009 at 00:01

To follow up on a recent post, here is the same real time clock demo using a JeeNode + USB BUB instead of an Arduino + Plug Shield:


(instead of JeeNode + USB BUB, the new JeeNode NoRF or a JeeNode USB could also have been used)

I chose to use two different ports for RTC and LCD, but these could just as easily have been daisy-chained on a single port.

The changes to the code are minimal, here is the complete sketch:

Screen shot 2009-11-29 at 15.44.07.png

The changes affect a few declarations at the top, and the fact that the use of the Wire library was hard-wired into the getDate() function.

Updated Thermo Plug

In Hardware on Dec 3, 2009 at 00:01

The Thermo Plug prototype has been updated to the final version:


This plug supports either a thermocouple, an NTC, or a 1-wire temp sensor on the AIO line, and either a buzzer or a relay on the DIO line. It does not use I2C.

The connections of the AD597 thermocouple readout chip are now correct, and there’s a new 4.7 kΩ pull-up resistor option when using the 1-wire interface.

I’m still looking for a good way to attach the K-type thermocouple (soldering is not a good option with those metals), and am considering adding this plug as kit with AD597, thermocouple, buzzer, and the rest of the components to the shop. This is the combination I’m using in my reflow oven / grill controller. The bare pcb is already available.

Plug Shield clock

In Hardware, Software on Nov 30, 2009 at 00:01

As a reminder that not everything here at Jee Labs is about JeeNodes, here’s a clock for the Arduino (which keeps track of time, even when not plugged in):


This was built with an Arduino Duemilanove, a Plug Shield, an RTC Plug, and an LCD Plug piggy-backed onto a 2×16 character display.

Here’s the sketch:

Screen shot 2009-11-29 at 13.12.46.png

And here are links to the PortsLCD.h and PortsLCD.cpp source files.

But there could be some serious trouble ahead…

This code depends on an extended version of the LiquidCrystal library that comes with the Arduino IDE version 0017. Since I don’t want to modify that code, I had to use different names, so the PortsLCD.h/.cpp files use the following class names:

  • LiquidCrystalBase – an abstract class containing all the generic LCD code from the original class
  • LiquidCrystalPins – this is for use with plain pin connections, as before
  • LiquidCrystalPort – this uses bit-banged I2C with one of 4 JeeNode ports
  • LiquidCrystalI2C – this is for use with hardware I2C, using the Wire library

These names are slightly different from the previous ports-only version, btw.

So PortsLCD is a library which does everything the original did, and more. The flexibility is that you can write your sketches with this and then use any type of LCD you like with it, by just changing a single line of code. And if you’ve got a different hardware hookup, a new class can be added for it based on this same code, so that again your sketch only needs to change a single line of code to use it.

So far, so good. This is the benefit of object-oriented code and polymorphism.

But there is a price, due to the way the Arduino IDE does things: even if you don’t use the Wire library, you’ll need to include it in your sketch! For similar reasons, I’ve been forced to include the RF12 driver in all my demo sketches, even those that don’t use it. Leaving it out leads to build errors and prevents uploading.

This is not a C/C++ issue, the gcc compiler is actually quite smart about leaving out things which are never used. No – this complication is caused by the way in which the Arduino IDE tries to do some clever things to simplify naive use of libraries. I’ll go into this in another post – it is not a show stopper yet, but it may become one as I start combining more features and code, since memory on an ATmega is quite limited.

To put it bluntly: the way the Arduino IDE currently deals with libraries is a ticking time bomb…

Updated Plug Shield

In Hardware on Nov 28, 2009 at 00:01

The updated Plug Shield has come in, here pre-assembled and with all the headers soldered on:


This fixes the problem with D9, and adds one extra feature: there is now a pull-up for the IRQ line, with a solder jumper to connect it to D3. See the label “JD3” at the middle right in the above picture. This makes the IRQ pin on the port headers compatible with the JeeNodes when an IRQ pin is needed.

This shield is still called “v1” due to an oversight, but that should not be too much of a problem because only 3 prototypes have been sent out. If you got such an “old” prototype shield and want the final one, get in touch and I’ll send it (pcb-only).

On a related note, the Memory Plug has also been updated (to “v2”, correctly this time). This fixes an addressing limitation with 128 Kbyte EEPROMs.


Meet the new Analog Plug

In Hardware on Nov 25, 2009 at 00:01

Here’s the revised Analog Plug (AP2):


Still the MCP3424, i.e. from 12- to 18-bit (!) resolution, depending on configuration, supporting 4 differential inputs with an input range of -2.048V to +2.048V. The plug is I2C based and can be daisy-chained with other I2C plugs on the same port.

Here’s a hookup to measure the voltage of a NiCd battery:


Note: I did not forget the solder jumpers. With this chip, floating inputs are ok. The I2C address is 0x68 (which is actually not such a good choice because it conflicts with the RTC plug).

The following code turns the JeeNode into a 4.5’ish-digit voltmeter:

Screen shot 2009-11-23 at 18.21.27.png

And here is the sample output:

Screen shot 2009-11-23 at 18.05.39.png

Is it precise? You bet.

Is it accurate? Well, my multimeter says 1.265…

Meet the Output Plug

In Hardware on Nov 17, 2009 at 00:01

Here is another I2C I/O plug:


It combines the MCP23008 8-bit port expander with a ULN2803 darlington array which can drive up to 500 mA @ 50V. The ULN2803 includes clamping diodes, so that relays and other small inductive loads may be tied directly to this plug.

Here is an example with a little unipolar stepper motor:


The red-black wire is from a 12V lab supply.

This demo sketch pulses the lower 4 bits of the output plug to rotate this motor back and forth by 200 steps:

Screen shot 2009-11-12 at 15.46.22.png

The above was inspired by some sample code by Chad Phillips. It has been added the the Ports library as “output_stepper” example sketch.

Memory Plug redux

In Hardware on Nov 15, 2009 at 00:01

Another case of me mixing up specs. Here’s the original prototype:


And here’s the latest one:


Guess what… the original prototype is ok. The “latest” one is bad :(

While testing the original plug, I noticed that multiple chips showed up at I2C addresses 0x50, 0x52, etc – i.e. with a gap in the addressing.

I thought this was a mistake in connecting the E1 and E2 address lines, but it turns out that the lower address bit is needed for 128 Kb addressing (while testing, I used some spare 64 Kbyte units). So without thinking, I changed the lines and had “final” versions made.

But it was no mistake… an M24M01 needs 2 I2C addresses to access both 64 Kbyte banks of its memory:

Screen shot 2009-11-08 at 19.27.04.png

So, in other words the latest plugs can’t hold 4 chips of type M24M01 – only two, in positions 0 and 2.

The original plug works as intended, with each 128 Kbyte chip responding to two I2C addresses. So a fully populated plug looks as eight different I2C memory chips, each capable of storing 64 Kbyte.

Doh. I’ll need to re-order. Until then – the remaining old / green plugs will be shipped.

Note: if you ordered memory plugs and received blue ones, and if you want to be able to use them with more than two 128 Kbyte memory chips, let me know and I’ll send you the boards which properly support all 4 chips.

Arduino plug stack

In AVR, Hardware on Nov 13, 2009 at 00:01

You could combine all these …


… and create an Arduino sandwich like this – with full access to all the Arduino pins:


That’s a Plug Shield with, from left to right / top to bottom:

Each of the plugs can be accessed via I2C, i.e. using the Arduino’s “Wire” library.

Would all this work? Yes, I’m pretty certain it would.

Would it be useful? Probably not in this combination…

I just wanted to show off the I2C plugs and shield ;)

Meet the Pressure Plug

In Hardware on Nov 12, 2009 at 00:01

Here is a little interface board for the BMP085 atmospheric pressure sensor – I2C based and daisy-chainable as usual:


This sensor is a bit tricky to solder by hand, as you can see in an older post.

The sensor is extremely sensitive and measures both pressure and temperature. The “bmp085demo” sketch in the Ports library hasn’t changed:

Screen shot 2009-11-05 at 15.16.54.png

Here’s some sample output:

Screen shot 2009-11-05 at 15.16.32.png

The temperature is not 27°C around here ;) – this board is simply still cooling down from the reflow!

This new Pressure Plug will replace the hand-soldered one in my OOK relay, of course.

Analog, but not quite

In Hardware on Nov 11, 2009 at 00:01

The original Analog Plug is a bit overkill and a bit expensive for 8 simple 12-bit channels. I’m going to switch to an MCP3424, which has “only” 4 channels. The interesting bit is that they go all the way up to 18-bit resolution – if you need only about 4 samples per second (think thermostats, voltmeters, etc).

Here’s the board I had made:


And here’s the patch I had to apply (VSS and VDD mixed up, doh!):


This sketch puts the chip in continuous 18-bit mode and reports the readings:

Screen shot 2009-11-05 at 17.54.24.png

Sample output:

Screen shot 2009-11-05 at 17.54.05.png

I tied channel 1 “-” to ground and connected a small trimpot to “+” – note that the input range is bipolar and should be within -2.5 .. +2.5 V (or less, since input gain is adjustable from 1x to 8x). The sample output shows readings while turning the trimpot a bit, with 18-bits these readings lie between -131,071 and +131,071.

Luckily only a few of these plugs have been made so far (as part of a larger panel with other stuff on it), so there’s no harm done. To redo them properly will just take a few more weeks, as usual…

Extension cables

In Hardware on Nov 10, 2009 at 00:01

As an experiment, I had these 150 mm long custom cables made:


They can be used for anything of course, including FTDI. But their main purpose, and the reason the wires are colored the way they are, is for use with ports and plugs:

  • PWR = Red
  • DIO = Yellow
  • GND = Black
  • +3V = Green
  • AIO = White
  • IRQ = Blue

Looks like these will be quite convenient, also for mounting stuff inside an enclosure.

Got a bit more than I will need here at Jee Labs, so they are now also in the shop ;)

Meet the Plug Shield

In Hardware on Nov 5, 2009 at 00:01

There are a couple of Arduino’s lying around idly here at the Jee Labs, so I thought it’d be nice to be able to attach some JeePlugs to them. Not all interface tasks require a wireless JeeNode, after all…

The main issue is how to deal with different voltage levels, i.e. 5V logic levels on the Arduino vs 3.3V on all the Jee stuff. Luckily, this is not a problem for an I2C bus, since there are chips which automatically convert between two different I2C bus levels.

So here’s the Plug Shield, carrying an RTC plug:


Check out the gold lettering!

There is room for up to 5 port connectors, all connected in parallel, with right-angle 6-pin female headers (I take straight headers and just bend their pins). This supports two plugs lying flat on the board and three pointing outwards, although many more can be attached through daisy-chaining.

The PWR pin is connected to 5V. The IRQ signal is currently not connected to any pin but could be tied to PD3 to be compatible with JeeNodes.

Note that the Plug Shield will only work with I2C-type JeePlugs – things like the Room Board and the Thermo Plug cannot be used.

There is a regulator to supply 3.3V to the port connectors on-board, as well as an I2C bus level converter. To maximize the space available to plugs, these are all SMD’s. The reset button and ISP header have been brought out as well, since the original ones on the underlying Arduino board cannot be reached.

This shield allows stacking and can be sandwiched between an Arduino and any other shields. The only requirement is that analog pins 4 + 5 must be used for hardware I2C – these are not available as I/O pins.

Here’s a demo, reading out the RTC:

Screen shot 2009-11-03 at 00.32.07.png

Uses the standard “Wire” library that’s included with the Arduino IDE.

There is a wiring mistake in the shield, causing PB1 to be shorted to ground, so as a result digital pin 9 can’t be used with this shield. I placed one of the headers the wrong way around. Doh!

I’ve added this shield in the shop anyway. Got only a handful of ’em for those who don’t care too much about that PB1/D9 issue. New shields will be made soon.

Apart from that, it’s working great. All I2C-based JeePlugs can now be used with standard Arduinos, without plug-stacking conflicts or voltage translation hassles. Want an RTC? LCD? UARTs? More I/O lines? You got it.

Update – The pcb was updated soon after this post, the above mistake only applies to the first few shields.

LCD Plug

In AVR, Hardware, Software on Nov 1, 2009 at 00:01

Here’s the new LCD Plug:


It’s a little piggy-back board for standard LCD modules with 16-pin connectors. The middle 4 pins are not connected, so that two 6-pin male headers are in fact enough to hook this board up to the LCD.

Here is a setup using a 2×16 character display:


The interface uses I2C, so this “plug” can be daisy-chained like all the others. The plug uses an I2C expander chip with a fixed I2C address of 0x24. There are two jumpers to select the voltage level for driving the logic supply and the backlight, respectively. The backlight can be turned on and off under software control.

A generalized version of the LiquidCrystal library included with the Ardiuno IDE 0017 is used to redirect the actual interface through a bit-banged I2C bus, using the Ports library. This was described in an earlier post. Details about how this code works are also available, see this post.

The latest Ports library now includes the new code, including the “lcd_demo” example as shown above:

Screen shot 2009-10-31 at 16.06.14.png

The only difference with the LiquidCrystal example is the definition of port 1 as I2C bus, and defining the “lcd” object to connect to the display via this I2C bus.

Room Board update

In Hardware on Oct 31, 2009 at 00:01

Here is the latest version of the Room Board, just in:


It works for all combinations of SHT11/DS18B20, PIR/EPIR, and LDR. Here’s SHT11 + PIR + LDR:


And here’s a setup with DS18B20 + EPIR + LDR:


Both can be used with the latest version of the rooms sketch.

But… if look closely at that second board, you’ll see that I still got it wrong!

The DS18B20 temperature sensor is labeled the wrong way around, and must be mounted as follows:


Drat – same mistake as last time!

And now I’ve also figured out how this happened. Here is the pinout shown on the Dallas Semiconductor / Maxim data sheet:

Screen shot 2009-10-30 at 14.43.29.png

B o t t o m  view. Doh!

I’m going to declare victory anyway, and call these boards final. Even though this issue will have to be documented and spelled out everywhere to prevent people from falling into this trap. I have 100 room boards, and I simply don’t want to trash them and wait another 3 weeks. Most people will probably use the SHT11 sensor anyway, where this issue is irrelevant.

Available in the shop now. Foul-ups happen, so be it. End of story.

New UART plug

In Hardware on Oct 28, 2009 at 00:01

The revised UART plug now works as expected:


This board has been reworked to use a 3.68 MHz resonator. Two solder jumpers allow using several UARTs on a single I2C bus.

Since the UART chips include 2x 64 bytes of buffering for transmit and receive data, and since they can be set to do hardware and software flow-control, this is quite an effective way to offload work from an ATmega328, once you need more than its single on-chip serial port.

See a previous post for sample code.

Documentation can be found at – the plug code (“up1” – has to be lowercase) at the end of this URL will redirect to the corresponding page in the documentation tree.

The BC1, BP1, EP1, MP1, PB1, and RP1 plugs are now also available. Nothing really exciting to report about them, I’m still waiting for a couple of more interesting ones such as the LCD Plug and the updated Room Board and Thermo Plug.

Assembly service

In AVR, Hardware on Oct 24, 2009 at 00:01

It’s time to try something new!

Sometimes, this DIY electronics stuff can be a bit daunting. Maybe you’ve never soldered microprocessor circuits before. Or maybe you’re worried about that RFM12B “SMD” module on the JeeNode. Or maybe you just want to get going fast, and not spend your time on the hardware side of things.

Meet the new Assembly service option:


For a small fee, I’m going to offer to assemble JeeNode kits for you, as well as soldering headers onto any of the plugs available from the shop.

This can help more people get started on this wireless and sensor hookup stuff. And it lowers your risk – you could get two kits, have one of them assembled, and build the other one yourself. Or if you don’t care about soldering at all, just get all the pieces you want to hook up in assembled form.

In fact, I’m going to extend this new service even further: if you get a kit to build yourself and it turns out that you can’t get it to work, then you can send it back and I’ll assemble / finish it for you. I can only do this if all the components are still undamaged, otherwise you’ll need to get a replacement kit. Since I don’t know whether this will work out, nor whether I can handle such a “return/repair” flow of items, I will only commit to do this until the end of November. If it works well enough, I’ll prolong this service.

The reason for doing this is not to add a massive amount of assembly to my workload, but to help people take the plunge with less risk. Especially if you’re new to all this physical computing stuff and electronics, I think you’ll find out that assembling kits can be a lot of fun and very rewarding. But hey, if you’re in doubt, just get a kit and some assembled parts so you don’t have to worry about everything at the same time.

Documentation conventions

In Hardware on Oct 19, 2009 at 00:01

With so many plugs and boards (f)lying around here these days, I’m trying to stick to a couple of tagging and documentation conventions.

First and most important one, is that each package has a unique ID which refers to a web page:


Even each board has such an ID:


(this plug is now called an “RTC Plug”, btw)

When you type in the URL, you’ll be redirected to its main documentation page – for example:

Picture 3.png

Did I mention that everything on this site is open source, software and hardware? Well, as you can see above, all the design files are freely available. Enjoy… just don’t do anything with ’em your mother wouldn’t approve of.

The other way to get to these documentation pages is via the “DOCS” link at the top of all the weblog pages. It points to an index of all available documentation pages.

As you can see, all product IDs are two letters plus a version number from 1 to 9. URLs of the form + lowercase-letter + lowercase-letter + digit always redirect to the latest documentation page, regardless of the structure of this site.

I’ll let you know when I run out of all the 6084 codes :)

Thermo Plug update

In Hardware on Oct 17, 2009 at 00:01

The Thermo Plug works, basically. Here’s the configuration with an NTC sensor and a buzzer:


Sample output, reading out the ADC periodically:

Picture 8.png

As the temperature goes up, the resistance and the ADC readings both go down. The actual conversion to the corresponding temperature will require a calibration and either a lookup table or a polynomial fit, as described in a previous post.

Here is the board layout:

Picture 8.png

The buzzer can be replaced by a relay plus clamping diode. Since it’s driven via an NPN transistor, there will be enough current to drive several types of relays. The buzzer / relay are hooked up to PWR, not +3V.

Another configuration for this board is with the AD597 thermocouple sensor chip. Unfortunately, I forgot to add a wire between pins 1 and 3, so it has to be added by hand – as you can see here:


Another view, with the attached K-type thermocouple:


The thermocouple responds to temperature change much faster than an NTC – and it’s already calibrated (second number is °C):

Picture 9.png

When I touched the sensor with my hands, it took less than half a second to detect a 5° increase!

Here is the sketch I used for the above demo:

Picture 10.png

Ok, time to tweak the Thermo Plug and fix that missing wire in the next pcb run.

New LCD Plug

In Hardware on Oct 16, 2009 at 00:01

There’s a new LCD Plug on its way – hopefully this one has the correct pinout.

Here’s the schematic:

Picture 7.png

This board is based on the same MCP23008 chip as the Expander Plug. Six outputs are used to drive the LCD panel (in 4-bit mode), one output controls power to the backlight, and one spare I/O line is available for a button or a LED – this is brought out to a 2-pin connector.

A breadboard version of a similar setup was described in an earlier post. The software to drive this plug has also been presented before.

The layout of the LCD Plug is as follows:

Picture 3.png

It departs slightly from the normal plug layout, because this board is intended to mount on the back of the LCD panel. There are two solder jumpers to select between PWR and +3V for both logic and backlight. R3 is a current limiting resistor for the backlight, it can be bypassed with a third solder jumper if not needed.

Now I get to play the waiting game again, to see if it comes out ok…

Room Board update

In Hardware on Oct 14, 2009 at 00:01

I finally figured out what was going on with the new Room Board.

The bad news: there are three errors on the board when using it with a 1-wire temp sensor and the EPIR motion detector board.

The good news: each problem is easy to work around.

Problem #1: the 1-wire DS18B20 outline is reversed:


So much for taking an EAGLE library component from the web and not checking it…

Problem #2: the 1-wire sensor really needs a 4.7 kΩ resistor pull-up:


The solution for both problems is to solder the sensor on the other way, and to add a resistor between two of the pins, as shown above.

Problem #3: a pull-up resistor is missing (again!) – it turns out to be essential to get the EPIR in the proper serial mode on power-up:


This can’t be done by enabling a pull-up in the ATmega as I originally thought, because that’s too late. The EPIR really checks for this on power-up. The solution is (again!) to manually add a 100 kΩ resistor between pins 2 and 4 of the EPIR connector.

Phew. So now all configurations work. Sort of… :)

I’ve added the Room Board to the shop, but as PCB only because there are several configurations possible and because some of these sensors and boards are relatively expensive (also for me to keep in stock).

With the caveat that I only have a handful available right now, and that these are “imperfect” prototype boards. With SHT11/SHT15 sensors and simple 3-pin PIRs, these prototypes will work fine. But for 1-wire and/or EPIR use, you’ll need to patch things as described above.

I’m going to create a new revision with all these issues fixed, of course. But it will take a few weeks to have new boards made.

The “Rooms” sketch for these boards has been updated to work with all configurations. It needs the NewSoftSerial library if the EPIR is used, and the OneWire library if the DS18B20 is used.

Experimentation setup

In AVR, Hardware on Oct 11, 2009 at 00:01

After coming up with the JeeBoard, which needs a PCB with at least an I/O expander and two LEDs/switches, I decided to go one step simpler and just wire up a version with no active components at all:


It connects the same 3.6 .. 4.5 V battery pack through a slide switch, and ties a breadboard to the AIO + DIO pins of ports 1 .. 3, along with +3V and GND. With a few headers placed flat on the board for various plugs.

Wiring this up is simple – note the added rubber feet:


Now it’s ready to go, with 3 rechargable NiMH’s:


And here’s the final setup:


Just to show how you can go nuts with plugs:


The battery pack connection is removable to give me a nice spot to insert a current-measuring multimeter.

First demo of this board coming up tomorrow…

Room sensor board

In Hardware on Oct 10, 2009 at 00:01

At last, the latest Room Board design is starting to work:


I’m no longer calling this a plug – that’s now reserved for things which you stick into a single port. One of my “tics” is that I like to play games with abbreviations – in this case: trying to abbreviate all product names to two unique letters plus a version number. By not calling everything a plug, I get more letter combinations to play with – so this thing is the “RB1” :)

The version you see above is my preferred configuration, but it requires sensors which are a bit expensive (SHT11) and Europe-based (ELV’s PIR kit). So there is room on the board for some alternatives: the SHT11 can be replaced by a DS18B20 1-wire temperature sensor if you don’t need humidity measurements. And the ELV PIR kit can be replaced by any other PIR sensor which runs off whatever voltage you’re feeding to the PWR pins – many PIR sensors can run with 5V and have an open-collector output, though their three pins may be oriented differently. Parallax and Futurlec come to mind.

The PIR can also be replaced by an EPIR (DigiKey part# 269-4710-ND, non-RoHS). It’s low cost but it draws about 5 mA due to its on-board (“sub-embedded”?) microcontroller. The Room Board will work with the EPIR plugged into the 8-pin “PIR2” connector on the other side of the board, but you have to also move the LDR to the pins marked LDR2. The reason for this is that that the EPIR uses a bi-directional serial connection and therefore needs two signal pins. Luckily, it has the smarts to also handle an attached LDR – so the result is the same.

Here’s the Room Board with an EPIR and a DS18B20 1-wire temperature sensor:


Haven’t tested this configuration yet, but every combination of PIR-or-EPIR plus SHT11-or-DS18B20 will be supported. Once the Room Board has been fully tested, it will be listed in the shop.

The Room Board can be plugged into any two opposite ports, but the software expects one of two specific board orientations on port 1 and 4: the PIR and EPIR must be located in the middle, i.e. roughly in between all port headers. It’s easy to change the code if you need other configurations.

Speaking of code, the source code for this setup is available here, as the “Rooms” sketch. It reads out the sensors and periodically sends out the readings over wireless.

Latest news: all the plugs and boards described yesterday have now been added to the shop, as either pre-assembled or pcb-only units.There are only half a dozen boards right now, so please be patient until new ones come in. Please get in touch if you have questions or run into anything unexpected with these plugs. I’m gradually filling in all the associated documentation pages, but some of them are bound to remain skimpy for a while.

Tiny as these plugs are, they sure keep me busy!

Expander Plug, revisited

In AVR, Hardware on Oct 9, 2009 at 00:01

Got some revised plugs. The Expander Plug now works:


Here’s a sketch which blinks all pins on the expander:

Picture 3.png

I forgot to check the A0 solder jumper orientation, so I accidentally wired my first plug up for address 0x21 instead of 0x20. Each Expander Plug can be configured for I2C addresses 0x20..0x23, i.e. up to 4 expander plugs can be daisy-chained on each port.

Expander plugs work nicely with the Breadboard Connector, to hook up a mini-breadboard like this:


The width of a mini-breadboard is slightly less than an Expander Plug + sideways headers, so daisy-chained plugs can each have their own breadboard.

In summary: the Blink, Expander, Memory, RTC, and UART Plugs all work. So do the unpopulated Proto Board and Breadboard Connector, of course.

More news about prices and availability in the shop tomorrow… once I finish my homework and figure out a few remaining pesky little details and logistics issues.

Prototyping board

In Hardware on Oct 7, 2009 at 00:01

Plugs are not required to hook up to a JeeNode, of course. They just act as pre-wired components which can be combined and re-used at will.

Here’s a more Ardino’ish shield-like approach, the Proto Board:


It doesn’t have any wiring, just plated-through holes to allow components and connectors to be soldered to either side. The rectangle on the left matches the SPI/ISP header below, while the rectangle on the right matches… an upcoming modification of the PWR/I2C connector.

The board is slightly asymmetric, i.e. larger by 0.1″ on one side than the other. Note that due to the way port headers are aligned, plugging this board the wrong way around has no effect other than re-arranging port numbers. No risk of shorts or wrong voltages on any of the pins.

Here’s another way to plug two of these boards in, if the port numbers printed on the board are ignored:


That’s about as much real-estate we can get from generic plugs. For larger projects I use standard perf board with copper islands and push the JeeNode upside down onto it i.s.o. the other way around.

Optimizing SMD

In Hardware on Oct 6, 2009 at 00:01

I’m trying to simplify some plugs a bit. The UART plug has a 3.6864 MHz crystal and two 18 pF caps:


(yeah, it’s an awkward fit)

Turns out that it works just as well with the 16 MHz + 10 pF combo I’m using in another project – using adjusted baudrate dividers, of course:


(somewhat better fit)

But hey, why stop there. A resonator with built-in caps would get rid of two more components – and it’s more than precise enough to generate accurate baudrates:


(awkward fit again, but who cares since it’s a test)

Cool: the 3.68 MHz resonator works – a 40% reduction in component count! Now I can make a new “release”.

I’m still readjusting my neurons to this hardware world. It sure is different from software – even though bits & bytes could be considered to be infinitely small, this hardware stuff somehow feels tangibly smaller…

Clock fixed

In Hardware on Oct 5, 2009 at 00:01

Ok, after switching to a DS1340Z chip, the RTC Clock Plug now works:


Sample output:

Picture 2.png

I first ran a sketch to set the time, then commented out the setting part and uploaded it again. As you can see, the time kept ticking – just as in real life…

And it keeps going on its internal battery while power is disconnected:

Picture 3.png

That’s the whole point of this plug!

The battery holder is not perfect. The type I got is for surface mounting, but the board is for a narrower through-hole type. Had to snip the sides of this one off a bit, and it didn’t solder on quite as intended:


But it works. The spring action is very strong and pushes the battery to the board anyway.

The code for this RTC Plug has been added to the Ports library as “rtc_demo” example, and is available here.

More serial ports

In AVR, Hardware on Oct 4, 2009 at 00:01

Here’s an easy way to add more serial ports via I2C:


I got the wrong crystal size, so it’s mounted a bit awkwardly:


There are two jumpers, allowing up to 4 serial ports to be added to each I2C bus – i.e. up to 16 on the bit-banged I2C buses, and 4 more on the hardware I2C line. Since the A0/A1 jumpers actually support up to 16 addresses with a bit of extra wiring, you could theoretically connect up to 80 serial ports to a single JeeNode!

Here’s some sample code:

Picture 5.png

It sets the serial port to 57600, 8 bits, no parity and then sends whatever comes in to the “normal” serial port. The default fast I2C bus rate of over 1 Mhz appears to work just fine.

The header of the UART plug is compatible with FTDI, so you can hook up another JeeNode to it:


In this case, I used a JeeNode with a room plug prototype. Sample output:

Picture 3.png

This demo code has been added as “uart_demo” example in the Ports library and is also available here.

Voltage Plug

In AVR, Hardware on Oct 2, 2009 at 00:01

The Voltage Plug generates up to four 0 .. 3.3V levels using MCP4725 12-bit DAC’s controlled from I2C:


This sketch switches between 0 and 4095, displaying as 1.2 mV and 3.295 V on my multimeter, respectively:

Picture 1.png

The cycle time was set to 5 seconds to give my auto-ranging multimeter time to adjust itself.

There is room for 4 DAC chips, which seems like a bit of overkill, but I couldn’t think of anything else to put there and the board looked so empty :) – perhaps some sort of voltage-follower op-amp or amplifier stage would make more sense? Anyway, I’ll probably remove two of those chips from the plug again.

The MCP4725 only has one pin to specify the lower address bit. There are in fact 4 different chips available from the manufacturer, to support up to 8 DAC’s on a single I2C bus. Since I got the “A3” version – and since I mixed up high and low again – this particular test uses address 0x67. For the final version I’ll fix the low-address bit and use “A0” versions, i.e. 0x60 and 0x61.

No LCD Plug yet

In Hardware on Oct 1, 2009 at 00:01

As mentioned before, the LCD Plug will need to be redone. The MCP23008 chip pinout was completely wrong…

But hey, it does look nice, doesn’t it?


Here’s how it’s supposed to go on the back of any LCD with a standard 16-pin header:


The board can be mounted very close to the LCD because it uses SMD parts:


Alternately, it could be flipped over and mounted alongside the LCD.

Note how the solder pad configuration is on the other side, so it can be adjusted once mounted. Not included in this first prototype is a small trim pot to adjust the contrast level.

So the real LCD Plug will take a bit longer – hopefully the next board will be without these crazy mistakes…

Analog Plug

In AVR, Hardware, Software on Sep 30, 2009 at 00:01

The second plug panel has arrived. I’ll document my test results in the coming days.

First, the Analog Plug – an 8-channel 12-bit ADC connected via I2C:


It’s based on the ADS7828 chip. Here’s a demo sketch to read it out:

Picture 3.png

I hooked it up using various gimmicks lying around here – this ties a trim pot to channel 4, with range 0 .. 3.3V on the wiper:


As you can see, the Breadboard Connector can be used to hook up to 8 of the 12 pins of this plug.

Here’s some sample output:

Picture 1.png

I slowly turned the wiper as you can see. It stops at 4095 counts, which represents the 2.5V of its internal reference. Appears to work fine in this test setup at the maximum I2C rate, somewhere over 1 MHz. The readings didn’t change by more than one count when touching various parts of the circuit, so as first impression it looks like it’s pretty stable.

This plug has two solder jumpers, to configure its I2C address to 0x48 .. 0x4B, which in hindsight is a bit overkill. Only minor nit is that I mis-labeled the A0 jumper – as shown in the picture, the address ends up being 0x49 i.s.o. 0x48. Oh well, a small silkscreen fix will resolve that later.

So there you have it – eight 3.5 digit voltmeters on one tiny blue-and-gold plug :)

LCD display via I2C

In AVR, Software on Sep 28, 2009 at 00:01

Ok, it’s working – always takes longer than expected, especially if you mess up in both hardware and software!


There’s a miniature trim pot on the left to set the contrast level. I haven’t yet added the transistor to turn the backlight on and off.

Note that with an MCP23017 chip there are 9 I/O lines available for other purposes. On the upcoming LCD Plug, I’ll probably use the smaller MCP23008 instead.

This particular setup works at the maximum I2C bus speed supported by bit-banging, which should be well over 1 MHz – I haven’t measured it. If the bus is long or is shared with slower peripherals it can be lowered to 400 KHz or 100 KHz by specifying an extra argument in the PortI2C constructor.

The sample code is available here. It will be integrated with the Ports library later.

PS. There are a few days left for the special offer in the shop. If you’ve ordered before or have participated on this weblog or in the forum, you can get 20% off until the end of September. Email me for a discount code.

Mounting options

In Hardware on Sep 27, 2009 at 00:01

I’ve been getting some questions about mounting options for the JeeNode lately. And once some plugs are out, that same issue is going to come up for these too, no doubt.

There are no mounting holes in the JeeNode. The reason for this is that it would increase the size by quite a bit (one hole isn’t enough, even two is debatable), which in turn could actually reduce the options for using a JeeNode since it would be larger than the current design.

The basic solution for this for me, is to treat the JeeNode as a module that plugs onto something else – be it a generic board such as the Jeeboard idea I described a while back, or a custom board created for a specific application.

Here is an example of a JeeNode with an LCD display:

Picture 2.png

Note that the JeeNode is mounted upside down, with the components facing downwards.

But where do you go from there? One approach would be to place a transparent acrylic plastic panel over this entire thing, with some stand-off’s to create a sandwich consisting of base panel, JeeNode and other components, and the acrylic panel on top. That’s the geeky way to do it: make the electronics visible!

I’m not sure I’d always want that. I also like things which are “closed”, with only control/display functions visible, and the whole thing having a nice and calm front plate.

This would be an intermediate solution – a clean front panel hiding all the techy stuff underneath it:

Picture 3.png

Still open on the side, where the connectors, power jacks, and even simple controls switches could be located.

The reason why all this awkward compromising is needed of course, is that with only single units (or say a few dozen kits), there is simply no way to get custom enclosures made that are affordable and also really look sweet – a JeeNode is not an iPhone!

Here are a few other options I’ve been pondering about:

  • Cardboard – design a fold-up box and print it out as template for a DIY cardboard enclosure. Would be very low-cost, but not very sturdy. And it looks a bit cheap…
  • Wood – this is the classical enclosure: a lot of work, but you can make it look any way you like, if you’re willing to go through all that. Takes a lot of craftsmanship.
  • Sandwiched foam – of the kind used as poster board for photographs. Again, a DIY design which you’d have to cut out and assemble yourself. Probably not easy to get real clean edges, cutouts, and holes. Not truly sturdy.
  • Acrylic front – as described above: a base pcb with everything mounted on it and the acrylic as cover on top. The you-can-see-what’s-inside option. Not easy to do yourself without a laser cutter or CNC router.
  • Aluminum front – this is a variation of the acrylic front. End result is no longer transparent, but creating a clean panel with labels is not trivial.
  • Prefab box – this is what many hobbyists do: get a plastic box, and drill holes and cut-outs in it, possibly also with an aluminum faceplate. Again, hard to get a nice clean result without a CNC router. But to be honest, I don’t think these (mostly black) boxes look that spiffy…

I really would love to find a nice generic solution for this. Right now, since pcbs are already being made completely to specification, and because they end up looking quite nice, I’m inclined to look for solutions with either the front, the back, or perhaps even both made of pcb material. With SMT components, most if not all through-holes can be avoided, leaving the back side available for all sorts of visible cutouts and labeling.

So what’s the solution? Just let everyone figure this out for themselves? Start saving for a laser cutter or a CNC router to be able to provide simple but accurately machined parts? To be honest, I wouldn’t mind doing the CNC thing – but until it becomes clear what a desirable result should look like, there’s little point picking any tool!

And then there’s plugs and daisy-chained plugs…

If you’ve got further suggestions or ideas on how to come up with kits that not only work well but also make the end result look really nice, please let me know!

Generalized LiquidCrystal library

In AVR, Software on Sep 26, 2009 at 00:01

Let’s dive into some C++ code for a change…

The Arduino version 0017 IDE has a nice library for driving standard character LCD’s, called… “LiquidCrystal”. The nice thing is that it mixes in the print() / println() functionality which is also used in the Serial library.

That makes it very easy to change a sketch to use either the serial port or the LCD screen to display results. Here’s how – let’s say you used this code in your sketch to print a value to the serial port:

Picture 2.png

The first thing to do is to generalize this slightly:

Picture 3.png

Functionally, nothing has changed. That’s the whole point, because you can develop and extend the sketch while testing everything via the serial port, as usual. Just use “Output” everywhere.

To change the output to the LCD, replace that “#define” line by the following lines of code:

Picture 4.png

This adds a bit of logic to easily switch between serial and LCD, without having to change a thing in the rest of the sketch. The “(2, 3, 4, 5, 6, 7)” parameters have to be set to the pin numbers actually used for your specific setup, of course.

So far, so good, although none of this applies to the I2C-connected LCD I’m working on. But by extending and re-organizing it a bit, it is possible to re-use most of the code of the original LiquidCrystal library.

The first thing I had to do was to rip apart the general and the pin-specific logic. That’s where C++’s abstract base classes and virtual member functions come in. I created a new “LiquidCrystalBase” class which has all the original code except for the pin-specific parts:


The “virtual … =0” is C++’s funny way of saying it doesn’t need definitions for these three functions yet. The result is an incomplete class – you can’t create objects of type LiquidCrystalBase, you can only derive other subclasses from it. Tricky stuff, but bear with me…

Note that all the pin-specific member variables have been removed as well.

The next step is to re-define the original LiquidCrystal class in terms of LiquidCrystalBase:

Picture 5.png

If you compare this to the original code, you’ll see that most functions member definitions are missing. That’s because they have already been defined in what is now LiquidCrystalBase, and the new LiquidCrystal inherits everything from it.

What LiquidCrystal does add, is a definition and implementation for each of the virtual config(), send(), and write4bits() members. It is sort of “filling in” the missing functionality. So the result is… a LiquidCrystal class which does exactly the same as the original.

That seems pretty useless, but it isn’t – what we now have is a generic part and a specialized part. Which means it is now very easy to implement a variant which works exactly like the original, but going through the I2C port interface instead:

Picture 6.png

Nice. Only a little bit of new code was needed to create a completely different hardware interface which is fully compatible with the original LiquidCrystal class.

Here’s the original example, using this new LCD-via-I2C library:

Picture 8.png

Note that the I2C port is available as “myI2C” and can be shared with other devices by defining them here as well. You could even daisy-chain multiple LCD displays on the same port if you wanted to.

That’s all there is to it. The sketch code itself remains the same. Welcome to the world of abstraction, à la C++ !

Update – the final version and source code are described in this followup post.

LCD Plug prototype

In Hardware on Sep 24, 2009 at 00:01

For one of the numerous projects here at Jee Labs, I’m going to need a little 2×16 LCD panel hooked up to a JeeNode. Time to get the breadboards and jumpers out:


On the left is a breadboard-friendly 5V power supply.

The chip is an MCP23017, which is a 16-bit GPIO expander for the I2C bus. For the LCD, I only need 8 pins but this particular project needs a few more, hence the MCP23017 i.s.o. of the MCP23008. What’s the project? Well, for now let me just say that it’s about Volts and Amps (no, not because it’s an electrical circuit).

Here’s the MCP23008, as originally planned for use with LCD panels:

Picture 2.png

The chip is running at 3.3V, matching the I2C bus, but the LCD is powered at 5V. This should not be a problem since all connections on the LCD are inputs, and a 3.3V “high” level ought to be sufficient as 5V “high” level as well. The PNP transistor for backlight control will need a second resistor between B and E, though.

Next step is to come up with code for this I2C setup!

Solder paste on gold-plated boards

In Hardware on Sep 22, 2009 at 00:01

Did I mention that blue + gold is the new chique around here?

All JeeLabs boards will use a blue solder mask and gold plating from now on, which is very nice for soldering. And because I think it looks nice :)

You may have seen this already, because all recent JeePlug proto boards use that design.

To make sure that solder paste would work properly, I did a little reflow test. First a hefty dab of solder paste of varying thickness, and three 0603 resistors:


Can you spot that third resistor? Hint: it’s parallel to the lettering.

Then into the reflow grill, taken up to 250°C as required for lead-free solder:


Notice how each of the resistors aligned itself nicely, due to the capillary pull of liquid solder. And how all the solder paste ended up on the gold contacts – that’s what solder masks do: repel solder!

Here’s the other side after reflow:


Not that this matters much, since solder paste is normally only applied to pads on the top side…

More re-design needed

In Hardware on Sep 21, 2009 at 00:01

This is embarrassing…

It looks like some trivial plugs in Plug Panel 1 do work, but everything of even the slightest complexity (and usefulness) is faulty :(

The Expander Plug has a completely incorrect pin allocation for the MCP23008 18-SOIC chip. Which I had to create from scratch in EAGLE, and obviously I’m still learning just how to do that. Lesson one: don’t move pins in a package around without checking their pin numbers afterwards!

Unfortunately, that means the LCD Plug I sent off a few days ago will also come back useless :(

The Thermo Plug can’t turn off its buzzer because a trace is shorted out to a pad (I guess I didn’t do a DRC), and the thermocouple interface isn’t working because the AD597 chip needs at least 5V as power supply. So much for sensing or controlling anything. Oh well, I suppose the NTC and 1-wire inputs work.

The Room Plug didn’t work with a 1-wire DS18B20 sensor, in fact it looks as if the 1-wire sensor is hooked up the wrong way around since it’s shorting out the 3.3V supply. And the EPIR sensor isn’t responding either. I haven’t tried other configurations yet.

The Clock Plug mistake was described yesterday. It’ll probably work with a DS1340 chip i.s.o. a DS1307.

The I2C Connector … well, ehm, I mixed up the AIO and DIO pins. Incredible stupidity.

Oh, yes, there is some good news – the Breadboard Connector “works”:


But then again, it’s a bit hard to mess up a tiny pcb with no electrical components on it :)

Drat. Back to the drawing board. I may need several iterations to get my act together. This will add weeks to the process. Of course it’s a learning experience, such as: lesson 2 – check and double-check, and lesson 3 – check everything again. E v e r y t h i n g !

Man, do I feel JeeSilly right now…

Clock Plug v1

In AVR, Hardware on Sep 20, 2009 at 00:01

The Clock Plug adds a real-time clock to a JeeNode:


A demo for setting it and reading it out follows:

Picture 2.png

Unfortunately, there seems to be a problem with it – it does not start up reliably, and connecting the backup battery makes it stop?

Oh, wait – the DS1307 is specified for a 4.5 .. 5.5V power supply, and I’m driving it from the 3.3V line! And yes, sure enough, it works fine when powered from 5V.


Time to look for another chip. Ah, looks like there is a pin-compatible one which does work at 3.3V – here’s a post from someone who fell into the same trap.

Update – the DS1340Z works fine, see this followup post.

Memory Plug v1

In AVR, Hardware on Sep 19, 2009 at 00:01

The Memory Plug adds flash memory to a JeeNode:


This particular one has 2 different brands of 512 Kbit chips on it: a AT24C512B by Atmel and a M24512 by STMicroelectronics, for a total of 128 Kbyte. By fully populating it with 1 Mbit chips, this plug can contain a whopping half megabyte of memory :)

Here’s small sketch to test reading and writing to it:

Picture 1.png

A value will be incremented each second. When restarted, the value will continue to increase since the last setting, demonstrating the non-volatile memory. The demo uses I2C address 0x50 to address chip #0 – chip 1 #is at 0x52, chip #2 at 0x54, and chip #3 at 0x56.

This demo is available as the eemem example in the Ports library.

Here’s the plug hooked up to a JeeNode:


This plug supports daisy-chaining of more I2C-type plugs.

So there you have it – a Solid State Disk!

Plug Panel 1 is in!

In Hardware on Sep 18, 2009 at 00:01

Woohoo, got my 10 prototype boards with 6 plugs and 2 connector boards in:


Already, several major and minor issues have appeared. I’ll report here as I investigate exactly how good or bad all these tiny boards have come out.

Here’s a first one, the Blink Plug:


The header has been soldered flat and on the bottom side, so that through-hole pins are raised slightly above the base level. This is a convention I intend to use for all plugs: male, flat, bottom-side, left. And with I2C daisy-chainable plugs: an optional female header on the right.

Here’s a silly way to use the plug… on an Arduino!


(apologies for the ugly flash picture)

The “port” header is pushed into Arduino pins 8 through 13. A trick is used to supply power via the I/O lines:

Picture 4.png

This demo sketch is available here as “arblink.pde”.

Note that with this very simple Blink Plug, pressing a button always turns its LED on. The proper LED state is restored once the button is released.

Port extension

In Hardware on Sep 15, 2009 at 00:01

Found these 6-pin female-to-female cables at Seeed Studio:


Available in 100, 200, and 300 mm lengths.

By adding an extended-length 6-pin male header as shown on the right, this can be turned into a convenient extension cable for ports and plugs.

The color coding helps create a convention for ports, since their connectors are not polarized, but be careful – it looks like my batch used a different set of colors than what is currently showing on their website. And the colors also differ from an FTDI cable, alas.

Ah, conventions… so many to choose from! ;)

Second plug panel

In Hardware on Sep 14, 2009 at 00:01

Here’s the second panel of plugs I’m about to send off:

Picture 1.png

Some pretty odd stuff on there. Top left is a breakout board I’m making for a 30-pin FPC connector. Just because it was easy to add, not likely to be of use to anyone else.

The Voltage Plug has up to four 12-bit DAC’s connected via I2C. Yes, I do have something in mind for them…

The LCD Plug now comes with a tiny “end plug” attached which can be separated from it if needed. It’s a 3.3V to 5V boost regulator. This makes sense for an LCD backlight, but I need to work out usage scenarios, otherwise this will cause major trouble – with 5V regulating down to 3.3V while at the same time boosting it back up…


In Hardware on Sep 13, 2009 at 00:01

Here’s a simple design for a little “Proto Board” which covers all the port headers and the ISP/SPI connector:

Picture 1.png

The PWR/I2C header on the JeeNode is not covered by this board. I’m still exploring some options, hence the unmarked rectangle at the right end. The board is deliberately slightly asymmetric, to make it easier to remember which way it goes on.

Holes will be plated through as always, with text labels on the other side as well.

I’m considering not adding any connections to allow all solder pads to be used in various ways. This does mean wires need to be attached directly to the header pins to use them.

Just exploring for now – I’ll probably add this to the next panel prototype run, just to see how it works out.

Even more plugs

In Hardware on Sep 12, 2009 at 00:01

This plug thing is starting to become addictive…

I’ve been working on another set of plugs, to extend the interfaces further. Here’s a preview of a few new ones, all using I2C and daisy-chainable:

Picture 1.png

From left to right:

  • UART Plug – a serial port with 64-byte RX/TX buffers and RTS/CTS lines
  • Analog Plug – 8 analog inputs with 12 bit resolution
  • LCD Plug – a piggyback board for LCD displays with a standard 16-pin header

Most of these plugs will have jumpers to allow connecting more than one of them to the same port (as I2C bus). So within the limits of power consumption, I2C bus lengths / loading, and processing bandwidth, this should allow for quite a bit of extensibility.

Boards done

In Hardware on Sep 4, 2009 at 00:01

Ok, the 8 little board designs are done and have been sent to manufacturing (doesn’t that sound impressive?). Here’s the final layout check:


(This is a screenshot from ViewMate, with all the Gerber files generated by Eagle loaded in.)

Here is a summary of what each board does, from left to right, top row:

  • The Blink Plug is as simple as it gets: two LEDs and two push-buttons.
  • The Expander Plug has 8 general-purpose digital I/O lines – based on the MCP23008 chip, it uses an I2C bus and allows daisy-chaining. Two jumper pads allow up to 4 of these plugs on the same bus.
  • The Thermo Plug ties the AIO pin to either an NTC (thermistor), or a K-type thermocouple (via an expensive AD597 chip), or a DS18B20 1-wire sensor. The DIO signal drives either an on-board buzzer or an external relay / light / DC motor via a transistor.
  • The I2C Connector is not a plug but hooks up to the 4-pin PWR/I2C header on the JeeNode and provides a “port-like” 6-pin bus for I2C-based plugs.

In the bottom row:

  • The Room Plug is a shield-like daughterboard which plugs into ports 1+4 or 2+3. It supports an SHT1x temperature/humidity sensor or a DS18B20 1-wire sensor, a PIR or ePIR module, and an LDR.
  • The Memory Plug is an I2C-type daisy-chainable plug with 1 .. 4 EEPROM chips (up to 512 Kb).
  • The Clock Plug is an I2C-type daisy-chainable plug with a DS1307 real-time clock and battery backup.
  • The Breadboard Connector is the thing marked “plug” in this previous post. It’s not a plug, just a bit of wiring between a bunch of pin headers. It also works on the rightmost pins of the Expander Plug.

I2C plugs are at least 0.1″ wider than daughterboards, so that they can’t accidentally be plugged into two ports at once (which would short-circuit just about everything!).

I haven’t tried all of this yet, the I2C stuff in particular is untested. I have no idea how many of these plugs could be daisy chained reliably, or what the limits are in terms of power drain. But with the I2C Connector, things should be fairly robust since it has pull-up resistors to bring the I2C bus in spec, as well as a 3.3V regulator.

Note also that all these I2C buses (up to 4 bit-banged ones and 1 with MPU hardware support) use 3.3V logic levels. Just like the rest of the JeeNode, I’ve decided to use 3.3V as standard voltage for everything. The “PWR” pin carries whatever voltage is fed into the system, though it will most likely be about 5V in many cases. More and more sensors and memories come in 3.3V versions, these days.

It’s far too early to say how far this can be taken. Can we connect up to 160 individual I/O pins on a JeeNode? (5 buses x 4 expander plugs), or 2.5 Mbyte of EEPROM memory? (5 buses x 1 memory plug) – I doubt it. Besides, if connecting the maximum number of I/O lines were a goal, I’d probably combine several 16-line expander chips on a special-purpose plug instead, or even use 40-line expanders.

Done! The next challenge is to maintain all this flexibility in the software.

Update – I’ve added some docs, very preliminary for now, i.e. until the boards get a proper workout.

Lots of plugs

In Hardware on Sep 3, 2009 at 00:01

After a lot of head scratching, I’m getting ready to have some prototype boards made. Here’s a recent version of the Gerber files:


And here’s a 3D rendering of the same which was astonishingly easy to do (I’m not going to finish it or fix the quirks – this was just to try out Eagle 3D):


You’re looking at eight tiny boards, most of which have already been presented in recent posts. It’s also eight ways to mess up in some more or less silly way, but hey that’s all part of the game.

Unlike the software design-code-test-rinse-and-repeat cycle, which can be done many many times per hour, the cycle time for hardware project runs like these is measured in weeks. W e e k s !

Since I don’t expect these boards to be right on the first iteration, this means that at least some of them will be more than a month off before I can declare victory and start using this stuff all over the place. But then again, each of the boards is in itself fairly simple, who knows…

Ok, I’ll do one last round of checking, tweaking, and re-generating the final Gerber files, and then the waiting starts…

Patience. Drat.

Meet the JeeBoard

In AVR, Hardware on Sep 2, 2009 at 00:01

I hate wires. Wires to power up stuff. Wires to transfer data. What a mess.

I just want to try out physical computing ideas on my desk, next to my (wireless) keyboard and my (wireless) mouse – while exploring the possibilities of hardware + firmware + software running on my “big” computer.

So here’s to scratching my own itch: meet the JeeBoard – a little 8×10 cm unit with no strings attached – heh ;)


A first mock-up with real parts, here still using a green JeeNode v2:


On the left, a couple of demo plugs have been inserted. Those that use I2C can be daisy-chained.

One port is permanently hooked up to an I/O expander chip with 6 digital I/O lines for the mini-breadboard, 2 LEDs, and 2 pushbuttons. The on-board battery pack provides 3.6V with NiMH or 4.5V with alkaline cells.

The little overhanging board on top of the mini-breadboard “feeds” 8 wires into the center of the breadboard: +3.3V, ground, and the 6 general-purpose I/O lines.

I’m going to mess around with the layout a bit and explore some actual hookups before designing a real PCB for this. But even just looking at the mockup makes me want to start trying out stuff with it. Wireless, of course!

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!

Mounting a JeeNode with plugs

In Hardware on Jul 9, 2009 at 00:01

As promised: here’s an idea how to combine things. First let me show that plug pinout again – because I can…

Picture 3.png

An idea I’d like to present is to mount the JeeNode facing down. The board would look something like this:


Each of the four port groups has the corresponding pins tied together. With a JeeNode plugged in you get this:


And with some example plugs added:


Note how plugs mount the proper way up, i.e. lying flat on the perf-board, because the upside-down mounting of the JeeNode takes care of mirroring the connector. The only thing to keep in mind is that port numbering now runs clockwise, with port 1 in the top right.

The extra female headers can be used for testing, or as simple breadboard pins for hooking up some LEDs. Some space could be saved by leaving them out, though.

I think there could be several advantages to this setup:

  • plugging stuff in the “right” way becomes quite obvious
  • if you wire up plugs appropriately, you can chain them sideways (i.e. for I2C use)
  • mix and match: put some components directly on the board if you prefer
  • it’s all easily constructed with off-the-shelf “perf board” (with or without copper)
  • it could even be made from a piece of cardboard with a few holes in it
  • my favorite fastening system works: a couple of zip-locks to tie things down
  • for better protection, simply add a cover and leave cables coming out the side
  • the whole sandwich can be solidified with spacers and remains low-profile
  • it’s all laid out in the plane – place a paper design on the board to guide you
  • it’s easily documented: just take a picture of it…

But perhaps best of all, you can still create a completely different setup for permanent use. Just unplug everything and re-assemble it in some other orientation. So while this approach takes up relatively much space for the connectors, it does give you total flexibility to re-arrange things any time later.

I’ll try this out in a couple of projects. But even just with this mockup I noticed that having the plugs flat on a supporting surface makes it all surprisingly stable, and easy to carry around.

Plug pinout

In Hardware on Jul 8, 2009 at 00:01

Here is the standard pinout I will be using for all my JeePlugs and port connections from now on:

Picture 3.png

Do not ask how many different variations and scenarios I’ve been through. You don’t want to know. I’ve got the scars and JeeNode debris lying around here to prove it. I agonize over these choices so you won’t have to …

There are difficult trade-offs whichever way you go, but this is it. The best choice, period.

From that, several consequences follow. The most important two being that the JeeNode v3 and the JeeLink will be supplied with female headers for the ports, and that these headers should be soldered on pointing up.

If you have the v2 JeeNode, then my advice is to make a couple of conversion cables or plugs, so that you can set up all future connections using new standard. That’s what I did anyway – I don’t even have a v3 JeeNode here yet, and I’m already wiring up new plugs using the above convention. The pain of converting now is nothing compared to having a confusing mix of boards and plugs and cables later.

Depending on the power source you use, plugging in things the wrong way can definitely damage circuits. I suspect that a 5V power source such as the fused one from USB on the JeeLink is relatively safe, but a 12V PWR line hooked up the wrong way is likely to damage the ATmega. So will shorting pins 1 and 2, i.e. PWR and DIO.

If you need to work with such “high” voltages, I would suggest using 4-pin plugs where possible. In other words, don’t even bring that PWR line out to the peripherals / plugs unless needed.

Back to the pinout and orientation of plugs. With female headers on the JeeNode / JeeLink, you can see that plugs will be oriented with the components sticking out.

For plugs requiring two ports, you can mount the male headers pointing down on the JeePlugs and use them as tiny shields. Plugging such a shield in the wrong way, i.e . turned 180°, has no serious consequences. The ports 1 & 4 or 2 & 3 will simply be exchanged. Your sketch won’t work, but at least it won’t cause any electrical shorts or power-line mixups. Plugs used as tiny shields are quite robust in that sense.

That’s it for using plugs (or your own perf-board) and hooking up stuff to each port. By sticking to these conventions, it will be easy to re-use components in different configurations later.

The choice for non-polarized pin headers was a very deliberate one. They are very low cost, small, and widely available. This matters to me because I intend to hook up tons of different things over time. It just means we have to carefully pick some conventions and stick to them. Done.

Tomorrow I’ll describe another variant compatible with this which helps avoid inadvertent reversed connections and which supports chaining with a port as I2C bus. It will also make it easy to construct a more permanent mechanical “fixture” when hooking up multiple sensors, indicators, actuators, etc.

IO Expander

In AVR, Hardware, Software on Jul 7, 2009 at 00:01

Here’s a way to expand the number of digital I/O lines on a port:

3686066291_f856efcb63_o This is a JeePlug filled to the rim with tiny components and connectors. It’s based on a PCA8574A I2C 8-bit I/O expander. Each of 8 pins can be used either as inputs or as “mostly” open collector outputs. See the datasheet for details.

Here’s the bottom side of the plug:


Crowded indeed!

And here’s a demo sketch called “expander” which blinks the eight LEDs connected between PWR and the respective I/O pins:

Picture 3.png

As with yesterday’s example, this is running the I2C at maximum bit-banging speed, and seems to work fine. It’s used to make 8 leds blink:


The connector block on this plug has 8 sets of three connections: GND, PWR, I/O. Note that PWR is connected, not +3.3V. The reason for this is that I’d like to try driving a bunch of servos from this plug one day – it’ll load the JeeNode down a bit but it should be feasible.

The “expander” sketch has been added to the Ports library and is available as ZIP file and in subversion.

External memory

In AVR, Hardware, Software on Jul 6, 2009 at 00:01

For one of the projects in the Jee Labs, I needed a bit more “permanent” memory than the ATmega’s EEPROM or even flash could provide. Here’s what I came up with:


That’s a 64 Kbyte AT24C512B serial EEPROM memory which talks via I2C.

It takes only 4 wires to hook this thing up:


And this is the mess you get in when you don’t have the right connectors and need to deal with older boards:


That’s the “regret plug” mentioned a few days back, to turn the downward pointing male header into an upward pointing female header, plus a “cross-over plug” to let me wire this thing up for the new JeeNode v3 pinout, yet use it on a (minimally populated) v2 board. Yuck!

Lesson: think about headers before deciding how to solder them on …

All future JeeNodes will be supplied with 6-pin female headers for the ports. Soldering them on pointing up is probably most convenient: it lets you stick little LEDs and wires in there, and JeePlugs can be placed pointing upright – such as this memory.

Back to the memory expansion. Here’s a test sketch:

Picture 5.png

Sample output:

Picture 4.png

As you can see, the count did not start with 255, as it would have if the EEPROM had still been empty. The JeeNode was powered off in between to demonstrate data retention.

This example code runs at full bit-banging speed – seems to work just fine.

The “eemem” demo sketch has been added to the Ports library and is available in this ZIP file as well as here.

There you go … a whopping half million extra bits of permanent storage :)

Simple plugs

In Hardware on Jul 1, 2009 at 00:01

Here are some basic uses for JeePlugs…

First the v2-to-v3 pinout converter:


It flips the +3V and AIO pins. Here’s the bottom view:


Not pretty, but robust, and it works. Here’s a v2 JeeNode which will allow me to use plugs designed for the new v3 pinout:


The shrink-tube yellow bands are a reminder that these are “crossover” plugs. Better avoid major confusion later, once there are more plugs all over the place…

Here’s a weird one, I’ll call it the “regret plug” because it lets me use JeeNodes with a header orientation I’m now regretting:


It lets you turn a JeeNode with downward facing male pin headers into onto one which has female headers pointing up, or male headers pointing sideways. Like so:


This is an odd contraption, but I’m sure it will come in handy one of these days. Note that there are no wires across the plug. Each side is independent and simply has 3 headers with all the corresponding pins soldered together.

The outer female headers have been soldered on at an angle to allow attaching to it – otherwise the JeeNode board edges would obscure the connector.

Note – Apologies for the confusing posting/re-posting today. I knew I had a post ready, but it got back-dated to June 1st, instead of July. Should all be fixed now, but some RSS readers might cache the previous post.

JeePlugs have arrived

In Hardware on Jun 30, 2009 at 00:01

Got some JeePlugs in today – yippie!

Here’s how I’ll probably use them most often – with one or two sideways headers:


(These boards were sent off before the big URL rename – such is life…)

Note that both ends and the middle rows are connected in a pairwise fashion. The middle row traces are thin and can easily be cut if necessary.

I used flat headers, soldered in the underside of the plug. That way you can chain them and they’ll hold the plug slightly above the plane for pins sticking out, etc.

Here’s one way to use them on a JeeNode:


The blue is the new green – all boards from JeeLabs will be blue with white markings.

Note the orientation here: in this setup, components are mounted on the outside.

And here’s another way to use the plugs, as mini shields:


The headers are soldered onto the inner rows, leaving the connections to each header pin available from both sides on the outer rows.

There’s nothing JeeNode-specific about these boards, by the way. They have plated through holes, which makes them more convenient for soldering components and wires on either side. And the pairwise pad connections can save a bit on wires.

JeePlugs are on their way

In Hardware on Jun 25, 2009 at 00:01

Ok, I’ve decided to get a bunch of JeePlugs made.

A JeePlug is a little prototype board designed to fit exactly on one or two port headers of a JeeNode (or JeeLink). Here’s the layout:

Picture 6.png

See an earlier post for a description of how these plugs can be fitted to the JeeNode / JeeLink.

Some of the holes are connected in a pairwise fashion. With traces which can be cut when such a connection is not desired. The outermost two rows are for header pins and wires to connect to each pin, respectively.

The main intended use for these plugs is as a mini-breadboard hanging off the side of the JeeNode, so that up to four of these can be attached at the same time. But sometimes a single AIO + DIO pin just isn’t enough, in which case these plugs can be used as mini-shields bridging across two opposite ports.

It’s pretty low-tech obviously, but I expect these plugs to be a huge time-saver. Not just because they make it easy to hook up all sorts of sensors, indicators, and actuators, but because the result really is a plug. They can be mixed and matched at will, since all ports are equivalent. All that’s needed is to adjust the port number in the sketch / code to match the chosen header, a trivial 1-line change.

And because ports are so versatile, each plug can be an analog + digital I/O line, or an I2C bus, or a serial line. There are definitely limits to this approach, given that a JeeNode is after all based on a micro-controller, not a full-blown PC – but still.

Being flexible, modular, and inexpensive – that’s what JeeNode ports are really about. Oh yes… and wireless :)

I hope to get various plug examples going in the Jee Labs in the months ahead.