Along with working on the RF hardware for the Zigbee development platform, I've also been pretty busy with helping get the Tokyo Hackerspace up and running. This past Saturday, I co-taught a class on basic electronics for members of the hackerspace as well as the Tokyo 2.0 crowd.

The Tokyo 2.0 group is mostly a bunch of IT people in Tokyo that get together once a month to talk about all things tech/IT/internet. The meetings are semi-networking events where you can see a bunch of hipster geeks sipping beers in a night club turned conference hall with a DJ spinning carefully selected non-intrusive music. I figure they're trying to recreate the hip, tech vibe that you see at events in San Francisco or SXSW (South by Southwest). 

The last talk was about cloud computing and I actually went to check it out since I had no clue what cloud computing was. After the talks, I can definitely say that I still have no clue. It seems it means different things to different people, but in my opinion, it just sounds like a fancy name for cheap web hosting. 

Anyways, the class turned out pretty good and everyone was enthusiastic to learn about electronics. It wasn't easy teaching the basic principles of electronics within two and a half hours, but we managed to pull it off. These days, you pretty much just need to know a bare minimum of theory since the main goal is usually to get the signal of interest into a microcontroller. However we had to conceptually explain and show what resistors, capacitors, diodes, voltage, current, and transistors were. I think teaching basic electronics is much more difficult than teaching more advanced topics because you have to really have mastered the fundamentals to teach it well. It was certainly a challenge to explain things in a way that non-electrical engineers could visualize and understand conceptually.

Along with that, I also got the first batch of the Tokyo Hackerspace development boards back. We'll be selling these in order to raise funds to buy equipment like oscilloscopes, soldering stations, and furniture. It's also going to handily serve as a common platform for future workshops that we do for embedded programming and analog interfacing to digital circuits. 

When we were discussing the boards, I gave people the option to choose different solder mask and silkscreen colors and made it a majority vote decision. The winner was a red silkscreen with a white soldermask since that was supposed to be symbolic of the colors of the Japanese flag. However the red lettering over the white solder mask made the silkscreen come out pink. I was surprised at first, but it really grew on me. The color scheme is definitely different than any other boards I've seen out there, and it appeals to the girls in the group who wanted a girly board. FYI, a lot of the guys wanted a red mask with black silkscreen which was a bit overly testosterone-charged. It would've made the boards look like video cards.

Also, I threw down some cash and bought some cheap, surplus multimeters from Akihabara for the group. It's mostly symbolic, but it's to show that we're taking steps to equip the hackerspace.

Overall, things look like they're moving forward  quite well. The space/studio is already rented and we should be moving in there next month. We're also planning an art/tech exhibition inside and inviting different artists and IT people to collaborate on it. 

So basically, with this and Zigbee, looks like things are going to be getting pretty busy for a while.

Here's a couple of pics of the boards and other miscellanea...

Took a half day off yesterday to hit up Wireless Japan 2009. One of the things I noticed about the shows this year is that they're much smaller than the events that were held last year. I guess show exhibitors is a pretty decent gauge of the economic health of an industry.

One of the things that surprised me is that I actually knew people at this year's Zigbee Pavilion. I guess the Zigbee community is pretty small. A couple of people actually recognized my blog as well which surprised me. I've spent so much time isolated in Japan that I have no clue about the audience, other than the webstats. And I suspect that half of the webstats are actually computerized bots that just want to spam my site. 

One thing that disappointed me was that TI Japan was conspicuously absent. I was hoping to talk to them because I'm not getting any responses for inquiries on purchasing the radios from the Japan disti. I was hoping to add some CC2520s to my dev board radios since they currently seem to be heavily weighted towards Atmel.

Speaking of Atmel, I was talking to the Atmel product engineer and he mentioned that there are a lot of things coming out soon on the Zigbee front. He was pretty straightforward about them so  I don't think they're a big secret (the datasheet was visibly open on the laptop and he was carrying samples in his pocket). They should be an announcing a single die AVR + radio based on the AT86RF231 soon. This would be a major improvement because their previous multi-chip modules that combined the AVR and 802.15.4 radios didn't seem to get very popular within the 802.15.4 community. You know its bad when they don't even have dev boards with the chips on them. Their most popular dev kit, the Raven, has a discrete AVR MCU and radio. They should have some new dev boards out soon as well.

I was also complaining to him that Atmel was ruining the price of dev kits and modules for everyone by pricing the Raven USB sticks at $40. He just smiled and said that it wasn't the first time he heard that complaint. Apparently, the original price for the Raven USB sticks were $29 but they had so many complaints that they had to raise it to $40. Damn...if they had to buy their own chips, they'd be losing shitloads of money. Other than that, the Atmel guy is totally cool and I told him that if he had free time, we could go to dinner. I hung out with him last year too and the guy's a total trance head. He would stay out until 5am and hit up the trance and techno clubs. Heh heh...my kind of engineer...

Checked out the new Ember EM351 ARM Cortex chips too. I have a feeling that they'll be popular in the metering industry since the current EM250/260 series is currently bursting at the seams in terms of code space. It's probably due to all of the security and features that got added into the Zigbee Smart Energy profile, so the Cortex lineup should ease things on that front. 

