Computing stuff tied to the physical world

Posts Tagged ‘JeeLink’

Time-controlled transmissions

In Hardware, Software on Jun 27, 2011 at 00:01

Receiving data on remote battery-powered JeeNodes is a bit of a dilemma: you can’t just leave the receiver on, because it’ll quickly drain the battery. Compare this to sending, where nodes can easily run for months on end.

The difference is that with a remote node initiating all transmissions, it really only has to enable the RFM12B wireless module very briefly. With a 12..23 mA current drain, brevity matters!

So how do you get data from a central node, to remote and power-starved nodes?

One way is to poll: let the remote node ask for data, and return that data in an ACK packet as soon as asked. This will indeed work, and is probably the easiest way to implement that return data path towards remote nodes. One drawback is that if all nodes start polling a lot, the band may become overloaded and there will be more collisions.

Another approach is to agree on when to communicate. So now, the receiver again “polls” the airwaves, but now it tracks real time and knows when transmissions for it might occur. This is more complex, because it requires the transmitter(s) and receiver(s) to be in sync, and to stay in sync over time.

Note that both approaches imply a difficult trade-off between power consumption and responsiveness. Maximum responsiveness requires leaving the receiver on at all times – which just isn’t an option. But suppose we were able to stay in sync within 1 ms on both sides. The receiver would then only have to start 1 ms early, and wait up to 2 ms for a packet to come in. If it does this once a second, then it would still be on just 0.2% of the time, i.e. a 500-fold power saving.

Let’s try this out. Here’s the timedRecv.pde sketch (now in the RF12 library):

Screen Shot 2011 06 24 at 20.54.37

It listens for incoming packets, then goes into low-power mode for 2 seconds, then it starts listening again. The essential trick is to report two values as ACK to the sender: the time the receiver started listening (relative to that receiver’s notion of time), and the number of milliseconds it had to wait for the packet to arrive.

There’s no actual data processing – I’m just interested in the syncing bit here.

The sender side is in the timedSend.pde sketch:

Screen Shot 2011 06 24 at 20.58.17

This one tries to send a new packet each time the receiver is listening. If done right, the receiver will wake up at just the right time, and then go to sleep again. The ACK we get back in the sender contains valuable information, because it lets us see how accurate our timing was.

Here’s what I get when sending a new packet exactly 2,096 milliseconds after an ACK comes in:

Screen Shot 2011 06 24 at 20.39.33

Not bad, one ack for each packet sent out, and the receiver only has to wait about 6 milliseconds with its wireless receiver powered up. I’ve let it run for 15 minutes, and it didn’t miss a beat.

For some reason, send times need to be ≈ 2.1 s instead of the expected 2.0 s.

Now let’s try with 2,095 milliseconds:

Screen Shot 2011 06 24 at 20.37.17

Something strange is happening: there’s consistently 1 missed packet for each 5 successful ones!

My hunch is that there’s an interaction with the watchdog timer on the receiver end, which is used to power down for 2000 milliseconds. I suspect that when you ask it to run for 16 ms (the miminum), then it won’t actually synchronize its timer, but will fit the request into what is essentially a free-running counter.

There may also be some unforeseen interaction due to the ACKs which get sent back, i.e. there’s a complete round-trip involved in the above mechanism

Hmm… this will need further analysis.

I’m using a standard JeeNode on the receiving end, i.e. running at 16 MHz with a ceramic resonator (specs say it’s 0.5% accurate). On the sender side, where timing is much more important, I’m using a JeeLink which conveniently has an accurate 16 MHz crystal (specs say it’s 10 ppm, i.e. 0.001% accurate).

But still – even this simple example illustrates how a remote can receive data while keeping its wireless module off more than 99% of the time.

Self-powered Opti-rebooter

In AVR, Hardware on May 18, 2011 at 00:01

After yesterday’s post about switching to OptiBoot, I decided to go one step further and go for a self-powered solution, a bit like this unit which has been serving me well for many months now.

So here’s the “Opti-rebooter” with a 400 mAh LiPo backpack:

Dsc 2521

