Computing stuff tied to the physical world

Archive for the ‘Hardware’ Category

Xanura CTX15

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

Another popular home automation module is the Xanura CTX15:

DSC_1228.jpg

That’s a live 220V power-line connection in the top right corner!

I’ve connected the CTX15 module through a UART Plug, with a 4.7 kΩ resistor in series with the RX signal (yellow from CTX15). This is because the signal swings up to 5V, whereas the UART plug only accepts 3.3V voltage levels. The module is powered from the PWR pin, which on a JeeNode USB carries 5V.

The CTX15 is a bi-directional interface, it can send as well as receive A10-type power-line commands (a superset of X10). The trouble is that it needs to be polled to read out what has been received and buffered so far.

Here’s a sketch which takes care of that:

Screen shot 2010-03-08 at 12.08.53.png

And here’s some sample output:

Screen shot 2010-03-08 at 12.08.40.png

As a test, I powered up yesterday’s XM10E test setup as well, to send out on and off commands to unit A.1 every 3 seconds. As you can see with the CTX being read out every 5 seconds, multiple received packets will sometimes be combined and returned as one reply.

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!

Catching sun rays

In Hardware on Mar 6, 2010 at 00:01

A few days ago, this country went through a curious ritual…

In the Netherlands, there is a subsidy as encouragement for people to place solar panels on their roof tops.

Screen shot 2010-03-05 at 23.03.57.png

The system works as follows:

You’re considering setting up a couple of photovoltaic solar panels.
You quickly find out that the government is handing out money for this.
Yippie … and then you get into the rules and regulations bit:

  • You can’t apply for the subsidy before March 1st.
  • There is a limited amound of funding.
  • On the day when submissions exceed funding … it’s roulette day!
  • … the remaining subsidies are assigned at random.

The result?

On March 1st – everyone submits their proposal for solar energy.

On March 2nd – sorry folks, we’re all sold out, try again next year!

It turns out that some 17,000 people signed up for 2010. And about 5,000 of them will win that lottery ticket.

Tell me, please, what’s the meaning of the word “encouragement” again?

Anyway, so much for silly incentives. The reason I’m posting this is that we’ve been looking into solar energy and have decided to install 18..20 solar panels on our roof. It’s relatively well-positioned, and even the cabling in the house turns out to be very easily adapted for it. And yes, I’m one of the 17,000 who signed up for the Dutch Solar Casino. Except that we’re going to go ahead regardless of the outcome (3 months from now!).

The numbers are much better than I expected:

  • With 18..20 panels, we can fill the smallest half of our roof
  • Modern panels can produce about 3600 “Watt peak” total
  • Heading and tilt are such that we’re still at ≈ 90% of optimal
  • Estimated yearly output will be 2500 kWh, 20% more than we need
  • Unused power is fed to the grid and billed at the same rate, as credit
  • In other words, the electricity grid will become a – very – big capacitor for us :)

All in all, I think it’s a good deal. There will always be better deals in the future, but this is fine.

As for buying more stuff to save and join the green hype: panels also need to be produced and shipped. The energy needed to do so appears to be less than what those panels produce in their first 18 months. So the electricity in the next 20..30 years after that is free, green, and effortless.

I was very surprised to find out that solar energy is practical at 52° latitude, but it really is.

Sooo… apart from seasonal swings and energy storage, Jee Labs will be “slightly off the grid” later in 2010!

JeeMon goes embedded

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

Testing out a new setup … I started by launching the JeeMon runtime executable as follows:

Screen shot 2010-03-02 at 15.41.09.png

Then I went back to my Mac and opened a browser window:

Screen shot 2010-03-02 at 15.56.12.png

It works! You’re looking at a little web server running on a tiny Technologic TS-7500 board:

DSC_1213.jpg

ARM based, 64 Mb RAM, µSD card socket on board, running Debian (lenny). It’s not very high powered, but in return it only uses 400 mA @ 5V, i.e. it can run off USB power.

I haven’t yet figured out how to get the FTDI USB serial driver on there, but once that’s solved this little unit will be able to act as host for USB-connected JeeNodes or JeeLinks.

The RAM and storage is more than sufficient to run even a very elaborate JeeMon setup, I expect.

This might be an interesting low-end always-on home sensor & automation system!

Fabrications

In Hardware on Feb 24, 2010 at 00:01

Several hours of work, and this sort of stuff is born… 16 new JeeNode USB’s:

DSC_1203.jpg

It looks pretty, but I’m not going to show you the high resolution picture… even on this one you can probably spot one or two problems :)

The fact is that hand-assembly of SMD takes a lot of patience. By now, I think it’s absolutely doable for one-offs, such as to assemble one board with some parts. But larger quantities do tend to bring out the trouble spots.

Usually, on a run this size, I’ll expect to see 3 or 4 boards not working right away, and ending up with perhaps one board which I can’t fix quickly. I’ve got a box with a bunch of units by now, which don’t seem to want to be cured. Oh well, their loss – that means they get to wither away in a dark box, waiting for better times :)

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:

DSC_1205.jpg

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 (BMA120?) 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.

Onwards!

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…

Improved bracket

In Hardware on Feb 12, 2010 at 00:01

Encouraged by some comments on yesterday’s post, I printed the same bracket again, laying on its side:

DSC_1188.jpg

The horizontal base comes out ok (I cleaned up the hole):

DSC_1189.jpg

Interestingly, the top of the bracket isn’t filled in, which is actually better:

DSC_1190.jpg

The sides look much better as well:

DSC_1191.jpg

(the Skeinforge settings aren’t perfect yet, layers could be mashed smoother together)

But wow – what a difference this makes! Thanks for the tip!

Here’s another object, a Geneva Wheel from Thingiverse:

DSC_1192.jpg

Turning is not very smooth, had to cut off some plastic from the round shafts, but hey: it works!

PS. Don’t worry, I’m working most of my time on JeeNode stuff, hardware and software that is… ;)

JeeNode bracket experiment

In Hardware on Feb 11, 2010 at 00:01

I just had to try making a little mounting bracket for JeeNodes…

Here’s the design:

Screen shot 2010-02-08 at 11.13.51.png

The design dimensions are 25 x 12 x 10.5 mm. It was created with OpenSCAD, which takes a description of the object and generates the solid model shown above:

Screen shot 2010-02-08 at 11.14.06.png

Does it work? Can it be printed? Can it be used? Yeah, sort of…

DSC_1180.jpg

Works for JeePlugs too, since all the boards have the same 21.1 mm width:

DSC_1182.jpg

Took me three tries to get the sizes and the little ridge right (the middle one):

DSC_1179.jpg

Pretty ugly stuff, when seen up close. But hey, that’s what pioneering looks like!

The ridge which holds the board doesn’t come out very clearly – the features are not yet a match for what the JeeCake 3D printer can do (or should it be the other way around?):

DSC_1181.jpg

But despite appearances, this bracket is already surprisingly functional. Apart from the awful surface and rough shape, it’s a springy and very robust little piece of ABS plastic. It could easily be screwed down, and it would hold the board quite well.

Fascinating, it’ll be fun to see how this evolves over the next few years.

Wireless CupCake

In Hardware on Feb 8, 2010 at 00:01

JeeCake, the CupCake 3D printer here, is an interesting mix of machine, electronics, and software.

The RepRap Motherboard is the main on-board controller, based on an ATmega644. It drives 3 stepper motors, communicates with the Extruder board, and talks to a desktop computer via its FTDI interface and a USB cable.

On the PC side (which can be Windows, Mac, or Linux), there is a Processing-/Arduino-like package called ReplicatorG to control the machine. It takes G-code, which is not related to Google in any way, but rather an ancient CNC control language from the 60’s.

ReplicatorG then converts this to a binary RepRap 3G protocol, as documented here and then uses that to drive the CupCake. Everything from moving the axes, adjusting the nozzle temperature, controlling the extruder motor, to writing settings in the machine’s EEPROM memory.

The neat part is that the v1.2 motherboard has an SD card adapter on board, and that the CupCake can run unattended by getting its detailed build instructions from files stored on an SD card.

Except for one little detail: there are no controls or displays on the CupCake, other than a few LEDs. This is not enough to select which file to print, adjust the zero position, or start a build. It looks like a new “Generation 4″ design is on the way, including an interface board with an LCD screen and some push buttons.

Right now, you have to connect the machine via USB, start everything up via ReplicatorG, and then you can yank the USB plug and it’ll happily continue printing what it started, right to the end (well, except that on Mac OS X 10.6, yanking USB cables can lead to kernel panics – looks like a serious bug in the FTDI USB driver).

Anyway, I don’t really care for controls, or even displays on the CupCake. All I want is some way to control a unit sitting on the other side of the room, or in a nearby room. It can be fairly noisy due to some sort of occasional wood panel resonance, and having it printing right next to me is not really my idea of fun.

Which is where JeeNodes come in: wouldn’t it be nice to be able to control the CupCake via wireless? The protocol is already perfectly suited for it, since it uses packets of max 32 bytes – well within the 66-byte limit of the RF12 driver. And if the object being printed is already on the SD card, then only a few packets need to be exchanged to get going. During printing, some status info could be sent back – again very low rate stuff, easily within the JeeNode’s wireless constraints.

Here’s the idea:

DSC_1177.jpg

Hook up a JeeNode to take the place of the USB cable, and let it behave as a RecpicatorG control program.

The interface needs to swap RX and TX for this, and because the CupCake’s signal levels are at 5V, two 1 kΩ resistors need to be inserted to prevent excessive current. One more detail is that the power pin on the FTDI connector is not connected, since the motherboard is powered off its own PC supply. So a separate wire needs to be added to power the JeeNode off the ISP connector right under the FTDI connector:

DSC_1178.jpg

The one wire not shown here is the ground wire, running from top right to bottom left on the other side of this little custom interface board.

It turns out that the motherboard is actually powered from the 5V standby supply pin, so it’s always powered, even when the power supply is in standby mode.

I’ve started writing some code on the PC/Mac side to control the CupCake without using ReplicatorG. Here’s some sample code in Tcl which works when connected directly through USB:

Screen shot 2010-02-07 at 15.05.08.png

And here’s the corresponding output:

Screen shot 2010-02-07 at 15.04.35.png

As you can see, it can access all sorts of status info, read the file names on the SD card, and control the machine. This is part of a larger project, the beginnings of which are now in the subversion code repository.

It takes a lot of work to make hookups like these work, because there are so many different bits and pieces (literally) involved. The next step is to see if the JeeNode can indeed communicate with – and control – the JeeCake, and then code needs to be written to replace the current direct-USB connection by a packet-based wireless hookup through a JeeLink + JeeNode.

Oh, and then I need to create some sort of little on-screen control panel to adjust the nozzle temperature, jog the Z axis up and down, pick a file to print, and start the print job! Not to mention making it robust and secure…

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:

DSC_1175.jpg

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.

Custom object

In Hardware on Feb 6, 2010 at 00:01

This is not what you might think it is:

DSC_1169.jpg

I’ve been placing my headphone next to me on my desk for ages. There is of course never enough room on top, but plenty of spare room underneath:

DSC_1170.jpg

So here’s my home-made headphone bracket:

DSC_1172.jpg

Here’s the design, made with Sketchup:

Screen shot 2010-02-03 at 14.22.47.png

I just picked a “2″ in a suitable font, re-sized it, “drilled” some holes in the base, and then “printed” it.

Piece of JeeCake!

PS. Given that CNC and 3D printing is not really the main focus of this weblog, I’ve set up a page on the wiki.

Update – design files added to Thingiverse.

JeeNode USB v2 error!

In Hardware on Feb 3, 2010 at 00:01

Yikes… there is a major bug in the current JeeNode USB v2 board!

The on-board MCP1703 3.3V has been connected with Vin and Vout reversed!

The effect is that the +3V pins on all the port headers will have approx. 4.7V instead of the intended 3.3V. This in turn means that all plugs connected to these headers will have a higher voltage than should be.

The on-board logic is not powered by this regulator but gets its power from the 3.3V pin on the FTDI chip, so the JeeNode USB v2 itself works just fine (my weak excuse for why I didn’t catch this problem earlier…).

Here is the schematic – with the problem staring me in the face, now that I know about it:

Screen shot 2010-02-02 at 13.51.39.png

Here are the printed circuit board traces:

Screen shot 2010-02-02 at 14.39.16.png

And here is the board with the voltage regulator connected the wrong way around, as it has been shipped until yesterday, i.e. Feb 1st 2010:

DSC_0737.jpg

If you have a faulty unit, there are a number of ways to fix this:

  1. Send it back and I’ll fix the voltage regulator for you.
  2. Remove the voltage regulator and add your own from a PWR pin to a +3V pin.
  3. Unsolder and re-solder the VR flipped, as described below.

To reiterate: this bug only affects plugs connected to the JeeNode USB, not the JeeNode USB itself. If you don’t use the ports, or don’t mind having a higher voltage on the +3V pins, then you could just ignore the issue.

Here’s how I’ve fixed this on existing JeeNode USB’s, including ones still in stock. First, I used solder wick to remove the regulator (careful not to lift the pads):

JU2 no VR.png

The next step is to mount the VR back on its side. The pins which need to be exchanged are:

MCP flip.png

One way to do this, is to turn the VR on its side and solder pins 1 and 2 back on pads 1 and 3:

DSC_1164.jpg

As last step, I added a thin wire from what used to be pad 2, to the pin now sticking out on top (was pad 3):

DSC_1162.jpg

As I said, I’ll be happy to do all this fixing for you if you send me your JeeNode USB v2.

It ain’t pretty (real bugs never are) – but it’ll at least let you continue to use the JeeNode USB v2 as intended.

All JeeNode USB v2’s shipped from now on will have this fix, until an improved “v3″ is ready. As always, “new copper” (i.e. a new PCB) will take a few weeks – it’s at the top of my list to fix and resolve this for good.

With many thanks to castello for drawing my attention to this bug on the forum.

Room Board assembly

In Hardware on Feb 2, 2010 at 00:01

As announced recently, I’ve now added a full kit for the Room Board in the shop, containing:

  • The room board PCB.
  • SHT11 temperature + humidity sensor.
  • An LDR light sensor.
  • The ELV PIR motion sensor.
  • Two 6-pin male headers.

Here is the kit (oops, forgot the two 6-pin headers):

DSC_0980.jpg

From top left to bottom right: PIR lens, PIR sensor, 3-pin header, SHT11, LDR, Room Board PCB, pre-assembled PIR sensor board.

The hardest part to solder is the SHT11 sensor. It has 10 gold pads on the side, of which only 8 are connected. Make sure you place the sensor in the right orientation. With the text on the pcb readable, the round part is pointing down:

DSC_0981.jpg

Next, solder in the LDR light sensor. Be sure to place it in the LDR1 position:

DSC_0982.jpg

The wires of the LDR may be a bit more difficult to solder than ordinary components, so be sure to use enough flux:

DSC_0983.jpg

Next, we need to prepare the ELV PIR sensor board – the board itse;f already has all the SMD’s soldered on, just the PIR sensor itself.

Careful – do NOT touch the surface of the PIR sensor, as any traces of oil will reduce its sensitivity:

DSC_0984.jpg

The sensor has to be pushed through the bottom side of the lens holder, into the board – from the non-component side:

DSC_0985.jpg

Solder the three wires and snip them off. Don’t use too much solder or you’ll risk shorting out the pads with the nearby components:

DSC_0986.jpg

Then turn the board around and click the fresnel lens onto the base (it has three different-sized notches):

DSC_0987.jpg

Next, we need to connect the boards together:

DSC_0988.jpg

The pins go through the room board and should be snipped off once soldered:

DSC_0990.jpg

Almost there – the last step is to solder the two 6-pin male headers onto the room board. To hold them in the right position, I just push them into a JeeNode:

DSC_0991.jpg

… then place the room board on top and solder both headers, all 12 pins. Leave the 8 holes on the side of the PCB free (these are for another type of PIR sensor):

DSC_0992.jpg

That’s it – you’re done!

For more info on uploading the “rooms.pde” sketch firmware to the JeeNode, go back to the docs page.

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:

DSC_1154.jpg

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:

DSC_1155.jpg

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.

Room node – last

In Hardware on Jan 31, 2010 at 00:01

Here’s a last post about mounting a room node in a ceiling corner.

The enclosure and support struts were cut out of an A4 sheet of foam board, according to the template PDF on the wiki:

DSC_0993.jpg

Unfortunately, the JeeNode doesn’t quite fit with the FTDI pins sticking out, so I had to cut away a bit of the support material. As you can see, everything is glued together with hot glue, even the room board. The battery pack is stuck on the top part with double-side tape.

The motion sensor sticks out in the middle, at the cross-point of two diagonals on that slanted surface, to be precise. The holes for the LDR and SHT11 have not yet been made:

DSC_0994.jpg

Here’s how everything sits in the completed unit:

DSC_0995.jpg

There’s still some leeway to move the JeeNode up a notch, but I’ll leave it at that.

Enough of all this mechanical tinkering!

Room node mount

In Hardware on Jan 30, 2010 at 00:01

It’s time to finish that room node ceiling mount, at least the prototype.

At first, I thought I’d use the new 3D printer for some sort of nifty mounting bracket:

Screen shot 2010-01-29 at 20.48.04.png

… but it turns out that there’ a much simpler solution:

DSC_0977.jpg

This pushes the top of the mount against the ceiling, right under the battery pack, which is by far the heaviest part anyway:

DSC_0978.jpg

I don’t like the look of the paper sheet wrapped around the foamboard, but whatever – it works!

There’s a new wiki page with the description and a PDF with the outline of the pieces required to make a ceiling mount. Haven’t quite accounted for the thickness of the foam, since it depends a bit on which way it’s cut and folded, but the PDF should be usable as starting point.

One more 3D post

In Hardware on Jan 29, 2010 at 00:01

Ok, one last post on the CupCake CNC trials before I get back to JeeNode stuff.

The raft is now very solidly stuck to the base:

DSC_0968.jpg

This thing really sticks well, with plastic pushed down into the criss-cross grooves of the acrylic base. The trick is to place a plain paper sheet between the extruder head and the base, and to lower the Z axis until the paper slides away with just a tad of friction.