And one of the things that kind of made me sad was seeing the ANT display at the front of the Nordic booth. ANT is a separate company from Nordic, but you can buy ANT chips which are Nordic nRF24xx chips with the ANT stack in the flash pre-programmed. The problem is that Nordic is making a heavy push towards Bluetooth Low Energy whose guns are aiming directly at the market that ANT made a niche out of. ANT has a good following in the personal health and fitness industry because the protocol is low power, small, and uses the nRF24 which is fairly cheap. However Bluetooth Low Energy is competing directly in this market, plus they have the backing of the cell phone giants and connectivity with Bluetooth enabled cell phones that sport dual mode chips. It's probably going to put the nails in the coffin of ANT if BLE is anywhere near as successful as they hope. It was also the first time that I heard an ANT rep bash a protocol other than Zigbee which was quite amusing.

And finally, here are the pictures. I threw in some eye candy just to see if it'd attract more visitors to the site. If so, then I might turn this into a combined Zigbee/trade show models site. Something similar to LowRider magazine and they're artistic use of females. Enjoy!

Yeah, it's been a nice little vacation from the Zigbee stack for me. You wouldn't believe how fatiguing it is to focus on one thing for a year and a half. The stack became part of my life, like I was growing a third arm (or a third leg...*ahem*). So intead, I've been focusing on building hardware development boards that I can use to set up Zigbee networks for real-life testing of the stack. Although it's going to take some time, in the end, I'm sure it will pay off. There's nothing like having access to a large supply of development boards that you can use as wireless sensor nodes. At least it beats having to purchase something like ten raven kits.

However that's another story. I've been spending a bit of time getting the Tokyo Hackerspace boards up. There was some initial hardware flaws that I found but after they were fixed, I got the board up fairly quickly. I was worried about porting my USB stack on to it since the AT90USB16 USB controller is different from the ones on the Raven board (AT90USB128). As an engineer, I was expecting all types of things to go wrong and was ready to pull out the USB protocol analyzer. Lo and behold, after the initial register configuration, the USB icon popped on to my screen and it came up as a COM port.  It was probably one of the first times for me that bringing up a board went so smoothly.

I can't really say that I was testing the boards out. It was more like playing. Working on the stack for so long prevented me from messing around with smaller circuits and trying out fun things since I was putting pressure on myself to get it running. However being part of Tokyo Hackerspace gives me an excuse to explore different components and try things that might not necessarily be WSN related. In essence, it gives me permission to play with electronics which is great.

I was worried that the AT90USB16 might not have enough juice to do a lot (500 bytes RAM, 16kB flash) but I figured I might as well try. So the first thing I did was throw up a command line on the THS board. I just re-used the same one I'm using on FreakZ so it went pretty fast. Once I got the command line going, it was time to play. I wrote a command to toggle the various LEDs on the board, but that got boring pretty quickly.

I wanted a way to demonstrate to the Hackerspace members how it could be used for rapid prototyping of small circuits. That's always a big obstacle because people talk a lot about different things they want to design, but the bottleneck is always in implementation. If it were easy to do a proof of concept implementation, I think it would ease up the design juices and let people get more daring with what they attempt. So I figured that GPS might be a bit impressive. I just happened to have a GPS module given to me from my friend in France. It's quite a nice one and goes for $60 on Sparkfun. The specs are very impressive: it can track 32 satellites at one time, can track position info even in deep canyons and dense foliage, and can update position info up to 5 times a second. Just what you'd expect from a geek gift and something I'm definitely going to use the next time I'm trekking through the dense jungles in Southeast Asia. 

Well, since it was just collecting dust in my parts bin, I pulled it out, soldered some headers onto it and prayed that it still worked. Let me just say: 3 wires, 8 lines of code, and no soldering. It was totally sweet! I was getting raw GPS position data and dumping it to the console. The breadboard peripheral was even better than I had hoped. 

After that experiment, I decided to play with the RGB LED. This is all in preparation of doing a demo to the Hackerspace folks with the board. I wanted to generate some excitement so that people can get motivated to think of interesting projects. I had previously talked to one of the members about designing LED based jewelry. He had mentioned that most of the LED accessories blink which is harsh and gaudy. He wanted something that would slowly pulse which is a more subtle effect for an illuminated accessory.

So I took some time to write some PWM code to control the brightness of the LEDs on the RGB LED. I basically had a 100 Hz update rate (10 msec period) for the PWM and divided that up into 255 intervals of ~40 usec. It's easier than it sounds. After that, I just had a simple counter that kept track of the phase and would turn off each of the LEDs if it matched the counter. Basically, it was just standard software PWM. I implemented some commands to manually control the brightness and also commands that could pulse the red, blue, or green LEDs with a specified pulsing interval. I think I'll probably re-use the same code for the AC light dimmer that I'm going to be using to test my Zigbee Cluster Library implementation. 

So anyways, here's some pics of what I did. I also presented it to the group last night. I can't remember the reaction very well though because I was kind of drunk. Pretty typical for a hackerspace meeting...

And in case you're curious, the final memory footprint including USB stack, command line, PWM, LED pulsing, and GPS was slightly under 8kB flash and about 280 bytes RAM. Looks like the tiny machine can pack a bit of a punch...

Today was kind of strange. The PCB files went out, the parts have been ordered, documentation's been written, license was changed, and the release was issued. I really had nothing to do today and it was a strange feeling. I started getting fidgety so I decided to investigate a problem with my USB device stack on Linux that someone reported. No problem found...worked on Ubuntu. Great. After such a long time pushing myself with all the stuff that needed to be done, having an involuntary free day like this was really eerie. I didn't know what to do with it.