Hookup is trivial, given that the JeeNode USB has an on-board LiPo charger. I picked a battery which matches the width of the board and fits quite well:

Dsc 2522

The two connectiosn of the LiPo battery are wrapped up in heat-shrink tubing to prevent accidental short circuits – the currents involved could easily cause trouble. Note that this is a “raw” LiPo cell, without any protection circuitry. That’s fine in this case, because the on-board circuitry takes care of charging.

To make this complete, the isp_repair.pde was extended to completely power down when done. So there’s no need for an on-off switch, the idle consumption is probably lower than the battery’s own self-discharge rate. And it blinks the on-board led twice: once on power up and once when properly programmed. Very convenient!

The way to use this thing, is: connect to a target JeeNode / JeeLink / Arduino, press the RESET button, wait three seconds, disconnect, done.

I also made changes to the very similar but slightly more elaborate isp_prepare.pde sketch, which was presented in this weblog post.

The updated isp_prepare.pde sketch supports a number of variations. These can be configured by adjusting a few values at the start of the sketch:

Screen Shot 2011 05 16 at 15.00.32

You can choose which type of boot loader to install, which sketch to load initially (just to start off, this can be overwritten later), and there’s a third option to adjust some “fuse bits” in the ATmega to select how fast the ATmega can start up after resuming from a power down.

That third option is particularly useful with battery-powered JeeNodes using the RF12 driver. With USE_FAST_WAKEUP set to 1, the power-up sequence is fast enough for an ATmega to wake up when the first data byte is received. This means you can completely power down the ATmega (while leaving the receiver running), and it’ll still be able to pick up incoming packets and respond to them. There is one gotcha: USE_FAST_WAKEUP can only be set to 1 on units running with a resonator – JeeLinks and Arduino’s running with a crystal must be not use the fast wakeup mechanism, as the clock may not start up properly in this case.

Haven’t tried it though – for now, that LiPo powered unit shown above is really the most convenient way for me to upgrade all the JeeNodes, JeeLinks, and Arduino’s floating around the house at JeeLabs.

Switching to OptiBoot

In AVR, Hardware on May 17, 2011 at 00:01

Now that some of the JeeNode/JeeLink boards from JeeLabs come pre-loaded with the OptiBoot boot loader, it’s time to start thinking about switching everything over. Having to constantly switch the Arduino IDE between “Arduino Uno” (OptiBoot) and “Arduino Duemilanove w/ 328” (original 2009 boot) is quickly going to become very tiresome …

See this weblog post for a quick summary of what all this uploading and boot loader stuff is about, and why you should care. In a nutshell: you need a boot loader on the ATmega to save sketches onto it via FTDI and USB.

There’s a nasty detail, though: to upload sketches you need a boot loader, but how does that boot loader end up on the ATmega in the first place? The good news is that this is usually done in the factory, well, ehm… at JeeLabs, in my case. The good thing is, it’s all taken care of, and the boot loader doesn’t normally get damaged or need to be replaced. It just works.

Except when the boot loader itself needs to be changed, as in the case of OptiBoot. Note that it’s quite worthwhile to switch to OptiBoot: the uploads are twice as fast, and you get 1.5 Kb of extra memory for your own sketches.

So how do you go about updating the boot loader on a JeeNode when you don’t have a special hardware tool called an “ISP Programmer”?

Fortunately, there is a simple trick to do this using a second JeeNode (or Arduino). I’ve written about this in a previous post. There’s an isp_repair.pde sketch in the Ports library which does everything (it emulates an ISP programmer, basically).

I’ve just updated the isp_repair.pde sketch to use OptiBoot.

Here’s the setup to upgrade a target JeeNode to OptiBoot using another JeeNode:

Six wires need to be connected as follows:

And then it’s a matter of attaching the target to the programming JeeNode, and then powering up the whole assembly.

If you happen to have the serial port connected to the programming JeeNode, you’ll see this info:

Screen Shot 2011 05 16 at 17.08.48

I made a permanent setup using a JeeNode USB, because I’ve got a pile of JeeNodes to reprogram here at JeeLabs:

Dsc 2518

