Computing stuff tied to the physical world

Archive for October 2009

,

Room Board update

In Hardware on Oct 31, 2009 at 00:01

Here is the latest version of the Room Board, just in:

DSC_0711.jpg

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

DSC_0712.jpg

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

DSC_0716.jpg

Both can be used with the latest version of the rooms sketch.

But… if look closely at that second board, you’ll see that I still got it wrong!

The DS18B20 temperature sensor is labeled the wrong way around, and must be mounted as follows:

DSC_0717.jpg

Drat – same mistake as last time!

And now I’ve also figured out how this happened. Here is the pinout shown on the Dallas Semiconductor / Maxim data sheet:

Screen shot 2009-10-30 at 14.43.29.png

B o t t o m  view. Doh!

I’m going to declare victory anyway, and call these boards final. Even though this issue will have to be documented and spelled out everywhere to prevent people from falling into this trap. I have 100 room boards, and I simply don’t want to trash them and wait another 3 weeks. Most people will probably use the SHT11 sensor anyway, where this issue is irrelevant.

Available in the shop now. Foul-ups happen, so be it. End of story.

,

More room sensors

In Hardware on Oct 30, 2009 at 00:01

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

DSC_0674.jpg

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

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

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

DSC_0675.jpg

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

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

,

Updated RF12demo

In AVR, Software on Oct 29, 2009 at 00:01

The RF12demo software which comes pre-loaded on all JeeNodes and JeeLinks has been extended a bit:

Picture 1.png

The new commands are:

  • l – to turn the activity LED on or off, if present
  • f – send a FS20 command on the 868 MHz band
  • k – send a KAKU command on the 434 MHz band

The new FS20 and KAKU commands were added so that a JeeLink can be used out-of-the-box to control the commercially available remote switches of these types. The updated demo is included with all new JeeNodes and JeeLinks from now on.

For example, to turn on channel 1 of a FS20 unit with housecode 0x1234, you can type in “18,52,1,17f” – i.e. the house code in bytes, the channel, and 17, which is the “on” command. Likewise, to turn on channel 1 of group B on KAKU, type “2,1,1k”.

The KAKU transmission range is not very high because the RFM12B radio used is tuned for the 868 MHz band, but even more so because the attached wire antenna is completely wrong for use at 434 MHz. If you want to use this for controlling KAKU devices and don’t get enough range, try extending the antenna wire to around 17 cm, i.e. double its current length. You can just attach an extra piece of wire to the end.

Which – unfortunately – is going to substantially reduce the range at 868 Mhz… so if you really want to use both frequency bands, you’ll have to use two JeeNodes or JeeLinks, each with their own properly sized wire antennas.

For more info about FS20, see these posts on the weblog. For KAKU, see these.


New UART plug

In Hardware on Oct 28, 2009 at 00:01

The revised UART plug now works as expected:

DSC_0692.jpg

This board has been reworked to use a 3.68 MHz resonator. Two solder jumpers allow using several UARTs on a single I2C bus.

Since the UART chips include 2x 64 bytes of buffering for transmit and receive data, and since they can be set to do hardware and software flow-control, this is quite an effective way to offload work from an ATmega328, once you need more than its single on-chip serial port.

See a previous post for sample code.

Documentation can be found at https://jeelabs.org/up1 – the plug code (“up1” – has to be lowercase) at the end of this URL will redirect to the corresponding page in the documentation tree.

The BC1, BP1, EP1, MP1, PB1, and RP1 plugs are now also available. Nothing really exciting to report about them, I’m still waiting for a couple of more interesting ones such as the LCD Plug and the updated Room Board and Thermo Plug.

,

Shop news

In News on Oct 27, 2009 at 00:01

Big news today for people from the US, Canada, Australia, and other parts of the world where the 915 MHz band is available for use with JeeNodes.

Paul Badger of Modern Device has added JeeNodes and a few other items to his shop – check it out:

ModevcoLogoLong.png

Please be patient as Paul gets all the necessary bits and pieces ready, but this means you’ll be able to get Jee stuff with US prices and (much) lower shipping costs if you live on the other side of the big pond.