Another strange thing was that Michael Jackson passed away. I was always a big fan of his, since my days as a pro dancer. If you're in the entertainment biz, you can't help but admire MJ, who was one of the few people that really knew how to put on a show. There's a reason why MJ, JJ (Janet Jackson), and Madonna are still the reigning icons in pop. My wife was devastated. She's a member of an online social fan club for MJ in Japan and I had to pretty much forcefully hold her back from buying a ticket to LA.

Bizarre...

We had the second meeting of the Tokyo Hackerspace today and I got a chance to present the design idea I had with the development boards. The response was more positive than I expected. We also got a chance to discuss what everyone wanted to get out of the group. I know I've mentioned this before, but there is a huge amount of IT brainpower and experience within the members. A lot of the interest centered on interfacing electronics with web services and physical computing. I'm still trying to get a handle on what physical computing actually is, but I suspect that it's where you interface a PC to real objects like sensor gloves and clothing. Rob Faludi, if you're out there, could you please enlighten me on this subject? 

Anyways, one of the best things is that there is so much energy to learn and try new things. It's like the complete opposite of working with real engineers. I suspect that I'm going to learn more than they will when all's said and done.

In the meantime, one of the issues I think we're going to face is to distill all of the areas of interest into things that are do-able. I think the best way to describe this would be how to separate things into baby steps so that we can actually make progress on hardware hacking and cool projects. I was discussing this with one of the other electronics guys and we think that, on the electronics front, there needs to be some workshops on fundamental electronics and embedded programming. On the other side, I think that we also need to tap some of the computing brainpower for web services and how to access them, as well as the experiences of the artists, musicians, and chefs. Once we can start diffusing the knowledge and experience, I think there's no limit to the design possibilities.

One thing I'm pretty sure of is that Contiki and uIP are going to be really popular. I'm going to be bringing in the Raven wireless boards at the next meeting and showing them some basic Zigbee functionality as well as explaining 6LoWPAN (IPv6 over 802.15.4 for the uninitiated). I'm pretty sure that it's going to spark a lot of ideas. 

Stay tuned, because I think this group has the power to realize a lot of the things that the WSN industry is just talking about. At least...(*buzzword alert*)...the Internet of Things, as applied to real things...

A lot of people waiting for the code release are probably wondering what the hell I'm doing. In fact, I'm even wondering that myself sometimes. The truth is, I've been spending all my free time in the last week and a half trying to design development boards for the stack. So I've finally finished the schematics for six different boards, three MCU boards, two radio boards, and a peripheral board. Designing the boards is actually quite fast, and if it were just a matter of putting the components together, then I think I can usually put together a board in a couple of hours. The problem is that component selection takes a long time. Have you ever seen the DigiKey catalog? That thing puts most phone books to shame.

One of the issues with component selection is finding a reliable supply of components. DigiKey has a habit of running out of components right when you need them, so I've been trying to choose components that are generic enough to have a second source supplier. On top of that, I'm trying to use components that I can source locally in Akihabara in case I get into a pinch in terms of delivery schedules. Along with that, you have to check the package sizes, draw the circuit symbols, the PCB footprint, and check the specs to make sure everything is kosher before you actually take a chance and throw it on the board.

The reason I needed to get the schematics out of the way is because I needed to place the orders as soon as possible. Once the orders are placed, then there will be a time lag that would allow me to do other things like finishing the docs and doing the PCB layout. Also, I wanted to grab the components off of DigiKey as quickly as possible because some of them were disappearing quickly. One of them was the DC-DC boost converter from TI (TPS61202) that can boost a 0.5V source up to 5V. I was planning on using these for my main MCU boards so that it would be easy to interface them to batteries and solar cells. Since they were new and energy harvesting is kind of a trendy thing in electronics now, they were disappearing quickly. I finally bought out the last of the stock from DigiKey so they're completely sold out until the next shipment. The MCU boards that use this chip will be a limited edition until the supply stabilizes.

Along with the wireless dev boards, one of the MCU boards I designed was for Tokyo Hackerspace. There are a lot of people there that are curious about electronics and want to learn more about it. So I put together a low cost board using a USB AVR (AT90USB162) with 16 kB flash. The board has the same modular connector that I'm using for my main dev boards so it can interface to the same peripherals. One of the peripherals that I created specifically for this board is a quick prototyping area using an adhesive-backed solderless breadboard. It's those white plastic things with a bunch of holes that you had in electronics lab back in school. Anyways, since the breadboard can plug into the MCU board, it will automatically have a 3.3V and 5V supply as well as GPIO, interrupt, I2C, and SPI lines. I think it's going to make a good learning platform for the people curious about electronics in Tokyo Hackerspace.

The plan is to make a "class set" of about ten boards that everyone can use free of charge and can also be used for a common platform for workshops, classes, and collaborative projects.  If people want their own personal board, they can purchase it through Tokyo Hackerspace with the proceeds going to buying basic equipment like soldering irons, hand tools, meters, and scopes for the group. 

Also, I'm thinking about what kind of workshops would be interesting. Along with basic electronics and programming, I'll probably collaborate with one of the other geeks on electrical/mechanical interfacing, and of course I think sensor interfacing will be quite fun. I'm also hoping that I can do some more advanced topics like embedded web servers using Contiki and uIP, and of course hands-on tutorials with the FreakZ Zigbee stack, but I'm going to have to wait and see on those ones since they require quite a bit of programming knowledge. 

