Arduino DuemilanoveIn 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:

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

▶ Comment

JEENODE, JEEPLUG

JeeNodes and complexityIn 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.

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.

▶ View 5 Comments

ARDUINO

Arduino and complexityIn Hardware, Software on Dec 28, 2009 at 00:01

This is – in a nutshell – the Arduino world:

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 extremelyhard, 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.

▶ View 3 Comments

CNC

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

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

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

hopefully!

▶ View 2 Comments

JEENODE

Carrier detectionIn AVR, Software on Dec 26, 2009 at 00:01

Wireless communication is a complex process. The ISM bands used by the

RFM12B module get used in various ways – some quite simplistic. For

“serious” use, what you want is to avoid transmissions interfering with each

other – which means at most one transmitter should be active at any given

time for a specific frequency band.

Easier said than done. This is what CSMA/CA is all about. It’s quite similar to

ethernet: you listen to the “ether” and wait until there is no carrier before

starting to send yourself. If everyone does so, then there will be fewer

“collisions” – i.e. messed up packets.

CSMA/CA isn’t perfect. It doesn’t scale all that well if there are lots of nodes,

all trying to find a free slot to send their packets out. There is always a non-

zero probability of collision, when two nodes decide at nearly the same time

that there is no-one else transmitting. And then, BOOM! … as they say.

One solution for that is another acronym: TDMA. Basic idea: have all the

nodes agree to only send in specific time slots allocated to them. This

requires a central coordinator, as well as pretty accurately keeping track of

time (which is non-trivial with RC-based watchdog timers for sleep modes

used with low-power nodes!).

In the ISM band, at least the 868 MHz one used in Europe, a simpler solution

is used: keep the air-waves more or less free. The rule is that each

transmitting node should send no more than 1% of the time, on average. With

one or two dozen nodes and a bit of randomness in timing, the idea is that

collisions will be relatively rare.

I recently added the 1% rule to the easy transmission mechanism in the RF12

driver (for the 868 MHz band only). So with the rf12_easy…() calls, adhering

to the 1% rule is now automatic.

The 1% rule is a very simple system, yet it works surprisingly well. I’ve got

over a dozen nodes around the house, sending out packets whenever they

feel like it. The off-the-shelf commercial weather station nodes I use are very

simplistic – they just send, ignore collisions, and send new data again a

minute or two later. Those nodes probably don’t even have receive capability.

The RFM12B transceiver module in the JeeNode is slightly more sophisticated,

in that communication can take place in both directions. So the receiver can

send back an “ack” packet, and the originating node will have some idea of

whether its last data packet ever made it to the destination (note that ack’s

can get lost as well – but that’s another story).

Still – the RF12 driver used in JeeNodes is just as careless as the other nodes:

it starts sending the moment it feels like it – except if a packet for its own net

group is currently being received. Sending packets with the RF12 driver can

still easily mess up whatever is currently going on in the air.

Well, as of today, things will improve a bit further. I’ve extended the RF12

driver code to look at the RSSI status bit before starting to transmit. If a

carrier is detected, even one that isn’t being recognized by the RFM12B, then

transmission will be delayed a bit. Here is the latest code in the RF12.cpp

driver:

This isn’t perfect – nothing ever is – because most nodes will be polling very

frequently and then start to send right after the carrier drops. So the chance

increases that nodes two and three will both try sending when node one

finishes. But let’s assume that the RSSI signal doesn’t drop to 0 for all nodes

at exactly the same time. If that turns out to be insufficient, a timer-

based exponential back-off mechanism can be added later.

And there is a substantial benefit: nodes will no longer mess up packets which

are currently “on the air”. As more nodes are being added around here, I

expect this change to cause less degradation due to collisions.

In summary: the RF12 driver is a very simple system. No CSMA/CA, no TDMA.

There are definitely limits as to what it can be used for. There are some

severe limits on how much data it can send, given that (on 868 MHz) each

node can only send up to 1% of the time, but this is also why such a simple

approach is actually quite effective. And why the RF12 driver is still just a few

Kb on an 8-bit ATmega, leaving lots of room for application specific code. I

happen to think that the RF12 approach strikes a pretty decent balance

between simplicity and effectiveness – and I’m always open for suggestions

on how to take this further.

▶ View 7 Comments

JEENODE

OOK reception with RFM12B ?In AVR, Software on Dec 25, 2009 at 00:01

Yesterday’s post described a setup to see the RSSI and DQD status bit