Behind the scenes, Paul Badger has been actively involved in the Jee Labs since early this year. I’m very happy that at last he’ll also be able to get involved with actual shipments.

Things are still evolving quite rapidly here w.r.t. plugs, so we’re still figuring how and when to make all the different plugs available, boards, pre-assembled, etc. The intention is to eventually provide all the same options as in the European Jee Labs Shop, but it may take some time to get there. It’s going to be a bit tricky to get it right with such a moving target…

This change also means that I’m no longer offering 915 MHz units from Europe – just 868 MHz.

On the plugs front there is some good news as well, as final versions of the Blink / Expander / Memory / RTC / UART plugs and the Proto Board are set to arrive here tomorrow. I’ll be updating the various bits and pieces and pictures once they come in, of course.

The astute reader will notice that there are still a few items missing. I’m expecting a few more boards by the end of the week, but there are also some delays due to a production issue which requires some boards to be re-made. That means some boards won’t be in for another two weeks and there’s little I can do about it :(

Not to mention the fact that stupid little mistakes with boards seem to have become a habit of mine… each mistake leads to a new round trip to the pcb shop, i.e. 3 weeks on average. Which is why I’m juggling as many overlapping release cycles as I can – while trying not to make yet more mistakes!

Next month all this frantic shop stuff should be over, and I hope to get back to some “real” lab work, with more s/w coding and finishing up some of the numerous projects cluttering up my desk… eh, I mean my entire office!


Four generations

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

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

DSC_0581.jpg

Here is the back side of each of them:

DSC_0582.jpg

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

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

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

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

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

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

,

Happy birthday, Jee!

In News on Oct 25, 2009 at 00:01

Today, exactly one year ago, I discovered the Arduino platform and decided to explore it and write about my adventures. That’s when this weblog started. Within a month, it became a daily weblog – as it still is today.

Early 2009, the JeeNode was born. Like every youngster, it has kept me very busy ever since, deep into the night at times. Fortunately youngsters grow up, eventually …

So today, I’d like to announce the availability of the JeeNode v4 – the fourth iteration of the JeeNode:

DSC_0617.jpg

The one thing you’ll notice (other than the by now “standard” blue-and-gold design) is the changed PWR/I2C header, left of the ATmega chip. It now includes the RX and TX pins, and has moved to a new location, closer to the port headers. The 4 inner pins are still the same. And it’s now called the PWR/SER/I2C (PSI) header.

The back of the JeeNode v4 has changed a lot more:

DSC_0619.jpg

Text! Lots of clearly readable labels to indicate what all the ports and pins are. And on the far right three “check-boxes” to mark which type of radio is on the board. The white area in the middle is for writing down your own info, such as the node ID assigned to this unit – or which sketch it is running. See the updated documentation.

The JeeNode v4 replaces the JeeNode v3 as of today. Le roi est mort, vive le roi!

As you may have seen, the new JeeLink v2 USB stick was announced a few days ago.

Along with these two, I’d also like to announce that a new JeeNode USB v2 prototype is currently on its way. It has exactly the same size and layout as the JeeNode v4, but with the FTDI pins replaced by a mini-USB socket (same as what’s used in most digital cameras). The JeeNode USB v2 replaces the JeeLink v1, using a different USB connector. Like the JeeLink, it is built with SMT components:

Picture 2.png

The JeeNode USB and the JeeLink are USB devices, and have three LEDs: green/red for RX/TX activity on the USB port, respectively, and a blue LED which could be used as wireless activity indicator. The base JeeNode has no LEDs, but it’s very easy to add an activity LED between SPI/ISP header pins 2 and 8.

The two JeeNodes will of course continue to work just fine with all the plugs, but they are also a particularly nice match for the new Proto Board:

DSC_0591.jpg

(shown here half-inserted on a JeeNode v4 for clarity)

I’d like to point out that the Proto Plug gives access to 18 of the ATmega328’s 20 I/O pins. Only two pins are dedicated to the on-board wireless radio module (INT0 and SS). To put it differently: these JeeNodes add ports as a modular way to extend and use the ATmega I/O capabilities, but their use is entirely optional: you can simply ignore all the extra supply and ground pins if you don’t need them. And you can run totally unmodified Arduino sketches on the JeeNodes and JeeLink.

So there you have it. One year old, yet already grown up: a nice little range of modules which combine low-cost wireless with an Arduino-compatible design, using a modular architecture for tying stuff to the physical world…

I’m very proud to see how far Jee Labs has come in one year, and can’t wait to put these building blocks to new uses and to see what others figure out to do with all this.

,

Assembly service

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

It’s time to try something new!

Sometimes, this DIY electronics stuff can be a bit daunting. Maybe you’ve never soldered microprocessor circuits before. Or maybe you’re worried about that RFM12B “SMD” module on the JeeNode. Or maybe you just want to get going fast, and not spend your time on the hardware side of things.

Meet the new Assembly service option:

DSC_0676.jpg

For a small fee, I’m going to offer to assemble JeeNode kits for you, as well as soldering headers onto any of the plugs available from the shop.

This can help more people get started on this wireless and sensor hookup stuff. And it lowers your risk – you could get two kits, have one of them assembled, and build the other one yourself. Or if you don’t care about soldering at all, just get all the pieces you want to hook up in assembled form.

In fact, I’m going to extend this new service even further: if you get a kit to build yourself and it turns out that you can’t get it to work, then you can send it back and I’ll assemble / finish it for you. I can only do this if all the components are still undamaged, otherwise you’ll need to get a replacement kit. Since I don’t know whether this will work out, nor whether I can handle such a “return/repair” flow of items, I will only commit to do this until the end of November. If it works well enough, I’ll prolong this service.

The reason for doing this is not to add a massive amount of assembly to my workload, but to help people take the plunge with less risk. Especially if you’re new to all this physical computing stuff and electronics, I think you’ll find out that assembling kits can be a lot of fun and very rewarding. But hey, if you’re in doubt, just get a kit and some assembled parts so you don’t have to worry about everything at the same time.


Monitoring failure?

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

Yesterday, the Jee Labs energy monitoring system stopped working:

Picture 2.png

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

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

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

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

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

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

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

,

OOK packet decoding

In Software on Oct 22, 2009 at 00:01

The OOK packets are now collected and stored in the JeeMon database.

Here are the first few readings from the barometric pressure sensor inside the OOK relay, as received by the central node and graphed by JeeMon:

Picture 3.png

Here is the outside temperature from a WS300 weather station on the roof:

Picture 1.png

JeeMon is written in Tcl – the following new code was added to process packets from the OOK relay and get the different parameters stored:

Picture 2.png

The RELAY decoder processes incoming data, separating the bytes into one or more messages and calling the corresponding type-specifc decoders. The RF868 decoder merely reformats incoming data to the format used by another decoder called “ALT” and which was already present in JeeMon. The RF434 decoder is just a stub for now. Note also that the DCF decoder logs the current time – it may seem odd, but storing the received time along with the current system time can be used later to detect local clock drift and compensate for it.

It’s perhaps all mumbo-jumbo for now, I just wanted to illustrate how messages get routed inside JeeMon, and that it takes relatively little logic to deal with new data sources.

This would really benefit from a flexible plug-in system, so that this sort of logic does not have to be added in JeeMon itself but can be picked up on-the-fly. Then it would be easy to add new nodes such as the OOK relay and have JeeMon automatically incorporate the corresponding logic to decode, process, and store their data packets.

,

OOK relay, revisited

In AVR, Software on Oct 21, 2009 at 00:01

The OOK relay to pass on 433 and 868 MHz signals from other devices has been extended:

DSC_0665.jpg

Spaghetti!

The following functions are now included:

  • 433 MHz signals from KAKU transmitters
  • 868 MHz signals from FS20 and WS300 devices
  • the time signal from the DCF77 atomic clock
  • pressure + temperature from a BMP085 sensor

Each of these functions is optional – if the hardware is not attached, it simply won’t be reported.

The BMP085 sensor in the top of the breadboard could have been plugged directly into port 3, but it’s mounted on a tiny board with the old JeeNode v2 pinout so I had to re-wire those pins.

Sample output:

Picture 1.png

There are still a few unused I/O lines, and additional I2C devices can be connected to port 3. Room to expand.

The source code for this setup is available here. It compiles to 10706 bytes, so there is plenty of room for adding more functionality.

This code includes logic for sending out the collected data to another JeeNode or JeeLink with acknowledgements, but I’m working on a refinement so it gracefully stops retransmitting if no receiver is sending back any acks.

As it is, this code will forever resend its data every 3 seconds until an ack is received, but this doesn’t scale well: all the “rooms” nodes do the same, so when the central receiver is unreachable every node will keep pumping out packets while trying to get an ack. It would be better for nodes to only re-send up to 8 times – and if no ack ever comes in, to disable retransmission so that only the initial sends remain.

I’m also still looking for a way to properly mount all this into an enclosure. There is some interference between the different radio’s, maybe all in one very long thin strip to maximize the distances between them?


Solar power

In Hardware on Oct 20, 2009 at 00:01

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

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

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

Picture 2.png

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

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

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

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

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

, ,

Documentation conventions

In Hardware on Oct 19, 2009 at 00:01

With so many plugs and boards (f)lying around here these days, I’m trying to stick to a couple of tagging and documentation conventions.

First and most important one, is that each package has a unique ID which refers to a web page:

FlySketchExport.png

Even each board has such an ID:

FlySketchExport2.png

(this plug is now called an “RTC Plug”, btw)

When you type in the URL, you’ll be redirected to its main documentation page – for example:

Picture 3.png

Did I mention that everything on this site is open source, software and hardware? Well, as you can see above, all the design files are freely available. Enjoy… just don’t do anything with ’em your mother wouldn’t approve of.

The other way to get to these documentation pages is via the “DOCS” link at the top of all the weblog pages. It points to an index of all available documentation pages.

As you can see, all product IDs are two letters plus a version number from 1 to 9. URLs of the form http://JeeLabs.org/ + lowercase-letter + lowercase-letter + digit always redirect to the latest documentation page, regardless of the structure of this site.

I’ll let you know when I run out of all the 6084 codes :)