The connector was constructed from a 2×4 header, with the pins bent in such a way that the whole thing stays in place when pressed into the 2×4 holes of the SPI/ISP header. And then the whole thing was sealed off with a few pieces of heat-shrink tubing:

Dsc 2519

To program a board (in this case another JeeNode USB), just power it all up and wait 3 seconds:

Dsc 2520

That’s it – you could call this an “opti-rebooter” :)

JeeLink v3 w/ OptiBoot

In AVR, Hardware on May 16, 2011 at 00:01

Small changes. Previous, i.e. v2:

Dsc 2515

And here’s the new JeeLink v3:

Dsc 2516

The changes are mostly cosmetic and include a number of changes to simplify the assembly process. Some minor but oh so important tweaks to more accurately fit it in the case:

Dsc 2517

See those four tiny notches line up? Phew!

Two changes which will be more important for everyone using these:

  • The JeeLink v3 comes with the OptiBoot loader pre-installed, i.e. you need to select the “Arduino Uno” as board type when uploading sketches to it.

  • The on-board DataFlash memory has been increased to 16 Mbit. This fast SPI-connected permanent memory makes it possible to use a JeeLink for collecting even more data when the PC is off (but power has to remain, evidently). The RF12demo sketch has a FLASH_MBIT constant defined, it should be set to 16.

You can easily see which JeeLink you have by looking at the gold lettering on the back side.

Apart from that, nothing really changes. All JeeLinks sent out from now on will be this new v3 build.


JeeLink DataFlash logging

In Hardware, Software on Sep 11, 2010 at 00:01

Since July, the JeeLink has undergone a slight hardware change. It used to include an 8 Mbit AT26DF081A DataFlash chip, but unfortunately this chip is no longer being produced:

Jl Dataflash

As it turns out, only very few chips are physically and electrically compatible with the AT26DF081A. The only one I could find is the AT25DF041A, which has half the memory, i.e. 4 Mbit.

So that’s what’s being included on the current batch of JeeLinks. I’ll review the alternatives when it is up for a revision, but for now I’ve just opted for this change – especially since the use of the on-board DataFlash memory chip on the JeeLink is probably still very limited.

Having said that, the “RF12demo.pde” sketch does include support for the flash memory, in the form of a continuous data-logging capability. This is the main topic of this post, actually.

All packets received by the JeeLink are saved up and stored in flash memory whenever 256 bytes of data have been accumulated – along with a sequence number and the current value of the millisecond counter.

This process takes place continuously, wrapping around when all available flash memory has been filled. There are some tricky details involved, since DataFlash needs to be erased before re-use. The way RF12demo does this is that it always erases one extra 4 Kb block of memory, just ahead of the current write buffer pointer.

The “sequence number” is a 16-bit counter which gets incremented on each power-up and whenever the buffer writing wraps around. In practice, it’ll never overflow, but there is a “w” (wipe) command to fully erase the entire flash memory and start over if that is ever needed. It only works when executed as “12,34w” to prevent an accidentally typed “w” from wiping the flash.

The data-logging mechanism in RF12demo can be used to catch up on received messages when the attached computer has been asleep for a while. There is a “d” command which dumps info about each 256-byte page in the DataFlash – for example:

    > 0d
     df# 34 : 2 698 28309
     df# 35 : 2 955 3849
     df# 36 : 2 1213 38883
     df# 37 : 2 1471 51360
     df# 38 : 2 1728 55763
     df# 39 : 2 1986 26600
     df# 40 : 2 2244 10261
     df# 41 : 2 2501 57698
     df# 42 : 2 2757 1373
     df# 43 : 2 3016 25513
     df# 44 : 2 3273 41145
     df# 45 : 2 3532 39344
     df# 46 : 2 3789 63313
     df# 47 : 2 4047 57266
     df# 48 : 2 4304 13464

Pages 34 through 48 contain data, all from the same power-up cycle (seqnum = 2), and spanning time 0.698 through 4.304 (seconds). The last values are 16-bit checksums, and less useful here.