Unfortunately, the next problem comes up – as seen in this first Geneva Wheel trial:

DSC_0967.jpg

It turns out that the next layer of the raft doesn’t stick well to the first one. I solved this by raising the default 230° setting to 240° for the raft.

Another serious problem was that there is a lot of plastic on the right end of the raft as the print nozzle paused (!) on each turn. And the second layer of the raft doesn’t extend all the way to the end. This was solved by adding three noise-suppressing 0.1 µF caps to the extruder motor and disconnecting all the end-stop optocouplers.

The object itself seems to come out fairly well, though there were some blobs of plastic around the nozzle during printing which clearly interfered with the X-Y motion at times.

Here are over a dozen more parts, printed using black ABS for a change:

DSC_0975.jpg

These all came out ok, but note that even these small parts take 10..15 minutes to print – each.

The biggest remaining problem is “warping” – it’s causing over half my trials to fail:

DSC_0976.jpg

This part failed to build (should have been 20 mm high), it slowly came off the base and started interfering more and more with the extruder nozzle. At some point the nozzle got stuck in fact. Note how the thickness of the part is completely uneven. This is caused by the ABS cooling down and shrinking a bit – slowly pulling itself off the raft (with considerable force). A heated baseplate seems to be the hack to solve this – but that will require a lot more tinkering.

Oh well. We’ll get there… eventually :)

Update – upgraded to ReplicatorG 0012 with Extruder firmware v1.8 and switched to Zach Hoeken’s thermistor settings (raft setting reverted to original 230°). The last change was to shine a halogen light on the platform and object, to heat it up a bit – this seems to get rid of just about all the warping, yeay!

More 3D trials

In Hardware on Jan 28, 2010 at 00:01

It’s not as simple as it seems…

Well, the CupCake worked straight out of the box, which is of course fantastic. But printing does seem to have two tricky bits, called “extrusion” and “rafts”.

Here’s the printer making its third part:

DSC_0963.jpg

What’s about to happen, is that the “raft” (that woven mat laid out on the bottom to hold the rest of the construction) is about to come off the base. In the above picture you can see two other problems: the raft itself coming apart, and a blob of plastic (front right) when the printer decided to pause for a few seconds, while the extruder kept pushing out plastic…

The problem seems to be that when the plastic cools down fully it becomes quite springy and rigid. Which is great for the final object, but causes trouble in keeping it stuck to the acrylic base. I suspect that the heated platform which people are experimenting with is to overcome this problem, by keeping the base slightly sticky for the duration of the build.

Or maybe a few wires extending further out from the raft would help, by “tacking down” the whole thing.

The other purpose of the raft is to even out the surface. In my case there is a slight difference in height across the base. I should probably try to get rid of that first.

Anyway, here are the objects made so far:

DSC_0964.jpg

The meandering plastic retains its shape – that’s probably part of the magic behind all this.

PS. The stepper motors are noisy. I don’t think the software I’m using is micro-stepping right now.

CupCake #361 is alive!

In Hardware on Jan 27, 2010 at 00:01

Just got the missing part for the CupCake CNC 3D-printer in from MakerBot – partly their mistake, partly my mistake, long story… anyway – in the end they were extremely helpful in coming up with a good solution.

Which I had to try right away, of course ;)

After a bit of head scratching w.r.t. firmware versions and uploading, everything came together at last.

Here’s the first object getting printed at Jee Labs – whee this is fun:

DSC_0959.jpg

After 8 minutes, it’s done and steps aside:

DSC_0960.jpg

Mystery object…

DSC_0961.jpg

After removing the “raft” and cutting off some loose ends:

DSC_0962.jpg

So what is it? Oh, nothing spectacular really – it’s a Z-endstop for the machine itself. I figured that after us people doing so much to get it going, this machine might as well start working on improving itself right away…

I’m astonished by how well this first part came out. Very clean, very plastic’y, much sturdier than I expected.

All that’s left is to give this new beast a name – Jee3D? JeeCup? JeeCake? CuppaJeeno?

Ceiling mount – sliding part

In Hardware on Jan 26, 2010 at 00:01

Ok, here’s the sliding part of the room node mount:

DSC_0953.jpg

Totally hacky for now, the reinforcement bits are all glued in and cut to shape.

What totally surprised me, is that the JeeNode itself barely fits, even though there seems to be so much empty space in there. The tricky bit is that it can’t stick out on either side – in the end I could only make it fit by turning it a little, and moving the battery pack out of the way to make room for that orientation:

DSC_0955.jpg

This thing is larger than I expected it to be – the big triangle against the ceiling is 14 cm on both sides and ≈ 20 cm on the long diagonal side.

Last step will to to figure out a way to mount this concoction. Oh, and then redo it all from scratch to create a decent printable DIY template.

Ceiling mount – first step

In Hardware on Jan 25, 2010 at 00:01

As promised, the foam board construction – well, a first step anyway:

DSC_0950.jpg

The “folds” are a bit ugly this way, I’ll hide them on the inside using V-cuts in the next version.

Room node and battery pack included for size comparison. You’d think they fit easily inside, but the battery pack is surprisingly tricky, given that the room node needs to stick through the slanted side facing outwards.

The “walls” are also a foam mockup I’m using to avoid having to use an actual ceiling corner :)

DSC_0951.jpg

Here’s how I intend to to place everything inside:

DSC_0952.jpg

The battery pack will be attached to the top, i.e. flat against the ceiling. The room node will be mounted such that the PIR sensor sits in the middle, sticking out.

Onwards!

Room node ceiling mount

In Hardware on Jan 24, 2010 at 00:01

Been pondering a lot lately on how to mount all those room nodes around the house…

Without an enclosure the room nodes look very “hacky”. And what’s even worse: there is no way to mount them! The problem is that you want to point the PIR sensors at least approximately into the center of the rooms they are overseeing. The least conspicuous place for them is probably in the corner, near the ceiling.

Our house has white walls, so naturally I’d like to have something white up there, not some black or metal box!

Here’s an idea:

Screen shot 2010-01-22 at 14.12.54.png

To be made of – wait for it – foam board!

It’s probably a bit hard to visualize, but the idea is to attach a triangular “corner plate” to the wall (using glue / nails / screws / telekinesis / whatever). Then you slide this assembly with JeeNode and battery pack onto it.

Here’s a paper mockup of the sliding part:

DSC_0946.jpg

With one or two “struts” to reinforce it, this ought to be fairly sturdy and easy to slide in and out (will probably have to do that often in the beginning!). Perhaps a few needle pins will be enough to keep it fixed in place.

Laid flat, the sliding part looks like this:

DSC_0947.jpg

Needs some holes in the middle section, for the PIR, SHT11, and LDR sensors.

The geometry of this thing is quite simple, once you wrap your mind around what it really is – an equilateral triangle placed against the top corner with horizontal cross sections on top and cutting off the bottom part:

Screen shot 2010-01-23 at 13.46.52.png

The trick will be to get the sizes right. The paper mockup shown here is about 12 cm on each side, enough for a JeeNode, but too small to also hold a 3x AA battery pack behind it. It also shouldn’t be too hard to make some extra templates pointing off-center – so that you’d essentially aim the PIR by picking the most suitable enclosure variant.

I’m going to try a version using foam board next. Never a dull moment :)

P.S. If you qualify for a 10% discount in the shop, please note that there are 7 days left.

Lithium node

In Hardware on Jan 23, 2010 at 00:01

The 3.6 long-life / low-current OmniCel lithium batteries just came in.

Say hello to the latest room node at Jee Labs:

DSC_0944.jpg

Colorful, eh? ;)

The battery is connected directly to +3V and GND, i.e. after the voltage regulator, since its operating voltage is an excellent match for the ATmega and RFM12B.

No motion sensor was needed for where this node is going (and I didn’t have any left anyway), so that reduces the current draw by some 40 µA. Average should be somewhere around 200 µA – as mentioned before, this can no doubt be optimized further.

Since there are no motion triggers, this node will only send one or two packets per minute – the battery should last well into 2011, according to the specs.

Unless the receiver is turned off and this thing starts re-transmitting all the time. I really need to fix that flaw…

For a fun enclosure, check out the Airwick post by Szymon Kobalczyk on the Jee Labs discussion forum.

Single AA room node

In AVR, Hardware on Jan 21, 2010 at 00:01

The range of things to try is just endless…

Here is a (v2) JeeNode with a (prototype) room board and a 1-cell battery:

DSC_0942.jpg

Note that this prototype board is turned 180° w.r.t. the official Room Board, to match the Rooms sketch.

This node uses a 1.5 => 5V converter from SparkFun, which I had lying around. It’s far from optimal, with one third of the energy eaten up by the 3.3V voltage regulator, but it’ll have to do for now. Let’s see how long it lasts…

The whole thing is mounted on a little piece of foam board with dual-sided adhesive tape. Just to try it out.

To give you an idea of what’s flying around over the 868 MHz airwaves around here:

Screen shot 2010-01-20 at 00.18.35.png

That’s some 10 room nodes, the OOK relay with a bunch of sensors, and the energy/gas metering packets. Note how the Linux system time is exactly in sync with the DCF77 atomic clock receiver (using UCT i.s.o. CET). Note also that the OOK relay data is currently reported twice: once through a direct USB connection, once over the air.

Lots of fun! And that’s just the beginning, as far as I’m concerned :)

On a related note: I’m investigating whether it would be feasible to bring out a complete kit for the Room Board – with motion, light, temperature, and humidity sensors all included. If I can find the right distributors and order in sufficient quantity, it might be possible to get such a kit in the shop for €39, incl. VAT. Let me just say that if it can be done, you’ll be the first to know!

Interesting battery option

In Hardware on Jan 19, 2010 at 00:01

Found an interesting (one-time, i.e. disposable) battery cell the other day at Farnell:

Screen shot 2010-01-17 at 21.03.13.png

These have the size of an AA cell, but they deliver 3.6V, so they can effectively replace 3 AA cells at once. The voltage is just right – this battery could be used with or without the JeeNode’s 3.3V voltage regulator.

The discharge graph is as follows:

Screen shot 2010-01-19 at 16.47.29.png

I’ve ordered a few with wires attached to them, so they could be tied directly to the PWR & GND pins of the FTDI connector. Will report back once some “field tests” have been done.

Update – better discharge graph, see comments below.

Fun board

In Hardware on Jan 17, 2010 at 00:01

Here’s a fun project:

DSC_0938.jpg

This is an A4-sized foam board with four “indicators”. Each of the colored vane pointers can rotate 90°. The idea is to place a sheet of A4 paper underneath them with some sort of scale, so that you can see 4 status values at a glance. Energy consumption, number of pending emails, whatever.

Here’s the back side:

DSC_0939.jpg

That’s an old v2 JeeNode with an ATmega168 and 4 cheap micro-servos strapped to it. The extra capacitors reduce the voltage ripple while these servos move, since they seem to generate quite a lot of noise.

The whole thing is held together by zip-lock straps:

DSC_0940.jpg

The servo axes pass through holes in the bottom, which is in the fact the front plate.

Here is a test sketch to move each of the servos via commands given to the serial port:

Screen shot 2010-01-16 at 10.55.46.png

The basic range for each servo is 45 to 135 degrees, and the h/j/k/l keys control each individual servo, so this lets me position each one with commands such as “45h”, “90j”, “135k”, “75l” etc. There are also commands to move all servos, or to return each one of them to the middle position. These positions are only approximate, each servo will need slightly different values for their end ranges.

It turns out that these servos can’t all be moved at the same time reliably. I’m guessing that they generate too much noise or pull down the 3.3V regulator too far. So all actions involving multiple servos need to be staggered. Another problem is that these low-cost servos sometimes get “stuck” and keep jittering around the target position – this can be prevented by detaching them, since each servo will stay at its last position.

Next step will be to drive these indicators from wireless. I’m going to postpone that for now, because this status display really needs a “switchboard” type application running on the central PC to manage real-time updates.

This thing can’t run off batteries, unfortunately, because the servos draw too much current. I’d be interested to make a display in the future which does run wirelessly – maybe something with solenoids or tiny DC motors.

One of the JeeHubs?

In Hardware on Jan 15, 2010 at 00:01

Just got this thing in:

DSC_0936.jpg

It’s a SheevaPlug with 512 Mb RAM, 512 Mb flash, Gb ethernet, and a USB host port.

As you can see, I plugged a JeeLink into it, along with a 2 Gb memory card.

This is just one of several configurations I am going to look into. One of the design criteria for the server side is that it needs to be portable to a fairly wide range of hardware, from desktop PC’s, to some really small embedded Linux boards. This SheevaPlug sits somewhere in between, with a lot more oomph than needed just for JeeMon, yet an idle consumptions of only a few watts.

Haven’t turned it on, let alone adapted the JeeMon software for it, but that’s only a matter of time.

Time? Man, that’s such a scarce resource around here!

Meet Roomie

In Hardware on Jan 13, 2010 at 00:01

It may not be the prettiest gadget in the home …

DSC_0931.jpg

… but I find it mighty convenient. I think I’m going to call it a “Roomie”.

The battery pack shown here is an older green one, the ones currently in the shop are black.

It’s nothing but a JeeNode with a battery pack and a Room Board on top. This example is not optimal, it uses a power hungry ePIR. But you get the idea.

The battery pack is tied to the dedicated connection for it – going through the strain relief holes and around the other side to the solder pads:

DSC_0932.jpg

And the whole thing is glued together with hot glue:

DSC_0935.jpg

Nice thing is that this doesn’t restrict the uses of a JeeNode. When switching the battery off, you can hook it up to a USB interface via the FTDI header.

In fact this will even work upside down on a foam board, as used with POFs:

DSC_0934.jpg

Just think of it as a JeeNode with a power pack sitting on its back :)

Pin I/O performance

In AVR, Hardware, Software on Jan 6, 2010 at 00:01

There was a discussion on the Arduino developer’s mailing list about the impact of a small change to the digitalWrite() function, and for some time I’ve been hearing that digitalWrite() has a huge amount of overhead.

Time to find out.

Here is the sketch I used to measure how often a pin I/O command can be issued using various mechanisms:

Screen shot 2010-01-05 at 11.42.53.png

The logic is that I’m counting how often the same command can be called between timer overflows, i.e. every 1024 µs (one byte, incrementing @ 16 MHz / 64), before the timer tick count changes again.

And here’s the sample output:

Screen shot 2010-01-05 at 11.42.14.png

There’s a small amount of jitter, which tells me the loops are syncing up almost exactly on the timer ticks. Interrupts have not been disabled, so the timer interrupt is indeed being serviced – once for each loop.

What these values tell me, is that we can do about:

  • 10 analog 10-bit readings per millisecond with analogRead()
  • 128 pwm settings per millisecond with analogWrite()
  • 220 pin reads per millisecond with digitalRead()
  • 224 pin writes per millisecond with digitalWrite()
  • 1056 pin reads per millisecond with direct port reads
  • 1059 pin writes per millisecond with direct port writes

(I’ve corrected the counts by 1000/1024 to arrive at these millisecond values)

So the Arduino’s digital I/O in IDE version 0017 can do roughly 1/5th the speed of direct port access on a 16 MHz ATmega328.

But WAIT! – There’s a large systematic error in the above calculations, due to the loop overhead. It looks like the loop takes 1024000/1251 = 819 ns overhead, so the actual values are quite different: digitalRead() -> 3712 ns, direct port read -> 151 ns. Now the values are more like 1/25th!

So let’s redo this with more I/O in each loop iteration (all 4 ports):

Screen shot 2010-01-05 at 11.55.31.png

The sample output now becomes:

Screen shot 2010-01-05 at 11.56.59.png

With these results we get: one digitalRead() takes 4134 ns, one direct port read takes 83 ns (again correcting for 819 ns loop overhead). The conclusion being that digitalRead() is 50x as slow as direct port reads.

Which one is correct? I don’t know for sure. I retried the direct port read with 16 entries per loop, and got 67 ns, which seems to indicate that a direct port read takes one processor cycle (62.5 ns), as I would indeed expect.

Conclusion: if performance is the goal, then we may need to ditch the Arduino approach.

Update – Based on JimS’s timing code (see comments): digitalRead() = 58 cycles and direct pin read = 1 cycle.

Update #2 – The “1 cycle” mentioned above is indeed what I measured, but incorrect. The bit extraction was probably optimized away. So it looks like direct pin access can’t be more than 29x faster than digitalRead(). As pointed out by WestfW in the comments, digitalRead() and digitalWrite() have predictable performance across all use cases, including when the pin number is variable. In some cases that may matter more than raw speed.

Update #3 – Another caveat – Lies, damn lies, and statistics! – is that the register allocations for the above loops make it extremely difficult to draw exact conclusions. Let me just conclude with: there are order-of-magnitude performance implications, depending on how you do things. As long as you keep that in mind, you’ll be fine.

Arduino Duemilanove

In AVR, Hardware on Dec 30, 2009 at 00:01

Not everything is about wireless. Nor about nodes, ports, or plugs. Of course not – that would be boring :)

To offer more choices, I’ve added the Arduino Duemilanove to the web shop:

Duemilanove_HI.JPG.jpeg

Jee Labs is now an official distributor for these famous boards. Woohoo!

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.

Arduino and complexity

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

This is – in a nutshell – the Arduino world:

Screen shot 2009-12-27 at 18.53.04.png

In prose: an ATmega board, some hardware peripherals, an environment for embedded software development, a front-end for visualization, and a website to bring all these facets together for a growing worldwide community.

For each of these, there are alternatives and variations. These add variety and increase the number of choices for everyone interested in this low-cost physical computing world. The “Arduino” name is conquering the world, and it sticks … even as “duino” suffix. Names are a great way to create a brand.

But what is Arduino, really? Is it an ATmega? Is it a board that fits in the palm of your hand? Is it a standard for connecting other boards? Is it a standard way of structuring software? Is it defined by a set of standard libraries? Is it the dual aspect of the IDE, i.e. Wiring vs. Processing? Is it the main web site or the discussion forum?

The answer depends no doubt on who you ask. And if this is a healthy ecosystem, then all of these will evolve and improve over time. In my opinion, the current state of an ecosystem is far less important than its ability to evolve.

That’s where complexity comes in.