,

Of JeeNodes and JeeLinks

In Hardware on Oct 18, 2009 at 00:01

There’s a new JeeLink coming…

DSC_0543.jpg

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

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

Picture 1.png

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

, ,

Thermo Plug update

In Hardware on Oct 17, 2009 at 00:01

The Thermo Plug works, basically. Here’s the configuration with an NTC sensor and a buzzer:

DSC_0661.jpg

Sample output, reading out the ADC periodically:

Picture 8.png

As the temperature goes up, the resistance and the ADC readings both go down. The actual conversion to the corresponding temperature will require a calibration and either a lookup table or a polynomial fit, as described in a previous post.

Here is the board layout:

Picture 8.png

The buzzer can be replaced by a relay plus clamping diode. Since it’s driven via an NPN transistor, there will be enough current to drive several types of relays. The buzzer / relay are hooked up to PWR, not +3V.

Another configuration for this board is with the AD597 thermocouple sensor chip. Unfortunately, I forgot to add a wire between pins 1 and 3, so it has to be added by hand – as you can see here:

DSC_0662.jpg

Another view, with the attached K-type thermocouple:

DSC_0663.jpg

The thermocouple responds to temperature change much faster than an NTC – and it’s already calibrated (second number is °C):

Picture 9.png

When I touched the sensor with my hands, it took less than half a second to detect a 5° increase!