What you can do with this data is play it back with the “r” (replay) command:

    > 0r
    r: page 33 48
    R 2 698 3 129 44 0 0
    R 2 704 61 4 17 6 34 116
    R 2 708 56 199 0 215 0
    R 2 944 56 147 0 215 0
    DF R 34 2 698
    R 2 955 3 133 44 0 0
    R 2 4298 61 52 232 0 135 39
    DF R 47 2 4047
    R 2 4304 3 185 44 0 0
    R 2 4525 56 198 0 215 0
    R 2 4538 61 52 233 0 134 39
    R 2 4541 61 4 1 135 49 145
    DF R 48 2 4304
    DF E 48 4 17476

If you replace the “R” and the next two numbers with “OK”, then you’ll see that a long stream of received packets is being reported. The data is internally stored as variable-length binary data, i.e. in a very compact format, but replay converts it back to the same bytes-as-small-integers format as the original “OK” packets.

The replay command also takes arguments to play back from a certain point. The way this works is that the output includes “DF R …” replay markers, which indicate which page has just been replayed. Furthermore, special “DF S …” store markers are also occasionally inserted in the output during normal reporting:

    DF S 49 4 28

With these two bits of information, it is possible to track the point in the logging process so far: whenever a “DF S” or “DF R” arrives, it marks which particular page has just been completed. By storing this on the receiving computer, we can remember how far we got when shut down (even accidentally).

To recover data when started up again, the replay command can be given 6 arguments: “S,S,T,T,T,T r” which tell the JeeLink to start replaying after sequence number SS and time TTTT.

This replay recovery hasn’t been added to JeeMon yet. Once implemented, JeeMon will be able to collect data from remote nodes even if the computer is off once in a while (at night, for example). All we have to do is keep the JeeLink powered, so that it will log all incoming data it its DataFlash.

Back to the hardware change in the JeeLink…

As mentioned on the discussion forum, the new DataFlash chips broke the RF12demo code, which looks for a specific hardware signature to detect the chips. I’ve added some conditional definitions to RF12demo, so that it can now be built for either the 4 Mbit or the 8 Mbit version:

Screen Shot 2010 09 10 at 21.27.24

The RF12demo.pde sketch in the RF12 library has been updated. This new version announces itself on the serial USB port as “[RF12demo.5]”. Note that the current batch of JeeLinks still has the older sketch, so you’ll need to recompile and upload the latest one if you want to use the datalogger functionality.

JeeLink’s “Plan B”

In Hardware on Apr 29, 2010 at 00:01

Hmm, it looks like the plastic “USB stick” cases are seriously and totally unavailable. I’ve completely run out of cases, and the next shipment from Farnell is reported to be in… July!

Can’t have everyone wait for it, so I’ve started replacing the case by some semi-transparent heat-shrink tubing:

Dsc 1375

It’s not quite as pretty or sturdy, but it does protect the board so you can easily plug in or remove the JeeLink. The red, green, and blue LEDs are still clearly visible.

If nothing changes on the delivery-of-cases front, then this change will become permanent. Otherwise, I’m willing to repackage any JeeLink you send back at no extra cost. Once the original cases are available again.

Will keep y’all posted on this …

Update – Just got a note from Farnell that the cases are shipping (!). I’m going to hold back on all JeeLink shipments until Monday – with a bit of luck, I can send them off with the “real” plastic cases after all!

Demo remote LCD

In Hardware, Software on Apr 6, 2010 at 00:01

It’s hard for me to realize just how confusing all this Jee stuff can be, and it’s certainly good to be reminded of that once in a while. Not everything makes sense for people who aren’t immersed into all this every day.

I want to improve that. In fact, it’s the main reason I’ve been chasing around in search of a good forum + wiki setup. As it stands, I’m hesitant to start writing down lots of things and, eh… yes, documenting all this Jee stuff. But this will change. Promise.

For starters, some good news on the forum + wiki front: I’ve decided to standardize on Markdown as formatting language. It’s ancient (i.e. proven), it’s clean, and with just one or two extras it will be good enough for most of the things I need. The reason I’m bringing it up here, is that I’ve just finished converting all the wiki pages to Markdown, as well as 90% of the current Jee Labs documentation pages. The forum remains bbForum, but it has now been adjusted to use Markdown formatting as well. So has WordPress. In fact, this is the first weblog post written in Markdown (in Textmate, my favorite text editor).