I'll keep everyone posted on how things go with this, but Tokyo Hackerspace looks like it's going to be fun and keep me a little busy. Here's some shots of the initial MCU and breadboard PCBs for THS. No, the tower in the logo isn't the Eiffel tower. It's the Tokyo Tower located in Roppongi and is part of the Tokyo Hackerspace logo. One of these days, I might even go check it out:

AT90USB162 Dev Board for THS

Breadboard peripheral for THS

 

Just attended the first meeting of the newly inaugurated Tokyo Hackerspace tonight. I've been looking for a group of people that are interested in electronics design for awhile, especially those that like offbeat designs.There's a good mix of people with some artists, physicists, a bunch of IT people, singers, and caterers. It seems like it's going to be really fun, and I think a lot of good things can happen when you have open source collaborations with a bunch of people from different disciplines. The funny thing is that closed source doesn't lend itself well to collaboration, since each side is always worried about disclosing their IP. 

The group is pretty heavily skewed towards people in the IT industry which should turn out pretty interesting. If things work out, you might be seeing Zigbee wireless sensor networks getting integrated into internet technologies. Plus, it might give me a chance of actually having a social life...

This is the second part of the writeup on the Bluetooth Low Energy event and should get into the meat and bones of the spec. I dropped the timestamps since I think they don’t mean that much after a certain point. I'm also holding off on the pictures, mostly because I'm too lazy to upload them. Sorry, but it's going to be a text fest.

Consumer Health
Tsutomu Miyoshi, Tanita

After the Casio presentation, Tsutomu Miyoshi started discussing Bluetooth Low Energy’s application to consumer health devices. You probably haven’t heard of Tanita too much if you’re not from Japan. Japan has, in my opinion, some of the world’s most sophisticated body scales (as well as toilet seats). If you want to know where the innovation from this country goes, I suspect a good deal of it ends up here. That being said, Tanita is one of the main manufacturers of consumer scales in Japan.
He started off by discussing Tanita’s move to consumer scales that connect to an online website where people can share their body weight, fat percentage, and loads of other things that I’d probably not want to know much about. There are two methods of transferring the data to a PC or gateway (yes, there’s a body scale gateway available through NTT): infrared and RF. The infrared is the cheapest method to use, and although the data rate is low, it is good for both battery life and cost. The problem is that it requires a line of sight connection.

The RF uses a 400 MHz low power radio and sends the data to a router provided by NTT for the Hikari (light) diet system. Once the data is uploaded, you can share it with others within your social groups, or diet groups I guess, and do other social things that you’d do with that kind of information. The site is also used to organize group walking events and each individual user can track the amount of steps taken, calories burned, and before and after weight.

He then went on to discuss how BLE can improve on the existing products and systems that Tanita is producing. The interoperability would allow other manufacturers to add to the Tanita health ecosystem. Then, he went into his grand plan which really freaked me out.

In Japan, there is currently a movement by the government to eradicate obesity due to the costs to the public insurance system. Before I continue, here’s some background info. In Japan, employees and students, or anyone under the public health insurance plan is required to take a physical checkup once a year. The idea that was proposed by the government was that if the doctor giving the physical determined that you were obese, they will insist that you meet with a nutrition advisor. The advisor will recommend a diet plan and equipment to monitor your weight, body fat, fitness, and progress. The data would be uploaded to a centralized database via the internet and the advisor will be automatically alerted if there are any problems with the diet plan. I can only assume that that phrase means that you’re not losing any weight. In the US, I’d be able to hear the privacy groups sharpening their legal axes, but for some reason, in Japan, I don’t think there is any opposition to this. Tanita’s proposal was that using Bluetooth Low Energy would facilitate the communication between the health monitoring devices and the centralized database via the phone or a BLE router.

I think that I now realize why some people are concerned about wireless sensor networks and privacy. It wasn’t exactly the best example he could have used to put BLE in a positive light, however there is a cultural difference in how Japanese people think vs Western cultures (ie: US, Europe) so I don’t think it struck him as invasive and horrifying.

Aside from that, he then went into details of what he wanted to see out of BLE:

  •    A very low cost single-mode RF chip
  •    Power consumption that would allow operation on a coin cell for long periods of time
  •    Usability issues addressed such as easy pairing between devices


BLE Technical Overview
Robin Heydon, Cambridge Silicon Radio

I had expected this guy to come out with horns and fangs, since he’s such a Zigbee and 802.15.4 basher. He was the one behind the blog I pointed out a few weeks ago that bashed both protocols, while he kept himself anonymous. I removed his name from that post because I didn’t want it to get picked up by the search engines (also the reason I’m not mentioning the blog name…you’d be surprised how efficient the Google bots are).

Well, other than looking like the comic book store guy from the Simpsons, he was a soft spoken man that was very passionate about his work with BLE. I must say that my image of him changed after watching him talk, however I still think its cowardly to bash other protocols anonymously.