Here is the sketch I used for the above demo:

Picture 10.png

Ok, time to tweak the Thermo Plug and fix that missing wire in the next pcb run.

,

New LCD Plug

In Hardware on Oct 16, 2009 at 00:01

There’s a new LCD Plug on its way – hopefully this one has the correct pinout.

Here’s the schematic:

Picture 7.png

This board is based on the same MCP23008 chip as the Expander Plug. Six outputs are used to drive the LCD panel (in 4-bit mode), one output controls power to the backlight, and one spare I/O line is available for a button or a LED – this is brought out to a 2-pin connector.

A breadboard version of a similar setup was described in an earlier post. The software to drive this plug has also been presented before.

The layout of the LCD Plug is as follows:

Picture 3.png

It departs slightly from the normal plug layout, because this board is intended to mount on the back of the LCD panel. There are two solder jumpers to select between PWR and +3V for both logic and backlight. R3 is a current limiting resistor for the backlight, it can be bypassed with a third solder jumper if not needed.

Now I get to play the waiting game again, to see if it comes out ok…


A JeeSupply?

In Hardware on Oct 15, 2009 at 00:01

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

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

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

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

Here’s a first design for it:

Picture 1.png

Click here for a larger PDF.

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

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

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

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

Picture 5.png

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

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

What do you think?