It’s not hard to construct a great system, even an elaborate one. But what is extremely hard, is to come up with a system which supports evolution of all the pieces involved. Because with multiple pieces, you have to make decisions. You have to interconnect the pieces, and that requires making choices. And once you do, you reduce the number of future paths, including many you don’t even know about yet.

Making choices can be good. Hooking up an Arduino to a PC via a serial connection is a great low-cost solution for uploading, debugging, and interacting. The transition from an RS232 connection + a separate power supply to a USB connection with “built-in” 5V power is an excellent example of how evolution can lead to substantial progress.

Technological evolution can take years. And as in life, that’s where the really interesting stuff happens.

Unfortunately in the Arduino world, I’m hitting some nasty edges which tell me we need more generality or flexibility. I’ll describe a few, in terms of interfaces between the different pieces shown above:

Voltage levels – the most widely used Arduinos are based on 5V, meaning that all their I/O pins are also 5V-based. More and more sensors can only be used with a supply voltage up to 3.6V or so. Interfacing them to a standard Arduino requires the use of level converters. Often, resistors will do – but you can’t simply ignore the issue. This is an area where I2C can help.

Hardware modules – the Arduino “shield” concept doesn’t extend very far, because each shield determines which pins it needs. Pins are a scarce resource, and each pin location on the connector is fixed. It’s hard to design shields which will actually stack with others. Even more so now that there is a new Arduino Mega with slightly different pin allocations.

Software modules – libraries are a great concept: code which is there when you need it, but doesn’t get in the way (i.e. included) if you don’t. Right now, adding a library which depends on say the “Wire” library means that you have to include the Wire library in your sketch even if you don’t ever use it. This is almost a show-stopper.

C/C++ code – on the surface, programming for the Arduino board is like programming in C and C++, with a bunch of very common issues resolved and a wide variety of useful functions available, ready to use. Newbies can get going fast and old hands can find their way around in no time. Except… the IDE does some funky things with headers and declarations. And it breaks a couple of fairly basic C/C++ conventions.

Automation – the IDE works with a specific scenario in mind. As of the latest 0017 release, multiple sketches and consoles are supported. This solves some of the issues, but it’s hard to automate this further: after uploading, I still have to manually launch the serial console. If I have some other app talking to the hardware, there is no mechanism to upload a new sketch and then resume that app because the serial USB connection is dedicated.

Visualization – it’s interesting to see how the Arduino / Wiring / Processing approach is bridging a huge range of hardware in an integrated manner. But there are several choices involved which reduce flexibility towards entirely different approaches. Some visualizations (as well as other types of data processing) would benefit from using a more internet-/web-centric approach. Lower-end hardware cannot support the Java environment used by Processing, so that code can’t be leveraged. There are alternatives. Scripting language support would be useful.

Don’t get me wrong: all these issues are tough ones! It’s probably impossible to solve them all and to make everyone happy. These issues are definitely not things open source software is obliged to address from day one. But my point is that this is not about where we are today, but about having the mechanisms to evolve to where we want to be tomorrow.

If you’ve followed this weblog for a while then you can probably guess that I’ve got some ideas and suggestions on how to move forward on all this. I would really like to help take the existing Arduino platform further – but I’m not sure at this point that it can be done within the current constraints. I don’t even know whether anyone else considers the issues listed above to be important. All I know is that as I continue to add more software and design new hardware, the “push-back” from the current Arduino design choices is increasing… a lot.

Do I want to change the Arduino world (i.e. make a case, convince people, find compromises) – or do I want to sidestep some of its decisions by starting all the way from scratch? I haven’t decided.

CupCake

In Hardware on Dec 27, 2009 at 00:01

Spent a day with the family on assembling the CupCake CNC 3D-printer. Great fun!

Here’s where we are now:

DSC_0916.jpg

The enclosure and all three axes have been assembled. As seen from the top:

DSC_0924.jpg

Still remaining: the plastics extruder and the electronics – next week, hopefully!

RF12 status lights

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

Here is a little setup to see what’s going on in the ether, wirelessly speaking, that is:

FlySketchExport.png

Four LEDs, blinking according to the following status signals:

  • RECV – blinks briefly for each received packet
  • RSSI – shows the value of the RSSI bit in the RF12 status
  • DQD – shows the value of the DQD bit in the RF12 status
  • ALIVE – blinks at 1 Hz, just to show that this node is alive

I changed some thresholds to get better results: RSSI threshold -91 dBm and DQD set to 7 (normally -103 and 4, in the current RF12 driver).

Here is the sketch which drives the LEDs accordingly:

Screen shot 2009-12-20 at 16.05.18.png

In this example, I’ve set up the RF12 parameters to receive group 5 in the 868 MHz band.

The result is quite interesting: DQD is flashing constantly, in an irregular pattern. RSSI blinks only once in a while, and some of these cause RECV to light up – as expected: only packets with the proper FSK format are filtered out, and only some of those are for this specific net group.

The reason for doing this will become clear tomorrow…

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:

DSC_0869.jpg

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

DSC_0870.jpg

Onwards. Quickly, please :)

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:

DSC_0866.jpg

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.

Battery life – refinement

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

Yesterday’s post described how to estimate the battery life of a JeeNode running the “rooms” sketch with the SHT11, ELV PIR, and LDR sensors. To summarize:

  • the code started out using 370 µA average current, i.e. roughly 7 months on 3 AA cells
  • of these, 200 µA were caused by the 1-second periodic wakeup “blip”
  • another 120 µA were due to the actual measurements and packets sent every 30 seconds
  • and finally, the remaining 50 µA come from the PIR + JeeNode current draw in sleep mode

Yesterday’s post was also about reducing that 200 µA blip consumption to somewhere around 20 µA.

Today, let’s tackle the other power “hog”: the 300 ms @ 12 mA spike. Here is that pattern again:

b1.png

The high peak at the end is the RF transmission of a packet, followed by a “knee” during which the node is waiting for the ack packet in RF receive mode.

Note that the main power drain is NOT caused by wireless communication!

This period of over 300 milliseconds is when the ATmega is polling the SHT11, waiting for a fresh reading. Twice in fact: once for the temperature and once for the humidity measurement.

So the explanation is very simple: we’re polling and waiting in full-power mode. Quelle horreur!

The fix requires a small modification to the SHT11 driver in the Ports library. Instead of a fixed delay, it needs to be extended to allow using an arbitrary function to waste some time. Here’s the modified code:

Screen shot 2009-12-18 at 01.00.53.png

A new second arg has been added, specifying an optional function to call instead of delay(). The code remains backward compatible, because this argument defaults to zero in Ports.h:

Screen shot 2009-12-18 at 01.02.45.png

So now all we need to do is define a delay function which goes into real power down mode for a little while:

Screen shot 2009-12-18 at 01.52.23.png

… and then adjust the two measurement calls to use this function:

Screen shot 2009-12-18 at 01.05.08.png

Does all this make a difference? You betcha:

b2.png

That’s a substantial fraction of a second in which the ATmega will draw considerably less than 12 mA. How much less? Let’s expand the vertical scale:

b3.png

Most of the time, the voltage is around 50 mV, i.e. 1 mA over 47 Ω. That’s the SHT11 current draw while active. There are two measurements – so everything behaves exactly as expected!

A couple of quick wake-ups remain, to check whether the SH11 measurement is ready. And so does the wireless TX/RX peak, of course. Here is an isolated snapshot of that RF activity (200 mV/div and 4 ms/div):

b4.png

Approximate current draw: TX = 35 mA, RX = 20 mA. Total time is about 10 ms.

Looks like we’ve reduced the power consumption of this once-per-30-second spike by perhaps 90%. As a result, the node now consumes about 20 (blip) + 20 (spike) + 50 (sleep) = 90 µA on average. Even with much smaller 800 mAh AAA cells, the battery life of these low-power nodes should now be over a year.

There are several conclusions to take home from this story, IMO:

  1. The biggest drain determines battery lifetimes.
  2. Measuring actual current profiles always beats guessing.
  3. A simple USB storage scope is plenty to perform such measurements.

If I had followed my hunches, I’d no doubt have spent all my time on getting the current draw of packet transmissions down – but as these experiments show, their effect on power drain is minimal.

There are more optimizations one could explore. There always are. But the gains will be limited, given that the ELV PIR sensor consumes 30..40 µA, and that it needs to be on at all times anyway, to be able to detect motion.

Sooo… end of story – for now :)

All source changes checked in. The entire rooms sketch still compiles to under 8 Kb of code.

Battery life estimation

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

To get an indication of battery power drain, I measured the voltage drop over a 47 Ω resistor in series with the 5V supply, using a JeeNode with Rooms Board and the latest version of the “rooms” sketch.

Here’s the blip I see, once a second (100 mV/div and 20 msec/div):

on-time-1.png

That’s a 40 msec pulse of about 5 mA, in other words: 5 mA during 4 % of the time, which averages out to around 200 µA current draw continuously. Not bad, but not stellar either: it’s 4 times the sleep mode current.

Every once in a while, a much longer and bigger spike shows up:

occasional-peak.png

Which looks like roughly 350 msec @ 12 mA.

Let’s assume the big one is a real transmission. It sort of fits: the spike at the end is a brief transmission at ≈ 35 mA total, followed by a 20-ish mA period of reception (waiting for the ack to come in).

Very roughly speaking, the area of that extra spike at the end is about the same as the 5-to-10 mA step at the start of this period. So as an estimate, we’re consuming about 12 mA during 350 msec – let’s round down to 300 msec.

Let’s also assume these bigger current patterns happen every 30 seconds, when the node is reporting changed values (everything other than motion gets reported at that rate in the latest “rooms” sketch).

So 1% of the time (300 ms every 30s), power consumption is 12 mA. This averages out to 120 µA continuous current consumption.

In other words: a JeeNode running this latest rooms sketch with the SHT11 and ELV-PIR sensors, is consuming roughly 200 (blip) + 120 (spike) + 50 (sleep) = 370 µA.

Using a 2000 mAH 3-cell AA battery, this should lead to a 225-day lifetime – over 7 months.

Can we do better? Sure.

It’s basically a matter of figuring out what’s going on during those 40 and 350 msecs, respectively. Interestingly, more can be gained by improving non-transmitting “blips” than twice-a-minute high-power RF packet exchanges.

Do those 40 ms @ 5 mA every second look a bit suspicious? Yep – that’s the “idling” power level. What happens is that I was a bit too pessimistic in the time spent in sleep mode. This was the code:

Screen shot 2009-12-17 at 00.51.26.png

Looks like this is about 40 ms off, and so the code ends up waiting for the 1 sec timer to expire… in idle mode!

Let’s change this to end up closer to the desired time:

Screen shot 2009-12-17 at 02.59.16.png

Here’s the new blip (different scales):

better-blips.png

We’re down from 40 to 10 msec blips – tada!

That translates to an average 50 µA current draw from the blips, bringing the total down to 220 µA. Which translates to a 375-day battery life: over a year!

Now we’re cookin’ … but could we do even better? Sure.

Note that only the 2 ms spike at the end of the 5 mA blip is the actual active period. The time up to then we’re just waiting in idle mode – and wasting power.

We could shorten the sleep timer to 994 ms, since we don’t care whether readings are taken exactly 1 second apart. Now the RFM12B-based watchdog timer will wake us up just 2 ms short of the target time. And sure enough, the 5 mA blip is down to around 3 ms – shown here with an even further expanded time scale:

final-blip.png

But that’s silly. We’re tweaking a millisecond timer, and we’re not even interested in an “exact” 1000 ms cycle in the first place! It makes much more sense to just use the RFM12B wakeup timer to get us close to that 1 second cycle, and then immediately take a measurement. Here’s the corresponding code change in periodicSleep():

Screen shot 2009-12-17 at 02.35.36.png

Does this make a difference? Definitely:

best-blip.png

One final remark: the above battery lifetime estimates do not take into account the increased power consumption when motion is detected and more packets are sent (up to once every 5 seconds). On the plus side, when no light / temperature / humidity changes happen, the packet frequency will drop further, to once-a-minute.

The above changes have been checked into the source code repository.

Update – I just found out that the DSO-2090 scope has a high-pass low-pass filter option:

smooth.png

Sure wish I’d found out about that feature sooner… it’s so much more informative: the initial ramp is probably the clock starting up, and the little peak could well be the LDR pull-up during ADC conversion!

Prototyping

In Hardware on Dec 17, 2009 at 00:01

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

DSC_0861.jpg

… and these:

DSC_0862.jpg

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

DSC_0787.jpg

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.

Rooms sketch, reloaded

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

With the new easy transmission mechanism and the low power logic implemented, it’s time to revisit the “rooms” sketch, which I use for all my house monitoring nodes based on the Room Board.

I’ve wrapped the code used in POF 71 a bit further, with these two extra functions:

Screen shot 2009-12-15 at 22.25.44.png

With this, the main loop becomes very simple – even though it will now power down the RFM12B and the ATmega328 whenever there’s nothing to do for a while:

Screen shot 2009-12-15 at 22.25.57.png

The lowPower() and loseSomeTime() code is still the same as in POF 71 – this is where all the hardware low-power trickery really takes place:

Screen shot 2009-12-15 at 22.24.57.png

Note that these need an “#include <avr/sleep.h>” at the top of the sketch to compile properly.

I’ve also disabled the pull-up resistor on the LDR while not measuring its value. This drops power consumption by over 100 µA, depending on actual light levels.

A quick measurement indicates that power consumption went down from 20 mA to some 50 µA (much of that is probably the PIR sensor). These are only approximate figures, because my simplistic multi-meter setup isn’t really measuring the charge (i.e. integrated current draw), just the current draw while in sleep mode.

These changes have been checked into the repository as “rooms.pde”.

This code isn’t perfect, but since “perfection is the enemy of done” I’ll go with it anyway, for now. One difference with the original rooms sketch is that the motion sensor is not read out as often so brief motion events might be missed. Another issue with this code is that if the central node is off, a lot of re-transmissions will take place – without the node going into sleep mode in between! IOW, a missing or broken central node will cause all remote nodes to drain their batteries much faster than when things are properly ack’ed all the time. Oh well, let’s assume this is a perfect world for now.

With these levels of power consumption, it’s finally possible to run room nodes on battery power. I’ll use some 3x AAA packs, to see what sort of lifetime this leads to – hopefully at least a couple of months.

Will report on this weblog when the batteries run out … don’t hold your breath for it ;)

Update – I just fixed a power-down race condition, so this code really goes back to sleep at all times.

Re-flashing and ISP

In AVR, Hardware on Dec 11, 2009 at 00:01

This is the second of two posts about everything related to uploading, re-flashing, bootstraps, FTDI, and ISP.

Yesterday’s post described the process of uploading new sketches via USB or RS232 using a boot loader.

But how did that boot loader get into the ATmega328?

That’s a bit of a chicken-and-egg problem. Ya’ can’t use a boot loader to get the boot loader into flash memory!

This is where a lower-level hardware-based mechanism called In System Programming (ISP) comes in. ISP is a clever trick in the ATmega chip which in effect activates a special boot loader built into the hardware. This is done by holding the RESET line of the ATmega low, at which point the chip becomes essentially useless, since the reset prevents the chip from starting to run its firmware. The trick is that in this mode, some of the pins on the ATmega become an interface to that special hardware-based built-in boot loader.

So what we need to do, is to manipulate those pins to send commands which will store data into the flash memory. What we’re going to send in most cases, is the data for the boot loader in upper memory. With that boot loader in place we can then switch to “normal” uploading via the serial interface and USB.

ISP programming is also used to change “fuse bits” on an ATmega. There are a few configuration settings for the ATmega – what type of clock it uses, how it boots up, enabling a watchdog timer, etc. These are stored in “fuses” which can only be adjusted via ISP programming.

There are 3 I/O pins involved in ISP programming, plus the reset line and power. On the Arduino as well as on the JeeNode and JeeLink boards, these lines are available via a 2×3-pin ISP connector with the following layout:

ISP pins.png

The interesting thing is that you don’t even need an Arduino or JeeNode to set up flash memory and fuses. ISP is so low-level that it works directly on the pins of an ATmega chip. This is very useful to pre-load the boot loader (or test program – anything you like, really) onto a chip before soldering it permanently onto a board.

(continued…)

Read the rest of this entry »

Uploading and FTDI

In AVR, Hardware on Dec 10, 2009 at 00:01

This is the first of two posts about everything related to uploading, re-flashing, bootstraps, FTDI, and ISP.

First, our goal: what we want to do is get our software (“sketch”) from the PC/Mac into the AVR ATmega328 microcontroller on our Arduino or JeeNode. This is a fairly simple process once all the pieces are in place…

The effect is that the flash memory built into the ATmega is re-flashed. Being flash memory, your software will remain in the microcontroller even without power – ready to start again once power is applied.

There are two ways to get your software into the ATmega: In System Programming (ISP) and uploading. ISP will be described tomorrow, here we’re going to focus on uploading.

Uploading works with a “boot loader”. This is a small piece of software started after power-up (or a reset), which usually listens on the RX and TX pins of the serial interface for commands. These commands then tell it what data to store in which part of the flash memory:

Screen shot 2009-12-09 at 12.25.31.png

The surprising thing is that the boot loader itself is also stored in flash memory. It’s stored in a small (1..4Kbyte) area in upper memory, and the data it writes always goes to the lower part of memory. That’s why it’s called a bootstrap or boot loader – imagine lifting yourself by pulling on the straps of your own boots. In this case the ATmega is lifting its own functionality up by reprogramming its flash memory via its own boot loader.

(continued…)

Read the rest of this entry »

Wireless Light Sensor – POF 71

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

After last week’s Hello World POF to get started, here is a new Project On Foam:

DSC_0824.jpg

A battery-powered wireless light sensor node. This is POF 71, and it’s fully documented on the wiki.

This project goes through setting up the Ports and RF12 libraries, setting up a central JeeNode or JeeLink, and constructing the light sensor node.

It also describes how to keep the node configuration in EEPROM, how to make a sensor node more responsive, and how to get power consumption down for battery use.

The POF includes code examples and uses the easy transmission mechanism, with the final responsive / low-power sketch requiring just a few dozen lines of code, including comments. The sketch compiles to under 5 Kbyte, leaving lots and lots of room to extend it for your own use.

