Well, here I am with the third consecutive weekly wrapup. I'm amazed that I've stuck to it so long.

There wasn't too much notable in the news this week, and in fact it's been pretty slow. The most interesting thing to me was the blog post by the mystery author who was documenting the Barcelona Continua event. If what he says is true, then I'm just amazed at how multi-million/billion dollar industries like wireless medical devices are decided. It actually seems like a circus event, not something that could determine how people live their lives in the future. If that really is the case, then I think I know a lot of open source and hacker projects that are better organized than that. The only other things that come to mind in the news are that Ember closed a new round of funding (yes...again...) and that some research outfit says that 802.15.4 is poised for growth. I remember hearing that back in 2004 and 2005 as well. 

For the FreakZ stack, I was finally able to release the documentation. The weather in Tokyo has been excellent lately, especially last week when you could view the beautiful cherry blossoms. It took all my powers of concentration to use up my free time and write documentation, but I had to get it out of the way to move forward.  I'm glad that I finished it, so that I can start testing and porting the mods to hardware. Can't wait to see things work and make weird devices like wireless dog feeders.

Also, I did manage to sneak away again this year to check out the 2009 Tokyo Sensor show. All I can say is that it was really disappointing. Last year, there were a lot of cool concept projects and many research projects were displayed by universities . This year, only one university had a display, and there was very little in terms of sensor networking much less wireless sensor networking. There were only two displays I saw that even mentioned Zigbee and one of them was from Keio university. The sad thing was that Zigbee was doing well compared to other wireless protocols. Wireless Hart, ISA100, and Bluetooth Low Energy were nowhere to be seen. I even checked out the Honeywell display, but it just had their latest industrial sensors. One interpretation would be that companies are pulling back from spending money on anything risky like WSNs and sticking with the tried and true. Another interesting thing was that the place was fairly empty. I suspect that they had trouble getting enough exhibitors because they were charging 1500 yen (~$15) at the door.

Anyways, along with all that, I spent $1200 to upgrade my computer to a fairly kickass system. I broke open the piggy bank and treated myself to a system with a Core2Duo E8500 (3.16 GHz), 4 GB RAM, a dual HDMI video card, and dual 24-inch HD LCD monitors. I can't believe how cheap the computer and LCD monitor prices have gotten. Since I'm getting a fat tax return, I decided to see if a system like this would actually improve my productivity. Just kidding. Now I can watch anime in HD, download it, and surf the web...all at the same time!!! Ahhh...the march of technology....

p.s. A side benefit is that my GCC compile times are gonna come down...

p.p.s. Yes...multiple people have told me that I should have gotten the Intel i7 quad CPU. Thank you, but  I'm just a cheap ass...

Here's the pix from the sensor show

I’ve decided to keep going with the weekly wrapup series. It’s a good chance to keep people updated on what’s going on with the stack as well as point out interesting things that are occurring in the WSN world. Recently, there’s so much activity in it that a lot of events can sometimes get lost in the noise. Also, it took five months in between code drops for the FreakZ stack. Without hearing about the status, it would pretty much look like a dead project.

One of the first things I wanted to point out was that I made a correction to my “Let’s Not Be Greedy” post. I’ve been operating under the assumption that Bluetooth Low Energy was already a released spec which, to my great surprise, was not true. The main point of the post remains unchanged though, and that is that the focus for the Zigbee Health Care profile shouldn’t be on winning the Continua bid. It should be on providing a solution for wireless medical monitoring over Zigbee and building an ecosystem around it  (ugh…I used a buzzword). Otherwise, if too much emphasis gets put on the Continua bid, then losing it may have a bad or demoralizing impact on the Health Care profile which would be a horrible shame. The world needs something like Zigbee Health Care with or without Continua. It could enable the elderly to live in the comfort of their own homes without worrying about getting hurt and having nobody around to help them. Or allow people that can qualify for outpatient care to avoid spending thousands of dollars on an expensive hospital stay which has a devastating impact on a family’s finances.