,

Room Board update

In Hardware on Oct 14, 2009 at 00:01

I finally figured out what was going on with the new Room Board.

The bad news: there are three errors on the board when using it with a 1-wire temp sensor and the EPIR motion detector board.

The good news: each problem is easy to work around.

Problem #1: the 1-wire DS18B20 outline is reversed:

DSC_0656.jpg

So much for taking an EAGLE library component from the web and not checking it…

Problem #2: the 1-wire sensor really needs a 4.7 kΩ resistor pull-up:

DSC_0657.jpg

The solution for both problems is to solder the sensor on the other way, and to add a resistor between two of the pins, as shown above.

Problem #3: a pull-up resistor is missing (again!) – it turns out to be essential to get the EPIR in the proper serial mode on power-up:

DSC_0660.jpg

This can’t be done by enabling a pull-up in the ATmega as I originally thought, because that’s too late. The EPIR really checks for this on power-up. The solution is (again!) to manually add a 100 kΩ resistor between pins 2 and 4 of the EPIR connector.

Phew. So now all configurations work. Sort of… :)

I’ve added the Room Board to the shop, but as PCB only because there are several configurations possible and because some of these sensors and boards are relatively expensive (also for me to keep in stock).

With the caveat that I only have a handful available right now, and that these are “imperfect” prototype boards. With SHT11/SHT15 sensors and simple 3-pin PIRs, these prototypes will work fine. But for 1-wire and/or EPIR use, you’ll need to patch things as described above.

I’m going to create a new revision with all these issues fixed, of course. But it will take a few weeks to have new boards made.

The “Rooms” sketch for these boards has been updated to work with all configurations. It needs the NewSoftSerial library if the EPIR is used, and the OneWire library if the DS18B20 is used.


JeeLink v1 bug!

In Hardware on Oct 13, 2009 at 00:01

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

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

Here are the two affected connections on the JeeLink v1:

jl1 build.FlySketchExport.png

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

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

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


An OOK relay

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

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

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

Here’s the hardware test setup:

DSC_0650.jpg

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

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

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

Picture 3.png

Sample output:

Picture 2.png

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

More work left to do…

,

Experimentation setup

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

After coming up with the JeeBoard, which needs a PCB with at least an I/O expander and two LEDs/switches, I decided to go one step simpler and just wire up a version with no active components at all:

DSC_0565.jpg

It connects the same 3.6 .. 4.5 V battery pack through a slide switch, and ties a breadboard to the AIO + DIO pins of ports 1 .. 3, along with +3V and GND. With a few headers placed flat on the board for various plugs.

Wiring this up is simple – note the added rubber feet:

DSC_0566.jpg

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

DSC_0568.jpg

And here’s the final setup:

DSC_0571.jpg

Just to show how you can go nuts with plugs:

DSC_0570.jpg

The battery pack connection is removable to give me a nice spot to insert a current-measuring multimeter.

First demo of this board coming up tomorrow…


Room sensor board

In Hardware on Oct 10, 2009 at 00:01

At last, the latest Room Board design is starting to work:

DSC_0628.jpg

I’m no longer calling this a plug – that’s now reserved for things which you stick into a single port. One of my “tics” is that I like to play games with abbreviations – in this case: trying to abbreviate all product names to two unique letters plus a version number. By not calling everything a plug, I get more letter combinations to play with – so this thing is the “RB1” :)

The version you see above is my preferred configuration, but it requires sensors which are a bit expensive (SHT11) and Europe-based (ELV’s PIR kit). So there is room on the board for some alternatives: the SHT11 can be replaced by a DS18B20 1-wire temperature sensor if you don’t need humidity measurements. And the ELV PIR kit can be replaced by any other PIR sensor which runs off whatever voltage you’re feeding to the PWR pins – many PIR sensors can run with 5V and have an open-collector output, though their three pins may be oriented differently. Parallax and Futurlec come to mind.