All suggestions welcome. Anyone who wants to participate in these POFs, or in the wiki in general, just send me an email with the user name you’d like to use. I’m only restricting edit access to the wiki to prevent spamming.

JeeNode power pins

In Hardware on Dec 7, 2009 at 00:01

The JeeNode has a number of connections for external power. This is the place before the 3.3V LDO regulator. Keep in mind that all these pins are tied together, electrically:

JeeNode power pins.png

This has two important consequences:

You can power a JeeNode through any of these pins. It does not matter how you connect power to a JeeNode, all of them will have the same effect. You don’t have to connect a battery to the battery connector or the FTDI connector, you can also tie it to a PWR pin on any of the port headers (as I tend to do with Projects On Foam).

You should avoid connecting multiple power sources. If you connect a 9V battery, for example, the JN will work fine. But if you leave it connected when plugging in an FTDI interface such as a USB-BUB, then the 9V will find its way to the FTDI chip, and through the internal ESR diodes probably also to some I/O pins. Chances are high that you’ll damage at least the FTDI and the ATmega chips at this point (thanks to Paul Badger for pointing this out). A 3- or 4-cell Alkaline / NiMh battery pack can probably take some abuse without damaging anything.

There are no diodes in these various connections because the JeeNode is designed to be usable under very low power conditions. Throwing away 0.6V (or even just half that with a Schottky diode) is not always an option. The MCP1702 voltage regulator on the JeeNode was specifically selected to have an extremely low drop-out voltage (under 0.1V at low power levels) and a minute quiescent current draw (under 2 µA). This means that you could power a JeeNode from just 3.4V, perfect for 1 LiPo or 3 NiMh batteries, for example. The price is reduced protection against incorrect use.

The JeeNode USB is slightly different. It is intended to always be powered from USB, i.e. with PWR fixed at 5V. There are no FTDI and battery connectors, and all the other pins are connected to the 5V line via a 350 mA polyfuse (PTC) as protection against over-current on the USB power line. You can probably power a JeeNode USB through any of the port or PSI connectors, as long as the voltage is around 5V. The current draw will be several mA higher than with a plain JeeNode due to the on-board FTDI chip.

Building the JeeNode v4

In Hardware on Dec 6, 2009 at 00:01

Here are the updated build instructions, using the latest v4 board.

This is the contents of the kit:

DSC_0593.jpg

You’ll need some basic skill at soldering but don’t worry, as there are only a few parts to solder on. The best way is to start with the lowest-profile part, that way you can place things flat on the table and press down to keep the parts in place. So let’s start with the 10 KΩ resistor:

DSC_0595.jpg

Turn the board around and solder the leads:

DSC_0596.jpg

(continued…) Read the rest of this entry »

FTDI Reset Supressor

In AVR, Hardware on Dec 5, 2009 at 00:01

Sometimes the simplest things are so obvious that it’s easy to miss them…

I occasionally do not want to reset a JeeNode when accessing it via USB. The reset is great for uploading, because the ATmega’s bootloader runs right after reset and intercepts such upload requests in a very convenient way. But sometimes, you just want to leave the ATmega running when re-connecting to it.

Meet the “FTDI Reset Suppressor”:

DSC_0827_2.jpg

All it does is break the reset connection between an FTDI interface such as the USB-BUB and the JeeNode.

Just to make this post a little longer, here are the steps to make one:

DSC_0827.jpg

And here is an action shot:

DSC_0828.jpg

Tada! And it’s totally voltage, baud-rate, and platform independent… :)

Update - it just occurred to me that this already exists, it’s a 5-pin stacking header! Or a 6-pin one, as follows:

DSC_0836

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:

DSC_0816.jpg

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

DSC_0818.jpg

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.

Hello World – POF 52

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

The first Project On Foam is inevitably a blinking LED:

DSC_0814.jpg

Not very exciting, but it’ll allow me to go through the steps needed to set up the development environment, the first-time USB hookup, and getting a first sign of life out of a JeeNode in Physical Computer terms…

There is a new section on the Jee Labs wiki which I’m going to use for POFs. For rather obscure reasons, this POF is #52 – it’s at http://wiki.jeelabs.net/pof/52 (new POF numbers always increase).

Note that as Project On Foam, this Hello World example is rather silly – because it doesn’t really need a foam base at all. But bear with me – this step is intended to help people through the first (and sometimes daunting) steps of getting started.

The challenge for me right now is to provide the proper information as concisely as possible. These POFs are being placed on the wiki so they can be updated and improved. There will be a few more people involved in this, which again makes the wiki much more suitable to collect and maintain all the POFs than say this weblog. New POFs will be announced on this weblog, but updates are an ongoing process on the wiki pages themselves.

There have been a lot of experiments and projects at Jee Labs over the past year, in various stages of completion. From hooking up all sorts of sensors to the house-monitoring network currently running here at Jee Labs. It is my intention to redo a number of these as POF, in more detail and with more background information. Other POFs will be completely new, though – the list of fun stuff one can do with Physical Computing is endless!

Other news: since assembly and reflow soldering of the JeeLink and the JeeNode USB has been going a lot better lately, their price has been reduced to €29.50 (incl. VAT and shipping) – see the shop for details.

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

DSC_0815.jpg

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…

JeeLink flash memory

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

The recently updated version of RF12demo automatically logs all incoming data to the 1 Mbyte flash memory in a JeeLink. It looks like this is starting to work fairly well – I’ve been leaving a JeeLink on for over a week now, picking up packets from a number of different sources around here. It’s still only 80% full:

Screen shot 2009-11-28 at 12.34.27.png

So the JeeLink is now at page 3102 of 3840. Here are the first and last lines from the dump command:

Screen shot 2009-11-28 at 12.36.37.png

Screen shot 2009-11-28 at 12.38.30.png

The first two numbers after the colon are the reboot count and the time in seconds since reboot. There have been a bunch of reboots (most of them caused by me connecting to the JeeLink via a terminal program to see how it’s doing). The last run has been going for almost 24 hours.

Here are the first and last lines of the actual stored data replay:

Screen shot 2009-11-28 at 12.42.30.png

Screen shot 2009-11-28 at 12.45.23.png

Again, the first two numbers on each replayed packet are reset count and seconds since reboot. The rest is the packet data itself.

That’s quite a bit of stored data – almost 84,000 lines of text. It took over 7 minutes to get it all across USB at 57600 baud. Each received packet of data uses about 10 bytes of flash memory on average, in this example.

These results are better than I expected. Even with much more data coming in, it should be possible to leave the PC turned off over say the weekend, with the JeeLink collecting all incoming data and then replaying it when the PC comes back on. The only requirement is a powered USB socket.

Good. My home monitoring network won’t need a PC or server to be constantly on, since I don’t intend to set up around-the-clock internet access to this info – unless perhaps while away from home.

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:

DSC_0806.jpg

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.

Onwards!

Introducing Projects On Foam

In Hardware on Nov 27, 2009 at 00:01

After exploring a number of options, I’m settling on foam board as the basis for my future Jee Labs demo projects. So here come the Projects On Foam – POF’s!

What’s a POF? Well… I start with two JeePlugs and solder some headers onto them, as follows:

DSC_0789.jpg

Then I take an A5-sized (148×210 mm) piece of 5 mm foam board / foam core:

DSC_0790.jpg

… and glue those two plugs onto it using sticky tape or hot glue, pins up:

DSC_0788.jpg

Last step is an optional battery holder and some rubber feet on the back side:

DSC_0792.jpg

And there you go, the basis for an endless variety of Projects On Foam:

DSC_0793.jpg

Just by sticking stuff together. Here’s an example:

DSC_0787.jpg

I’ll probably fix one or two mini-breadboards onto the board as well.

The end result is modular, reusable, light, cheap, and sturdy enough to pick up and move around. It’s not meant for permanent setups, the whole idea is really to “doodle” with nodes and plugs in this way until everything works, and then to take it all apart and either rebuild the whole circuit from scratch with all the individual components, or to place these boards and plugs inside a more permanent enclosure.

Here’s another trial, with a cutout for the LCD to make it stick in place a bit better:

DSC_0759.jpg

(apologies for the flash lighting)

As you can see, by adding a sheet of paper between the board and the different components, everything can be labeled and annotated.

I still need to fool around with this approach a bit more, but so far so good – it would be easy to make templates as PDF’s so others can replicate these Jee Labs projects more easily.

If there is any interest in this, I can make foam boards and other doodahs available via the shop. There’s really nothing to it.

Update – POFs now have their own section in the wiki.

JeeNode comparison matrix

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

All the final boards are in now. It’s time to step back a bit. Let’s start with a picture:

DSC_0785.jpg

From left to right: JeeLink (v2), JeeNode USB (v2), and JeeNode (v4).

Here is a summary of the similarities and differences between these units:

jee-comparison.png

(this comparison matrix is also available as PDF)

So there you have it – one happy JeeFamily :)

Update – Nov 30: lower prices for the JeeNode USB and the JeeLink!

Update – Dec 1: added the new low-cost “JeeNode NoRF” kit.

Meet the new Analog Plug

In Hardware on Nov 25, 2009 at 00:01

Here’s the revised Analog Plug (AP2):

DSC_0780.jpg

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:

DSC_0782.jpg

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:

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…

Node, node, node

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

Ok, finally got around to building a bunch of JeeNodes for all those room boards I had waiting:

DSC_0775.jpg

Just for the heck of it, I decided to leave the boards joined together, as they come from the pcb manufacturer. This picture was taken just before separating these final units.

Small detail: on the left the original 10 µF capacitors, lying down, and on the right the new ones I will be using from now on, which are much smaller and leave the battery connection pads exposed.

The good news is that these units all worked out of the box. Great, eight of ‘em will go straight to their room :)

I’m not having quite as much luck so far with the assembly of JeeLink and JeeNode USB boards, both using SMT parts. There, I often have to debug 2 or 3 out of 10 boards before they work. Occasionally, even that doesn’t solve it so once in while a board gets set aside, awaiting further debugging some other time.

It’s called “production yield”, I think, and I’m not quite there yet… oh, well.

Arduino?

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

What is it? Hype? Hobby? Hacker stuff? Here is the best overall introduction I’ve seen so far – by Dave Jones. It’s 19 minutes – plenty of time to get used to his accent :)

(view directly on YouTube)

I think he really touches on all the important aspects and inevitable trade-offs.

Me, I use the Arduino bootloader for JeeNodes and JeeLinks all the time, and the Arduino IDE to compile and upload stuff to them, as well as the serial console in many cases. I do use my own editor environment – which is easy to do once you disable Arduino’s built-in one (this is not well documented, Google for “Arduino external editor”). So for me the Arduino is really the bootloader, plus the IDE just as compile/upload system.

As Dave points out, the Arduino is a wrapper around the avr-gcc compiler + avrdude in combination with a convenient USB-based upload/console/power hookup. The rest is libraries, conventions, a Java based IDE (based on Wiring), and optionally a Java-based PC-side front end called Processing.

On the embedded software side, it’s really standard full-scale C and C++.

Which is great, IMO. I can keep going with the Arduino-compatible JeeNodes and JeeLinks, and their built-in wireless, port conventions, 3.3V operation, and all the add-on plugs – knowing that much of this will work fine with as well as without all the stuff going on in the Arduino ecosystem right now.

Yeay, it’s drawing!

In Hardware on Nov 22, 2009 at 00:01

Baby steps in CNC land, but still a milestone for me:

DSC_0774.jpg

With a pencil, the worst that can happen is a broken tip. I’m not quite ready to put a Dremel on there, turning at 10’s of thousands of RPM, and chewing its way through anything that happens to be near it. Need to get the limit switches and the relay board going first, so it can be turned off under computer control. Besides, it’ll be noisy and get very dusty.

The red-black wire hanging down the “gantry” (yeah, new words every day) is for the limit switches, which have been glued in place but not yet hooked up. The switches have been connected in series, two per axis and using the Normally Closed pins so that the circuit gets broken when a limit switch trips. That way it will also act as stop signal when a wire gets pulled loose.

I’m still exploring, but I think I’ll call the longest axis (towards the camera) the X axis, and the sideways one the Y axis. Let’s just stick with Z for up and down ;)

The drawing is the standard demo built into EMC v2, and I had to move the paper during while drawing because it would have run off the edge otherwise:

DSC_0772.jpg

Some oddities in there because the pencil is not rigidly attached to the tool holder, but basically it’s doing all the right things. And making funny sounds as the steppers go through curves such as for the “C” and the “S”. Can it draw an accurate rectangle? I hope to find out soon.

So now zee Jee Machine is writing on paper! Onwards!

OOK unit

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

Here’s an ELV 868 MHz OOK receiver, connected to the new JeeNode USB:

DSC_0771.jpg

Note that this plug can be used for any of the four ports, simply by plugging this thing in one of the four possible orientations. In this case, it’s hooked up to port 1.

The receiver is mounted on a JeePlug for stability:

DSC_0768.jpg

There really are only three wires: GND, +3V, and the received bit stream, which is tied to the AIO pin:

DSC_0769.jpg

You can clearly see the built-in pcb antenna on these last two pictures.

The code for this is similar to the one used in an earlier post and basically runs a couple of bit decoders in parallel to recognize FS20, (K)S300, and EM10 commands. It’s available here. Sample output:

Screen shot 2009-11-19 at 15.02.31.png

Or have a look at the OOK relay, with which this plug will also work.

I really need to clean up and merge the different OOK decoding sketches – they all have slightly different capabilities…

One thing which would be very nice to do with this unit, is a general sketch which reports incoming OOK packets but which also uses the OOK sending capabilities of the RF12 driver to send out such packets, to control FS20 devices for example. That mould make this a general-purpose bi-directional 868 MHz OOK unit, connected via USB and controllable via simple serial-port commands.

I’ll punt for now. Don’ have time to go into this. Or perhaps I should say… exercise left for the reader :)

And maybe one day we’ll get OOK input going without extra hardware ?

PS. Good news: everything is now in for the JeeNode USB, so I’ve started shipping them.

CNC progress

In Hardware on Nov 20, 2009 at 00:01

The CNC router is coming together nicely. The controller board works so far, and so does the EMC software running on a Dell laptop:

DSC_0763.jpg

Here’s the complete setup, next to the V90 (the electronics will go inside once finished):

DSC_0762.jpg

And here’s the EMC 2.3.4 software, running under Linux (Ubuntu 8.04):

Screen shot 2009-11-15 at 16.10.16.png

It just finished “doing” the demo, i.e. making the motors turn in lots of mysterious ways.

Some tech specs: the laptop has a worst-case real-time jitter of around 17600 nSec, which means the computer can send out up to 30,000 steps per second. I’m using quarter stepping, so that translates to 800 steps per rev, 4000 steps per inch, i.e. max about 7.5″ per second on the X and Y axes (which the motors can’t handle anyway – I may switch to 1/8th micro-stepping later). The system uses imperial units for the screws, so that’s what I’m sticking with, but I’ll probably do most designing in metric units. Resolution of the machine is about 0.006 mm for X & Y, and even higher for the Z axis. Don’t know about accuracy, repeatablity, and backlash yet – that’s where lots of tweaking will probably be required.

Next step is to mount the motors on the V90, and then go through all sorts of adjustments to make this thing move properly in all three axes. Oh, and hooking up the emergency button and the six limit switches.

And that’s just the CAM side of it all… CAD will be a completely different story!

CNC electronics

In Hardware on Nov 18, 2009 at 00:01

First step to CNC was the mechanical assembly of the V90. Little to report here – it took an hour or two. Adjustment and tweaking will probably take a bit longer, once things start to move.

The next step was a bit more work – here’s the power supply + electronics stuff, mounted on some scrap wood. It was made flat enough to mount inside the V90, underneath the work area and X-axis (Y-axis?) slide:

DSC_0760.jpg

At the top what this is all about: connections for three stepper motors and a strip to hook up limit switches and the emergency stop button.

The power brick in the bottom right supplies 5V to the parallel-port side of the RF-isolated breakout board and the opto-isolated relay board. That means the 24V @ 6.5A supply can’t ever reach the computer. It also avoids 1A current through the linear voltage regulator to supply the relays (i.e. 20W of heat, just to go from 24V to 5V).

End stop switches, heat sink, and relay board have not yet been added / connected. Plus some power cable fasteners at the bottom, so they can’t be yanked loose.

All the high voltage is in one area at the bottom, to be covered by a shield. But even without the shield: all the exposed metal is recessed so it can’t be touched without sticking some sharp object in there – 220V scares me!

Meet the Output Plug

In Hardware on Nov 17, 2009 at 00:01

Here is another I2C I/O plug:

DSC_0756.jpg

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:

DSC_0755.jpg

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.

JeeFab?

In Hardware on Nov 16, 2009 at 00:01

Heh, heh. Some crazy stuff is about to happen in the Jee Labs…

I’ve received a CNC router kit, i.e. the subtractive way to create 2D and 3D shapes. This one:

Picture 2.png

It’s one of the simplest CNC units available, from what I can tell. The work area is about 30 x 45 cm (A3).

Got various ideas to try out – from one-off pcb’s to front-panels. And more.

CNC routers can be very noisy and dusty, so this thing will be placed in a corner of the garage. A trusty ol’ Dell Inspiron 5000 laptop will sit next to it, running EMC and driving it all via the parallel port.

I’ve also ordered an extruder-type machine, i.e. the additive way to create 3D shapes. This one:

cupcake

I don’t expect any of this to be a time saver – on the contrary, getting all the details right for CNC is going to take a huge amount of time and effort. But if it helps me try out ideas and explore new avenues, then so be it.

Yeah. Totally. Crazy. I know…

Memory Plug redux

In Hardware on Nov 15, 2009 at 00:01

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

DSC_0505.jpg

And here’s the latest one:

DSC_0699.jpg

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:

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.

Energy tracking with Cost Control

In Hardware on Nov 14, 2009 at 00:01

The ELV Cost Control is a set with two power measurement units and a display:

87747_F01_GeCostControl.jpg

Every 5 seconds the base units transmit their readings over 868 MHz, each with a unique 4-digit ID. The display shows actual and aggregated results for up to 5 units. You have to press a button to get an update, i.e. the receiver is only activated on request – for about 6 seconds.