His presentation, however was probably the most interesting out of all the other ones because he was one of the people that was getting his hands dirty in it. He’s writing the spec for BLE and addressed a lot of the differences between Bluetooth and BLE. Here is my quick one-minute summary:

  • BLE uses GMSK modulation instead of GFSK for Bluetooth with a modulation index of 0.5.
  • BLE only uses 40 channels as opposed to a much larger number of channels for Bluetooth. 37 data channels are for adaptive frequency hopping (AFH) and three channels are used for advertising and discovery.
  • Link layer has four states: scanning, advertising, initiating, and connected
  • BLE now only has one fixed packet structure with two types of packets: advertising and data. FYI, this is similar to 802.15.4 with command and data frame types, but 802.15.4 also uses two extra types: beacon and ACK.
  • BLE has a feature called a “lazy ACK” where the ACK arrives within the next data frame. I’m not sure how they would handle ACKs if only one frame was transmitted though since they only have two frame types.
  • BLE has simplified link messages: 8 link layer control messages vs 75 messages for normal Bluetooth
  • Application level protocols only use attributes. Bluetooth uses 9 different protocols to implement different device functionality.
  • Security management handled by the host. The slave can receive a long term key from the host along with a diversifier. The actual key is made by combining the long term key with the diversifier. Don’t ask me about any more details than that.
  • AES-128 is used for security and to derive the long term key for the slave.
Okay, so that was most of the protocol stack up to the application layer in a nutshell. I wanted to save the discussion of the application layer as a separate topic because I found it quite interesting.

The application layer uses a concept called attributes which is a generic data structure. Each attribute has a:

  • Unique attribute handle to identify itself
  • A data type field to identify the type of data
  • Access parameter, ie: read/write/set/discover

Also, attributes with similar functionality can be grouped together into services and profiles.

For those that are familiar with Zigbee, this sounds very similar to the Zigbee Cluster Library. Each cluster in the library is composed of attributes which have an attribute ID, a data type identifier, access parameter, and of course the actual data. Similar attributes are grouped into clusters and these clusters are re-used in the Zigbee Cluster Library among the different device profiles.

I think it’s not a coincidence that many protocols are realizing the need for something similar to generic attributes and groupings to standardize device behavior. To be honest, I hated the concept of the ZCL when I first encountered it and tried to understand how to implement it. However I can see now that it’s probably one of the best features that Zigbee has to offer and I think that’s why we seem to be seeing a lot of other protocols that are adopting a similar approach.

I think that’s about it for the BLE technical presentation. I can’t remember too much more than that, which may mean that it was too technical to sink deep into my head.

Enabling Innovation
Karl Tormark, Texas Instruments

This guy talked about Bluetooth Low Energy being used for refrigerator magnets. I automatically tuned him out.

Making Internet Connected Products Easy
Nick Hunn, WiFore

This was the last presentation I attended. I was already suffering from Powerpoint fatigue, but made it to the technical info which was really what I was after. To be honest, Nick Hunn scares me more than Robin Heydon who gave the technical presentation. Robert Heydon is basically a geek with an opinion, something that I completely understand. Nick Hunn is something completely different.

On his blog, he bills himself as a wireless evangelist and is also part of the Bluetooth Low Energy Evangelisation (shouldn’t that be with an ‘z’?) Working Group . That is just totally, fucking weird. Hearing him give his presentation, I can see that he’s a nice guy, soft-spoken, etc…but the scary thing is that he’s a technology optimist.

If you’ve been in the industry for a while, and are somehow involved with actual implementation, then you’re most likely a technology pessimist or a skeptic. That means that when I hear people making pie in the sky assessments about Zigbee like they’re going to sell a zillion 802.15.4 radios and Zigbee will take over the world by the end of the year, I just roll my eyes and continue to work.

Technology optimists are the guys in Silicon Valley or some other tech hub that believes that the next big thing will be location aware social networking where you can leave online messages at a café so your friends going there later will know that you’ve been there. You might as well just pee in the corner instead.

Anyways, his presentation was about internet enabling your products and he started off his presentation with a slide on the definition of an internet connected product…that’s when he hit everyone with the words: “Consumer Electronics 2.0”. He then continued on about how Bluetooth Low Energy will enable devices to communicate with phones while throwing out multi-bonus Scrabble buzzwords like "revolutionary as opposed to evolutionary" and "disruptive innovation". The phones will support BLE Gateway functionality which provides a pipe to the internet. Middleware would then be able to access the device directly (via the phone). The data collected from the devices will be uploaded to some web application via a web service. All this will be provided by Bluetooth Low Energy. “Any gateway will be able to work with any device”.

Yowzah…that’s the kind of talk that makes me cringe. You should avoid anyone that tells you stuff like that for any technology. He just spanned something like a half decade of spec development, multi-million dollar research and development, and probably a couple of thousand man-months of coding with a wave of his hands. Is it possible? Sure. Is it possible within five years? Hmmm….

Conclusion
Well, my venture out into the world of BLE was quite interesting and informative. I wanted to check it out firsthand because there’s so much shit-slinging between the different protocol camps including Zigbee. Since I cover news on all different WSN topics, I’m naturally curious about the reality of the strengths and weaknesses of any protocol. There’s no one protocol that can cover everything.

My final conclusion is that Bluetooth Low Energy is a spec that is being developed to extend the functionality of mobile phones. They aren’t looking at real wireless sensor networking, in the vein of multi-hop systems and monitoring and control applications. Instead, they seem to be trying to connect different peripherals to phones, with a bizarre emphasis on watches. In my opinion, they’re trying to be the USB of a mobile phone, where you have an easy interface that provides access to the wealth of functions that a mobile phone can perform. Since mobile phones are becoming like mini-computers that everyone carries with them, this is probably a good choice from a commercial perspective. Many new devices can be created to connect with a phone and the market is already there. However it’s most likely going to enable a new generation of gimmicky gadgets geared towards yuppies and techno-freaks.

