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 :)

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 0×68 (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:

And here is the sample output:

Is it precise? You bet.

Is it accurate? Well, my multimeter says 1.265…

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:

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

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 0×50, 0×52, 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:

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.

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:

Sample output:

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…

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 ;)

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 http://jeelabs.org/up1 – 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.

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!

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.

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…

Ok, after switching to a DS1340Z chip, the RTC Clock Plug now works:

Sample output:

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:

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.

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…

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…

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:

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.

Here’s the second panel of plugs I’m about to send off:

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…

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:

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.

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.

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.

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

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.

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

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:

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.

Here is the standard pinout I will be using for all my JeePlugs and port connections from now on:

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.

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.