Setup is trivial. Tracking current power consumption, peak power consumption, projected monthly & yearly cost, and hours on vs. total is extremely straightforward.

This is a very convenient setup because you can put the sensor in the outlet, way down deep behind everything if needed, and then take individual appliances out to see what effect each one has on the total consumption.

I found out that my 5-port Ethernet hub draws 3W (of which 2W in the adapter), and an old monitor I’m only using occasionally uses 4W (both asleep and “off”).

Our TV + amplifier + speakers + satellite receiver is drawing 6W when idle. Most of this is the Mac Mini (used as TV), due to an energy saver which cuts power to all other appliances when the Mac sleeps.

At €12.95 per outlet, this is the cheapest good-working solution I’ve found so far for tracking power use at individual outlets. I’m thinking of getting several more of these for the refrigerator, washing machine, and other intermittent power consumers.

Does anyone know whether the Cost Control wireless protocol has been documented?

Arduino plug stack

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

You could combine all these …

DSC_0750.jpg

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

DSC_0751.jpg

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:

DSC_0735.jpg

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:

DSC_0748.jpg

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

DSC_0749.jpg

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:

DSC_0752_2.jpg

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

JeeLink flash works

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

Ok, the last hurdle has been passed. The new 1 Mbyte flash memory on the new JeeLink v2 works – I’ve been able to erase the chip, write data to it, and read it back.

Here is the main test code I used:

Screen shot 2009-11-05 at 00.26.33.png

And here’s the output:

Screen shot 2009-11-05 at 00.26.00.png

Some timing results can be gleaned from that output:

  • Erasing the entire chip takes 5.7 seconds (!)
  • Reading takes about 1.1 mSec per 256-byte page
  • Writing takes about 1.4 mSec per 256-byte page
  • Reading 8 bytes takes about 90 µSec

Good enough, but definitely not instant in the ATmega’s time scale.

This code needs to block-out interrupts while accessing flash memory because the radio can generate lots of interrupts which need to be serviced quickly over that same SPI bus. Some care is needed to give enough attention to the radio during long memory transfers – it looks doable.

Anyway, I’ve started assembling a bunch of these JLv2’s. Here’s the very first hand-soldered batch:

DSC_0741.jpg

At last!

Meet the JeeNode USB

In Hardware on Nov 7, 2009 at 00:01

Here is a brand new JeeNode USB v2, this is the successor of the JeeLink v1:

DSC_0737.jpg

This is the first (hand-soldered) unit, I had to stack a resonator on its side to fit it in – properly-sized resonators should be coming in soon. The final version will have the usual bright yellow antenna wire – I merely used black to remind me that this is a prototype. You don’t want to know how many different versions of various units are scattered all over the Jee Labs…

The JeeNode USB is a JeeNode with built-in FTDI interface and mini-USB jack. It uses surface mounted parts and has exactly the same size as the basic JeeNode. All the headers and connectors are in the same place, so this thing is plug-compatible – apart from the 6-pin FTDI connector vs. the mini-USB jack, of course.

The JeeNode vs. JeeLink naming confusion is a bit unfortunate, but I’m hoping to resolve it now – before the confusion gets even worse. There is no “v1″ of the JeeNode USB, btw.

The JeeNode is the unit with ports and headers. There is the basic JeeNode v4 with through-hole parts, and now there is also a JeeNode USB v2, with SMT parts.

The JeeLink v2 is the unit in the shape of a USB stick, using SMT parts. It has no headers, but it has extra flash memory on board. And it comes in a Cool Clear Case.

Both JeeNodes as well as the JeeLink have an RFM12B wireless radio module.

Ok, everything is starting to come together now.

Activity LED

In Hardware on Nov 6, 2009 at 00:01

The new JeeLink v2 has an “activity LED” added, which is not present on the JeeNode.

This is simply a LED from PB1 (Arduino pin 9) to “+” via a current limiting resistor. It’s very easy to add the same activity light to the JeeNode, using a 4-pin connector:

DSC_0623.jpg

Now place this contraption on the SPI/ISP connector as follows:

DSC_0621.jpg

Voilà – it even has PWM!

The latest RF12demo code now has a “l” command to test the led – “1l” turns it on, “0l” turns it off again.

Woohoo – this is post #300 !

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:

DSC_0731.jpg

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.

More efficient computing

In Hardware on Nov 4, 2009 at 00:01

A few days ago, I replaced my (3y old) MacBook Pro + (8y old) Cinema Display with a brand new 27″ iMac. Here’s the result:

Screen shot 2009-10-31 at 17.59.38.png

That’s the total energy consumption of my work desk – i.e. computer, lights, and a some USB-powered stuff. The scale is in Watt-per-5-minutes, so if you multiply all figures by 12 you’ll get the normal Watt ratings.

There are many different operating modes here – night-time near off, full sleep, display sleep, display on, a few computing peaks, and in the evening also the lights on.

On Oct 30 both machines were active, while all the data from the old setup was being migrated to the new one.

The interesting parts are the low periods at night which more or less dropped to zero, even though the iMac is simply sleeping (with BlueTooth and USB still on), not turned off.

It’s also nice to see that even with this new dual-core 3.3 GHz monster, energy consumption is noticeably lower most of the time – not just in idle mode!

These readings were obtained with the ES-1 sensor described a while back + a central JeeNode + JeeMon.

Meet the new JeeLink v2

In Hardware, News on Nov 3, 2009 at 00:01

Just in!

DSC_0728.jpg

Look at that fancy gold lettering – neat, huh?

And the first hand-soldered unit is working perfectly:

DSC_0729.jpg

Here’s the new software-controlled LED:

DSC_0730.jpg

This is in addition to the red TX and green RX LEDs, indicating USB activity.

Only thing not tested yet is the new on-board 1 Mbyte flash memory. Once that’s done, I’ll start assembling a couple of these. Will be a lot easier once the solder paste stencils come in.

JeeNode v4 on a breadboard

In Hardware on Nov 2, 2009 at 00:01

Now that the JeeNode has labels on the back, there’s a convenient way to use it with mini-breadboards:

DSC_0671.jpg

This uses male-male headers with extra-long pins, so that the JeeNode can still use female headers:

DSC_0670.jpg

To get more space to work with, use two mini-breadboards:

DSC_0672.jpg

Plenty of room for lots of experiments, even for a few plugs.

LCD Plug

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

Here’s the new LCD Plug:

DSC_0722.jpg

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:

DSC_0721.jpg

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 0×24. 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:

DSC_0711.jpg

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

DSC_0712.jpg

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

DSC_0716.jpg

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:

DSC_0717.jpg

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.

More room sensors

In Hardware on Oct 30, 2009 at 00:01

I’m getting ready to install a new round of room sensors around the house. Am using the remaining prototype boards, now that the final version is ready:

DSC_0674.jpg

Some rooms here don’t really need relatively expensive SHT11 sensors and some places don’t need a motion sensor, hence the variation across these 6 new units.

These boards require some patches, as described earlier, for use with the EPIR sensor, i.e. the three leftmost boards shown above.

The patches are easy to apply on the back of these little boards:

DSC_0675.jpg

That’s a 4.7 kΩ pull-up for the DS18B20 1-wire sensor, and a 100 kΩ pull-up for the EPIR.

Installing these will bring the total to 10 active nodes, but that’s still not the end of the story. Once everything is done, I’ll have 16 JeeNodes with room boards and sensors watching over this house. It’ll be interesting to see how the temperature changes across the different rooms, and what humidity levels are reached in the basement and beneath the house once winter sets in…

New UART plug

In Hardware on Oct 28, 2009 at 00:01

The revised UART plug now works as expected:

DSC_0692.jpg

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.

Four generations

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

After one year, I thought it’d be nice to compare all the JeeNode versions which have come out – up to and including the latest v4:

DSC_0581.jpg

Here is the back side of each of them:

DSC_0582.jpg

The back side in particular illustrates the evolution which has taken place this year.

In version 1, there were no labels – mainly because I hadn’t figured out how to do those and I was eager to just see the darn thing work

Version 2 added some minimal labeling (in copper, to save on production charges!) and a ground plane. Port pairs 1+4 and 2+3 were moved 0.1″ further apart. The mounting holes were dropped.

Version 3 was really the first production-ready one. It added lots of text on the component side, plus a bit of eye candy by going for blue solder masks. I switched to yellow wire for the antenna, to help remind me that this is the version with the final port and pin layout – the one which matches all the new JeePlugs. Version 3 did get the silkscreen for the regulator wrong, but it also made it to the Make Magazine weblog – cool! :)

Version 4 now takes this evolution to its logical conclusion: a clear visual “identity” in the form of blue-and-gold color choices and lots of labels on both sides of the board. No more guessing! The PWR/I2C connector moves a bit and is augmented with two more pins. This JeeNode is the narrowest of all, it now has precisely the same width as all the plugs (21.1mm / 0.83″). This is the grown-up version at last, focusing on actual usage convenience along with a proud & pleasing appearance.

It’s time to move on. The JeeNode is done.

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:

DSC_0676.jpg

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.

Monitoring failure?

In Hardware, Software on Oct 23, 2009 at 00:01

Yesterday, the Jee Labs energy monitoring system stopped working:

Picture 2.png

A few hours went by before I found out, because I’m not constantly checking these graphs nowadays.

Couldn’t figure out why, so I reset the sending node next to the electricty/gas meters, and shrugged it off as a fluke because it all started working again.

A few hours later, after dinner, we find out that there’s water dripping down right next to that JeeNode, but more importantly the whole meter closet is soaking wet in some places. Whoops… not good!

Turns out that there was a leak in the kitchen drain right above that meter closet. Fortunately, the problem was easy to identify. And didn’t lead to fireworks.

That was around 8 PM. Only this time the JeeNode is also soaking wet – free-hanging constructions are not such a good idea after all, I guess. Unplug. Wipe off the water. Let it dry for a few hours. Plug it back in.

OK, the energy monitoring setup is working again. Tomorrow, I’ll fix the drain pipe – properly.

The drawback of tinkering is that you always blame your own stuff when there is a failure. But in this case, it was trying to tell me about a problem coming from elsewhere…

Solar power

In Hardware on Oct 20, 2009 at 00:01

The Lighty project described earlier on this weblog was an attempt to create a node for outdoor use, which periodically reports some light measurement details and powers itself indefinitely via solar energy.

At the time, I couldn’t figure out how to get the power consumption down far enough, nor how to prevent the LiPo battery from overcharging.

I think I found a solution for both, triggered by a recent article in Elektor:

Picture 2.png

The main idea here, is to simply short out the solar panel when the LiPo voltage reaches 4.15 V, using a MOSFET. The battery voltage has to be measured using a voltage-divider which doesn’t constantly drain the battery – this can be solved with a low-power op-amp in voltage follower mode, using a 2:1 voltage divider. The LT1494 op-amp will work with varying supply voltages and consumes only about 1 µA.

I think I’ve got the resistors attached wrong though – need to brush up on my op-amp knowledge…

When using the ATMega’s A4 (PC4) and A5 (PC5) pins, everything can be hooked up using just the PWR/I2C connector. If this works as intended, it’ll make a nice and simple solar power setup for any JeeNode.

Anyway, I’ve ordered a MOSFET and an op-amp to see whether this idea can be made to work.

Update – looks like the op-amp can be avoided, the ATmega328p datasheet says the ADC input impedance is 100 MΩ, so two 1 MΩ resistors should work fine as voltage divider, with less than 2 µA power consumption.

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:

FlySketchExport.png

Even each board has such an ID:

FlySketchExport2.png

(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 http://JeeLabs.org/ + 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 :)

Of JeeNodes and JeeLinks

In Hardware on Oct 18, 2009 at 00:01

There’s a new JeeLink coming…

DSC_0543.jpg

No external connections, just a little antenna wire sticking out. Uses a 10 ppm crystal to accurately keep track of time and has 1 Mbyte of flash memory on-board so it can collect data in unattended mode. This new JeeLink’s only purpose is to attach to a computer for communicating with JeeNodes and several commercially available RF controlled devices (KAKU, FS20, etc). It has three LEDs: RX, TX, and ACTIVITY.

The above will be called the JeeLink (v2) – I’ve just sent off my second prototype to the pcb shop. Quite a few tweaks and tricks were needed to fit everything into such a tight enclosure:

Picture 1.png

The current JeeLink (v1) is also going to change. First of all, it’s going to be called the JeeNode USB (v2) in the next revision since it really is a JeeNode, but with the FTDI-USB adapter added-on. Other changes will be mostly to make the standard JeeNode and this new JeeNode USB even more compatible with each other.

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:

DSC_0661.jpg

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:

DSC_0662.jpg

Another view, with the attached K-type thermocouple:

DSC_0663.jpg

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…

A JeeSupply?

In Hardware on Oct 15, 2009 at 00:01

For some time now, I’ve been thinking about creating better tools for my own use here at Jee Labs. One of them would be a simple power supply with adjustable voltage and current limits. Nothing fancy, even 1 Amp is really overkill. But with a finely adjustable current limit and a continuous readout of the actual voltage and the current draw would be really nice.

Yes, there are lots of laboratory supplies. Cheap ones even, with such capabilities. I’ve got one. But they don’t measure or limit well in the milliamps range I’m interested in. And they are all so… b u l k y !

So the idea of a “JeeSupply” was born: a little unit which runs off any simple power brick, and which uses a JeeNode to perform all the control tasks. Why a JeeNode? Well, because then I could display the readout on the PC/Mac screen, and do it wirelessly without cluttering up my desk. And set it wirelessly as well, of course. It wouldn’t take much to turn it into a stress testing rig, gradually raising the voltage and plotting the current draw over time, or lowering to see when the circuit fails. Auto power-off. Watt-metering. Motor/servo test rig. Lots of extensions come to mind once it’s under computer control.

As I said, I don’t really need much power. Even just going up to 12 V @ 500 mA would be quite useful. Especially if the whole unit is so small that you can place it on the table next to the circuit it’s feeding.

Here’s a first design for it:

Picture 1.png

Click here for a larger PDF.

It has two switching power supplies. One produces 5V and powers the JeeNode and some of the other chips, the other is based on a L6902D and generates the requested voltage. This particular switching regulator has built-in current limiting. Normally, this would be done via a fixed current sense resistor, but in this case there’s a “high-side current sensor” chip involved which converts the current to a 0-based voltage level – this level is read out by the JeeNode, and also attenuated by a digital potentiometer to adjust the actual current limit. A second digital potentiometer is used to adjust the output voltage. This is all done via an I2C bus.

The digital pots have 257 steps, which is a bit limited at the end of the V and I ranges. For this reason, I added a second pair of pots in parallel to be able to tweak the values a bit more. My hunch is that the non-linearity of this setup may work out nicely, but I haven’t thought it through yet – these extra digital pots are entirely optional anyway.

The JP1 .. JP4 connectors on the left are connected to the port headers on a JeeNode. All pins have been assigned to some function, just to see how far one could take this.

There are two more connectors: one brings out the I2C bus to drive an LCD display, the other allows connecting some LEDs, buttons, and a rotary encoder to adjust settings directly. Both are optional – with remote control, this JeeSupply would need no other connections than a power jack and the two output power lines. It could all be built very compactly – not much larger than the JeeNode itself:

Picture 5.png

The above circuit can deliver up to 25 V or so, and can probably handle 1 amp. But I really don’t care – any 8 .. 30 V power brick will drive it. I just want it to work well in the 2 .. 5 V range with a few hundred milliamps of current at most. And because both supplies are efficient switching types, there will be little heat involved.

I haven’t built this circuit, I haven’t even tried it on a breadboard. But I sure could use a pair of these in my daily lab work. Something like this would definitely help detect and debug short circuits and other common electrical wiring mistakes in all those little projects sprawling around here. It might even save a chip from frying, occasionally.

What do you think?

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:

DSC_0656.jpg

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:

DSC_0657.jpg

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:

DSC_0660.jpg

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.

JeeLink v1 bug!

In Hardware on Oct 13, 2009 at 00:01

The JeeLink v1 board had two problems I knew about and which I’ve been able to work around. A few days ago a third more serious problem was brought to my attention – the C4 10 µF capacitor which was supposed to filter out ripple for the on-board MCP1703 regulator turns out not to be connected to ground. Whoops!

The GND pin on the PWR/I2C connector is also not properly connected due to this same problem, but this is probably of slightly less importance.

Here are the two affected connections on the JeeLink v1:

jl1 build.FlySketchExport.png

The solution is to connect either of these to another ground pin on the board. But since this problem was only just found, all JeeLinks sent out before October 9th will have this problem still in them.

I’ve documented all known problems on the JL1 Build page, along with suggestions on how to fix them – so if you have a JeeLink and it’s not working as expected, please check out that page.

After this bad news, and at the risk of having everybody who planned to get a JeeLink hold off and wait – there is also some good news to report: a successor for the current JeeLink v1 is currently “in the works”. So all the teething troubles of the JeeLink v1 will one day be over – unless I mess up again, of course :)

An OOK relay

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

After having hooked up OOK radios in a few ways, I’ve decided to create an “OOK relay” – a little unit which listens for OOK-encoded data on the 433 and 868 MHz bands, and then re-transmits the decoded data as “normal” packets via the RF12 driver. OOK stands for “On-Off Keying” as opposed to the more advanced FSK – “Frequency Shift Keying” used by the RFM12B’s – i.e. AM vs. FM.

The benefit of an OOK relay is that OOK reception then automatically gets integrated into all the data collection from other JeeNodes that’s already going on anyway. Since an RFM12B can send both 433 and 868 MHz OOK signals, the end result is a pretty complete solution for all sorts of things going on over the air.

Here’s the hardware test setup:

DSC_0650.jpg

The 433 MHz receiver is seen from the side, standing almost straight up with the white antenna wire. It’s connected to DIO of port 1. The 868 MHz receiver is lying flat, with the red antenna wire, and is connected to AIO of port 1. Both receivers are powered from the 3.3V supply.

The reason for this particular setup is that I can use two different pin change interrupts for both: PCINT1_vec for 868 MHz and PCINT2_vec for 433 MHz. No need to decide inside the interrupt routine which is which – this saves some interrupt routine overhead.