Okay, let me step down from the preacher’s pulpit now since I seem to be rehashing old posts…

For people interested in the stack, one brave soul actually ventured into the hardware side, which I should mention is untested for the new mods, and tried to get it up and running. In doing so, he found a big bug in the USB device stack that made it dysfunctional when the code is compiled with optimization. The thread can be found here in the forums and revolved around not using the keyword ‘volatile’ on certain variables that were used to signal incoming data. For those not too familiar with the inner workings of C, the ‘volatile’ keyword instructs the optimizer that the variable can be changed outside of where it is being used. Normally, if the optimizer sees a variable being used but doesn’t get changed anywhere in the local function or file, it’ll see it as useless code and rip it out. This normally causes strange behavior in optimized code because things don’t function as they logically should. It’s a pretty ugly bug. Anyways, this makes me realize that I need to review the main Zigbee stack for instances of this problem as well.

I didn’t get anywhere with the code documentation and testing other than helping fix the USB bug. If anyone is interested in kicking the tires on the stack, I’d recommend using the simulator for now. I still need to update and test the hardware side along with udpating and adding to the documentation. I’m also planning on implementing a similar command set as the simulator for the Raven USB board so that people can simulate what they want to do first on a nice, safe PC and then go into the dirty world of real-life hardware.

Also, as the time that the stack runs on real hardware starts to draw near, I’m starting to prepare some development boards that people can use to evaluate the stack. In most cases, a Raven kit will probably be fine, but if you want to do customization like using sensors other than the temp sensor on the Raven or need extra I/O, its very difficult. The headers are non-standard and almost all of the I/Os are used up. So actually, it’s a good opportunity for me to hopefully generate some income on the side by selling dev kits, especially since I need to make development boards for personal use anyways. My free time this past week was mostly consumed by exercising my poor web design skills to put together an online shop. I'd have to say that I prefer debugging software than trying to figure out why my CSS isn't displaying correctly. I should have an online shop up and running in a month or two and I’m actually hoping that hardware sales turn out to be a good way to keep the project funded. Plus, I enjoy designing hardware. I'm basically a hardware guy at heart and it's tough to beat the feeling you get when you receive the fat FedEx pack with your new bare PCBs.

One of the boards I have in mind is a learning board for the Contiki OS. There’s a real lack of boards that are targeted to the specific strengths of Contiki. The OS has so much to offer, ie: TCP/IP stack, wireless protocol stack, GUI system, and support for loads of sensors. Plus, since the OS is so small, cheaper microcontrollers can be used which can lower the board cost. At least cheaper than the microcontrollers for something like say, a Zigbee stack;) Anyways, that’s gonna be in the works as well so if anyone has any suggestions on features they’d like to see on a Contiki board, let me know.

I was a little disappointed this week that the Embedded Systems Conference didn’t yield a whole lot of news about wireless sensor networks. Normally, a big ol’ flurry of press releases would precede a trade show like that, but it doesn’t seem to be the case this year. This could mean that there’s not a lot of new products to announce, or that companies aren’t relying on trade shows to make big news splashes anymore. An interesting (and probably revealing) thing is that this year, they gave away free engineering survival kits . They aren’t for surviving in the woods, or even bad debugging sessions like the 'volatile' bug I mentioned earlier. They’re for surviving layoffs. Interesting way to set the tone of the conference.

Well, I guess that’s about it for now and pretty much all the interesting things I have to say. Actually, outside of this website, my life is really quite boring…

I wrote previously about the meeting last week in Barcelona that the Continua Health Alliance had to choose a low power radio. The demos and lobbying are over and the decision mostly likely rests between two protocols: Bluetooth Low Energy and Zigbee. That decisions should hopefully come by the end of the month.