The PIR can also be replaced by an EPIR (DigiKey part# 269-4710-ND, non-RoHS). It’s low cost but it draws about 5 mA due to its on-board (“sub-embedded”?) microcontroller. The Room Board will work with the EPIR plugged into the 8-pin “PIR2” connector on the other side of the board, but you have to also move the LDR to the pins marked LDR2. The reason for this is that that the EPIR uses a bi-directional serial connection and therefore needs two signal pins. Luckily, it has the smarts to also handle an attached LDR – so the result is the same.

Here’s the Room Board with an EPIR and a DS18B20 1-wire temperature sensor:

DSC_0646.jpg

Haven’t tested this configuration yet, but every combination of PIR-or-EPIR plus SHT11-or-DS18B20 will be supported. Once the Room Board has been fully tested, it will be listed in the shop.

The Room Board can be plugged into any two opposite ports, but the software expects one of two specific board orientations on port 1 and 4: the PIR and EPIR must be located in the middle, i.e. roughly in between all port headers. It’s easy to change the code if you need other configurations.

Speaking of code, the source code for this setup is available here, as the “Rooms” sketch. It reads out the sensors and periodically sends out the readings over wireless.

Latest news: all the plugs and boards described yesterday have now been added to the shop, as either pre-assembled or pcb-only units.There are only half a dozen boards right now, so please be patient until new ones come in. Please get in touch if you have questions or run into anything unexpected with these plugs. I’m gradually filling in all the associated documentation pages, but some of them are bound to remain skimpy for a while.

Tiny as these plugs are, they sure keep me busy!


Expander Plug, revisited

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

Got some revised plugs. The Expander Plug now works:

DSC_0626.jpg

Here’s a sketch which blinks all pins on the expander:

Picture 3.png

I forgot to check the A0 solder jumper orientation, so I accidentally wired my first plug up for address 0x21 instead of 0x20. Each Expander Plug can be configured for I2C addresses 0x20..0x23, i.e. up to 4 expander plugs can be daisy-chained on each port.

Expander plugs work nicely with the Breadboard Connector, to hook up a mini-breadboard like this:

DSC_0627.jpg

The width of a mini-breadboard is slightly less than an Expander Plug + sideways headers, so daisy-chained plugs can each have their own breadboard.

In summary: the Blink, Expander, Memory, RTC, and UART Plugs all work. So do the unpopulated Proto Board and Breadboard Connector, of course.

More news about prices and availability in the shop tomorrow… once I finish my homework and figure out a few remaining pesky little details and logistics issues.


Light to RF converter

In Hardware on Oct 8, 2009 at 00:01

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

DSC_0573.jpg

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

DSC_0574.jpg

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

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

Picture 3.png

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

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

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


Prototyping board

In Hardware on Oct 7, 2009 at 00:01

Plugs are not required to hook up to a JeeNode, of course. They just act as pre-wired components which can be combined and re-used at will.

Here’s a more Ardino’ish shield-like approach, the Proto Board:

DSC_0549.jpg

It doesn’t have any wiring, just plated-through holes to allow components and connectors to be soldered to either side. The rectangle on the left matches the SPI/ISP header below, while the rectangle on the right matches… an upcoming modification of the PWR/I2C connector.

The board is slightly asymmetric, i.e. larger by 0.1″ on one side than the other. Note that due to the way port headers are aligned, plugging this board the wrong way around has no effect other than re-arranging port numbers. No risk of shorts or wrong voltages on any of the pins.

Here’s another way to plug two of these boards in, if the port numbers printed on the board are ignored:

DSC_0564.jpg

That’s about as much real-estate we can get from generic plugs. For larger projects I use standard perf board with copper islands and push the JeeNode upside down onto it i.s.o. the other way around.


Optimizing SMD

In Hardware on Oct 6, 2009 at 00:01

I’m trying to simplify some plugs a bit. The UART plug has a 3.6864 MHz crystal and two 18 pF caps:

DSC_0563.jpg

(yeah, it’s an awkward fit)

Turns out that it works just as well with the 16 MHz + 10 pF combo I’m using in another project – using adjusted baudrate dividers, of course:

DSC_0561.jpg

(somewhat better fit)

But hey, why stop there. A resonator with built-in caps would get rid of two more components – and it’s more than precise enough to generate accurate baudrates:

DSC_0562.jpg

(awkward fit again, but who cares since it’s a test)

Cool: the 3.68 MHz resonator works – a 40% reduction in component count! Now I can make a new “release”.

I’m still readjusting my neurons to this hardware world. It sure is different from software – even though bits & bytes could be considered to be infinitely small, this hardware stuff somehow feels tangibly smaller…


Clock fixed

In Hardware on Oct 5, 2009 at 00:01

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

DSC_0558.jpg

Sample output:

Picture 2.png

I first ran a sketch to set the time, then commented out the setting part and uploaded it again. As you can see, the time kept ticking – just as in real life…

And it keeps going on its internal battery while power is disconnected:

Picture 3.png

That’s the whole point of this plug!

The battery holder is not perfect. The type I got is for surface mounting, but the board is for a narrower through-hole type. Had to snip the sides of this one off a bit, and it didn’t solder on quite as intended:

DSC_0557.jpg

But it works. The spring action is very strong and pushes the battery to the board anyway.

The code for this RTC Plug has been added to the Ports library as “rtc_demo” example, and is available here.


More serial ports

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

Here’s an easy way to add more serial ports via I2C:

DSC_0547.jpg

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

DSC_0548.jpg

There are two jumpers, allowing up to 4 serial ports to be added to each I2C bus – i.e. up to 16 on the bit-banged I2C buses, and 4 more on the hardware I2C line. Since the A0/A1 jumpers actually support up to 16 addresses with a bit of extra wiring, you could theoretically connect up to 80 serial ports to a single JeeNode!

Here’s some sample code:

Picture 5.png

It sets the serial port to 57600, 8 bits, no parity and then sends whatever comes in to the “normal” serial port. The default fast I2C bus rate of over 1 Mhz appears to work just fine.

The header of the UART plug is compatible with FTDI, so you can hook up another JeeNode to it:

DSC_0559.jpg

In this case, I used a JeeNode with a room plug prototype. Sample output:

Picture 3.png

This demo code has been added as “uart_demo” example in the Ports library and is also available here.


JeeLink assembly line

In Hardware on Oct 3, 2009 at 00:01

Here’s a peek into the Jee Labs kitchen:

DSC_0554.jpg

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

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

From top left to bottom right, sort of:

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

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

DSC_0555.jpg

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

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


Voltage Plug

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

The Voltage Plug generates up to four 0 .. 3.3V levels using MCP4725 12-bit DAC’s controlled from I2C:

DSC_0546.jpg

This sketch switches between 0 and 4095, displaying as 1.2 mV and 3.295 V on my multimeter, respectively:

Picture 1.png

The cycle time was set to 5 seconds to give my auto-ranging multimeter time to adjust itself.

There is room for 4 DAC chips, which seems like a bit of overkill, but I couldn’t think of anything else to put there and the board looked so empty :) – perhaps some sort of voltage-follower op-amp or amplifier stage would make more sense? Anyway, I’ll probably remove two of those chips from the plug again.

The MCP4725 only has one pin to specify the lower address bit. There are in fact 4 different chips available from the manufacturer, to support up to 8 DAC’s on a single I2C bus. Since I got the “A3” version – and since I mixed up high and low again – this particular test uses address 0x67. For the final version I’ll fix the low-address bit and use “A0” versions, i.e. 0x60 and 0x61.

,

No LCD Plug yet

In Hardware on Oct 1, 2009 at 00:01

As mentioned before, the LCD Plug will need to be redone. The MCP23008 chip pinout was completely wrong…

But hey, it does look nice, doesn’t it?

DSC_0550.jpg

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

DSC_0551.jpg

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

DSC_0552.jpg

Alternately, it could be flipped over and mounted alongside the LCD.

Note how the solder pad configuration is on the other side, so it can be adjusted once mounted. Not included in this first prototype is a small trim pot to adjust the contrast level.

So the real LCD Plug will take a bit longer – hopefully the next board will be without these crazy mistakes…