The code was created from the two existing decoders for these receivers, and will be made available once everything is finished. Right now, the decoders work happily alongside each other:

Picture 3.png

Sample output:

Picture 2.png

I cheated a bit though by selectively powering the receivers, because there is a hardware problem… it looks like these receivers are interfering with each other. They only work when the other one is off. It’s not that surprising, given that one frequency is almost an exact harmonic of the other. Maybe placing the two receivers physically further apart, or adding better RF power supply decoupling will fix it. They should be able to work together, even receive signals on the two frequency bands at the same time.

More work left to do…

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:

DSC_0565.jpg

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:

DSC_0566.jpg

Now it’s ready to go, with 3 rechargable NiMH’s:

DSC_0568.jpg

And here’s the final setup:

DSC_0571.jpg

Just to show how you can go nuts with plugs:

DSC_0570.jpg

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:

DSC_0628.jpg

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:

DSC_0646.jpg

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:

DSC_0626.jpg

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 0×21 instead of 0×20. Each Expander Plug can be configured for I2C addresses 0×20..0×23, 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:

DSC_0627.jpg

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.

Light to RF converter

In Hardware on Oct 8, 2009 at 00:01

While testing out some new code to handle extended FS20 packets in the forum, I remembered that I had an FS20 LS sensor still lying around:

DSC_0573.jpg

Puzzled? Maybe the back will show a bit better what this thing is about:

DSC_0574.jpg

Still puzzled? Me too – until I assembled the kit and tried it out. There is a light sensor on the back with a bit of sticky tape, which you’re supposed to place over a LED or some other light signal.

What it does is whenever light on or off is detected, it sends out an RF signal at 868 MHz using the FS20 protocol. So any FS20 receiver can pick it up:

Picture 3.png

The four buttons are a way to adjust all sorts of settings. I haven’t tried those, the factory defaults seem to work just fine for me. As it is this is a nice install-and-forget unit. Hopefully the battery will last a year or more.

Could this report the fridge light? Hmm, not sure – not all packets are coming out. Maybe it’ll be ok if the receiver is close enough.

Cool – another wireless gadget to help automate stuff around the house!

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:

DSC_0549.jpg

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:

DSC_0564.jpg

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:

DSC_0563.jpg

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

DSC_0561.jpg

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

DSC_0562.jpg

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

DSC_0558.jpg

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:

DSC_0557.jpg

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:

DSC_0547.jpg

I got the wrong crystal size, so it’s mounted a bit awkwardly:

DSC_0548.jpg

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:

DSC_0559.jpg

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.

JeeLink assembly line

In Hardware on Oct 3, 2009 at 00:01

Here’s a peek into the Jee Labs kitchen:

DSC_0554.jpg

This is my – tada! – JeeLink assembly line. A factory in-a-box, so to speak.

I keep this box stored away for when I need to make a new batch of JeeLink v1’s. Usually I assemble 1, 2, or 3 panels at a time – depending on how many parts I have available at that moment. Each panel has 4 JeeLinks.

From top left to bottom right, sort of:

  • Small containers with the parts required for the board. Many of the parts are so tiny that you could actually put thousands of them in these little boxes. Some parts, such as the USB plug and the ATmega chips are a bit larger.
  • The syringe with lead-free solder paste, as well as a few plastic syringe tips. Got this from Farnell – nowadays I use the stencil so these are no longer used really. The solder paste is in a jar, stored in our fridge in the garage.
  • Cotton dabs – used with a bit of alcohol to clean off the boards after use. Not needed for the solder paste, but if I have to wick off some excess solder, the wick leaves a very ugly residue. Alcohol stored elsewhere, I don’t want the bottle to leak in here!
  • The stencil and the little adapter I made to hold a panel of 4 JeeLinks.
  • Toothbrush, goes along with the cotton dabs to clean up.
  • On the right is the – ahem – “squeegee” I use to apply solder paste. At first I thought it’d be completely unsuited for this task, but it actually works surprisingly well.

The most important items are actually not in this box, because I use them for everything on a daily basis – an illuminated magnifying glass, very thin tweezers, a “third hand”, and a 15W (yes, 15!) soldering iron:

DSC_0555.jpg

Take away any of these and there would be no Jee Labs.

So if you ever get pre-assembled units from the shop with smd parts soldered onto them, you can now picture yours truly with something like this sitting next to me…

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:

DSC_0546.jpg

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 0×67. For the final version I’ll fix the low-address bit and use “A0″ versions, i.e. 0×60 and 0×61.

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?

DSC_0550.jpg

Here’s how it’s supposed to go on the back of any LCD with a standard 16-pin header:

DSC_0551.jpg

The board can be mounted very close to the LCD because it uses SMD parts:

DSC_0552.jpg

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:

DSC_0545.jpg

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:

DSC_0544.jpg

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 0×48 .. 0×4B, 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 0×49 i.s.o. 0×48. 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 :)

Another display option

In Hardware on Sep 29, 2009 at 00:01

Here’s another display option, using a 16×32 LED panel by Futurlec:

DSC_0535.jpg

The pattern was hand-coded, to help me figure out which pin is which. The board has 3 16-bit shift registers and corresponding LED drivers. This display can be much brighter than in this picture, I’m using PWM to dim it way down and reduce average current consumption (I think it was 40 mA i.s.o. over 250 mA).

The board is powered from 5V and requires 6 output pins – I’m just using the DIO + AIO pins from three different ports for this test.

Note the 470 µF cap hooked up to the power lines of port 4 to help avoid glitches – switching 32 LEDs on and off at 1 KHz can generate a lot of noise!

Sample code for this display can be found here.

It’d be fun to have this display in a nice enclosure and drive it from packets received over wireless from another JeeNode!

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!

Parts!

In Hardware on Sep 25, 2009 at 00:01

The flip side of experimenting with electronic stuff, is that you end up with a lot of little things!

DSC_0530.jpg

To avoid losing my sanity, I’m now trying to get organized. The above has about 50 bags with one or a few tiny parts in them, mostly stuff from DigiKey and Farnell. SMD, through-hole parts, sensors, little batteries, buzzers, you name it…

And that’s just a fraction of the mess I’m creating around here :)

Anyway, I’ve been spending my time to try and get to grips with this. Bags of similar sizes in one box. A sheet printed out with unique label numbers, and then the work starts: put label on bag, place in box, and add a line to a little database with Location, Label, Description, and Notes. Then it won’t matter where the stuff is, since it’ll be tagged with a note in the database. I use DEVONthink for this, its storage and search capabilities are just right for me.

The trick of course, is to use tags. I’m going to start using the different vendor options to add my own tags during the on-line ordering process. Doesn’t matter one bit what the tag is, as long as it’s unique. I’m using tags like F0001/F0002/… for Farnell items, D0001/D0002/… for DigiKey, etc. By printing a batch of them on a sheet, it’s trivial to keep all tags unique. I don’t have small labels, so I print on larger ones and then slice up the sheet to create lil’ ones:

DSC_0532.jpg

The texts are created in Tcl/Tk by placing a bunch of them on a canvas the size of an A4 sheet along with thin cutting lines, and then saving the result as postscript. So now I can run “numprint X2500″ to get a printable sheet of labels X2500 .. X2639 in exactly the right spot. Very configurable, very automated.

So trivial. So overdue…

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:

DSC_0527.jpg

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!

Bi-color LED

In Hardware on Sep 23, 2009 at 00:01

In trying to save precious I/O lines, I wanted to use one line for three states:

Picture 2.png

Red (logic 1), green (logic 0), and off (tri-state).

The way this SMD bi-color LED is connected is:

Picture 3.png

The idea being that together, the forward voltages of these LEDs is more than 3.3V, so they can’t both light up. Both are rated at 2.0 V typical (2.4 V max) forward voltage.

And in fact it almost works as expected. The only problem is that when the I/O pin is left floating, the red LED still lights up dimly – it’s hard to see in the photo, but it really does.

These LEDs are rated at 80 mA peak and 30 mA continuous, btw – so I figured I wouldn’t need a resistor, at least for the test. For a more permanent setup, a 100 Ω resistor between this circuit and the I/O pin would probably be better.

I wonder if there is a simple way to turn the red LED completely off – a 1N4148 diode between 3.3V and the red LED perhaps? That might also dim it a bit, since it’s brighter than the green one.

Geek news: this is post # 2^8 :)

Update – the extra diode helps. Here’s a better test, showing red, orange, green and off:

Picture 2.png

The “orange” isn’t truly convincing with the clear LED I’m using, but its reflection on a piece of white paper looks ok.

Four states on a single I/O pin!

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:

DSC_0515.jpg

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:

DSC_0516.jpg

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:

DSC_0517.jpg

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

DSC_0510.jpg

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:

DSC_0507.jpg

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.

Whoops!

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:

DSC_0505.jpg

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 0×50 to address chip #0 – chip 1 #is at 0×52, chip #2 at 0×54, and chip #3 at 0×56.

This demo is available as the eemem example in the Ports library.

Here’s the plug hooked up to a JeeNode:

DSC_0506.jpg

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:

DSC_0503.jpg

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:

DSC_0504.jpg

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!

DSC_0508.jpg

(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.

Connecting a battery

In Hardware on Sep 17, 2009 at 00:01

There are a number of ways to run a JeeNode off batteries. The lower bound is around 3.5 .. 3.6 V, depending on current draw. With 3.5V, the voltage regulator only has about 0.2V to work with, which is probably ok as long as the total current consumption stays under 50 mA or so. The maximum allowed voltage is around 13V, but drawing too much current at that level will lead to excessive heating and cause the voltage regulator to shut down.

So with alkaline and NiMH, you need only 3 cells.

For temporary connections, use the FTDI connector:

DSC_0496.jpg

For more permanent connections to the JeeNode v3, you can hook up a 3-or-more-cell battery pack as follows:

DSC_0497.jpg

The 10 µF capacitor next to the battery connectors can then be folded flat over these wires again, if needed.

Another option would be a 9V battery:

DSC_0498.jpg

Keep in mind that 60% of those 9V will be turned into useless heat in the voltage regulator…

And then, there is the option of using a rechargeable Lithium cell (LiPo). They supply 3.7 .. 4.1 V – a perfect match, if you take the proper safety precautions with charging them.

Update – note that the FTDI connector and battery connectors are both attached to the same “PWR” line, so please remove the battery (or add a disconnect switch) when connecting the unit to FTDI.

JeeNode pinout

In Hardware on Sep 16, 2009 at 00:01

I don’t think I published this pinout overview before:

jeenode pinout.png

Also available as PDF – use your printer’s print-4–pages-per-sheet setting to print a smaller version as reference.

Port extension

In Hardware on Sep 15, 2009 at 00:01

Found these 6-pin female-to-female cables at Seeed Studio:

DSC_0495.jpg

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…

Daughterboard

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.

Build progress

In Hardware on Sep 10, 2009 at 00:01

Aha, now we’re getting somewhere:

DSC_0493.jpg

Almost perfect reflow this time – only had to fix 2 solder bridges on the rightmost FTDI chip, then add the USB connector and wire antenna. All four worked right away!

The trick is to press harder on the stencil at the end, so that a truly thin layer of paste remains when lifting it off. It was a bit too thin in some places in fact, so I had to dab a bit of extra paste on a few pads.

This stencil thing is indeed a huge time-saver over applying paste with a syringe to each individual dot. It’s not just the amount of work, it’s also the type of work: keeping a steady hand while doing all those 100′ish dots per board was extremely tedious.

The total time spent on assembling these four boards was 1:30 hours – not stellar, but ok.

Four more boards done!

Smaller still?

In AVR, Hardware on Sep 9, 2009 at 00:01

Now that the JeeLink is a reality, and SMD has become an option, I’m already wondering how far to take this…

Because, well, there’s this neat USB stick case available:

DSC_0491.jpg

I suspect that the same FTDI + ATmega + RFM12B as on the JeeLink can be fitted in there, but at the cost of omitting all expansion. No ports, no headers, no reset, nothing – but nevertheless an Arduino / JeeNode / JeeLink compatible unit.

There may even be room for a few Mb of flash memory. So this could be used as central interface to a PC/Mac, and it could collect data while the computer is off – as long as the USB port is on (a powered hub perhaps).

Would it make sense to create a separate unit for this? Just for the wow factor? Let me know, please…

Final JeeLinks

In AVR, Hardware on Sep 8, 2009 at 00:01

After the goof-up of not heating the boards up enough for lead-free solder, I simply re-did the reflow with a 250°C temperature profile. This appears to be near the limit of what my reflow grill can do, btw.

Here’s a fully assembled JeeLink:

DSC_0490.jpg

Note that I soldered all headers in, including two which aren’t supplied standard with the JeeLink:

DSC_0489.jpg

As shipped, the JeeLink comes with the 4 port headers, not yet soldered in.

While it still takes me quite a bit of time to assemble these JeeLinks, all four of the ones I did are now working (ahem, that’s a lie: I shipped two JL’s without proper testing… impatient as I was!).

So this story has a happy ending – the JeeLinks are ok now, it’s time to move on …

SMD pick and place

In Hardware on Sep 7, 2009 at 00:01

Now that the solder stencil is ready for use, I went ahead and tried it – using solder paste and a (not-so-wide) squeegee type tool. Here’s the result:

DSC_0479.jpg

If you look closely, you can see how nicely the paste ends up on the pads:

DSC_0479_2.jpg

The stencil needs to be cleaned for future re-use, though:

DSC_0477.jpg

(sorry for the incandescent light reflection)

Ok, now the tricky part – the “pick and place machine” (me). The result:

DSC_0480.jpg

That’s the illuminated magnifying glass I’m using, by the way.

Looks perfect to me:

DSC_0481.jpg

Baking now, in my JeeNode-based reflow controller:

DSC_0482.jpg

Hm, this stuff is considerably smellier than before. Here’s the result…

DSC_0485.jpg

Wait a minute – if you look closely you can see that a lot of the pads show up as a gray surface, not the shiny metal I was expecting!

WHOOPS – I used a temperature profile for leaded solder, but this is lead-free solder – silly me!

Stay tuned for the rest of this story… tomorrow.

Solder paste

In Hardware on Sep 6, 2009 at 00:01

As I mentioned before, the main problem I have with SMD’s on JeeLinks is applying too much solder paste.

Well, I just got a few test stencils in the mail from Paul Badger of Modern Device, who is experimenting with a laser cutter and a variety of plastic sheets.

So here’s my first DIY solder paste stencil jig for JeeLinks:

DSC_0474.jpg

In good DIY fashion, it’s made of things I “happened” to have lying around, such as a piece of “foam” used by photographers, i.e. a few millimeters of foam (PU?) sandwiched between two thin plastic sheets. It’s easy to cut so size, and a bit of a cushion might actually help level out the pressure when applying paste. I used hot glue to fix a couple of pcb scraps to the board, and a single line of adhesive tape to fix the stencil.

This jig opens up to take a panel with 4 JeeLink boards, like this:

DSC_0475.jpg

It’s all about getting the alignment right, of course:

DSC_0476.jpg

Will it work? I’ll report in the next few days…

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:

panels.png

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

lotsofplugs.png

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

jlpcb-029.png

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

pastedGraphic.png

A first mock-up with real parts, here still using a green JeeNode v2:

DSC_0469.jpg

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!

JeeNodes now with 328

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

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

DSC_0467.jpg

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

Memory Plug design

In Hardware on Aug 30, 2009 at 00:01

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

Picture 4.png

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

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

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

Clock Plug design

In Hardware on Aug 29, 2009 at 00:01

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

Picture 2.png

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

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

Thermo Plug design

In Hardware on Aug 28, 2009 at 00:01

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

Picture 1.png

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

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

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

Expander Plug design

In Hardware on Aug 27, 2009 at 00:01

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

Picture 1.png

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

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

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

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

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

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

Picture 3.png

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

Room Plug design

In Hardware on Aug 26, 2009 at 00:01

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

Meet the 20×21mm “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!

RJ11 daughterboard

In Hardware on Aug 24, 2009 at 00:01

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

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

DSC_0445.jpg

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

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

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

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

JeeLink issues solved

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

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

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

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

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

DSC_0449.jpg

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

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

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

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

Lots of nodes

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

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

DSC_0444.jpg

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

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

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

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

JeeLink status

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

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

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

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

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

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

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

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

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

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

DSC_0443.jpg

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

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

CD drive as X/Y table?

In Hardware on Aug 20, 2009 at 00:01

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

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

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

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

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

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

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

DSC_0437.jpg

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

DSC_0438.jpg

Here’s another one from AOpen:

DSC_0439.jpg

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

DSC_0440.jpg

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

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

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

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

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

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

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

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

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

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

DSC_0441.jpg

DSC_0442.jpg

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

New home sensor setup

In Hardware on Aug 19, 2009 at 00:01

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

DSC_0435.jpg

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

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

DSC_0434.jpg

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

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

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

DSC_0436.jpg

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

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

FS20 developments

In Hardware on Aug 18, 2009 at 00:01

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

85076_F04_GeSteckdosenl.jpg

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

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

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

LED polarity

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

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

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

DSC_0433.jpg

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

frame3.jpg

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

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

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

JeeLink build woes

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

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

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

DSC_0432.jpg

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

Here are a couple of extreme close-ups:

frame1.jpg

frame2.jpg

frame4.jpg

frame5.jpg

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

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

Building the JeeNode v3

In AVR, Hardware on Jul 15, 2009 at 00:01

The v3 boards are finally ready! Here’s a step by step overview on how to assemble a JeeNode v3 kit:

DSC_0427.jpg

You’ll need some basic skill at soldering but don’t worry, as there are only a few parts to solder on. The best way is to start with the lowest-profile part, that way you can place things flat on the table and press down to keep the parts in place. So let’s start with the 10 KΩ resistor:

DSC_0408.jpg

Turn the board around and solder the leads:

DSC_0409.jpg

Then carefully cut them off:

DSC_0410.jpg

Continue in a similar vein with the four 0.1µF ceramic capacitors:

DSC_0413.jpg

Next the IC socket, which is a bit more work. The best thing is to solder two diagonally opposite pins, then check that the socket is pushed in all the way:

DSC_0414.jpg

If not, reheat and fix it. Then solder the remaining 26 pins:

DSC_0415.jpg

The 10 µF electrolytic capacitor is polarized – there is a “+” marking to indicate which way it should be soldered in. I normally bend the leads first and then make it lie flat on the board:

DSC_0416.jpg

Next the voltage regulator IC. This one needs special attention because it has to be mounted differently from what the marking on the board says. The reason is that the board was designed for an LP2950, but the kit includes an MCP1702 which has a different pinout. Here is how it should be mounted:

DSC_0417.jpg

The 16 MHz resonator is next, it’s the tallest part on the board:

DSC_0418.jpg

You’re almost there now. The radio module is a surface mounted module, which needs a slightly different approach. Put a bit of solder on one pad, then place the module over it and reheat to stick it in place:

DSC_0419.jpg

Once correctly positioned, add solder to each of the remaining pads to make shiny round joints:

DSC_0420.jpg

The 6-pin male FTDI connector can now be soldered on, I usually mount it sideways, but the choice is yours:

DSC_0421.jpg

A simple wire acts as antenna for the radio – attach it to pin 1 of the radio module. You can bend it as needed afterwards. I used a red wire, even though the kit probably has a yellow one.

One more step and you’re done: add the four 6-pin port headers.

Good, the soldering is over. Now bend the pins of the ATmega microcontroller slightly inwards so it fits into the socket. Make sure you only press it firmly down after all the pins are in the proper position.

Voilá! Your finished JeeNode:

DSC_0424.jpg

If you have a USB-BUB adapter, you can now plug it in and try out the board (note the 3.3V jumper – the JeeNode uses 3.3V logic signals). The ATmega that comes with the kit is pre-loaded with the RFM12demo sketch to get you up and running in no time:

DSC_0428.JPG

That’s it. Congratulations with your new JeeNode v3!

My first reflow

In Hardware on Jul 13, 2009 at 00:01

Here’s my new super duper reflow setup:

DSC_0402.JPG

I decided to use a JeeNode as reflow controller. This is all about hammers, nails, and dog food, after all :)