Yeay for one set of conventions, and yeay again for simplicity!

Ok, back to the main topic of this post.

Here’s a demonstration on how to send a text string to a remote LCD via wireless JeeNodes. This is the hardware I’m going to use for that remote LCD node:

  • a JeeNode USB
  • an LCD Plug with 2×16 LCD display
  • one extension cable
  • plus a hookup to USB to power this whole thing

Dsc 1300

Ok let’s set up a simple demo sketch for the remote receiver end (code here):

Screen Shot 2010 04 05 at 20.09.58

Very simple, really: wait for an incoming packet and display the bytes as characters on the LCD. Plus some initialization code.

On the sender end, I’m using a JeeLink running the pre-loaded “RF12demo” sketch:

Dsc 1302

First step is to put the JeeLink in the right mode:

8b 4g 1i

That’s the 868 MHz band, group 4, node ID 1.

Now we can send a message to node 9, which is running the remoteLCD sketch, by sending a packet with the individual character codes to the JeeLink (the “9” at the end is the destination node ID):


The result:

Dsc 1305

Yippie. No wires. Magic! :)

Ready to Link!

In Hardware on Mar 23, 2010 at 00:01

Today, a fresh batch of JeeLinks came in:


All ready to go (and, no, you don’t get to pick the antenna color of these units…).

Got several bits and pieces in today, which means I’ve been able to fulfill most of the pending orders – at last!

One other item worth mentioning is that I finally have the black mini-breadboards in stock:


The delay (since last December!) was in the end all due to my own negligence – I had forgotten to fill in a form to supply more details about the contents of the package which was being held at customs. Doh.

Lots of new plugs to finish, several other new items, and yet more boards I’m going to try out. Plus a couple of days reserved for non-JeeLabs activities later this week.

It’s going be be a busy end of March!

JeeNodes on Bifferboard

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

The Bifferboard described yesterday is a bundle of fun (well, for geeks like me anyway…).

But this weblog is about physical computing, not just embedded hardware or software.

So let’s hook up a JeeLink!

The first hurdle is a silly one: my Bifferboard only has a single USB slot, and it needs the USB stick to run off. So for this experiment I added an unpowered USB hub:


Did I mention that this is a standard Debian setup? Here’s the kernel log with the JeeLink plugged in:

Screen shot 2010-03-15 at 12.45.30.png

Note how it recognizes the FTDI serial link without having to install or configure anything. Perfect!

The other factoid which can be gleaned from this info is that it took about 36 seconds from the start of the kernel boot to this stage. From this, I’d estimate a Bifferboard with JeeMon to boot up in well under 60 seconds.

To verify that the USB recognition is really complete, I used this little test in “try/application.tcl”:

Screen shot 2010-03-15 at 12.52.44.png

And sure enough, it recognizes and identifies the USB device:

Screen shot 2010-03-15 at 12.54.32.png

Let’s try one more thing – by changing try/application.tcl to this code:

Screen shot 2010-03-15 at 13.01.48.png

Sample output:

Screen shot 2010-03-15 at 13.01.23.png

That’s a Bifferboard receiving JeeNode packets via a JeeLink – yippie!

I can now go back to developing JeeMon further on my desktop machine, in the knowledge that software updates are one little restart away (due to JeeMon’s built-in self-updating over internet) and that apps will probably work as is on a Bifferboard. Long live platform independence!

One of the JeeHubs?

In Hardware on Jan 15, 2010 at 00:01

Just got this thing in:


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

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

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

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

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

JeeLink flash memory

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

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

Screen shot 2009-11-28 at 12.34.27.png

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

Screen shot 2009-11-28 at 12.36.37.png

Screen shot 2009-11-28 at 12.38.30.png

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

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

Screen shot 2009-11-28 at 12.42.30.png

Screen shot 2009-11-28 at 12.45.23.png

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

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

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

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

JeeNode comparison matrix

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

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


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

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


(this comparison matrix is also available as PDF)