The rest of the protocols vying to be chosen are mostly proprietary and specific to a single radio architecture which is controlled by a single company. I don't think these stand too much of a chance because standards bodies, or anyone for that matter, would choose a single source supplier to base all their work on. This is especially true after what happened to Z-Wave now that they got purchased by Sigma. It's just a little bit risky.

A lot of people are talking about the battle between Zigbee and Bluetooth, but in my opinion, it's a no-contest. The problem isn't that one protocol is better than another. Zigbee has multi-hop capability and a potential entry point into the majority of homes in the US and many other countries through smart metering and RF4CE. Bluetooth has a huge established base in the mobile phone market that they snuck into via earpieces. The main questions to look at are:

  1. Which technology would fulfill the requirements set aside by Continua
  2. Which technology would allow medical devices to get to market quickly
This shouldn't be a political game. Continua was set up to standardize wireless medical device communications to benefit people by bringing interoperability and also lowering medical device costs.

So although both Bluetooth and Zigbee can handle the requirement of fulfilling the Continua requirements, the second one is a definite win for Bluetooth. Bluetooth's medical profile has been around since 2007 and they've had actual experience in designing products and applications with it. That means that the spec has probably been debugged, modified, and contorted to fit real world requirements. As they say, software and standards are like wine, they get better with age…Actually, I just made that up right now. Nobody really says that, but it'd be nice if they did. And remember who said it first…

2009-04-04: My argument on #2 for Bluetooth is no longer valid. Although Bluetooth is mature, Bluetooth Low Energy is not. Please see update at bottom...

Anyways, the point is that the Bluetooth medical device profile is more mature, has real world applications already available, and a large user base that it can leverage. They've also been working with the Continua group for a long time and the Bluetooth Low Energy spec has targeted medical apps almost from the beginning. Well, not exactly…there was an awkward adolescent time when they were Wibree and targeted wireless wristwatches, but that quickly went out the window when they realized that people just used wristwatches to either tell time or show off how rich they were. Of course if you look at the Bluetooth Low Energy spec, you can see that they don't support multi-hop routing. This is because the spec is designed for networks where everything is in close range, ie: a mobile phone and a few sensors being worn somewhere on the body. It's not like they were targeting farming where you need to disperse sensors across corn fields or grape vineyards.

Also, Zigbee was rightfully busy handling smart energy which turned out to be the biggest thing that could have happened to the Alliance. I believe there's a consensus that without smart energy, Zigbee could possibly have ceased to exist. This meant that they had to put a lot of focus on the tough deadlines that were handed down to them from the bodies that contracted the work. I've talked to some of the people involved back in early 2008 when they had impossible deadlines to meet to show working smart energy applications. I'm surprised that they didn't lose a couple of members due to heart attacks. Now all of that work is paying off and Zigbee is taking off with the stimulus package funding smart grid renovation. However the down side is that the Zigbee Personal Home and Healthcare profile (actually renamed to Zigbee Health Care, I believe) was a bit neglected as the group was fighting for its life.   

Right now, Bluetooth Low Energy is in the same position. If it doesn't get the Continua bid, then I can't really think of any other application it has. I suspect that it would just cease to exist. The spec committee literally bet the farm on this one bid, and have been preparing for it for years. So in terms of a standoff between Zigbee and Bluetooth Low Energy, I don't think that Zigbee will win.

The main thing that worries me is that work will be stopped on the Zigbee Health Care profile if they don't get the Continua win. The Zigbee Alliance has made huge strides in the last year and cemented themselves in the market with the smart energy windfall and the RF4CE remote control standard. It's almost guaranteed that Zigbee will be the main WSN standard inside the home. So let's not be greedy. It won't be the end of the world if Continua chooses Bluetooth. In the meantime, Zigbee can focus on smart energy, RF4CE, and finishing the health profile, and take the next battle for medical device supremacy to the market instead. By that time the Zigbee Health Profile should be more mature, field tested, and have a large user base it can leverage. If it's really better for medical devices than Bluetooth, it'll show up in market adoption. In my opinion, that's always the real test for any technology.