The grill is turned on and off via an FS20 remote power switch, which is controlled by the on-board RFM12B. No need to get into relays and high-voltage stuff. Total cost including grill, LCD, and remote switch is under € 100.

The whole setup can be battery powered. I used the new plug breadboarding approach for prototyping it all:

DSC_0403.JPG

The “P” at the lower left indicates it’s currently in the pre-heat phase, now at 110° with a target of 140°.

The port assignments on the JeeNode are:

  • Port 1: serial 4×20 LCD display, based on the Modern Device LCD117
  • Port 2: NTC on AIO with 1 KΩ pull-up to 3.3V, piezo buzzer on DIO
  • Port 3: two leds: green is running, red is grill power on
  • Port 4: two switches: white is run/stop, black is select profile 0..9

I’m not using PID control. Merely did a manual test to determine the overshoot, and am compensating for that by turning off a bit earlier. It turns out that this grill has a huge overshoot: some 65°C ! … so I removed both Teflon-covered metal plates and am now using a 0.5 mm aluminium panel instead. Overshoot is now around 30°.

The system can be configured through FTDI / USB. Once set up, it can be operated without computer. The LCD display is optional but a great convenience.

Here’s the first test board (using some scrap boards from SparkFun):

DSC_0404.JPG

This is the cool-down phase, i.e. with the grill open. The temperature sensor is taped to a separate board to track things under similar conditions. The tape needs to be heat resistant, of course… I got it from DealExtreme:

DSC_0405.JPG

And here’s the final result:

DSC_0406.JPG

Only used a few resistors for this trial, and spread some paste on the TQFP pads to see how that comes out.

If you look closely, you’ll see that the leftmost resistor under header pin 13 is “tomb-stoned” – it’s standing straight up as the capillary pull of one pad took over. I probably put too much paste on one pad and not enough on the other.

But the rest looks good… f a s c i n a t i n g !

I seem to be getting a decent temperature profile. Things heat up nicely, stay in soaking ramp-up mode for a while, and then go up to a few degrees over 220°C. When the grill has to be opened up for cooling down after reflow, the system beeps to draw my attention.

FWIW, the source code for this setup is available here.

There’s still an intermittent problem with the NTC hookup – I’m getting occasional flakey connections on the enamel wires, which are simply wound tightly around each end of the NTC. Can’t use solder there, and I haven’t found another solution for that. For now, the controller just powers off when the NTC reading is bad, but that’s a pretty horrible approach.

Conclusion so far: reflow is absolutely doable for hobbyists (my second try went perfectly!), with the paste being the most tricky bit. Stencils are probably very useful to apply paste quickly and evenly.

See also Stephen Eaton’s recent post, where he describes his latest results with SMD reflow.

Reflow temperature

In Hardware, Software on Jul 12, 2009 at 00:01

For my upcoming reflow experiments, I’d like to use a JeeNode to track the temperature and perhaps also control the grill. As the saying goes… when you have a hammer JeeNode, everything looks like a nail sketch.

So I hooked up a 10 KΩ NTC resistor rated up to 300°C as voltage divider with a 1 KΩ resistor pull-up. Bought a cheap and probably not-so-accurate multi-meter with thermocouple-based temperature readout. And then the fun starts – turned my grill on and watched it heat up and then cool down, while jotting down the “readings” from this “experiment”. I felt like a high-school kid in physics class again :)

The results:

Picture 1.png

Not bad. The readout is a bit coarse at the higher end, but I think it’s accurate enough for reflow soldering in the 170° .. 240° range. The grill goes up to 260°C from what I can tell.

But I didn’t want a lookup table, so I went looking for a polynomial least-squares regression fitter on the web and found this one. Great: copy and paste the 18 heat-up readings, then try out a few polynomes – turns out that a 7th degree polynome fits well, matching the measured data within a few tenths of a degree.

And then I found an even better site called ZunZun – it lets you fit polynomes and graph the results and generate the C++ code. No need to copy lots of coefficients!

Here’s what I ended up with, using a “Lowest sum of orthogonal distance (ODR)” fit:

Picture 1.png

Corresponding C++ code:

Picture 4.png

To be able to configure this thing, it would be nice to be able to enter degrees. That’s easy to do by also fitting the inverse function:

Picture 7.png

Corresponding C++ code for the inverse:

Picture 6.png

Great. Onwards!

Programming a 32-TQFP chip

In AVR, Hardware on Jul 11, 2009 at 00:01

With SMT parts, all sorts of things change. For the JeeLink, I’d like to set the fuses and flash the bootstrap code to the ATmega chip before soldering it to the board. Here’s how:

DSC_0399.JPG

This is a zero-insertion-force socket for 32-TQFP chips. You put the chip on, press down, and the whole thing presses these 32 gold-plated contact fingers onto the chip. There are several alignment edges in there making it relatively easy and quick. It’s no doubt made for machine operation but it works nicely by hand as well.

And here’s the result – an ISP programmer which works with the Arduino IDE:

DSC_0401.JPG

I’ll start flashing a couple of ATmega168 chips, in eager anticipation of the JeeLink boards…

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:

DSC_0396.jpg

Each of the four port groups has the corresponding pins tied together. With a JeeNode plugged in you get this:

DSC_0395.jpg

And with some example plugs added:

DSC_0394.jpg

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:

3686871488_b2366a7459_o

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:

3686871410_0e325c3a2b_o

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:

3683813851_d524fedae2_o

That’s a 64 Kbyte AT24C512B serial EEPROM memory which talks via I2C.

It takes only 4 wires to hook this thing up:

3684626986_c2c8f1119c_o

And this is the mess you get in when you don’t have the right connectors and need to deal with older boards:

3683813971_e00e924cb0_o

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

Mystery JeeNode

In AVR, Hardware on Jul 3, 2009 at 00:01

Some more pictures from yesterday’s puzzle…

3681641100_900fdf0f6e_o

Added a second LDR on the left and a DS18B20 1-wire temp sensor. A 4.5V @ 35mA solar cell has also been soldered in.

The sensor is a TSL230R light sensor, as Milarepa correctly commented:

3679117790_f89f0caa7d_o

It has one frequency pulse output, with two other port pins used to control sensitivity (1x/100x) and frequency divider (2x/50x). The fourth I/O pin is used as power supply for the chip, so that it can be turned off completely in sleep mode.

Here’s the whole assembly from the side:

3681641152_3a6d49194e_o

And here the complete JeeNode (using a different solar panel which turned out to be too weak):

3679151344_f871517b7c_o

So what does it do? And what is it for?

Well, two things really – but I’ll be the first to admit that this isn’t truly general purpose and unlikely to be very meaningful for anyone else.

The first use is to help me take better pictures. The photos on this weblog are all taken using nothing but a white sheet of paper and plain old-fashioned daylight. Benefits are that it’s free and abundant, it needs no space for a light-box setup, and it tends to produce beautiful images.

The problem which you may have seen on this weblog, is that daylight ≠ daylight. Sometimes it’s too dark outside, and sometimes the light is too harsh. Worse still, many of the photos end up with a blueish tint. I’m having a hard time predicting this, so it seemed like a nice idea to just throw a bunch of light sensors together and try to correlate this to picture quality over a few weeks time.

The other purpose of this unit is to act as test-bed for long-term solar-powered use. That means getting the power drain down to very low levels of course. But I also added the ability to read out the voltage of the solar cell and of the battery, as well as temperature (solar cells are sensitive to that). And LDRs facing opposite directions, to try and detect sun vs. cloud cover weather info.

This seemed like an excellent project for JeeNodes and JeePlugs. Once it’s working well enough – auto-ranging the light sensitivity and such – I intend to put this up on the roof and just let it send out packets every 5 minutes or so, day and night. This will make an excellent yet non-critical test setup as well as allow me to track solar intensity over the entire year. Think solar panels…

Tomorrow I’ll post several sketches: one showing how to read out everything and report it over the serial FTDI connection, then two more to show how to turn this into a send/receive solution with two JeeNodes, and the last one showing how to get power consumption down.

Stay tuned!

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:

3672042410_7d5b23f1b8_o

It flips the +3V and AIO pins. Here’s the bottom view:

3671235369_b5d1054071_o

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:

3672042554_6468878165_o

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:

3672042632_8a891a56a4_o

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:

3671235565_ac050f2bd5_o

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:

JeePlugs

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

JeePlugs

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:

JeePlugs

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.

Breadboard limits

In AVR, Hardware on Jun 29, 2009 at 00:01

Here’s something which isn’t a good idea with breadboards:

Breadboard limits

I used a socket with wire-wrap pins to be able to connect a few wires yet still be able to use the whole thing in a breadboard. If you look closely, you can see that the 5-pin metallic connectors inside the breadboard are pushed out – making the adhesive separate from the rest. Whoops.

Wire-wrap pins are clearly too thick to be pushing into breadboards…

Arduino Mega + shield

In AVR, Hardware on Jun 28, 2009 at 00:01

Got myself an Arduino Mega – an Arduino on steroids:

Arduino Mega + shield

Compatible with current Arduino shields, but extended to support a lot more pins.

Ordered it from NKCelectronics, along with their new extended shield for it:

Arduino Mega + shield

There’s a lot of them pins on there…

I decided to attach a solder-less breadboard to it, to be able to experiment with projects which need more I/O lines or comms than a standard Arduino:

Arduino Mega + shield

It fits, but just barely. Had to cut off the little hooks on the plastic. Using a breadboard in this way covers up all the identifying pin texts on the silkscreen, alas.

Actually, it doesn’t quite fit – couldn’t get all headers on:

Arduino Mega + shield

I’m using a mix of 4- and 6-pin headers, since I had them lying around. As you can see, the last 4-pin header makes it impossible to fit that other header in, so I left off pins 22 and 24. It might have worked with an 8-pin header i.s.o. 2x 4-pin.

And here’s the final “stack”:

Arduino Mega + shield

Conclusion so far? I’m not sure this is the way to go. I think it’s an abomination, to be honest. There are so many pins to connect that the two boards are very hard to separate once stacked up. You don’t want to pull too hard on one side and end up with bent pins when the thing finally comes apart.

And how often do you need that many I/O pins one one fixed board setup? Sure, the ATmega1280 has 128 Kb of flash memory, which is plenty to get fairly complex sketches going. But it also builds on that trend of using stacked shields – and let’s face it: a single shield is often great, but with 2 or 3 you end up with pin allocation nightmares (for designers) or conflicts (for users). Multi-stacking is tricky, requiring special stacking headers.

Nah, I’d much rather go with ports, and extensions for that, and connecting two or three independent units over a bus if need be. But then of course I would, that’s why I went for such an approach with JeeNodes after all.

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.

Meet the JeeLink

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

I’m proud to announce a new board next to the JeeNode, called the JeeLink. Yes, there’s a pattern in the naming choices made for products on this site.

The JeeLink is very much like a JeeNode, but in the format of a USB stick and with a few small differences listed below. Here’s the layout:

Picture 2.png

As you can see, the JeeLink has basically the same headers as the JeeNode, but with a USB plug in the place of the JeeNode’s FTDI connector.

The JeeLink is useful in two different ways, I think: first of all, if you have a couple of remote JeeNodes, you’ll probably need a central node as well to tie the whole network to a personal computer. The second use case is that it can be used as a JeeNode with built-in FTDI-to-USB conversion – which is exactly what it is, technically speaking.

A major difference with the JeeNode also, is that the JeeLink is built with SMD parts. The intention is to make it available in pre-assembled form and as bare board. No kits with parts – that’s reserved for the JeeNode since I don’t want to stretch myself too thin.

There will be a more detailed description of the JeeLink once it is ready and working, but here’s a first overview:

  • the dimensions of a JeeLink are slightly different, obviously
  • the I2C and SPI/ISP headers are not in exactly the same position as on the JeeNode
  • there’s no battery connector (who needs one with USB?)
  • the FTDI-type USB connection includes two on-board activity leds

So there you have it – a new descendant in the Jee family. With on-board RFM12B wireless radio of course, and 4 ports to connect absolutely anything you like to. Just like the JeeNode.

The JeeLink is the initiative of – and was designed in collaboration with – Paul Badger of Modern Device. We’ve been having a heck of a time together, hammering out all the details and making sure the result will be as good as we can possible make such a new concept. I’m proud of the result, and hope you’ll like it as well. Should have properly working JeeLinks in my hands in July, assuming Mr. Murphy doesn’t barge in to spoil the party.

More JeeNode v3 changes

In Hardware, News on Jun 22, 2009 at 00:01

Here are a few more details about the upcoming JeeNode v3 board.

First off, I said no more changes w.r.t. the pinout. Not true – the I2C/PWR pinout has also changed:

i2c.png

For a couple of reasons which I don’t want to go into just yet. The GND pin is now on the outside, just as on the FTDI header. Note that PWR is the incoming voltage, not the regulated 3.3V at which the ATmega operates (including those SDA / SCL pins).

The other change worth mentioning here, is that components have been rearranged slightly to make room for 2 pads to connect a battery or battery pack – along with holes for strain relief. Both leads are clearly marked “+” and “-” to avoid polarity mistakes.

The JeeNode is well suited for battery use due to it’s 3.3V design and because it has no on-board LEDs. The regulator lets you choose from a huge range of battery options (hence the soldering pads i.s.o. a fixed battery choice): 3x or 4x AAA or AA, NiMH or Alkaline, or one of the increasingly popular 3.6 .. 4.1 V Lithium batteries, which are great as long as you take care not to short-circuit them and not to discharge them beyond their advised limits.

So there you have it. The new JeeNode v3 board is just about ready to send off to manufacturing. I hope to get my hands on them early July.

More SMD stuff

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

My adventures in SMD miniaturization-land continue:

SOIC chips

Those are two Atmel chips – an ATtiny85 (SOIC-8) and an ATtiny84 (SOIC-14).

Compared to 0603 parts, these are actually quite large. The distance between the pins is 1.27mm (0.05″), half of regular through-hole parts.

But you do need fine tweezers, and a ZIF socket to flash them or try them out without soldering is also nice:

SOIC chips

The lid snaps down, making a firm connection with each of the 14 pins.

Hm, I see now that the SOIC-8 dimensions are a bit wider than the SOIC-14 package. So the smaller package doesn’t fit in this (pricey) ZIF socket.

So not only is this stuff small – it’s also easy to overlook such differences!

Fortunately there are datasheets.

JeeNode v3 pinout

In Hardware, News on Jun 20, 2009 at 00:01

There are two important pinout changes in the upcoming JeeNode v3:

  • On all four ports, pins 4 and 5 will be swapped (AIO and +3V)
  • Pins 1 and 2 of the SPI/ISP header will become pins 7 and 8

So the final pinout for ports is:

Preview of “jeenode-v3.graffle”.png

The change isn’t being made on a whim – I’ve got several things plugging into ports here which will need to be changed to work with the new pinout. And it will affect everything plugged in for years to come. One of the reasons for the change is that it lets you plug in a 3-wire servo (pins 3..5). Another reason is that it is compatible with the BBB board already out there (also pins 3..5).

As before, a 4-pin connector on pins 2..5 is often all you need. The outer two pins are for more advanced uses.

As before also, pin 1 carries the input voltage to power the board, and can be anything from 3.5V to 13V. With an FTDI connector it will usually +5V. Batteries work great, anything from a 9V block, or 3x AAA/AA (both NiMH and alkaline), or even a LiPo battery.

Note also a small change in pin names: the 3.3V regulated power supply is now called “+3V” instead of the somewhat ambiguous “VCC”, and the interrupt line is called “IRQ” instead (was INT).

Every future JeeNode design will use this pinout on every port.

The new SPI/ISP header is (pin 1 at top left):

spisp.png

This is an “extended” ISP header. The main reason for this change is that pins 1..6 are now compatible with a standard 6-pin in-system programming connector, through which the ATmega’s fuses, flash, and EEPROM can be programmed. Note that the JeeNode is a 3.3V device, it should not be driven by an ISP programmer set to 5V voltage level.

The two extra pins are tied to digital I/O lines B0 and B1, and allow connecting more SPI devices to the JeeNode. Note that SPI is used internally by the RFM12B radio module, so these pins should not be re-configured for other purposes, although you could use SEL0 and SEL1 as general-purpose I/O lines if you want – a LED and a push-button switch perhaps.

