Here’s a fun gimmick from DealExtreme:
It won’t make you look sharp, but these glasses are pretty effective. There’s a built-in white LED with battery (that’s the big black case) which isn’t that great, but it comes with three plastic lenses of varying strength.
Really works well, even if not quite for a neurosurgeon ;)
This’ll be great for some SMD stuff I’d like to explore.
Ok, let’s finish off what I started yesterday – here are yet more tiny AVR boards:
From left to right:
Here is the previous line-up again for comparison:
See yesterday’s page for a description of what is what.
If you look closely, you’ll see that yesterday I used a JeeNode v1 board.
Here’s another comparison of little AVR-based boards:
From left to right:
Unfortunately, I forgot to show the RBBB (Real Bare Bones Board), and the new Strobit unit (also shown here) – they both deserve a place in this line-up.
These little boards are not entirely equivalent, but all of them are great for AVR-based fun DIY projects.
There is an interesting site in the UK called Dynamic Demand. The idea is to let the 50 Hz power-line frequency vary slightly to indicate the current load of the entire grid. Simple line-monitors can then track this locally and respond by voluntarily shutting down some power consumers (i.e. turning off freezers, A/C units, or electric heaters for a little while). With a bit of collaboration, the grid would then presumably recover as the load eases off – and overcome these demand peaks. I love the idea, it’s so beautifully simple.
The Dynamic Demand site also has a page showing the current frequency online, here’s a snapshot:
I don’t think this mechanism is being used – or even considered? – in the Netherlands but I couldn’t resist setting up a JeeNode to monitor the frequency myself. The sketch:
What it does is measure elapsed microseconds between 100 transitions of its input signal against the 1.1V bandgap reference voltage. That’s 50 ups and 50 downs, which should take 1 second.
The AIO pin of port 1 is connected to a rectified but unregulated AC voltage, coming from a 17 VAC power brick through a diode plus 1:10 voltage divider. The signal looks as follows:
And here’s some sample output:
Note that for stable and repeatable results, the JeeNode will need to be fitted with a crystal as clock.
The accumulation over 100 transitions is a simple way to average all the pulse durations. Most of the code then tries to present a nice result, with sufficient accuracy to display minor variations.
Nice and tidy.
Here’s a fun new project, the JeeBot:
A little platform with two continuous-rotation servos, a JeeNode, and a (4x AA) battery pack. It’s all mounted and fixed together with what I had lying around: strong epoxy-based perf-board and lots of fasteners.
The electronics isn’t “quite finished” as you can see:
The JeeNode can be removed. There’s a small slide switch on the side to turn on power.
First task would be to get this thing rolling and steering – adding a small coaster of some sort on the right side under the batteries, to keep this thing off the floor.
The more ambitious plan is to make this thing stand upright and self-balance… who knows, one day, maybe it’ll be able to walk roll on two feet wheels?
Here are four very similar wireless AVR-powered solutions side-by-side:
From left to right:
The XBee has more software on board, giving it more functionality. The CPM module, which is only marginally bigger than a DIL-14 chip – including antenna! – does not come with software loaded AFAIK, but there is open source software available for it. The middle two boards are compatible with Arduino IDE “sketches” and support the RF12 driver library by yours truly.
Here’s the LISY300AL gyro sensor, mounted on a Sparkfun breakout board:
The sensor is not extremely sensitive, but works at 3.3 V. It has a single analog output, so readout is trivial:
Sample output:
The readout changes as this setup is rotated around the horizontal plane. Looks like the self-test (pin 5) to ground can be omitted, btw.
One (tiny!) step closer to a self-balancing bot…
Update – the Segwii website is a fantastic resource on how to accomplish self-balancing in a fairly similar setup.
Here’s some fun with a servo:
A slider drives the two servos in opposite directions, so you can make this thing turn on the spot.
Here’s the sketch:
Had to use SoftwareServo instead of the Servo library which comes with Arduino IDE 0015 – which didn’t work for me.
Turns out that only pulses from 1.4 to 1.6 msec actually have any effect on the speed of the servos, the rest of the 1.0 .. 2.0 msec range just makes them run at full speed. These ara Parallax (Futaba) Continuous Rotation Servos.
Note that the servos are driven from the PWR line, i.e. the full 5V – but the servo pulses are 3.3V, like the rest of the JeeNode.
It’d be nice to use a Wii Nunchuk controller as input. Even more fun would be an accelerometer / gyro combo to turn this thing into a self-balancing bot …
The RF12 driver has been extended to support power down as well as wake-up.
This example uses the RFM12B wake-up timer to generate an interrupt in about 1 second, then powers down, then leaves the radio off once power is back up:
That last call is important, because otherwise if the system happens to power up due to some other trigger, then the wake-up interrupt may happen later and cause problems. This way, regardless of why the system came back up, we make sure that the RFM12B wake-up interrupt stays off. The radio is still off at this point.
The argument to rf12_sleep() is a time value, in units of 32 ms. The maximum value is 127, i.e. 4 about seconds between wake-ups. If you need longer sleep times, change the logic to go back to sleep right away until the proper amount of time has elapsed.
To turn the radio back on, use “rf12_sleep(-1)” to start listening to packets again after the next rf12_recvDone() poll. Since the RFM12B consumes a fair amount of power, it’s best to wait with this right until you’re ready to send out a packet.
Here is the new code, which is now included in the updated RF12 driver:
The RF12 driver software is available over here or as ZIP, this is an Arduino-compatible library.
Stephen Eaton, the guy behind Strobit, very generously sent me two of his boards and prototype boards:
These units run at 3.3V by powering them off a corresponding USB interface, such as the boards from Modern Device and SparkFun. And it’s fully compatible with the RF12 driver and the RF12demo sketch – I’ve run a successful test with it. This particular unit has no crystal, so it’s running off its internal 8 MHz RC clock. Works fine, just treat it as an Arduino LilyPad in the IDE.
As you can probably see these well-designed boards are slightly shorter and wider than a JeeNode. Very neat to see the SMD stuff on there – clearly lots of room left. Note that the board doesn’t have a voltage regulator – it’s intended to run straight off a CR123 battery, for which connections exist on the back.
A really neat trick is that the holes for the header pins are slightly staggered. This means that when you push in a header, it fits snugly even before soldering – a huge convenience, considering how soldering those headers is always a bit tricky on the JeeNode, especially with 4-pin headers.
Lots of attention to detail, such as the silkscreen text where you can mark which frequency band module has been used. And two (pretty bright) red leds.
Another neat feature is the prototype board (“shield” in DuinoSpeak):
Lots of room for some custom stuff. Room for 4 through-hole LEDs + resistors, a reset button, and an ISP connector. This could also be used to mount a LDO voltage regulator. Given that the Strobit board itself is so flat, I’m inclined to place this shield underneath to keep total height to a minimum – but that’s just me, and would not be optimal while trying out stuff.
Anyway: congratulations, Stephen – I’ll report further when I get to do more with these units.
The JeeNode Pulse hasn’t fully materialized yet – it’s the configuration I’d like to use around the house. Here’s a new configuration:
PIR and LDR on port 1, BMP085 on port 2, and SHT11 on port 3. There’s obviously no point in having a BMP085 sensor in more than one node, but for now it’s easy to leave it in for testing.
Different PIR sensor (from ELV). That sensor draws 30..40 µA – this matters for battery-operated use because it’ll be permanently on.
Here’s the main part of a first sketch, using the new power-down logic:
The code compiles to around 9 Kb. This includes floating point calculations in the SHT11 driver and the serial port reporting, both of which could be jettisoned later.
Sample output:
The values are:
That last value is way too high for battery use – this code is spending 0.316 seconds collecting sensor data… in high power mode!
Breaking down the time spent, it looks like the BMP085 takes 2x 7 ms, and the SHT11 takes 2x 70 ms. The odd thing is that the SHT11 seems to take 300 ms when taking both temperature and humidity readings.
The good news is that the power-down current consumption of this setup is around 40 µA.
What needs to be done, is to spend the waiting time in these sensor read-out periods in power-down mode as well. The BMP085 driver already supports low-power readout by splitting the start and end parts of the driver, so that the waiting time can be handled in the calling loop. The SHT11 driver will needs to be adjusted to allow a similar approach.
With a bit of luck, only a millisecond or two will have to be spent in high-power (10 mA, haha!) mode. Then perhaps 2..3 milliseconds with the RFM12B radio active, and that should be it.
With a 15..60 second reporting period, the node would stay almost entirely in power-down mode. An average power consumption of under 100 µA total should be feasible – giving well over a year of service on 3 standard AAA batteries.
But that’s not all. To effectively use the PIR module, the code must be set up to handle motion-detect triggers at any time, also in power down mode. One approach would be to wake up (i.e. use a pin change interrupt), note the change and power back down. A refinement would be to “preempt” and start transmitting right away when motion is first detected – and then re-schedule future transmissions so the average reporting period remains the same. This makes the central JeeHub aware instantly of motion detected by the various nodes.
Just came across the eKo range of commercial products by Crossbow. Interesting how the eKo and Jee-Node/-Hub/-Mon designs almost exactly overlap – well, seen from a large distance anyway.
Their “JeeNode”:
Their “JeeHub”:
Their Linux server hardware and software:
Of course the eKo products are a million times more mature and advanced than the Jee-stuff which isn’t even a product, but still…
After several months tinkering with the JeeNode v2 boards, I’m starting to make a list of things I’d like to change for a future design.
What I’d like to keep:
What I’d like to change:
This could perhaps become the layout:
Not 100% sure about the SPI/ISP and I2C/PWR pin headers – though I’m inclined to keep them, somehow.
No idea when or even whether this ever materializes, just some thoughts.
Here is an experiment to try and (ab)use the RFM12B module for OOK reception, such as sent out by a FS20 remote control. First the complete sketch:
The interesting bit is that this appears to work – the LED flashes when I press a button on the FS20 remote:
Since the signal is made to come out on the AIO port 1 pin (A0), this whole unit can be plugged into a second JeeNode running the OOK decoding code from an earlier post. Like this:
The reason for using two JeeNodes is that the one receiving the OOK signal is 100% tied up in a loop polling the status register. No problem – we simply upgrade to a dual-core setup :)
Unfortunately, the combination isn’t working yet. I’ll need to use the scope or logic analyzer to figure out what’s going on. Perhaps the RFM12B’s RSSI circuit is not fast enough to faithfully reproduce OOK transitions.
Oh, well.
While surfing around on the web, I came across the FreeRouting website. It lets you grab a Java app which does auto-routing. It takes time, but it is quite advanced.
One feature really caught my attention: the ability to take an EAGLE .brd file, auto-route (or just optimize) it, and then bring the results back into EAGLE. It’s all documented here.
Here’s what it did to the JeeNode v2 design (jee-pcb-003.brd), which was routed 100% by EAGLE (after quite a bit of tweaking to make it succeed).
Before:
After:
(there are some discrepancies between the two, due to some hidden ground planes)
I haven’t checked it much, nor applied any DRC’s, but if it’s all correct then that’s 9 via’s instead of 26 – not to mention the considerably simpler traces. Impressive!
Let’s get that JeeNode power consumption down …
The no-savings baseline from two days back was 10 mA, with a few simple measures getting it down to 1.31 mA, i.e. waiting in idle mode with the pre-scaler set to 64 and turning the RFM12B clock off.
It turns out that the ATmega328 is quite a bit more power efficient in that mode, the same sketch consumes 0.67 mA, i.e. half that of an ATmega168. Great – that’s an easy gain. Unfortunately it doesn’t carry over as much to power down mode: 125 µA versus 137 µA. There is still some unexplained power use there – maybe some of the circuits need to be turned off explicitly, or some more output pins floated.
Anyway, the next idea to go beyond 1.31 mA is to use the watchdog timer for idling away in power down mode. The basic code structure will be as follows:
Ooh, wait – turns out that there is a simpler way, which doesn’t require changing the main application logic after all. We can let the watchdog generate an interrupt without resetting the system. Here’s the code I ended up with after some experimentation:
Note the added dummy watchdog interrupt routine. Without it, the code apparently enters a nasty infinite loop when the watchdog fires, which is hard to get out of – even after a hardware reset.
Usage: 139 µA while waiting – 99% of the time. Great.
The code can actually be streamlined a bit – simply leave the watchdog running to pull the processor out of power down mode once a second:
But there’s more. The ADC can be disabled to reduce the power drain even further:
Now usage drops to 24 µA while waiting. Cool.
One last change is to disable the brown-out detection, which in turn disables the internal voltage reference. Changing the high fuse from 0xDD to 0xDF drops total power usage to a diminutive 6.8 µA. Perfect.
So there you have it – 1500 times less power usage!
Update – see the discussion in this post for a change which gets this down to 3.7 µA …
Update 2 – changed the low fuse from 0xFF to 0xEE, i.e. 64 µs start-up i.s.o. 1+64 ms (ok for resonator, not ok for a crystal). This will help get the power up duration down once I start looking into it.
Yesterday’s code has several bugs:
As already mentioned, a delay is needed to let the serial data leave the USART before the pre-scaler change messes up the clock and baudrate. But there are also two other serious problems:
Both bugs can be fixed by carefully rewriting the code:
The differences are subtle, but essential. Without it, the loop will get stuck within just a few seconds of starting the sketch. With the above fixes it’ll run properly forever… I think.
Ok, first step in lowering JeeNode power consumption is to establish a baseline.
Here is the original code, the first few lines of the loop that is – the rest is the actual sensor readout and calculations, which take about 10 milliseconds:
Usage: 9.80 mA (slightly different from yesterday’s post, hooked up to USB from now on).
First change is to make the delay loop explicit:
Usage: 10.05 mA – no idea why it’s slightly higher. Anyway 10 mA will be used as baseline – this is the current drawn before any power-saving measures are introduced.
First step: lower power use by putting the processor in idle mode while it’s waiting for the next readout time. Included “avr/sleep.h” and changed the loop to be as follows:
Usage: 5.58 mA – it works, cool!
Next idea is to lower the system frequency, but only while waiting – so that readout, processing, and serial I/O remain unaffected:
Usage: 1.99 mA – whee! But there is a small gotcha – the system now goes into slow mode before the serial port has finished transmitting. A “delay(3)” at the end (or start!) of the loop is needed to fix this.
For comparison: with just the pre-scaler and no idle mode, usage is 2.15 mA – so the bulk of the savings comes from slowing down the system clock. Idle mode saves roughly 10% at lower frequencies.
One more important saving is possible due to the onboard RFM12B radio module, which powers up with its 10 MHz crystal clock running. Adding a bit more code to access the radio and disable its clock lowers power usage from 1.99 mA to 1.31 mA.
So these three simple measures combined already lead to a 7.5-fold power reduction: “waiting” a bit more carefully and turning off the RFM12B. All without affecting the main application code in any way.
As for the bottom line: putting the processor in power down (from which this code won’t ever wake up) uses 137 µA – and removing the MPU chip brings it to 17 µA. Note that with 140 µA average usage, a JeeNode can run for two years on 3 standard AA batteries.
It ‘s possible to reduce the power consumption from 1.31 mA to the µA range by powering down the processor and using the watchdog timer to wake it up – but that requires another set of changes to code and fuses – stay tuned…
Update – see this more recent post for additional details.
This contraption:
… when connected as follows:
… makes it easy to measure the supply current, with a BMP085 pressure sensor hooked up in this case:
Just under 10 milliamps, as you can see. That’s just the JeeNode running the BMP085 demo at 16 MHz, sending a new reading over the serial port every second. The RF12 module has not been turned on.
If the JeeNode is to be used for a WSN, then it will have to get its power consumption down. Way down, in fact…
The title of this post can be interpreted in two ways, both accurate: 1) the Bubba Two NAS from Excito was my back-up server for the MMnet1001 module, and 2) that Bubba box is now my main JeeMon server and back in the air with all the electricity / gas / weather monitoring working again, as well as the Pachube and Bwired feeds.
I will probably stick to the Bubba from now on. It’s running Debian Etch Linux, and there’s a JeeMon runtime for it so the switch-over was trivial.
This NAS box consumes about 4 watt, which is less than the specs because it has been modded to use a 2.5″ SATA disk instead of the standard 3.5″ ones they normally ship. It’s also a 300+ Gb file server which has been running various periodic tasks for almost a year now. There’s in fact much more disk storage in the form of 3 additional USB disks, but these are normally powered down (via a KAKU switch).
The electricity / gas metering monitor – which has been running for months – stopped working:
It just flat-lined, dead, nada. Power cycling everything and re-flashing the meter node did not fix it. I don’t see any packets from the meter node on the air when listening via an independent JeeNode.
The only packets right now are from a JeeNode pulse upstairs, which keeps resending – indicating that the central JeeHub isn’t replying with an ack. Weird.
I’ve adjusted all nodes to explicitly use netgroup 0x50, since there have been changes to the RF12 default netgroup and CRC calculation. Just to rule out a potential issue.
Still no go. I’m flabbergasted.
Update – uh, oh… the JeeHub 3.3V regulator is way too hot. It’s shutting down from time to time. Not good!
Time to switch to plan B – a JeeNode used as packet receiver connected to my “Bubba II” NAS. It’s been running all the time to collect weather data from the KS300 anyway. Still no electricity / gas metering data coming in, but at least all the remaining JeeNode and KS300/FS20 data gets logged again.
Update 2 – first there was one problem (JeeHub failing), then I created another one by re-flashing the metering JeeNode with the wrong node ID – doh! Anyway, metering data is coming in again now. Still don’t know why / how the JeeHub broke, but it was up for a hardware revision anyway…
Following up on yesterday’s new serial I/O layer, implemented on top of the RF12 driver, here’s another demo using the “<<” and “>>” operators to send data across. First the sample code:
Then the sample output:
(these are slightly older screenshots, not yet using “rf12_config()”)
The output is a bit mixed up because the nodes were not reset at the same time, but you can see the data coming in on both nodes. These are independent bi-directional transmissions, even though in this case similar data is being sent since the same demo is running on both nodes.
As with the “rf12serial” demo, there are still some serious limitations with this – I still need to debug and add more flow-/congestion-control logic in this new implementation (the code is in “RF12sio.cpp” inside the RF12 library).
Much of this sort of logic relies on timers: the “RF12sio.h” header defines a simple millisecond timer which is also available for general use.
The new RF12 code is starting to work. I’ve added it to the RF12 library, along with a demo which sends characters across the wireless link in both directions. Here’s the code:
And here’s some sample output on two terminal screens:
Other side (the “transmittee” text is my typo):
There are still major flaws in the code:
But it’s a start!
The “Teensy” by PJRC is a tiny AVR processor with embedded USB device port:
It’s similar but not quite identical to an ATmega168 Arduino (no analog inputs, no I2C, and some other diffs). But the basics are the same, and you can even adapt the Arduino IDE to feed it sketches.
Now there’s a “Teensy++” with 64 Kb flash, 4 Kb RAM / EEPROM, and analog inputs and I2C:
Plenty of oomph for much larger applications!
It’s still not quite what I’m after though, since these operate at 5V (although the Teensy++ can be made to run at 3.3V that only works when not tied to a USB port). I’ve all but abandoned 5V logic, because the RFM12B wireless modules require < 3.8V to operate and because battery power is simpler when in the 3 .. 4.5 V range.
Still, these look like nice little boards, and at a good price.
It’s becoming a bit tedious to set up and manage JeeNodes, each with their own RF12 configuration. Prompted by a recent request, I’ve created what I think is a much more practical configuration system using some of the ATmega’s built-in EEPROM.
The basic idea is to split the configuration and the setup code. The “RF12demo” sketch which is part of the RF12 library has been extended into a general EEPROM configuration utility. Here’s its new startup screen:
So now you can type commands on the serial port to adjust settings. These are stored in EEPROM along with a description string and a 16-bit CRC checksum. When launched later on, the last settings get re-used so this becomes a set-and-forget thing.
What’s more important though, is that the RF12 library has been extended with a new “rf12_config()” call which you can use instead of “rf12_initialize(…)”. It does a couple of things:
As a result, it’s now a lot simpler to set up a sketch with RF12 communication. All you need to do is upload and run the RF12demo once to configure things, then upload your own sketch and use “rf12_config()” to re-use the same configuration.
Here’s an example / skeleton:
The output from this sketch is:
It’s a bit cryptic to keep the code overhead small, but you can see that I configured this unit to act as node “Z” (i.e. 26), using network group 212, and operating in the 433 MHz band.
The RF12 configuration data is stored in EEPROM addresses 0x20..0x3F (this can be changed in “RF12.h” if it interferes with your own EEPROM use).
Now that the RFM12 is working, here’s the list of differences between RFM12 and RFM12B I’ve come across:
More differences, found by Reinhard Max:
Here is the back of the module, RFM12 on the left, RFM12B on the right:
(these also happen to be for different frequency bands, as you can see)
And here is the front view, with RFM12 on the right and RFM12B on the left this time:
The RFM12 unit on the right has a pull-up resistor added on top – note also the exposed pads at the top.
Note how the alignment of the solder pads on the JeeNode PCB is a bit off – these are v1 PCB’s, the v2 PCB’s have better alignment.
Had a wonderful time in Barecelona, admiring Gaudi’s fantastic architecture such as the roof of “La Pedrera”:
You might not have noticed my absence since the daily Jee Labs weblog updates went on as usual, based on posts which were prepared in advance.
Anyway, it’s good to be back …
The current JeeHub includes a MMnet1001 Linux module, which is great for running JeeMon. But for an even more basic always-on system, it’s possible to forego the Linux part – here’s the idea:
The whole thing is powered from USB, which must remain on permanently. There is no need for the attached computer to be on all the time, because incoming data can be saved into the on-board DataFlash memory. Depending on data volume and memory size, it ought to be possible to have a few days of autonomy.
The 433 and 868 MHz OOK receivers make this thing suitable for receiving weather data from off-the-shelf components, as well as responding to KAKU and FS20 remotes (and others like them). And since the RFM12B is so versatile, it can also send out 433 and 868 MHz OOK commands to those systems.
One thing I forgot to add in the above diagram, is a DCF77 receiver – or perhaps using a crystal or RTC. As has been mentioned a few times, the JeeHub needs to have a fairly accurate sense of time to do its main job of collecting real-time readings.
Only a minimal number of signals/ports are needed for the main tasks, there are several pins left to connect a few extra sensors.
The main bottleneck will probably be the amount of code needed to make such a JeeHub Lite perform basic home automation tasks. An Atmega328 might help a bit.
The normal monitoring and reporting work is still done with JeeMon, but now running on the attached PC (which can be Windows, Mac OS X, Linux, whatever). In such a configuration JeeMon must catch-up and extract saved data from the DataFlash in the JeeNode whenever it is launched.
When you have a hammer, everything looks like a nail. Or in my case, a potential enclosure for JeeNodes:
This adjustable enclosure came with some small relays shipped to me a while back.
Now if only I could figure out a way to make JeeNodes run a while on these batteries:
That’s a 3.7 V @ 100 mAh Lithium cell. Three months endurance would be the minimum needed to make this practical, that’s about 40 µA average power draw (the RFM12B draws 30 µA in sleep mode, though that could be lowered tenfold by connecting it to a switchable regulator such as the LP3985). Hm, might actually be feasible.
Got myself a new soldering station a few weeks ago:
The intention was to replace my old (but analog temperature-controlled) 15W weller, which is a bit weak. This unit is 45W and shows when the iron is ready.
Unfortunately, it broke down after a just a few times… I suspect that the heating coil is blown: the temperature stays at 25°C no matter what. Bummer.
Oh well, that should teach me to know buy dirt cheap bargains – this thing was just €29 – and now I’m stuck with a heavy piece junk plastic. I’m not tempted to replace the iron, it’d probably break again quickly. Maybe I can at least salvage the 24V @ 2A transformer in there. Two of those would make a nice isolation transformer, nice to have for experimenting with 220V AC power control and sensing.
Found yet another passive infrared module for around €10, by ELV:
Hooked up to port 1 of a JeeNode, and shown here with the USB “BUB” interface by Modern Device. Note that this uses a JeeNode with 6-pin port connectors, since the PIR module requires at least 5V. The output is open-collector, and therefore compatible with the 3.3V levels expected by the JeeNode (using the internal pull-up resistor).
Sample output, from a slightly adjusted version of the “pir_demo” example sketch which is in the Ports library:
Range and sensitivity seem to be ok. The signal is more jittery that with the ePIR and Parallax modules, it will have to be de-bounced it a bit in real-world use.