And the company that said they'd give up on the Zigbee Health Care profile if they didn't get the Continua win...should really man up and a grow a pair of balls...

Updated 2009-04-04: Looks like there's a chance for Zigbee after all. I was looking over the Bluetooth Developer's Preview to see if I should sign up and check it out. It turns out that the Bluetooth Low Energy spec hasn't even been published yet which came as a major shock to me. When I got the developer's preview email, I had thought they were going to preview devices, and not the actual spec...*sigh*...[/Akiba]

Wow, it’s nice to be taking a short breather, especially after this week. It’s been an emotional roller coaster.

It all started with the smart grid hacking fiasco last weekend. I woke up on Sunday morning and saw the article that got put up by CNN . There was very little info on the actual vulnerability other than some comments made by Travis Goodspeed as one of the researchers that was working on the security testing. I then assumed that the vulnerability was referencing the side-channel attack pointed out on Travis Goodspeed’s blog the week before and wrote a counterpoint article based on this. Of course my basic assumptions were wrong , and little did I know when I wrote the post that the whole issue would blow up the way it did.

Anyways, now that there is slightly more info, it looks like a host of vulnerabilities were discovered as pointed out in the press release from IO Active , the security company doing the research. Also, we got to see this interesting correction made at IT World based on comments from Travis Goodspeed. It could imply that Zigbee wasn't at fault for the worm that made headlines since his specialty is on WSN security.

Anyways, one thing that is clear is now that wireless sensor networks are starting to get deployed in the real world, security and security testing will become very important. Also, the bad press associated with vulnerabilities that are allowed to slip by is going to become extremely painful.

Moving right along, after that whole issue kind of died down, Zigbee announced the release of their Personal Home and HealthCare (PHHC) device profile. This was really great and I’ve been wondering when this would be released. You’d think that I have access to these documents being a member of Zigbee, but since I’m on the lowest rung of the membership ladder, I only get access to publicly released profiles, which are…ahem…public. The main benefit of membership is that I can attend interoperability events and its kind of cool for an open source project to be part of Zigbee. Anyways, it doesn’t matter too much whether I have early access to profiles in development because I’m struggling just to get to the point where I can implement the released profiles.

The PHHC spec will be really interesting because it will allow interoperability between medical devices which is one of my main goals for the stack. However it’s a bit of a precarious position for the Zigbee Alliance. If you read between the lines, the release of the Zigbee PHHC profile was probably forced, due to a big event going on right now. Probably not a whole lot of people are aware that there was a big meeting in Barcelona, Spain this week by many different wireless protocol groups because the Continua Health Alliance was going to decide on a radio for their specification . This is probably why you’ve also been seeing the recent press releases for ANT+ , the low power protocol based on the Nordic chip, with the focus on the press releases for health and fitness applications. For those that don’t know, Continua is a group that is trying to enable interoperability between wireless healthcare devices and they have very significant industry backing. This decision will probably decide the protocol winner in the wireless health device market, and as Nick Hunn mentioned in his blog , a prominent Zigbee backer mentioned that if Zigbee wasn’t chosen, his company would probably cease development and support for the PHHC.

At a recent conference a spokesman for one of the major chip companies behind the ZigBee PRO healthcare profile let slip the fact that if it failed to win Continua approval, his company would probably kill their ZigBee PRO healthcare development effort.

This is the precarious position that Zigbee is in on the medical device front. Most of the attention and marketing dollars for Zigbee went to their bid towards the smart metering initiatives. If you’ve been following the newsfeeds on the blog recently, you’d have seen that the majority of the Zigbee news is related to the smart grid upgrade. Bluetooth Low Energy, on the other hand, has been quietly working and lobbying with the Continua Health Alliance for a while now and they are in a good position to win the radio decision. Either way, the results can only be good for the world since a single standard will allow the big boys to start implementing wireless medical devices and hopefully bring down the cost of healthcare.