reported by the RF12 driver in real time.

One of the interesting results is that I can see the RSSI light come on when

pressing a button on the FS20 remote transmitter – even though that’s an

OOK signal, not FSK!

When adjusted to run at 433 MHz, the RSSI indicator also lights up with the

KAKU remote.

In both cases, the DQD signal appears useless – it just shimmers all the time.

The RSSI signal is encouraging, though. It turns out that getting it to blink

reliably did depend on setting the threshold right. At -103 and -97 dBm, it was

on all the time – only the -91 dBm value produced a usable signal. I hope

that’s the case with all units.

Could this be used to receive FS20 or KAKU?

Well, I just had to try. My idea was to continuously poll the RSSI status bit and

then “mirror” its value to a DIO output pin. Then use a second JeeNode to

treat this as a normal OOK pulse train.

Here’s the “rssiMirror” sketch I used:

Does it work? Unfortunately … no :(

Time to hook up the Logic Analyzer to see what’s going on. I connected the

above digital output to the first channel, and a real OOK receiver on the

second channel:

Guess what… the RSSI signal is indeed detecting the presence of a

transmitted signal, butit’s way too slow!

Here’s the same sample, zoomed in on the real OOK pulse train:

As you can see, there’s a pretty good sequence of transitions, 400 µs and 600

µs apart. Oh well, so much for the RSSI status bit – it’s nice to detect the

presence of a carrier, but not more than that.

Next thing I tried was the DQD signal. After tweaking the DQD threshold to 3,

this is what came out:

Yeah, sure, it seems to track the signal, but not reliably, and with a huge

number of extra transitions. Note how the top timings are all multiples of 25

µs apart – that’s because it takes 25 µs to read out the DQD status bit.

Coarse, but fine enough in principle to track 400 / 600 µs pulses from an FS20

remote.

So, again: nice, but no dice. Neither the RSSI nor the DQD status bits are fast

and accurate enough to decode a slow OOK pulse train with.

Next attempt was to try and pick up the ARSSI signal, direct off the RFM12B

module – as mentioned in this forum discussion. There’s a German

forum which describes where to pick up that signal:

And sure enough, here’s a scope capture of an FS20 transmission:

Yeah, it’s there alright. But the signal is a bit weak. I’d rather not dedicate the

analog comparator or ADC to it, and besides – that still leaves the need to

compare against the average level – there’s a nasty 0.4V bias in that signal.

Here’s the same signal, AC coupled:

And here’s a zoomed-in area, showing what looks like pretty decent 400

µs and 600 µs pulses:

So yes, a small self-adjusting comparator can proabably turn this into a nice

digital pulse train – but it’ll require some extra components, and I’m a bit out

of my league on designing such a circuit.

Oh well – perhaps this information will help someone else further along. It’s

been a good learning experience for me, even if the result is not quite what I

had hoped…

Tomorrow, I’ll describe another – successful! – outcome from this RSSI / DQD

exploration.

▶ View 2 Comments

JEENODE

RF12 status lightsIn 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:

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:

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…

▶ Comment

JEEPLUG

Idiot plugIn Hardware on Dec 23, 2009 at 00:01

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

Such as the reversed pins on a recent plug.

Here’s the solution:

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

Onwards. Quickly, please :)

▶ View 1 Comment

JEENODE, JEEPLUG, LOWPOWER

Power tracker – softwareIn AVR, Software on Dec 22, 2009 at 00:01

Yesterday’s post described a small circuit to track power consumption of

JeeNodes to help optimize sketches for minimal power consumption.

Let’s put that circuit to use, with a bit of software to measure actual power

consumption. The basic idea is to continuously measure current and

then integrate these measurements to determine the sum of all power

consumption intervals, regardless of levels.

The reason for this is that we’re not really interested in current draw but in

the amount ofcharge consumed by the JeeNode. As far as the battery is

concerned, drawing 1 mA for 1 hour is the same as drawing 100 µA for 10

hours (in the ideal case, anyway). The fancy way to say this is that we need to

measure Coulombs, not Amps. Or rather micro-Coulombs, i.e. µC. That’s really

easy once you realize that 1 µA is the same as 1 µC per second. Or to put it

differently again: 1 mAh = 3600 mC. So a 1000 mAh battery is really nothing

but a 3600 C charge.

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

second.

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

It reports averaged power drain in µA/sec (the second value is the number of

samples per second). The 10% correction which I had to apply in my setup

could be due to a number of factors – most likely it’s due to resistor