I’ve made a few experimental add-ons using the SPI/ISP connector, such as this one. They will need to be adjusted for v3, but as with ports the same new pinout will be used for all future JeeNodes and derivatives from now on. Although some of them might not have such a connector at all.

That’s it – no more changes. Now I can “standardize” everything I want to connect to the JeeNode ports!

Don't sneeze

In Hardware on Jun 18, 2009 at 00:01

Ok, so this is what 0603 SMT parts look like:

Don't sneeze

That’s a 0.1 µF capacitor and a 10 kΩ resistor.

Trouble is, they are small

Don't sneeze

The “0603″ part designation for SMD’s stands for 0.06″ x 0.03″ (roughly), which is 1.6 x 0.8 mm. Here’s a good overview, from that same SMT page on Wikipedia:

SMT_sizes_by_Zureks.png

Well, it sure is something new for me to try out such miniature components!

Fortunately, that’s as small as it gets (I’ll leave 0402 components to the industrial parts-placement machines). Other capacitors (3216), voltage regulators (SOT23), and microcontrollers (SOIC) are all a bit larger.

Prototyping with JeeNodes

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

Here’s a little board I used for a while with a JeeNode:

Pulse prototype

It has 6 female header underneath, which get plugged into a JeeNode with its header pins sticking upwards. It has an LDR, a diode I tried to use as voltage reference, a plugged-in SHT11 temperature / humidity sensor, a 3-pin connector to plug in a Parallax PIR sensor, and a 2-pin header (top right, behind the SHT11) which was used to connect a couple of 1-wire temperature sensors).

There are a couple of issues with this, though some are probably unavoidable for such one-off / ad-hoc solutions. For one: it’s a bit of a mess. One reason is that with this setup the 1-sided perf-board I used has to be mounted upside down to allow soldering in the female headers. That’s awkward, because it means you have to “surface mount” most components.

One option is to use perf-boards with plated-through holes. These are several times more expensive than single-sided boards, though. But more importantly, cheap one-sided boards are often based on “Pertinax” (SRBP) which is a lot easier to handle than FR-4 epoxy: you can simply break them on a sharp edge, with the row of holes acting as perforation.

The other problem with putting everything on a single board is reduced flexibility. In this case I had to add a second 4-pin female header on top to accommodate the SHT11 plug I had already made – which would have fitted just as well directly on the JeeNode.

One nice benefit of per-port prototyping is that it is easy to re-use this stuff in different configurations. In fact, as with the SHT11 plug showing in the picture, that’s precisely what happened.

So I’ve been thinking a bit about ways to use JeeNodes for experimentation. Which happens a lot around here. One simplifying convention is to always use male headers on the JeeNode. That leaves essentially two choices (ignoring sideways mounting for now):

Picture 1.png

I’m thinking of having a bunch of, ehm, “JeePlugs” made: tiny boards with a 6×8 “prototype” area containing plated-through holes, plus a 6-pin female header and connecting pads. Three ways to use these:

Picture 2.png

You’ll need male headers for use with a breadboard, but I’m assuming you’ve used the breadboard to figure out the connections with the bare parts, so this post focuses on using female headers for the JeePlugs.

In all cases, the orientation of the pins is the same, so once you have a plug set up with stuff on it, you could still use it in multiple ways. And plug them onto any of the 4 ports at will, of course.

One last refinement is to make these plugs around 20 x 25 mm – i.e. long enough to optionally plug onto two ports in that inverted 3rd example shown above. Here’s a first design:

Picture 3.png

It’s really not much more than a tiny perf-board of the proper size for JeeNodes with a couple of doubled-up connections. Using plated-through holes so components and wires can easily be soldered from either side.

The plugs are not labeled with pin numbers or signal names, because those depend on the orientation in which you use them. For that, use the markings on the JeeNode itself (starting with v3, that is).

These JeePlugs only makes sense in larger quantities, so I haven’t yet decided whether I really want to order them. I sure could use some, but it wouldn’t be practical to have less than a hundred or so of them produced.

Reflow experimentation

In Hardware on Jun 15, 2009 at 00:01

Got this little skillet/grill thing recently:

Heating plate

Quite a convenient size (and it can be stored upright) – the usable area is around 25 cm diagonal. It’s also relatively weak at 700 Watt, but since it’s so small it still easily reaches the solder melting point within a few minutes (with the lid closed).

I’ll be experimenting with this thing for SMD reflow soldering. Will need to measure and control the temperature (an NTC resistor rated for 300° no doubt, but I don’t know which type yet).

If the heat collection in these plates makes the thing too slow to control properly, I could take the plates out and use some sort of grid instead:

Heating plate

Note the heat sensor in the middle, triggering a thermostatic switch.

Ideally – of course – I’d want to control this thing with a JeeNode, but I’m not willing to spend very much time on that right now. We’ll see. First thing will be to measure the temperature ramp-up/-down behavior of this thing, with the lid open and closed.

If this works, it’s a pretty good deal for €19.95 !

New JeeNode v3 design

In AVR, Hardware on Jun 14, 2009 at 00:01

Here’s an – improved! – board design for the JeeNode:

Picture 1.png

The main two changes are: labeling of all the components and pins, and a change in the ISP/SPI pin header (pin 1 is now also pin 1 for ISP). All connectors are in exactly the same place, but the board is a tiny fraction wider.

For details, see the EAGLE files (jee-pcb-011.sch and jee-pcb-011.brd). The PDF of the schematic shows that the functionality is unchanged – other than the ISP/SPI header pinout change, this board should be 100% compatible with the JeeNode v2.

The v3 board was designed in collaboration with Paul Badger of Modern Device, to whom I’m most grateful.

I’ve just ordered a batch of these boards. Should be able to report here in ten days or so as to whether they are working properly. Let’s hope so!

Bad things happen

In Hardware on Jun 13, 2009 at 00:01

Looks like one of the sensors broke:

Broken sensor

That’s an IMU (Inertial Measurement Unit) with a dual accelerometer and a gyroscope. The gyro is the “big” one on the right. It senses rotation around the Z axis perpendicular to the board. The accelerometers are working fine, but the gyro appears to be toast. No matter what I try, it produces a noisy but fixed analog voltage. Connecting either of the self-test pins doesn’t doing anything.

Ouch, the gyro is also the most expensive part (in the €25..50 range). And this was a rather nice and sensitive one. Oh, well…

(that’s an Arduino with a battery pack by LiquidWare underneath, btw – so I can move this thing around and hook up the scope without having to attach power)

Ancient technology

In Hardware on Jun 12, 2009 at 00:01

This is fun. For one of my numerous projects, I wanted to resurrect a 15 year old LaserPrinter which has been gathering dust for a while:

Ancient technology

A “state of the art” 600 DPI PostScript laser printer for the Mac. With a whopping 6 MB RAM and LocalTalk / RS-232 / Parallel interfaces. Those were the days.

Plugging it in and running a self-test from the menu was all it took:

Ancient technology

As you can perhaps guess from the Dutch report in the bottom left, it has printed a mere 8050 pages in its lifetime so far.

Yeah. Back then, they knew how to make things. You just turn it on and it works. That toner cartridge must be at least 10-years old, btw!

Got some ideas about hooking up a JeeNode to this thing, probably via the serial port. The printer draws a lot of power and does not really have a standby mode, so the RFM12B could be used to control a remote KAKU power switch, for example. We’ll see…

JeeNode v2 kit notes

In AVR, Hardware on Jun 11, 2009 at 00:01

Just to make sure I didn’t forget anything – here’s the contents of a JeeNode v2 kit with parts:

JeeNode kit contents

For those of you who are about to receive the kits: they should match what’s shown above. If I forgot anything please let me know and I’ll take care of it right away.

The ATmega168 is pre-flashed with the standard Arduino boot loader and the RF12demo sketch.

As for assembling these kits, the main thing to keep in mind is the orientation of a few components and the ways things should be hooked up – see the recent post and the reference doc and close-ups on this site such as this one:

JeeNode v2

These are first-generation boards without silkscreen (I’m still learning about all this PCB design stuff!), although there are tiny markings on the top copper layer if you look really closely.

One important detail I forgot about is the antenna: for these 868 MHz units, I use a piece of 85 mm insulated wire. It needs to be connected to the ANT pin, which is the one in the corner as you can see in the above picture. You need an antenna, I’ve not been able to bridge even the shortest distance without one.

Building the JeeNode

In AVR, Hardware on Jun 9, 2009 at 00:01

Now that a few people have started building JeeNodes for themselves, here’s a close-up:

MCP1702 detail

Make sure you put that MCP1702 voltage regulator in exactly as shown. That’s the TO-92 package in the middle.

The board was intially designed for an LP2950, which has a different pinout. The MCP1702 does not have ground in the middle, hence the twisted positioning.

Note also how I use flat 6-pin headers, even for the FTDI connector. All the header pads are large enough to solder them on in any orientation you like.

FWIW, I’ve still got 9 JeeNode boards left (and probably all the parts needed as well). So if you want ‘em let me know. I can send bare PCBs for €5 each. Or the PCB with all parts including 868 MHz radio and pre-flashed ATmega168 for €17.50. Shipping included if you order more than one.

JeeBot Duo schematic

In AVR, Hardware on Jun 8, 2009 at 00:01

Heh – my most “sophisticated” robot so far. Here’s the plan for the electrical hookup of the JeeBot Duo:

Picture 1.png

There’s quite a bit of functionality in there, all the way to an on-board LiPo battery charger. Other things to note: the Baby Orangutan controller (BOC) can shutdown all power (to avoid running down the battery too far) and the JeeNode can reset the BOC if need be.

The two processors communicate with each other via an I2C bus. The on-board FTDI header connects to the BOC serial port and supplies power to the LiPo charger. The FTDI header on the JeeNode can be used for monitoring, control, and uploading, as usual.

JeeBot Duo – in progress

In AVR, Hardware on Jun 7, 2009 at 00:01

To continue this bot-craze, here’s another design, the JeeBot Duo

More JeeBots in progress

This design is considerably more advanced. From left to right:

  • two 50:1 micro motors with wheels and encoders (Pololu)
  • a 6-pin FTDI header
  • the Baby Orangutan 328 motor controller (Pololu)
  • underneath: a low-voltage boost regulator (Pololu)
  • at a 45° angle: IMU board with 2-axis accelerometer and gyro (SparkFun)
  • a JeeNode v2 with on-board RFM12B 868 MHz radio module
  • underneath: a 860 mAh LiPo battery

It’s called a JeeBot Duo because there are two processors on board. The plan is to put the self-balancing smarts in the Baby Orangutan – which has all the hardware needed to connect to all sensors and motors. The JeeNode is available for telemetry, remote control, and perhaps to connect to further gimmicks later on.

Initial tests show that the motors have plenty of speed and torque, and draw 40 .. 300 mA each, depending on load. The boost regulator can produce a constant 5.4 V for the motors, while the battery level gradually decreases. There’s a tiny bit of slack in the gears, which translates to about 1 mm of slack/travel on the wheels.

The remaining space is for a compass module and an on-off switch. That makes this a relatively complete autonomous unit, able to sense its vertical position and change, as well as the distance traveled and the compass heading. With the proper software, it should one day be able to respond to commands such as “go 2 meter north”, or “drive around in a 1-meter circle”.

But that’s a long way off. Lots of tuning and software development will be needed to get there…

JeeBot Mini – in progress

In AVR, Hardware on Jun 6, 2009 at 00:01

Here’s a second design, called the JeeBot Mini – no less:

More JeeBots in progress

The first JeeBot used servo’s but that’s not really such a great fit for self-balancing. This one uses miniature (and pretty weak) motors, directly driven by the ATmega’s I/O pins. The small socket is for the same Memsic 2125 accelerometer as on the original JeeBot, but placed at a 45° angle to use both X and Y axis together.

On the right is a tiny 100 mAh LiPo battery – plenty for simple trials. No gyro, no regulator, and no resonator (so far). No JeeNode either – just a serial FTDI interface and a bare ATmega168 chip running the LilyPad bootstrap @ 8 Mhz, straight off 3.7 V from the battery.

I’m waiting for some wheels for this thing. Am not sure the wheels will turn fast enough to regain balance once detected. If not, maybe raising the center of gravity by extending the “chassis” upwards will help. Or bigger wheels. Or both. Or maybe the design choices are hopelessly wrong already… we’ll see.

Minimal motion

In AVR, Hardware on Jun 3, 2009 at 00:01

Now that I’ve been bitten by the robot bug, it’s hard to stop. Wanted to experiment with a minimal setup for self-balancing:

Minimal motion

These are 1.5 .. 3V motors with 1:96 gears from Conrad. What’s special about these is that they only need some 20..30 mA current, which is sort of within the direct-drive capability of an ATmega168. That means 2 I/O pins per motor can be used to create an H-bridge without any further electronics.

Here’s a small sketch to drive these from a JeeNode:

Picture 1.png

A couple of details show that this really is pushing the limit: without the capacitors, timing becomes erratic. Also, the delays between reversals seems to be needed to bring the motors to a stop. I suspect that there’s still some very bad stuff happening due to inductive kickback, so diodes to ground and VCC are probably required to avoid damaging the MPU chip.

But it does run. It’s all driven off a tiny 100 mAh LiPo battery in that picture above, and it kept going longer on a charge than I was willing to wait for. Probably over an hour – total power draw is in the 50 .. 60 mA range.

Anyway, this is even more spielerei than the JeeBot. Just wanted to find out whether these components might be used for a little baby balancer one day. This would also require wheels and at least an accelerometer.

Vertical JeeBot

In AVR, Hardware on Jun 2, 2009 at 00:01

Here’s a first example of the JeeBot standing upright:

Vertical JeeBot

When held upright on startup, it actually stands on it’s own two wheels very calmly, compensating immediately for slight imbalances for a couple of seconds. But beyond a minor error, it fails to regain its balance – so my hands are right outside the picture, ready to catch it :)

Have added a Memsic 2125 accelerometer to provide a sense of what’s up. It’s connected to port 1, with the X and Y axes each producing pulses at around 100 Hz.  The gyro kicks in when it’s falling either way. Having both near the center of gravity helps, as the counter force of the servo won’t disturb the accelerometer as much.

Here’s the main code. It has a crude low-pass filter and PID control loop:

Picture 1.png

The parameters were set using (much) trial and (much) error. I’ll clearly need to learn more about PID control to make this thing properly self-balancing. The loop runs 49 times per second on average, which also happens to be the servo pulse rate – maybe there’s some accidental interaction with the SoftwareServo library.

But still, a lot better than I had expected after one day!

Horizontal JeeBot

In AVR, Hardware on Jun 1, 2009 at 00:01

The JeeBot has made its first explorations, using a Nunchuk controller:

JeeBot baby steps

It drives on two wheels plus a coaster ball to support the batteries – although not very fast and veering slightly to the right. It will also turn, by rotating the servos in opposite directions. The batteries push down hard on the coaster ball, making the wheels slip when turning if the surface is not hard enough. The control mechanism is somewhat proportional, although it seems to work best by just pushing the joystick to its limits.

Here’s the current primitive control loop:

Picture 1.png

Some more close-ups:

JeeBot baby steps

From left to right: the Wii adapter, batteries with coaster ball underneath, on-off switch, JeeNode, and the edge of the servos.

Not much wiring needed to get it going:

JeeBot baby steps

The two resistors divide the battery voltage in half, so it can be measured by an ADC pin. Note the use of wire to “bundle up” the Nunchuk I2C “bus”.

Port layout so far: 1 = unused, 2 = left servo + battery level, 3 = right servo, 4 = Nunchuk via I2C.

I’ve also mounted the gyroscope (not connected yet) in the proper orientation to sense rotations around the wheel axis:

JeeBot baby steps

Will need to add an accelerometer as well, no doubt.

The center of gravity is just about on the power-switch, between the battery pack and the JeeNode. Which is quite low when this thing is placed upright, not sure the servos + control loop will respond fast / accurately enough for balancing.

Current consumption is around 30 mA when idle, 160 mA with wheels turning freely, and up to some 300 mA under load – these 4 NiMH batteries give about 5.2V under no load when full, but I’ve seen it drop to 3.7 V under load after a bit of use – not so good…

Seeing sharp

In Hardware on May 31, 2009 at 00:01

Here’s a fun gimmick from DealExtreme:

Seeing sharp

It won’t make you look sharp, but these glasses are pretty effective. There’s a built-in white LED with battery (that’s the big black case) which isn’t that great, but it comes with three plastic lenses of varying strength.

Really works well, even if not quite for a neurosurgeon ;)

This’ll be great for some SMD stuff I’d like to explore.

Yet more AVR size comparisons

In AVR, Hardware on May 30, 2009 at 00:01

Ok, let’s finish off what I started yesterday – here are yet more tiny AVR boards:

Another AVR board line-up

From left to right:

Here is the previous line-up again for comparison:

More AVR size comparisons

See yesterday’s page for a description of what is what.

If you look closely, you’ll see that yesterday I used a JeeNode v1 board.

Update – same photos, higher resolution: first, second.

More AVR size comparisons

In AVR, Hardware on May 29, 2009 at 00:01

Here’s another comparison of little AVR-based boards:

More AVR size comparisons

From left to right:

Unfortunately, I forgot to show the RBBB (Real Bare Bones Board), and the new Strobit unit (also shown here) – they both deserve a place in this line-up.

These little boards are not entirely equivalent, but all of them are great for AVR-based fun DIY projects.

Measuring the AC line frequency

In AVR, Hardware on May 28, 2009 at 00:01

There is an interesting site in the UK called Dynamic Demand. The idea is to let the 50 Hz power-line frequency vary slightly to indicate the current load of the entire grid. Simple line-monitors can then track this locally and respond by voluntarily shutting down some power consumers (i.e. turning off freezers, A/C units, or electric heaters for a little while). With a bit of collaboration, the grid would then presumably recover as the load eases off – and overcome these demand peaks. I love the idea, it’s so beautifully simple.

The Dynamic Demand site also has a page showing the current frequency online, here’s a snapshot:

Picture 2.png

I d