So there you have it – one happy JeeFamily :)

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

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

New RF12demo

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

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

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

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

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

Screen shot 2009-11-18 at 18.33.06.png

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

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

Screen shot 2009-11-18 at 18.31.34.png

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

Screen shot 2009-11-18 at 18.45.14.png

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

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

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

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

Screen shot 2009-11-18 at 18.45.52.png

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

Screen shot 2009-11-18 at 18.46.18.png

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

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

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

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

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

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

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

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

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

JeeLink flash works

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

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

Here is the main test code I used:

Screen shot 2009-11-05 at 00.26.33.png

And here’s the output:

Screen shot 2009-11-05 at 00.26.00.png

Some timing results can be gleaned from that output:

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

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

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

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


At last!

Meet the JeeNode USB

In Hardware on Nov 7, 2009 at 00:01

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


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

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

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

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

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

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

Ok, everything is starting to come together now.

Activity LED

In Hardware on Nov 6, 2009 at 00:01

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

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


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


Voilà – it even has PWM!

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

Woohoo – this is post #300 !

Meet the new JeeLink v2

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

Just in!


Look at that fancy gold lettering – neat, huh?

And the first hand-soldered unit is working perfectly:


Here’s the new software-controlled LED:


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

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

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.

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:


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!

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:


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:


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:


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

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:


Even each board has such an ID:


(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 + 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…


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.

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

JeeLink assembly line

In Hardware on Oct 3, 2009 at 00:01

Here’s a peek into the Jee Labs kitchen:


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:


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…

Port extension

In Hardware on Sep 15, 2009 at 00:01

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


Available in 100, 200, and 300 mm lengths.

By adding an extended-length 6-pin male header as shown on the right, this can be turned into a convenient extension cable for ports and plugs.

The color coding helps create a convention for ports, since their connectors are not polarized, but be careful – it looks like my batch used a different set of colors than what is currently showing on their website. And the colors also differ from an FTDI cable, alas.

Ah, conventions… so many to choose from! ;)


In Hardware on Sep 13, 2009 at 00:01

Here’s a simple design for a little “Proto Board” which covers all the port headers and the ISP/SPI connector:

Picture 1.png

The PWR/I2C header on the JeeNode is not covered by this board. I’m still exploring some options, hence the unmarked rectangle at the right end. The board is deliberately slightly asymmetric, to make it easier to remember which way it goes on.

Holes will be plated through as always, with text labels on the other side as well.

I’m considering not adding any connections to allow all solder pads to be used in various ways. This does mean wires need to be attached directly to the header pins to use them.

Just exploring for now – I’ll probably add this to the next panel prototype run, just to see how it works out.

Boot loader problems

In AVR, Software on Sep 11, 2009 at 00:01

Whoops – I messed up with several packages I’ve sent out to people. Ouch.

The gory details are in the discussion forum, but here’s the short version:

  • I’m shipping ATmega’s pre-programmed with the Arduino bootstrap and the RF12demo sketch. Mighty convenient, since it can get you going a lot quicker.
  • And to simplify my work I, ehm… sort of tried to automate it a bit.
  • So I burn the bootloader with the Arduino IDE and the burn the RF12demo sketch using “avrdude” from the command line.
  • Cool. Except that the second step undid the work of the first step… doh!
  • So I ended with ATmega328’s which have the RF12demo but no bootstrap loader.

It turns out that avrdude erases a chip by default when re-programming it. So the bootloader, which is loaded in high-mem, got cleared when storing the demo in low-mem. And of course that doesn’t show in a quick test: the demo on the chip, which I always check, works just fine. Which is why I sent out a few bad JeeNode kits and JeeLinks.

All it took to fix this was one lousy little “-D” command option for avrdude!

So now I’ve decided to automate all the way, and burn the fuses, the bootloader, and the demo sketch all in one go – from the command line.

Here’s what it takes – I have these files in one directory:

Picture 1.png

The hex files were copied from the Arduino “bootstrap” area and the RF12demo “applet” build area, respectively.

The makefile contains these commands:

Picture 2.png

