Computing stuff tied to the physical world

Archive for November 2009

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.

UpdatePOFs 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 0x68 (which is actually not such a good choice because it conflicts with the RTC plug).

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

Screen shot 2009-11-23 at 18.21.27.png

And here is the sample output:

Screen shot 2009-11-23 at 18.05.39.png

Is it precise? You bet.

Is it accurate? Well, my multimeter says 1.265…

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!

New RF12demo

In AVR, Software on Nov 19, 2009 at 00:01

An updated version of the RF12demo sketch has been checked in. Also available as ZIP.

This adds preliminary support for the 1 Mbyte dataflash memory present in the JeeLink v2.

The idea is very simple: the RF12demo app reports all incoming packets as before, but now also stores all valid packets in flash memory, if present. This is done by collecting packets into a 248-byte RAM buffer, and saving it to flash whenever it fills up. Small portions at the high and low end of flash memory are reserved for future use, the remainder is treated as a circular buffer of 256-byte pages – 3808 to be exact (i.e. 952 Kbyte).

The RF12demo commands have been extended accordingly, here is the startup screen on a JeeLink v2:

Screen shot 2009-11-18 at 18.33.06.png

There is a “DF” line at the top which shows that dataflash memory was found, with page #41 written to last, and that we’re in the 3rd reboot since the flash was wiped. This unit picks up incoming data in group 5 @ 868 MHz.

The new “d” (dump) command reports which pages contain data:

Screen shot 2009-11-18 at 18.31.34.png

At this point, I did a reset of the JeeLink, and then left it on to collect some more data. Here are the last few lines of a subsequent dump:

Screen shot 2009-11-18 at 18.45.14.png

The new entries were added starting on page 42, and the clock started at zero again (there is no RTC). Some 248 seconds later, new entries were logged on page 43. The last number on these lines is a page checksum, btw.

The new “e” (erase) and “w” (wipe) commands require specific constant values as input arguments so that these destructive commands are not activated by a mere typo.

So far so good. The JeeLink can now keep track of what is coming in. But that’s just half the story. We also need to be able to get data out again, “replaying” the log from a certain point. This takes a bit more work.

Firstly, whenever a page gets saved to flash, something like this is sent out to USB:

Screen shot 2009-11-18 at 18.45.52.png

This means that page 44 with seqnum 3 was saved with some entries starting at time 505 (seconds since the JeeLink was powered up). Here are the last few lines of a dump made right after that save:

Screen shot 2009-11-18 at 18.46.18.png

The sequence number is an integer which increments on each reboot, and whenever the flash memory buffer wraps back to the first page. So the combination (seqnum,time) is unique and monotonically increasing, over time and across reboots.

On the PC side, these DF “packets” should be treated as readings and stored like any other incoming packet.

To get the saved entries out of the JeeLink, the PC has to send a “replay” command when it connects to it. This replay command must contain the last sequence number and time stored on the PC for the above DF packets. The JeeLink will look for the location of this page in flash memory (or the earliest one thereafter) and will then replay everything stored from there on.

This code is still work-in-progress, but the plan is to replay these packets as lines starting with “R seqnum time” instead of the usual “OK” prefix. Replay takes place at full speed, but depending on the amount of data stored this can still take a substantial amount of time.

After the requested data has been replayed, the JeeLink resumes its normal mode of reporting “OK” packets, “?” checksum errors, and “DF S” save commands.

I haven’t finished implementing the replay command yet, but storage of incoming packets seems to be working, so an updated version will be able to get at that stored data later.

One last point to note is that this storage implementation has built-in automatic “wear leveling” and hence creates no “hot spots”: there is no page in flash memory which gets written to more often than others, so this memory will be usable for at least its full 100,000 rated cycles. This is done by scanning the entire flash memory on startup to determine the last page written to, and by erasing 4 Kbyte blocks only when needed, ahead of the write pointer.

Total size of the new RF12demo is under 10 Kb, so there’s still lots of room left.

Update – several fixes and replay code added. Not 100% right yet, but all functions are implemented now.

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 0x50, 0x52, etc – i.e. with a gap in the addressing.

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

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

Screen shot 2009-11-08 at 19.27.04.png

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

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

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

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

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!

Build and pinout errors on older posts

In AVR, Software on Nov 8, 2009 at 00:01

There has been an unfortunate dependency between the Ports library and the RF12 library for some time now, causing the Arduino IDE to generate errors such as these:

ide-errors.png

(etc…)

The workaround right now is to include both in your sketch, even if you only need one:

Screen shot 2009-11-04 at 10.50.42.png

I’ve been planning to do a major overhaul of the library and software in general, but until then this is the way to avoid those pesky errors. It probably affects quite a few sample sketches on this weblog.

Another thing to watch out for (thanks, Ian!) is that some older examples on this weblog use the JeeNode v2 or even v1, which have a different pinout. To uses those examples with the latest JeeNodes, you have to swap pins 4 and 5, i.e. +3V and AIO.

Please let me know when examples from earlier weblog posts don’t work as described. A small fix and note added to these posts might be all that is needed!

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.

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

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 0x24. There are two jumpers to select the voltage level for driving the logic supply and the backlight, respectively. The backlight can be turned on and off under software control.

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

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

Screen shot 2009-10-31 at 16.06.14.png

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