From a WSN point of view, I think a big weakness is that the mobile phone plays such a dominant role. Many important WSN applications won’t be in the proximity of a mobile phone and will most likely be autonomous, just collecting data or with someone remotely controlling valves and switches. This might have the unintended effect of relegating BLE into a single-hop universal gateway interface to a phone rather than a serious wireless sensor networking protocol.

One of the big issues I had was that the Bluetooth profiles won't work with BLE. This means that all the work that went into the Bluetooth Health Device profile won't be able to be carried over to BLE. This was a major disappointment and I need to retract my old blog post about BLE and Continua. I don't think the BLE spec is ready for medical devices and I think that it's going to be a quite some time before they can have a real spec dedicated to them. 

Updated 2009-04-21: Just got an email saying that the BLE presentations were uploaded. I'm not sure if you need to register to view them, but they can be found here .

Hi all. I checked out the Bluetooth Low Energy Developer’s Preview Conference in Tokyo today and jotted down some notes about each of the speakers and presentations. Here’s the writeup on it:

10:46 am:
Just arrived at this event about 20 minutes ago. The keynote was actually at 9:30 am, but I decided to skip it because it sounded like a yawner. I needed some extra time to feed the dog and take my morning poop. My target was to arrive at 10 am, but I decided to try out a new subway line this morning. It turned into a total disaster where the subways came infrequently and I got lost twice in the underground catacombs. All in all, I lost an additional 30 minutes and missed the second presentation which was Bluetooth Low Energy marketing. Fortunately, I wasn’t too interested in it, since the main presentation would be the technical details of the BLE spec in the afternoon. I arrived just in time for the break in between presentations so I grabbed two cups of coffee and decided to walk around. There weren’t any devices on display and the morning attendance looked a little thin. Probably others had the same idea I did. A nice thing was that they had real-time translators and transceivers with earpieces so you could listen to the presentations in Japanese or English. I asked the person next to me if the transceivers used Bluetooth Low Energy. He didn’t think it was too funny.

11:00 am:
Mika Saren, Nokia

Mobile Phones as Network Gateways

The next presentation is about to start. The speaker is Mika Saren from Nokia. He discussed a lot of phone-centric concepts in wireless sensor networking and I got the impression that BLE is mainly about phones. It makes sense because it would give BLE a huge installed base and increase the functionality of phones. If that’s the case, it might be a master move by Nokia.

His talk focused on mobile phones as a gateway to new types of service that enable data collection from sensors and forwarding to online servers via the phone. It was mostly focused on health monitoring and also sports and fitness where the sensors are worn on the body and transmit data to the phone. I’m not too sure how many soccer players play with their cell phone in their pockets, but maybe I’m just not too knowledgeable about soccer. He did give an interesting example of how a phone that uses BLE can sense your location and change your phone profile based on it. Hence when you’re home, it can switch work calls to voice mail, etc. I would think they could already do this with GPS, though.



 11:17 am
Bluetooth Low Energy for Sports and Fitness
Marco Suvilaakso, Polar


This guy spent way too much time talking about his company. Polar makes fitness technology devices like wrist-worn heart rate monitors and body sensors. They are used by people like triathletes to monitor speed, heart rate, etc. His presentation looked like it was just copied and pasted out of the company’s marketing presentation, and there was even a section on Polar’s proprietary 2.4 GHz wireless protocol. After we got through the marketing part, then he finally started talking about BLE.

He showed a couple of slides about the applications that Polar is looking at using BLE for like wrist-worn transmitters that collect data from body-worn sensors team sports. This sounded kind of niche-y but he also had mentioned that fitness equipment manufacturers (ie: Lifecycle) could integrate BLE and work with Polar if the transceivers can reach a low enough cost point. If BLE takes off, then they will be able to have their body sensors communicate with mobile phones which act like a gateway to some online service. The image of Nike suddenly popped into my head which is what I think he meant.

The last section was the most interesting to me. He mentioned the work being done on the BLE health and fitness working group. They are currently working on a device profile for this segment and data from any low energy health device can be converted to the same ISO/IEEE 11073 data format used by HDP (I assumed this meant Bluetooth Health Device Profile) and USB personal healthcare class for data compatibility outside of Bluetooth. Apparently, this was mandated by Continua. Hmmm...I didn't even know there was a USB class for health devices.

By now, one thing is clear. The phone is going to be at the center of this spec. He mentioned that the dual-mode Bluetooth chipsets won’t cost any more than the regular BT radios. If so, then BLE might turn into a monster when the spec is stabilized and chips start rolling out. However in my opinion, there is still a lot of risk. USB tried the same thing with their On-The-Go spec which incorporated a host and device in the same chip. They underestimated two things:


1)    The willingness for companies to spend money to write new software
2)    If the host + device chips will cost the same as the device only chips, then the device chips could be sold for less.


I’m interested to see if BLE can navigate past these hurdles. Note: I was on the failed OTG spec committee…*sigh*



 11:39 am
Etsuro Nakajima, Casio
Bluetooth in Casio Watches


When this guy took the podium, he immediately established his alpha geek in the realm of watches. I am the proud owner of a Casio G-Shock and many versions of the former calculator watches, but it’s obvious this guy eats and breathes watches. His first slide was interesting in a non BLE way. The actual number of watches being sold has been decreasing since 2000 or so. Turns out that people are relying more on their cell phones for timekeeping and either don’t bother with watches or don’t buy them in the quantities they used do. The other interesting slide was that the total revenue from watches has been increasing steadily. This means that people buying watches are buying expensive ones, most likely for conspicuous consumption.