So all I need to do now is to plug in the ISP programmer and put a fresh ATmega chip in its socket, then type “make”. This works for both the JeeNode and the JeeLink chips.

Easy… once done right!

Build progress

In Hardware on Sep 10, 2009 at 00:01

Aha, now we’re getting somewhere:


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

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

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

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

Four more boards done!

Smaller still?

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

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

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


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

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

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

Final JeeLinks

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

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

Here’s a fully assembled JeeLink:


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


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

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

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

SMD pick and place

In Hardware on Sep 7, 2009 at 00:01

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


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


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


(sorry for the incandescent light reflection)

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


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

Looks perfect to me:


Baking now, in my JeeNode-based reflow controller:


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


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

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

Stay tuned for the rest of this story… tomorrow.

Solder paste

In Hardware on Sep 6, 2009 at 00:01

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

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

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


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

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


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


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

Meet the JeeBoard

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

I hate wires. Wires to power up stuff. Wires to transfer data. What a mess.

I just want to try out physical computing ideas on my desk, next to my (wireless) keyboard and my (wireless) mouse – while exploring the possibilities of hardware + firmware + software running on my “big” computer.

So here’s to scratching my own itch: meet the JeeBoard – a little 8×10 cm unit with no strings attached – heh ;)


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


On the left, a couple of demo plugs have been inserted. Those that use I2C can be daisy-chained.

One port is permanently hooked up to an I/O expander chip with 6 digital I/O lines for the mini-breadboard, 2 LEDs, and 2 pushbuttons. The on-board battery pack provides 3.6V with NiMH or 4.5V with alkaline cells.

The little overhanging board on top of the mini-breadboard “feeds” 8 wires into the center of the breadboard: +3.3V, ground, and the 6 general-purpose I/O lines.

I’m going to mess around with the layout a bit and explore some actual hookups before designing a real PCB for this. But even just looking at the mockup makes me want to start trying out stuff with it. Wireless, of course!

JeeLink issues solved

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

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

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

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

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


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

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

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

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

JeeLink status

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

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

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

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

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

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

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

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

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

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


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

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

LED polarity

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

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

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


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


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

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

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

JeeLink build woes

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

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

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


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

Here are a couple of extreme close-ups:





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

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

Programming a 32-TQFP chip

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

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


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

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


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

Meet the JeeLink

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

I’m proud to announce a new board next to the JeeNode, called the JeeLink. Yes, there’s a pattern in the naming choices made for products on this site.

The JeeLink is very much like a JeeNode, but in the format of a USB stick and with a few small differences listed below. Here’s the layout:

Picture 2.png

As you can see, the JeeLink has basically the same headers as the JeeNode, but with a USB plug in the place of the JeeNode’s FTDI connector.

The JeeLink is useful in two different ways, I think: first of all, if you have a couple of remote JeeNodes, you’ll probably need a central node as well to tie the whole network to a personal computer. The second use case is that it can be used as a JeeNode with built-in FTDI-to-USB conversion – which is exactly what it is, technically speaking.

A major difference with the JeeNode also, is that the JeeLink is built with SMD parts. The intention is to make it available in pre-assembled form and as bare board. No kits with parts – that’s reserved for the JeeNode since I don’t want to stretch myself too thin.

There will be a more detailed description of the JeeLink once it is ready and working, but here’s a first overview:

  • the dimensions of a JeeLink are slightly different, obviously
  • the I2C and SPI/ISP headers are not in exactly the same position as on the JeeNode
  • there’s no battery connector (who needs one with USB?)
  • the FTDI-type USB connection includes two on-board activity leds

So there you have it – a new descendant in the Jee family. With on-board RFM12B wireless radio of course, and 4 ports to connect absolutely anything you like to. Just like the JeeNode.

The JeeLink is the initiative of – and was designed in collaboration with – Paul Badger of Modern Device. We’ve been having a heck of a time together, hammering out all the details and making sure the result will be as good as we can possible make such a new concept. I’m proud of the result, and hope you’ll like it as well. Should have properly working JeeLinks in my hands in July, assuming Mr. Murphy doesn’t barge in to spoil the party.