tolerances (they are all 5%).

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

As you can see, the baseline power drain is a fantastically low 56 µA/sec in

this case, but once or twice a minute it goes up to 14 mA/sec for several

seconds. Not sure what’s going in here – need to investigate (now that I can!).

It would be nice to automatically detect the baseline, i.e. the average low-

level sleep consumption, and things like the peak current and the percentage

of the total consumption caused by such peaks. Extending the software to

handle this is more work.

With slightly more elaborate software, it will be possible to place the power

measurement plug between the measuring JeeNode and the JeeNode under

test, and then leave it alone. A 1-day or 1-week average should give an

excellent estimate of battery lifetimes.

▶ Comment

JEENODE, JEEPLUG, LOWPOWER

Power consumption trackerIn 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:

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:

 

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.

▶ Comment

JEEPLUG

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

Here is a utility class for the UART Plug:

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:

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

Sample output:

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.

▶ Comment

JEENODE, LOWPOWER, SENSORS

Battery life – refinementIn 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:

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:

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:

So now all we need to do is define a delay function which goes into real power

down mode for a little while:

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

Does all this make a difference? You betcha:

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:

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

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.

▶ View 4 Comments

JEENODE, LOWPOWER

Battery life estimationIn 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):

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:

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:

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:

Here’s the new blip (different scales):

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:

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

Does this make a difference? Definitely:

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:

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!

▶ View 3 Comments

JEENODE, JEEPLUG

PrototypingIn Hardware on Dec 17, 2009 at 00:01

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

… and these:

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

Jee Labs:

Since I’m too lazy to always dismantle and re-use everything – especially

POFs – I decided to get some more and also add these mini breadboards and

wire jumpers to the web shop.

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

timeless.

▶ View 1 Comment

JEENODE, LOWPOWER, SENSORS

Rooms sketch, reloadedIn 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:

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:

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:

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.

▶ Comment

Biodegradable bagsIn News on Dec 15, 2009 at 00:01

I recently ran out of the silvery electrostatic bags I’ve been using to package

JeeNode kits and other stuff. So for the next batch, I decided to use bags

which are biodegradable. They have a funny soft feeling to them and are

actually much more flexible:

These bags come with a “Farnell” ad printed on them (the supplier of these

bags) – so be it…

If you order stuff from the Jee Labs shop, you may also receive stuff packaged

in small clear plastic zip-lock bags. That’s because I have them lying around

anyway – they are re-used from the extension cables, which I received in

packages of 1-per-bag, whereas they are sent out as 5-per-bag. Since the

harm of having “consumed” these plastic bags has already been done, might

as well re-use them a second time…

FWIW, I feel pretty bad about adding so much packaging to a world full of junk

already. And being involved in quite a bit of transportation of all this stuff,

both by getting it here and by getting it out as packages to lots of

people. Atoms ain’t bits – that’s for sure!

All I can say is that I save up and batch my orders as much as possible, and

use as little and as light packaging as I think I can get away with.

▶ View 4 Comments

JEENODE

Better FS20 transmissionsIn Software on Dec 14, 2009 at 00:01

The RFM12B can be tricked into sending OOK (on-off-keying) signals – which

is also called ASK (amplitude shift keying), by doing exactly what the term

stands for: turning the transmitter on and off.

This has been used in several examples to control FS20 and KAKU remote

power switches – just search for these terms on this weblog in the box at the

bottom right of this page and you’ll get all the related posts.

The code I’ve been using for FS20 so far is:

As it turns out, the timing is not quite up to scratch. JGJ Veken drew my

attention to this in the forum and by sending in a couple of pictures, including

this one:

(Wow – great instrument, a 100 MHz Tektronix 2232 storage scope!)

A 0 bit comes out as 250/468 µS, and a 1 bit as 428/722 µS – pretty far off the

400/400 + 600/600 µS specs.

Here’s what we came up with after a few trials:

The end result is within a few percent of the target, well within spec – yippie!

I’ve updated the code in the RF12 examples (including RF12demo) in

the code repository and the ZIP file.

A similar tweak could probably be used for the KAKU signals, but these use a

lower rate of bit signaling, so the jitter is probably somewhat less important.

Update – the KAKU tweak has also been checked in, and the code has been

simplified a bit further.

▶ View 5 Comments

JEEPLUG

Serial dataloggerIn Software on Dec 13, 2009 at 00:01

Two new classes have been added to the Ports library:

MemoryPlug – provides access to the EEPROM(s) via PortI2C