I wish I could go into the details of his watch presentation which was fascinating and went into the history of watches at Casio, different graphs on watch face size versus features, etc, but it’s a bit offtopic and probably not too interesting for anyone that’s not into Casios.

He made some pretty strong statements about BLE, the most memorable being: “Bluetooth Low Energy is the future focus of Casio”. Some of the features he’s envisioning is getting the time sync signal from the phone (which I assumes gets it from the cell base stations), phone control via watch, and sensor monitoring. The phone control thing sounds really cool. How fun would it be to send callers to voice mail by pushing a button on your watch.

He also mentioned some applications like an out-of-range warning from the watch when valuables go beyond a certain distance. This could be like car keys, wallets, etc. This was mentioned by the Nokia guy also, but I think it might be kind of tough. They are all planning to use RSSI for the proximity measurement, but from what I’ve seen and personally experienced, the RSSI can be influenced by obstacles, interferences and a bunch of other things. I remember Zigbee had the same concept back in 2005 but it kind of died off…Some of the other applications are things like a “panic button” that will automatically dial an emergency number on your cell phone (or to a hospital/call center), and an alert system that can be used to issue systemwide alerts, like if you’re in range of a missile hit. Don’t laugh, that was his actual example, and pokes some fun at North Korea who is constantly threatening to fire missiles at Japan.

The main point he was trying to make is that BLE is a better fit for the watch market than Bluetooth was and can help reverse the trend of declining sales volume of watches. He’s looking at BLE to pair watches with cell phones and piggyback on cell phone sales.
The last thing he kind of mentioned under his breath is that Casio is also looking into wearable devices. You listening out there, Mr. Faludi?

That's it for part 1. I'm going to continue with the writeup later. I need to cook dinner for my wife 'cuz that's the kind of man I am...a pussy... 

In an excellent confirmation of Murphy's Law, the day that I finished my taxes and was going to mail them out (no e-file if you're address is outside the US), my monitor and my printer broke.


There’s been some buzz on the internet lately that the smart grid is vulnerable to hackers . This coincidentally came out after a security company issued a warning about a smart meter’s vulnerability to being hacked, which coincidentally came out a few days after Travis Goodspeed discussed how to hack the AES-128 encryption on an 802.15.4 radio. I covered his post last Sunday , a day before the security alert was released. And for those that don’t know what I’m talking about, 802.15.4 is the wireless communications protocol which is used for Zigbee, one of the main wireless communications methods being deployed in smart meters.

So before everyone’s panties get all bunched up, I thought I would make an attempt to clear things up about this AES-128 attack mentioned in Travis' blog post. Fortunately, since I run an independent Zigbee site, it gives me a little bit of leeway to comment on this somewhat murky topic that touches on two taboo subjects: hacking and discussing 802.15.4 without inserting marketing propaganda.

First of all, how did we end up like this? Well, first Travis Goodspeed posted on his blog that he was able to capture the AES-128 encryption keys on an 802.15.4 chip using a side-channel attack (thanks for correcting me on the terminology Robert). Then it got picked up by Hack-A-Day , which is actually an interesting website that I like to browse every so often to see who made the latest automated home beer brewer. Incidentally, the hack-a-day post got linked to so much that it knocked me off my #17 position on Google for the “Zigbee” search term and so, as of this writing, I’m sadly sitting at #18 (Damn you Google and my lack of SEO knowledge about Zigbee Zigbee Zigbee...).

Anyways, from Hack-A-Day, it got linked to by a bunch of others sites including some news outlets such as CNET and CNN . In fact, it even made the headline news on CNN whose reporters probably know nothing about Zigbee, 802.15.4, or hacking, but decided to carry the story with the theme that upgrading the smart grid is unsafe and can make it vulnerable to hackers. Ughhh…upgrading the PC communications infrastructure is also unsafe and can make it vulnerable to hackers. Hmmm...upgrading to eBooks with a Kindle is also unsafe and can let hackers browse your collection of Sweet Valley High novels (that Jessica is such a bitch)...

So first, let’s deconstruct this sequence of events and take a look at the source…how the attack on the 802.15.4 node was performed. According to Travis’ blog, it was done by sniffing the SPI bus which is an external communications bus carrying data from the microcontroller to the radio. The microcontroller in question was the MSP430 on a TelosB board, famously used in TinyOS wireless sensor networks. The radio was a Chipcon CC2420 which has since become a TI CC2420 since they purchased the company a few years back. The attack was a side-channel attack which meant that they exploited the actual hardware implementation rather than a vulnerability in the security algorithm itself.

When you’re configuring the radio at startup, the first thing you do is write to the registers. You do this to turn the radio on, set the channel that the radio will be operating at, the transmit power, etc. One of the things you will also need to do is set up the security since the CC2420 has an AES-128 encryption engine on-board the radio. This is to offload the encryption processing from the microcontroller since typically, 8-bit microcontrollers (think Atari 2600) don’t have a lot of computing horsepower.

When you go through the security handshaking procedure, you will eventually have to write the AES-128 keys to the encryption engine on the radio and it’s at this point that the vulnerability occurs. If you use an SPI sniffer such as the Beagle SPI analyzer, you can just capture all of the signals and then search for the address of the encryption registers. When you see SPI writes to the encryption key registers, you can pick off the data accompanying those writes and that’s where the keys are exposed.