Of course being an small, independent, open source project, I don’t much care about Continua, political, or market forces because I exist in my own small bubble. I’m determined to add support for the PHHC in my stack and hopefully, enable other open source groups to make interesting medical products. I did a code drop this week with code to support all the way up to the Zigbee Cluster Library which sets me up for implementation of the profiles. Of course I was a little disappointed to find out that Zigbee Residential isn't really being supported by too many vendors, hence nobody to play with at the interoperability events. So I had to make the decision to change my plans and start targeting Zigbee Pro. Luckily, a minimal implementation of Zigbee Pro doesn't require a whole lot of extra features so I'm hoping it won't impact the time it takes to get a usable version of the stack too much. 

So as you can see, there’s been a lot of drama this week and quite frankly, it's all a bit exhausting. But one thing is for sure: wireless sensor networks are starting to take a prominent role in many industries and what we’re witnessing are the growing pains as it makes the transition from theory to reality. I feel lucky that I’m part of this and can watch it unfold. Ahhh...I remember when I could go a couple of days without any WSN news to post. Now its taking up quite a bit of time just covering all of it...

So now it’s time to rest up a bit. I’m expecting a lot of news next week with the Embedded Systems Conference taking place. There’s a big focus on sensor networks, energy harvesting, smart grid and renewable energies, and many other things that I’m sure will tickle my pickle. It’s a bit exciting...

I just wanted to clear the air on that last post I made regarding the side-channel attack by Travis Goodspeed. I received a lot of feedback from people involved in wireless sensor network security and also people involved with the actual issue being discussed. Regarding the emails I received from the people involved, I can't reveal much without causing problems for them and actually didn't get a whole lot of information. However they did inform me that my basic assumptions were wrong and the vulnerability issues did not involve the side-channel attack. They also hinted that SCADA may be involved. From the IOActive press release issued on Monday, it could be inferred that multiple vulnerabilities were found to exist. My personal suspicion is that different attacks may have been chained together to create a worm that could propagate such as an attack such as one to gain access to a device, and then a different set of attacks to propagate the worm. 

The security company that ran the testing had been doing it for about a year and were most likely contracted by the same people involved that contacted groups like the Zigbee Alliance and other organizations for the smart grid upgrade. Hence, my post had taken the issue too lightly in assuming that only one attack or even one protocol was involved. It's starting to sound like multiple communications protocols were involved and that the vulnerabilities are a system issue rather than a defect of any one technology in particular. 

And finally, regarding Travis Goodspeed, he is a supporter of wireless sensor networks and is trying to improve WSN security by making his findings public. If you check out this presentation he previously made at Toorcon on the vulnerabilities of 802.15.4 and TinyOS, you can see that he has a deep understanding of the CPU architecture and memory handling and tries to impart to the audience basic security principles for embedded systems on his final slide:

  • NEVER use null-terminated strings.

  • Use Java if it's affordable.

  • Test and audit your code thoroughly.

Hmmm...not too sure about Java on embedded systems, tho :)

Although my post on the smart grid vulnerability may have looked like it was targeted at him, it was actually an expression of my frustration with the media who I thought took his side-channel attack and extrapolated it into a media frenzy about how wireless sensor networks make the smart grid vulnerable to attack. In retrospect, I regret that I jumped to conclusions when I first started to see the media wave building, but because of it, have learned many valuable lessons on the importance of designing stacks with security in mind...especially that if you don't, there's gonna be a huge public backlash.

And in case you're interested, here's the press release issued by IOActive on Monday 03/23...

Updated 2009-03-25: Aurelien pointed out a very interesting link at IT World. Apparently, they made a correction:  "Due to incorrect information provided by a security researcher, the story misstated the state of research into malicious worm technology for Smart Grid devices. The researcher quoted in the story, Travis Goodspeed, said his earlier comments were based on erroneous information and that research into Smart Grid worms is theoretical. The deck headline and paragraphs three and 10 have been changed." Link