MemoryStream – access one or more pages as a byte stream

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

a Blink Plug on port 3:

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

It collects all incoming data from the serial / USB port, as much as will fit on

the Memory Plug’s EEPROM chips that is (512 Kb if all four M24M01′s have

been installed).

Pressing button 1 (green LED on my setup) replays all stored data back to

that same serial port (this process is interrupted if anything is received).

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

stored so far.

Here is some sample output:

What I did was: 1) send “aaa”, 2) press button 2, 3) send “bbb”, 4) send

“ccc”, and 5) press button 1. As you can see, everything sent after pressing

button 2 is echoed back when button 1 is pressed.

The first line of the sample output illustrates random access to the Memory

Plug without using streams. Multiple memory chips will be addressed as if

they were one, i.e. the MemoryPlug class automatically selects the proper

0×50..0×70 I2C device address.

The public interface to these two classes is as follows:

You can define multiple streams at the same time on a single memory plug,

by picking different starting pages, and they can fill additional pages in

increasing (dir=1) or decreasing (dir=-1) order.

▶ Comment

JEEPLUG

BlinkPlug classIn Software on Dec 12, 2009 at 00:01

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

interface is:

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

This code demonstrates how to turn LEDs 1 and 2 on or off, and how to

access buttons 1 and 2 – pushed() will detect a transition from released to

pressed (with proper de-bouncing), whereas state() returns the current button

state (no de-bouncing logic).

There is some special logic in this class, because each LED/button pair on the

Blink Plug is connected to the same I/O line. Reading out the button requires

briefly turning the LED off, and the I/O line should never be set to drive the

output high. These details are conveniently hidden in the above class.

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

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

▶ Comment

ARDUINO, ISP, JEENODE

Re-flashing and ISPIn 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:

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 »

▶ View 4 Comments

ARDUINO, JEENODE

Uploading and FTDIIn 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:

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 »

▶ Comment

JEENODE, LOWPOWER, POF

Low power mode againIn AVR, Software on Dec 9, 2009 at 00:01

After yesterday’s Wireless Light Sensor was announced, I wanted to push a bit

more on the low-power front.

The POF described two simple tricks to get the power consumption from 19 to

3 mA, roughly. It turns out that a single extra step will get the idle

consumption down to some 20 µA. That doesn’t mean we’re getting a 15-fold

battery lifetime increase, because I’m measuring the current at idle time but

not accounting for the brief periods of high-current activity which also occur.

But it’s a major reduction in power consumption.

Here’s how … but this requires going a bit deeper into some low-level

AVR/ATmega chip features.

First, here are some utility functions we’re going to need:

The lowPower() routine disables the ADC subsystem and then enters the

specified low-power mode in the ATmega. Once it resumes, the ADC

subsystem setup will be restored to its previous state.

The loseSomeTime() does just what is says on the box: go into comatose

mode for a more-or-less controlled amount of time. The trick is to activate the

RFM12B watchdog just before passing out. This leads to larger power savings

than we would have with the ATmega’s watchdog, btw – and it’s easier to

implement.

The complication is that we risk losing all track of time. It’s a bit hard for an

ATmega to count heartbeats when its heart has stopped beating – not only

are there no beats, it’s also stripped of its counting abilities while in coma…

So instead, we estimate just how long we’ve been away from the watchdog

time chosen for the RFM12B, and correct the milliseconds timer built into the

Arduino. That’s what the “timer0_millis” stuff above is about. It will not be

quite as accurate as before, but that’s probably acceptable for a sensor node

like this one.

The last issue is that we need an indication about how long we can go

comatose. I’ve added a “remaining()” member to the MilliTimer class to

obtain this information.

Now, all the pieces are in place to change the code in the Wireless Light

Sensor from this:

.. to this:

So there you have it. Most of the time between each measurement once a

second, the node will now go into a very low-power mode of around 20 µA. My

current measurement tools are inadequate to measure exactly what amount

of charge is being consumed, which is what this is really about. So accurate

battery lifetime calculations are not yet possible – but I expect it to be in the

order of months now.

I’ve updated the Wireless Light sensor POF to point to this post and include

this trick.

▶ Comment

JEENODE, POF, SENSORS

Wireless Light Sensor – POF 71In 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:

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

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

▶ View 2 Comments

JEENODE

JeeNode power pinsIn 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:

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.

▶ View 2 Comments

JEENODE

Building the JeeNode v4In 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:

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:

Turn the board around and solder the leads:

(continued…) Read the rest of this entry »

▶ View 4 Comments

JEENODE

FTDI Reset SupressorIn 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”:

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:

And here is an action shot:

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:

▶ View 2 Comments

JEENODE, JEEPLUG

JeeNode clockIn Hardware, Software on Dec 4, 2009 at 00:01

To follow up on a recent post, here is the same real time clock demo using a

JeeNode + USB BUB instead of an Arduino + Plug Shield:

(instead of JeeNode + USB BUB, the new JeeNode NoRF or a JeeNode USB

could also have been used)

I chose to use two different ports for RTC and LCD, but these could just as

easily have been daisy-chained on a single port.

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

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.

▶ Comment

JEEPLUG, SENSORS

Updated Thermo Plug

In Hardware on Dec 3, 2009 at 00:01

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

This plug supports either a thermocouple, an NTC, or a 1-wire temp sensor on

the AIO line, and either a buzzer or a relay on the DIO line. It does not use

I2C.

The connections of the AD597 thermocouple readout chip are now correct,

and there’s a new 4.7 kΩ pull-up resistor option when using the 1-wire

interface.

I’m still looking for a good way to attach the K-type thermocouple (soldering

is not a good option with those metals), and am considering adding this plug

as kit with AD597, thermocouple, buzzer, and the rest of the components to

the shop. This is the combination I’m using in my reflow oven / grill controller.

The bare pcb is already available.

▶ Comment

JEENODE

Easy transmissionsIn Software on Dec 2, 2009 at 00:01

I’ve extended the RF12 driver with three “rf12_easy…()” functions, which

should make it easier to implement nodes which need to periodically report

some data to a central JeeNode or JeeLink.

Here’s a complete sketch which sends the current value of the millisecond

counter over wireless:

The above sketch compiles to roughly 3 Kb of code. Some extra notes:

The “rf12_initialize(…)” call sets this node up as node “W” (23), using 868

MHz, and using group 5.

The “rf12_easyInit(5)” call sets up the easy transmission system, with

data to be sent every 5 seconds.

The “rf12_easyPoll()” call needs to be called often – at least once per

millisecond or so would be best.

The “rf12_easySend(…)” call passes the data to be sent, i.e. pointer to

that data and the number of bytes.

There’s quite a bit of additional logic hidden behind these three calls:

Even if called often, new data will only be sent at most every 5 seconds,

as requested.

Lost and damaged packets will automatically be resent, with up to 8

retries.

Packets are only sent if the data has changed.

To force data to be re-sent even if unchanged, call “rf12_easySend(0,0)”.

Here is some output from a capture utility I use:

As you can see, the 4-byte millisecond value is only sent once, every 5

seconds.

The argument to rf12_easyInit() is in seconds, and can be anything from 1 to

255 seconds. In addition, using zero as argument means: send as often as

possible. For the 815 MHz band this depends on the number of data bytes, to

enforce the “1% max bandwidth rule”. The actual rate will range from about 7

packets per second for 1 byte of data, to about 1 packet per second for 66

bytes of data. For the 433 and 915 MHz frequency bands, the maximum rate

is fixed at 10 packets per second, regardless of the data size.

I’m currently using a simple algorithm which tries to resend at 1-second

interfals when packets are lost or damaged. This can be extended to

“exponential back-off with randomization” later on. My first concern is a

simple-but-robust first implementation.

There is still an issue with the current RF12 driver, which can cause duplicate

packets to arrive at the destination (an extra sequence bit needs to be added

to each packet to detect loss of acknowledgement packets – this change

affects the protocol and requires re-flashing all the current nodes, which I

don’t want to do just yet). Such duplicate packets can easily be filtered out at

the destination. There is also an issue with picking up the wrong ack, this

probably only affects nodes at the limit of their range (i.e. when not all the

nodes receive the same things).

No changes were made to the RF12 driver core, these calls are purely a layer

on top. They use broadcasting to get data from different nodes to a single

central node, and currently there is no way to combine this with reception of

data coming towards a node. But as the above example shows, for the

specific scenario of sending out data these calls should simplify the

development of remote nodes a fair bit.

The new code is now in the subversion repository, as well as in

the RF12.zip archive.

Update – documentation for these new calls has been added to the Café

docs.

▶ Comment

POF

Hello World – POF 52In AVR, Hardware, Software on Dec 1, 2009 at 00:01

The first Project On Foam is inevitably a blinking LED:

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