Incidentally, the security company in the CNN article that said the meters could be hacked for as little as $500 in equipment were wrong.

IOActive, a professional security services firm, determined that an attacker with $500 of equipment and materials, and a background in electronics and software engineering, could "take command and control of the (advanced meter infrastructure), allowing for the en masse manipulation of service to homes and businesses." 

The Beagle SPI analyzer is $300. Just thought I'd drop some ghetto engineering knowledge...

However the blog post doesn’t mention the limitations on the attack they performed and this point should be understood. The first limitation is that the device must be authorized to join the network. There’s no way that the device will ever be able to obtain the AES keys from the trust center (errr…meter) unless it’s an authorized device, since the meter doesn’t like to hand out keys willy-nilly. Hence, there’s little chance that you can just take a random device, sit outside of someone’s house, and hack into their network using this attack. It would have to be an inside job since smart energy devices will most likely require pre-installed keys and authentication information to identify the particular user.

The other limitation is that the device would have to use a separate microcontroller and radio, hence it can then have its SPI bus exposed with its nibbles flapping in the wind. However the Zigbee smart energy transceiver market is pretty much dominated by a company called Ember who decided to include the microcontroller and radio inside the same chip in which case, the SPI bus will not be exposed because it won’t exist.

Okay, so say some smart energy device manufacturer is using a separate microcontroller and transceiver. Incidentally, this is my favorite configuration because you can be free to choose the microcontroller (I like ARM’s, and I don’t mean that as a fetish) and the radio. Will this evil meter cause the downfall of all the people browsing facebook in the free world? Uhhh…no. This is because when the smart energy device joins the meter’s local network, it will receive a specific key for that device only. That key will only be valid to communicate with the trust center (err…meter…again) and can’t access any other device in the network. As mentioned on the other news sites, getting on to the local meter’s network will not give you access to all the meters in the nation. Hell, the utility companies can’t communicate with each other, even if they wanted to. If some enterprising hacker could pull that off, they should be running our utilities.

So let’s say that some metering manufacturer accidentally designed a meter with this particular vulnerability. And also, let’s say that some hacker stole some poor family’s power meter, leaving them in the dark and unable to watch the Daily Show with John Stewart and that funny episode where he trashes Jim Cramer, and proceeded to take that meter apart and get a key to communicate with the utility. Oops…Zigbee isn’t used to communicate with the utility. Most likely the meters will be using either powerline networking or some cellular technology for the backhaul communications to the utility. So this would be a dead end for the enterprising Zigbee hacker and he’d have to call on his reinforcements in the powerline or cellular industries to finish the job.

Don't take this the wrong way. Travis Goodspeed has a history of hacking (in the security sense) embedded devices and revealed many vulnerabilities that exist in the TelosB motes. He also exposed a lot of the vulnerabilities of TinyOS using these motes, including numerous buffer overflow attacks which since have been fixed.  It wouldn't surprise me if he found another one in a commercial stack. Also, his partner Aurelien Francillon wrote an article on how to create a worm and inject it into embedded Harvard architecture microcontrollers like the ones on the MicaZ motes. This in itself is pretty impressive since buffer overflow attacks usually assume a von Neumann architecture so you'd have to do some backflips with your assembler to get this to work.

What it all comes down to is that communication stacks needs to be designed in such a way that they are secure. This mostly entails protecting the data path to disallow buffer overflows which are the normal entry points for attacks (ie: enforcing maximum buffer size limits in code and checking them) but as Travis pointed out with the side-channel attack, there are other vulnerabilities that could be exploited as well. And for the record, I'm pretty sure my stack is going to get hacked just for the sheer irony of me writing this post...

So the point is that hacking any communications protocol is possible, but contrary to the claims of the security company, the hack is not practical for taking over the nation's energy infrastructure. All the meters are not connected by a local RF protocol as is assumed by the security company that published the alert. This is because there will be a variety of microcontrollers and communications protocols to handle the local wireless network, the local powerline network, and the backhaul to the utility. Contrary to the claims in the quote above, it won't be possible to take over a bunch of meters with Zigbee alone, because you would also need to compromise the backhaul as well. This will probably be difficult because I don't think even the utilities can agree on what the backhaul technology should be. The worst a hacker can do is attack a single meter if it fits all the limitations, and then it would just severely annoy their neighbor and this is assuming that the hacker can obtain the authentication codes for that residence. Instead of holding up the smart grid buildout until a committee can decide on security standards, which would be even more disastrous and possibly more vulnerable to hacking, we should be simultaneously testing the meters for vulnerabilities and updating the firmware to fix those that are found. We can't let fear stand in the way of progress...unless it involves AIG and Wall Street bonuses...

Updated 2009-03-22: Just checked the driver to make sure I was enforcing the max buffer length to prevent a buffer overflow attack. Looks like it's okay...Yowzah.... Updated 2009-03-22: The buzz is reaching a crescendo. The issue just got posted to Slashdot which means that it's going to be seen by all the major news outlets on the web. Nothing more for me to do so I'm going to finish watching my anime. Updated 2009-03-23: Apologies to Aurelien Francillon, the author of the paper and the PPT on the Harvard architecture buffer overflow attack. I didn't realize that I had previously traded emails with him where he shared links to medical groups working on wireless outpatient monitoring for the elderly with me. This whole post reeks of my frustration on the potential for this security issue to derail the energy grid upgrade which I see as a potential way to decrease the US's energy consumption and for the country to contribute to improving the environment.