panstamp weblog

Lagarto connects SWAP networks to the IP world

2012-02-19T17:56:00.004+01:00

Whilst beta-tests follow their own progresses, I've been working on a piece of software that will be the master key for bringing panStamps to the IP world. Lagarto is a lightweight software solution designed to run in low-power computer platforms like PlugComputers and RaspberryPI's.

Figure 1: Lagarto logo

This solution introduces a simple but powerful architecture where no central process is needed. Just servers and clients run autonomously whilst communicating among them via simple cross-platform mechanisms:

HTTP GET/POST for reading and writing physical values
ZeroMQ for notifying events occurred from the physical networks

Lagarto is a multi-process platform. This platform consists of one or multiple Lagarto servers and none, one or multiple Lagarto clients. Lagarto servers provide their own embedded web server (WSGI) so that configuration and basic control/monitoring of the physical networks can be accomplished via Web and HTTP GET/POST requests. No need to pass through a different service or process to do the basic stuff.

Figure 2: Lagarto basic architecture

Lagarto introduces a simple JSON-based protocol, used in both HTTP and ZeroMQ communication channels. Since ZeroMQ and HTTP are multi-platform, Lagarto servers and clients can be developed using almost any programming language, on any OS. At the moment of writing this blog entry, only a Lagarto server has been developed. It's obviously Lagarto-SWAP, the process charged to interface SWAP networks (and hence panStamps) with future Lagarto clients. For the moment, Lagarto-SWAP provides a nice way to read and write SWAP values from any HTTP client- I'll try to describe some examples about possible HTTP integrations of Lagarto-SWAP with third-party applications in future posts.

And finally, some screenshots:

Figure 3: Lagarto-SWAP general settings page

Figure 4: Lagarto-SWAP endpoint panel

Wiki documents

2012-01-06T23:16:00.002+01:00

The wiki pages have been updated with new contents. This wiki is now our documentation platform and should become the main reference when working with panStamps. Beta-testers may take these documentary base to start learning concepts and procedures, but please bear in mind that this is just a starting point. The wiki will need to be improved, enriched and re-structured in order to face real questions and help our future community. Thanks in advance for your feedback!

Ready to start the game

2011-12-18T17:58:00.006+01:00

Months of work are close to give the expected results. Beta-tests will finally start in January 2012 so I'll still have some weeks to finish software tools, documentation and templates. I admit being a bit impatient for getting practical feedback from testers, each one with different expectations, skills and application fields. By the way, sorry for those still wanting to join the beta-test program but, unfortunately, the list is closed. Thanks to everyone for your support and ideas or simply for following this humble blog.

Figure 1: Battery-powered sensor board

The above is a battery-operated board, ready to connect to different ambient sensors like the TMP36 temperature sensor or a DHT11/DHT22 dual temperature-humidity sensor. This board is powered from a single AA battery and the boost regulation is accomplished by a MAX1724. I must say that I hoped to hook this board to a solar cell but results have not been as good as expected. MAX1724 is not very well suited for this kind of application. My next attempt will use the BQ25504 from Texas Instruments, and some solar cells specially designed for indoor applications. I'm pretty sure that this will be a winner combination

Figure 2: Sensor board and panStick

I'm receiving a lot of e-mails asking about a date for the commercial release. Well, it's maybe a bit soon for giving a precise date although May 2012 is what I've always had in mind. Meanwhile, I'll be updating this blog with the latest news regarding this project, including the progresses done during the beta-tests.

New panStamps

2011-11-22T17:19:00.012+01:00

After a long period of time, new prototypes are here! Production has taken almost four weeks given that I've had to coordinate very different actors in this process: PCB manufacturer and assembler, two different part suppliers, international duties and finally shipping companies. Next time, and for regular productions, I hope to reduce the necessary times since mechanisms have already been set up.

Picture 1: new panStamps

I was hopping the yellow silkscreen to provide a better contrast when printed over the black solder mask. However, the yellow ink seems to be a bit transparent so I'm finally getting something closer to a light gold color. Not bad once I got used to although next production run will probably use white silkscreen.

Now it's time program boards and run some basic tests before sending boards to beta-testers.

Picture 2: new panStamps

New DIP-24 format has considerably reduced the size of panStamps (new dimensions = 30.5 x 18 mm). On the other hand, the unsoldered 5-pin row still gives access to the SPI port, used to program the Arduino bootloader.

Picture 3: panSticks

panSticks are just USB boards where to plug the panStamps onto. These boards can be used to program panStamps serially from the Arduino IDE and also interface wireless networks from computers.

Picture 4: Bare PCB's - Top layer

Picture 5: Bare PCB's - Bottom layer

HouseAgent, a promising open door to the "Internet of Things"

2011-10-17T08:31:00.000+02:00

First of all, please sorry for the long delay since my last post. I've been busy with different tasks within this project, including production, logistics and commercial plannings. New prototypes are coming in two or three weeks, already soldered and checked from factory. I've also ordered some base boards for testing new concepts and use cases but I'll be soldering those boards by myself until I decide which of them go for regular production.

But I don't want to bore you more. Instead, I prefer to let you know about my progresses in the technical area. Those of you usually following my blog probably know that I was planning to start a computer-based development, a new application to connect SWAP networks to the IP world. In a few words, bring the "Internet Of Things" concept to the panStamp project. This was not a simple task since a lot of work was involved, even if the concept behind it was quite simple. I initially called this new application "panTastic". However, a few months later, Paolo Di prodi, from Robomotic, let me know about HouseAgent, a very promising open source project developed and maintained by Maarten Damen.

HouseAgent is an open Home Automation software, maybe similar in concept to other well-known applications (ex: HomeSeer, Mr. House, HAL, etc) but with some particularities that will probably let it find a privileged position in the open source home automation area: very good architecture ready to face nowadays' cloud computing challenges, a simple plugin interface to make the creation of new communication plugins a simple task, multi-platform (HouseAgent is 100% Python), and the requirement for a very low memory footprint are some of HouseAgent's main strengths. From my very personal point of view, HouseAgent, once finished and released, will be perfect for all those new Home Automation projects requiring to work on very low-power computers (ex: ShevaPlug, Pogoplug, etc).

Figure 1: View of a SWAP custom page within HouseAgent

The good and bad thing about HouseAgent is that it's still under development. Thus, if you want to use this software in real projects you will probably need to wait some months before its release. On the other hand, if you are a developer and want to contribute to the project with your ideas and work, then Maarten and the rest of the HouseAgent team will certainly welcome you.

New PCB design - V.1.0

2011-08-18T19:44:00.002+02:00

The board design goes as expected. The new panStamp PCB design is finished so it's now time to work on the mother boards. PanStick, the USB board where panStamp sits on is closed to completion too. On the other hand, I've started some other developments, most of them aimed to act as proof of concept:

Solar harvester

This board is a milestone in the panStamp project. Finding a good compromise between solar cell, step-up PSU and storage device will bring us the product we are looking for: a mother board for ambient measurements capable to work even under poor light conditions.

Basic energy meter

I want to test the performance of the Atmega at 8MHz in direct AC measurements, including power factor and active/reactive readings.

RGB strip driver board

This is just a toy for controlling RGB strips and creating coloured ambiances.

Ethernet board

A simple way to interface SWAP networks from the IP world without having to use a computer as gateway. This is more or less an extension of the opnode project although I've not decided yet whether this board will go for regular production or not.

Back to the panStamp design, I've not uploaded the KiCad files to the wiki yet since I want to test some prototypes first. Instead, I'm posting here some pictures about the board. The circuit is surely quite definitive as I don't expect to do any major change on it, but the PCB will probably suffer some changes, once I have the opportunity to test the RF performance.

Figure 1 : Schematics of the panStamp V.1.0 board

MCU and external pinout

One interesting thing is that the new board will include a three-pin footprint for an external resonator. Using Atmega's internal 8 MHz oscillator will be the default option but sometimes a faster clock may be needed. I'm also searching a 32.768 KHz (RTC) cristal that fits on the 1.3 mm x 3.2 mm footprint. This would let us save a couple of microamps in periodic sleeping applications.

Figure 2 : Schematics of the panStamp V.1.0 board

RF front-end

Figure 2: 4-layer panStamp board

New panStamp PCB taking shape

2011-07-28T13:05:00.000+02:00

We've got to a point where we need to make new boards and start beta-testing the panStamp concept. New boards have to solve the only issue detected so far, that's the intermittent problem when programming the panStamps from the Arduino IDE via USB. Apart from that, there are some technical improvements that will bring us new possibilities:

New boards are 24-DIP (0.6 inches) instead of 28-DIP.
SPI pins appear in a supplementary row, still accessible from the panStamp. This action has let us switch to the mentioned 24-DIP package.
Resonator footprint added. XTAL1 (PB6) and XTAL2 (PB7) pins are then removed.
All Atmega's IO pins are now available except INT0 (PD2) and the CC1101 chip select pin (PB2) that are exclusively dedicated to the communications with the RF front-end.
The Atmega328P will have a 32-MLF package instead of the 32-TQFP. We save a lot of space on the board doing this.
New boards have four layers instead of two, improving performance and allowing reasonable microstrip widths.
Passive components are now SM0402 packages instead of SM0603. SM0402 is the recommended package for any RF device emitting near the 1-GHz band.
New SMA connector footprint added into the board. We'll then have two possibilities: wire stub antenna for the cheapest designs and whip antenna for those special nodes needing greater communication ranges.

Besides working in a new hardware version of the panStamp, I'm also designing some specific mother boards, some of them being of great importance for the project:

USB board for programming panStamps and interfacing PC-based applications. The whole USB board and panStamp will fit into a conventional USB-stick enclosure.
New solar-harvester board for indoor applications. The NCP1400 approach will be abandoned and will surely use a MAX1722 instead, with lower quiescent current. For the solar part, we'll switch to a silicone amorphous panel, with greater sensibility under poor light conditions. On the accumulator side, different options will be available: NiMh AAA battery or super-capacitor.

And some other boards for internal evaluation. We'd see later whether these boards would see the light commercially or not. This will surely depend on the practical results and degree of interest from the community:

RGB-Strip controller.
Energy meter to be used with external current transformer clamps.

If everything goes as expected, new boards should be ready at the end of September. Those having transmitted their interest in participating in the beta-tests will be then contacted. Thanks everyone for your interest in the panStamp project!!

Static XML data for abstract M2M protocols

2011-07-07T16:18:00.001+02:00

Abstract protocols are usually a good option when transporting information from a device to another without much complication. Simplicity, flexibility and quick adoption are the main strengths of abstract protocols and abstract data schemas. These strengths have doubtless led JSON, Soap, HTTP and Modbus to a priviledged place within the Automation Industry.

However, abstract protocols lack a certain degree of interoperability in some situations; additional application layers on top of the existing protocols. In a common peer-to-peer application, both peers have to share a given convention in order to understand what is communicating each other. An actuator may be waiting for an alert sent from multiple sensors. Thus, our actuator must know how alerts are coded into the incoming communication frames. In this example both ends (sensors and actuator) are specialized nodes. Each one concentrates into running a simple task (sensing alerts and hearing them) so programming the data-coding convention into the actuator is the simplest way to let it know about incoming alerts.

However, more capable devices, like coordinators, masters, gateways or data concentrators usually need to decode data received from many nodes so hard-coding data conventions into these devices (as opposite to incorporating these conventions into the communication frames themselves) is not a good idea. These devices are not specialized ones; since they may accept a variable amount of data types, another approach must be considered.

For those high-end devices needing complete information about the data being exchanged, it would be possible to maintain local or remote repositories of device descriptions. Since XML is an extended language with numerous parsers for any programming language, why re-inventing the wheel. The following example is a first attempt to create static device definitions to complement SWAP in high-end devices. For the Dual Temperature and Humidity mote:

<?xml version="1.0"?>
<device>
  <manufacturer>panStamp</manufacturer>
  <product>Dual Temperature/Humidity sensor</product>
  <pwrdownmode>true</pwrdownmode>
  <registers>
    <reg id="11">
      <endpoint type="analog" dir="input">
        <description>voltage supply</description>
      </endpoint>
    </reg>
    <reg id="12">
      <endpoint type="analog" dir="input">
        <description>humidity</description>
        <position>0</position>
        <size>1</size>
      </endpoint>
      <endpoint type="analog" dir="input">
        <description>temperature</description>
        <position>1</position>
        <size>1</size>
      </endpoint>
    </reg>
  </registers>
</device>

The above schema mainly consists of registers and endpoints. Registers are SWAP's natural data containers whilst endpoints are what really matter to end-user applications. Thus, registers are divided into one or multiple endpoints in a simple way. In the above example, register with ID=11 has only one associated endpoint (voltage supply) so this endpoint will take its value from the complete register. On the other hand, register with ID=12 consists of two endpoints. "Humidity" takes the first byte (position = 0, size = 1) from the register value. "Temperature" takes the second byte (position = 0, size = 1).

Finally, device definition files like the above one would be indexed by their product code, which uniquely identifies manufacturer and product type over the air.

I may still add some additional fields to the above schema but this will be pretty much the system used by SWAPdmt, panTastic and any other high-end device or application wanting to identify wireless motes and their resources.

OpenChronos is finally SWAP-enabled

2011-06-29T00:38:00.002+02:00

Endless weeks of work, porting SWAP to the standard Open Chronos firmware, adding new functionalities and debugging all this... Longer than I initially expected but it was worth the work. I'm now able to do what I planned to do with my Chronos: browsing and controlling external SWAP endpoints, transmitting data from the internal sensors, configuring the watch and still keep most of the functionality provided by the Open Chronos firmware.

The following slides navigate along the Chronos screens, showing some of the functionality already provided by the standard Open Chronos firmware and also the new SWAP features:

For those wanting to take a look at the code, I still have to consult the Open Chronos team about the best way to merge both works. If maintaining a fork is the solution, then I'll upload the project to the panStamp code page as I did with the Arduino work and the Java tools. I understand than replacing Simpliciti by SWAP may not be of the interest to everyone so forking from the trunk project may be an option.

-- Edit --
These SWAP mods have been recently added to the Open Chronos project as a fork from the main project:
https://github.com/dberenguer/OpenChronos
-------------

What are the main differences between using Open Chronos with Simpliciti or with SWAP?

General functionality
Both firmwares provide similar functionalities, except that the SWAP firmware does not include a method for re-flashing the Chronos wirelessly. Instead, the Chronos has to be reprogrammed using the JTAG programmer provided in the kit.

Transmission of accelerometer data (ACC mode)

With Simpliciti, the Chronos sends XYZ accelerometer data every 0.5 seconds whilst SWAP initially stablish a periodic interval of 1 second in order to simplify resources and save power. However, this may be changed in the future.

Reception of packets in SYNC mode
Simpliciti plays with periodic windows where the Chronos is able to receive data. Out of these windows , the radio remains inactive. The SWAP way is much simpler although more power consuming. Instead, the new Sync mode is mainly limited to short transactions, like sending a limited number of configuration commands.

Firmware footprint
Due to the simple nature of SWAP, the new firmware does around 2 KB of savings in Flash space. I've not done the necessary RAM tests but I'd say that SWAP saves some space there too.

Power consumption
More or less the same in both cases, depending on the working mode in use.

ez430-Chronos powered from the external JTAG connector at 3.6 VDC

Mode	SWAP	Simpliciti
Normal operation (radio off)	12 uA	15 uA
Accelerometer, radio off	0.88 mA	0.88 mA
Sync mode	16.26 mA	4.5 mA
ACC mode, radio on	0.1 mA	4.5 mA

Table 1: Table of consumptions. Comparison between SWAP and Simpliciti.

Regarding the storage of user data in Flash (the CC430 processor has no EEPROM inside), I had to give it up due to the large space consumed by the infomem driver. Open Chronos, like TI's stock firmware, already takes most of the flash space provided by the CC430F6137 processor (32 KB) so adding this new feature forced me to remove some others.

By the way, I've added a custom configuration window for the Chronos in the SWAPdmt tool. This has let me run my tests quickly without having to type the configuration commands by hand from the serial terminal.

Figure 1: SWAPdmt configuration window for the ez430-Chronos

Anything else to relate? Well, this has nothing to do with the firmware but I had wanted the Chronos to show a better wireless range – a few meters according to my tests – but this was not a surprise since other users reported the same limitation. Anyway, I hope to improve this range after placing a decent whip antenna to the panStamp connected to my computer. But these new experiences will surely deserve a new entry in this blog.

Wiki documentation

2011-06-10T23:06:00.005+02:00

I just wanted to let you know that I'm (slowly) documenting everything related to this project in the Google Code wiki page

Currently, there are just a couple of pages available but I have the intention to make this wiki grow with further resources, descriptions and manuals.

This page introduces SWAP, the basis of the protocol itself, frame format and types of packets:
Description of the SWAP protocol

This other page describes the mandatory registers that any SWAP device has to maintain in order to provide basic interoperability between devices:
List of mandatory registers

I'm now working in the way to provide information about custom registers. I've finally taken the decision to use XML files for that purpose. From a functional point of view, any software or device wanting to automatically detect the available registers or endpoints in a wireless network should have access to a central repository of XML product descriptions. Then it would be just an issue of identifying the correct XML file from the product code, one of the mandatory registers listed in the above wiki page.

SWAPping packets with my ez430-Chronos – Part 2

2011-06-01T15:49:00.000+02:00

I've been doing some progresses on the custom firmware for the ez430-Chronos. I'm now able to control panStamp outputs via SWAP from the Chronos browser. Besides, whenever the SWAP mode is activated, the Chronos periodically sends multiple data measured from its internal sensors: temperature, barometric pressure and altitude (calculated from the barometric pressure).

Figure 1: Chronos watch displaying a SWAP binary output

As for the external values, temperature and humidity are received from a battery-operated panStamp whilst LED's are controlled by a second panStamp connected to a permanent power supply. You may notice the little heart appearing on the left side of the screen. That little heart indicates that the endpoint is an output so that it can be controlled from the arrow buttons. I'd like to upload a video showing these and other features but I want to show something more interesting than just turning a couple of LED's on and off.

The rest of features already existing in the Open Chronos firmware are enabled, except for the continuous transmission of accelerometer data, where I'm still working on. Another feature that needs to be added is the ability to save configuration data on the Chronos flash, including calibration data. After this, I think that my Open Chronos add-ons will be ready for release.

Finally, my Chronos is experiencing a notable voltage drop whenever it enters the communication mode. Maybe my Chronos came with a discharged battery so this may explain the problem. In any case, I'll need to replace the battery... once I find how to do it.

SWAPping packets with my ez430-Chronos

2011-05-14T16:40:00.001+02:00

It's been a while since my last post, mainly because I've been working on things that may not be really interesting for the readers of this blog, such as improving the Java library and developing a first version of the opnode panTastic server – and I mean “server”, it still lacks the necessary communication clients in order to do the application really usable.

But finally, I've found the time to work with my new ez430-Chronos kit (868 MHz). As I explained in a precedent post, I had the idea to integrate the Chronos watch into the panStamp ecosystem. This desire has led me to develop a SWAP extension for the Open Chronos platform, on top of the existing MRFI (Minimal Radio Frequence Interface) stack. The availability of the MRFI API has enormously simplified my work since it provides the necessary functions to send and receive wireless packets. However, I've had to tweak this API a bit in order to make it usable with custom protocols, not only with SimpliciTI.

Figure 1: ez430-Chronos kit

My custom ezChronos application is based on the Open Chronos project, an open source implementation of the original Texas Instruments sources, that can be compiled using the open MSPGCC4 compiler. As for the flashing procedure, I'm using MSPDEBUG as serial uploader through the provided USB programmer.

Figure 2: programming the Chronos watch serially

One of the great things about the Chronos is that panStamps can natively communicate with it using FSK and GFSK modulations with all the packet smartness enabled at both ends. CC430 MCU's and CC11XX radios share a common packet structure so the communication between these families of IC's is done quite straightforward.

In my opinion, anyone wanting to develop his own protocol for the Chronos has previously to learn about how the SimpliciTI stack is implemented and how this stack is anchored to the existing display menus. When I started this development I thought that the menu interfaces were a bit more protocol-agnostic that they really are. In fact, I've had to surgically replace some of the current dependencies with the SimpliciTI stack with custom functions that do more or less the same but without the initial stack calls.

Back to the interesting things, porting SWAP to the Chronos platform has been very simple. I'd even say that replacing SimpliciTI by SWAP has saved some Kilobytes of flash so I've finally gained some additional space for the new data browser.

Figure 3: simple benchmark

The above diagram shows the components used in a simple test. The Chronos watch receives and stores temperature and humidity values sent from the humidity&temperature panStamp whilst the PC+modem set is used during configuration only. In fact, everything in the Chronos, including the data pages to be displayed, is configured wirelessly through the use of configuration registers. Again, the basic philosophy of the SWAP protocol, where everything can be represented in form of addressable registers, has vastly simplified things in this development. From the PC, I only had to send a SWAP command addressed to a given configuration register (one per SWAP data page) that simply sets the origin of the data to be displayed, a basic text label and some transformation operands. Then, the watch basically listens for incoming SWAP informations and refreshes the internal data pages when necessary.

Figure 4: Some custom SWAP pages

As you can see, the bottom line of the display, initially reserved for labelling each SWAP endpoint, has some obvious limitations. It's a 6-digit 7-segment area so before writing any text onto it, anyone has to decide which label fits best these limitations. Anyway, for the above test I just wanted to identify each endpoint with some basic alphanumeric identifiers: “hu 1” for Humidity 1 and “tE 1” for Temperature 1.

Anything else? What is this custom application supposed to do apart from displaying external SWAP data? Well, the new Chronos firmware includes pretty much the same functionality than the stock firmware:

Date and time
Time alarm
Stopwatch
Temperature sensor
Pressure sensor and altimeter
3-axis accelerometer

Moreover, my current implementation updates an internal SWAP register with the values extracted from the temperature and pressure/altimeter sensors. Thus, anyone may query this register wirelessly whilst the SWAP mode is active on the Chronos. I wanted to do the same with the accelerometer values but then I realized that the initial TI approach is much more usable so I'll surely work on developing a similar function using SWAP instead of SimpliciTI. Once completed, this feature will let us manually release a continuous stream of xyz-accelerometer data for any third-party application wanting to exploit (or simply plot) these data.

So... what's next? Some of the above features need to be improved but, apart from that, I still need to solve some issues regarding the consumption on the Chronos and the way the watch stores data after each configuration. I also need to decide the amount of custom pages available on the watch and the way the external endpoints may be controlled from the Chronos. I'll initially work on controlling some binary switches from the up-down buttons but later I'll probably want to control analog setpoints or even RGB data. Finally, I'll want to extend the SWAP device management tool to configure the Chronos from one of its graphical windows instead of having to send the configuration commands manually from a serial console.

I'll try to document these progresses and much more in future posts so please... stay tuned for the next.

Speech Recognition from Google - New possibilities for Open Home Automation

2011-04-27T19:36:00.005+02:00

Although this does not seem to be related to the panStamp project, I've always wanted to integrate voice commands into my home automation software without having to pass through some of the existing commercial solutions; most of them being platform dependent.

Last week a friend pointed me to Google Translate, one of the new Google apps for mobile platforms that translates voice statemens to a good number of languages. This application seemed to recognize our very different voices on the fly without having to pass any previous training. Even complex statements were being recognized with a high degree of precision, and all that from a simple small application installed on an iPhone!

Speech recognition software has proven to be one of the most specialized areas in the software programming world. Only a few companies develop voice recognition engines and most of these software rely on complex voice models and ultra-secret recognition algorithms. Some of these applications, like Windows' Voice Recognition Engine are mostly specialized in recognizing short commands. Other, like Dragon Naturally Speaking, seem to offer a better performance for dictating applications.

Over the past years I've been studying the possibility to add speech recognition capabilities to my custom software applications, mainly to those solutions having to do with Home Automation. Some years ago I decided to play with HomeSeer's integrated speech recognition scripting engine. Well, HomeSeer was using Windows' engine in those times but HomeSeer did offer a good scripting interface for controlling the Home Automation stuff from voice commands; something really useful and well documented. Unfortunately, Windows was providing speech recognition only in English. As you may guess, I needed something closer to my mother language so I ended by giving it up.

Now Google arrives with a very interesting solution, and I mean interesting due to the following reasons:

Google's Speech Recognition API would seem to be free and open source. This feature would let us integrate these Speech Recognition capabilities into any existing software, including my panTastic software.
It's client server-based. This means that the client just has to generate an audio file and then send it to Google's remote voice recognition servers. A few seconds later, Google responds with a formatted string containing the text recognized from the provided audio file. The whole speech recognition engine, including voice models and dynamic algorithms, are placed in Google's servers. Thus, we can do speech recognition almost from any lightweight device capable to record audio.
The API is http-based so it's truly open-platform. We Linux users would be finally allowed to run speech to text routines in a decent way. Indeed this http API opens new possibilities to open control software like opn-max and panTastic (soon...) since we'll be able to keep the small factor and low power and still provide Voice Recognition capabilities.
We'd take advantage of the growing voice models being added to Google's servers, probably being improved dynamically along the use from the wide community (??).

On the other hand, there are some drawbacks that will have to be considered too:

Any device wanting to do Voice Recognition through Google's engine will have to be on-line. This should not be an issue for most Home Automation applications though.
The whole recording-transmission-processing-reception procedure takes a few seconds. Some users may expect a faster response to their voice commands.
Google Speech Recognition seem to be still under test. As result, Google may want to move their servers or change the API URL address without previous notice.

OK but, how can Google Speech Recognition engine be used from a custom software? I've deeply browsed the net during the last days and found very little information about Google's API. It would seem that most of Google's efforts are being focused on providing speech recognition capabilities for Android and some of Google's most popular applications, including Google Chrome. Finally, I found this great source of information:

http://www.commandlinefu.com/commands/by/sairon

Sairon, the maintainer of the above website provides some interesting scripts that would let us integrate the speech-to-text engine in any application with IP connectivity. Since I was mainly interested in testing the Speech Recognition Engine in Spanish, I modified the suggested scripts for my convenience.

First of all, we need to create a flac file with the desired voice command to be processed. The sampling rate must be 16 KHz:

sox -r 16000 -t alsa default recording.flac silence 1 0.1 1% 1 1.5 1%

Once the flac file created, it's time to transmit it to Google's Speech Recognition server through a wget command:

wget -q -U "rate=16000" -O - "http://www.google.com/speech-api/v1/recognize?lang=es&client=Mozilla/5.0" --post-file recording.flac --header="Content-Type: audio/x-flac; rate=16000"

Sairon suggests a more complex script, identifying the http request as coming from both Mozilla and Chrome, maybe as a way to offer some redundancy. For my tests, I just used the Mozilla portion of the command.

Less than three seconds after running the above wget command I got the following response from Google:

{"status":0,"id":"b62308e814a4287240f68d23258914d2-1","hypotheses":[{"utterance":"estamos probando el motor de reconocimiento vocal de google","confidence":0.8816453}]}

Indeed, “we were testing Google's Voice Recognition engine”, a command spoken in a very natural way without having to include additional pauses between words. Quite awesome given my precedent experiences with other VR software. At the end of Google's response, 0.8816453 seems to show the degree of confidence of the resulted procedure, more than 88% of confidence would not seem so bad.

Finally, Sairon also explains how to use Google's text-to-speech engine:

wget -q -U Mozilla -O output.mp3 "http://translate.google.com/translate_tts?tl=es&q=esto+parece+funcionar+a+la+perfeccion"

opnode panTastic: architecture of a new server controller

2011-04-15T14:15:00.000+02:00

I must admit that I slightly abandoned my opnode project long time before starting the panStamp project. After more than five years, opnode has not gotten the popularity that I initially expected, surely due to the cost of the custom hardware. Opn-max is the only opnode relying on a low-cost third-party (Linksys) hardware platform and people still seems reluctant to do the jump – hacking the Linksys NSLU2 has resulted a bit complicated for non Linux users.

Figure 1: opn-max controller running on a Linksys NSLU2

This said, I've planed to revolution the opnode project since I started this blog. I see lots of synergies between opnode and panStamp, maybe not for simple wireless networks but most people wants to integrate different technologies nowadays, and that is exactly the goal of the opnode project: piping different communication technologies into a common IP integration platform. The old opnode architecture has resulted to work efficiently and fast. However, the “one gateway per cloud” paradigm is a bit costly and not very popular in the Home Automation area. Instead, most people prefers to invest in more powerful hardware capable to work as a multi-port gateway or controller. At least, this is what I've learned from the opnode community.

Figure 2: old “one gateway per cloud” paradigm

Coming from the Industrial world, I'm a big fan of isolating networks and tasks through the use of independent gateways. However, I understand that Home Automation hobbyists prefer to take such decision themselves. On the other hand maintaining a single plural project instead of several vertical ones seems that will simplify my life a little. All these factors have led me to conceive a new opnode, panTastic, a controller with all the features provided by opn-max plus the possibility to add support for different communication technologies into a common box.

Since the current opnode software was exactly tuned to follow the old paradigm, panTastic will need a new architecture, something really open to the addition of new communication ports and protocols without having to rebuild the whole application along each addition. Moreover, I want this project to be as much programming language independent as possible, at least regarding the development of plugins (or clients). As result, I've configured a new architecture where the main core (panTastic server) dialogues with multiple communication clients. Each client is then the responsible to maintain the necessary communication tasks with each wireless cloud or bus field.

Figure 3: panTastic architecture

Flexibility is maybe one of the main features of such architecture. Anyone can decide whether to integrate multiple communication technologies or not, place the client inside or outside the server box or simply develop the client using any programming language capable to work with TCP/IP sockets. As for the hardware, panTastic will work on any 32-bit platform capable to run Java ME, SQLite, Perl, PHP and LightHttp. In other words, almost any cheap x86 platform such as the ShevaPlug or any of the eBoxes should be able to run panTastic without problems.

Regarding the integrability of panTastic, this project will let us do many things with our wireless PAN's:

Maintain different PAN's (SWAP-based or not) from one or multiple panTastic controllers.
Use the IP LAN as a common communication trunk for different panTastic controllers and thus for different PAN's.
Program events and scripts for each PAN or bus field.
Monitor and control endpoints from any web browser.
Generate and display Web charts based on data stored in the SQLite database.
Integrate wireless and wired clouds into other remote software applications via xAP BSC or custom TCP/IP (opn-max, Mr House, HomeSeer, HAL, MainLobby, etc).

In summary, panTastic will bring new possibilities to SWAP networks, providing a good degree of smartness, even to clouds formed by very simple motes.

Solar experiences: first tries

2011-04-11T18:47:00.000+02:00

In precedent posts I've introduced some informations about power consumptions. As a rule of thumb, when configured as battery-operated devices, panStamps may drain a few microamps in power-down mode and a few miliamps when measuring and transmitting. Under these circumstances, powering a panStamp based board from a couple of AA batteries should give us an autonomy between one and three years, depending on the particularities of each project (consumption of the sensor, DAQ and transmission intervals, time remaining in Rx after each transmission, etc).

Now I want to go a step further and create real autonomous wireless motes; no need to replace batteries at all since solar energy is available for free almost everywhere. Before adding more complexity to the hardware, I thought about checking this concept with a common solar battery, one of those cheap USB chargers for cell phones.

Figure 1: panStamp base board being powered from a solar phone charger

The solar charger appearing in the above picture may seem somehow overkilled for our purpose; the most simple (and cheap) solar chargers may be used instead. The base board where the panStamp is plugged onto was originally designed to work as programmer and USB interface. It also includes a LDO, independent from the ft232 on-chip voltage converter, so that the FTDI USB chip can remain unpowered (through an external jumper) whilst the board can still be powered from an external 5VDC power supply.

However, the above solution is not what I had in mind when I planned to build cheap and simple solar-powered devices. Thus, I needed to go back to the basis, restart my solar design and do things step by step.

My first decision was to build a boost power supply where to base my solar design on. Powering a microcontroller from a solar cell is a bit more complicated than simply connecting the cell to the Vcc and GND pins. Voltages provided by solar cells are far from being constant and regulated. Moreover, I need to back up some of the power produced into a battery or capacitor. Finally, I want my solar kit to cost less than USD10. Otherwise I'd see no reason for abandoning the (above) USB solar battery approach.

Regarding the step-up voltage regulator, the NCP1400 chip, made by ON Semiconductor, appears as a good candidate. It costs less than USD1.0 and requires only a few passive components. This regulator is capable to start converting 0.8 V into other more usable voltages and keep conversions when the voltage source goes below 0.2 V. In order to test the samples received from the manufacturer, I built some small boards that will let me plug different power sources and storage devices.

Figure 2: NCP1400 test board schematics

This step-up regulator is not only suitable for solar designs. Since it accepts low voltage ranges, I'll be able to power my panStamps from single AA/AAA batteries, ensuring that their charge will be drained more efficiently than simply connecting AA/AAA pairs as described in the precedent post.

Figure 3: NCP1400 test board

Finally, I ordered some cheap solar cells from Internet and a supercapacitor where to store the excess of power and keep the panStamp running through the night. The supercapacitor is a 6.6F 2.7V ELNA DZ one, purchased from eBay, that should show a low ESR (Equivalent Series Resistance), 0.2 ohms or so. Choosing a good supercapacitor is very important, not only for the amount of charge that it will be able to store but also for its rate of discharge. A low ESR ensures low current leakages.

Figure 4: Cheap solar cells. 29 x 59 mm. 2V 45 mA under direct sunlight.

Once I got all the necessary pieces I assembled them all together and run some tests. I initially expected the ensemble to work under low daylight conditions and still be able to back up the necessary energy to work through a whole night...

Figure 5: My first solar engine

… Unfortunately, none of my initial wishes fulfilled. Firstly, the solar cells resulted to work only under direct sunlight. Under the shade, even with good indirect daylight, these cells do not provide the necessary voltage to make the regulator work. My second frustration arrived when I checked that the supercapacitor was not able to keep its charge more than 7 minutes, even when my panStamp was not consuming more than 0.2 mA. All these bad news have led me to review my design and get the following conclusions:

1. I need to look for more efficient solar cells, capable to produce a minimum of voltage and current even under low daylight conditions. In household applications, these solar-powered sensors won't rarely be placed under direct sunlight so my current solar cells are useless.

2. The NCP1400 board requires low ESR capacitors. Placing a good supercapacitor besides not so good filtering capacitors makes the whole design discharge quicker. As filtering capacitors I initially used some tantalum ones that I had in stock but later I realized that their ESR's were not acceptable for my design. Instead, I'll have to search better ones, with ESR's below 0.3 ohms.

3. I need to try other supercapacitors. The one purchased from eBay theoretically has an ESR of 0.2 Ohms but I've not been able to find the original data sheet. Indeed, I'd say that ELNA no longer makes this reference and, instead, Mouser and other distributors provide the 4.7 F value and lower ones. I'm beginning to question the quality of this 6.6 F supercapacitor.

In summary, I guess it's an issue of replacing pieces in my current design. I'll try to document in future posts my progresses and other experiences about this exciting topic.

Humidity & Temperature wireless mote

2011-04-02T14:41:00.000+02:00

More than a week without posting a single article to this blog... My second son was born yesterday after a week full of stress, worries and finally happiness :-)

Meanwhile, I've only progressed on the software aspects of the panStmap project. The jswap Java library has been improved with some smarties that will let the user application send commands to sleeping motes when they come back to life for their periodic reports. Additionally, a basic XML profile inspector has been added to the engine, providing a number of informations to the master application about each available device from a single product code (8 bytes). Nevertheless I wanted to close this week with a practical application, a true sensor mote that sends temperature and humidity values with the use of a panStamp, a couple of AA batteries and a DHT11 Humidity & Temperature sensor

Figure 1: Humidity & Temperature panStamp sensor

DHT11 is an interesting sensor providing compensated digital temperature and humidity values through a single wire. There are some example applications about DHT11 for Arduino so integrating this dual sensor with panStamp has resulted to be very easy.

Figure 2: Another view of this home-brew wireless sensor

As you can see, the hardware part of this practical example is quite simple. Just to be noted that the DHT11 sensor is actually being powered from a panStamp digital pin so that the sensor can be unpowered before the panStamp enters the power-down mode. This will ensure that the wireless mote will not exceed 5 uA during sleep and, although I've not checked the power consumption when in active mode, I expect to have an autonomy of about 1.5 years with the showed alkaline batteries.

Firmware wise, what is behind the scenes? The arduino sketch is primarily represented by the following loop code:

/**
* loop
*
* Arduino main loop
*/
void loop()
{
   epTable[EPI_PRODUCTCODE]->getData(); // Transmit product code
   delay(10);
   epTable[EPI_VOLTSUPPLY]->getData(); // Measure and transmit voltage supply
   delay(10);
   epTable[EPI_HUMIDTEMP]->getData(); // Measure and transmit humidity and temp values (2 bytes)
   delay(100); // Listen for remote commands for 100 msec
   panstamp.sleepFor(WDTO_8S); // Power-down for 8 sec
}

The above code may be modified to make the panStamp sleep during longer periods. Besides, anyone may prefer to not to send the product code so frequently or decompose humidity and temperature in two different endpoints. All this is customizable by the developer.

But previous to the above code, the new non-standard endpoints have had to be declared somewhere in the sketch:

/*
* Add here your custom endpoints
*/
// Voltage supply
static byte dtVoltSupply[2];
ENDPOINT epVoltSupply(dtVoltSupply, sizeof(dtVoltSupply), &updtVoltSupply, NULL);
// Temperature and humidity from the DHT11 sensor
static byte dtTempHum[2];
ENDPOINT epTempHum(dtTempHum, sizeof(dtTempHum), &updtTempHum, NULL);

Here both endpoints are declared and statically allocated. For each endpoint, a pointer to an “updater” function or “getter” is passed as argument to the ENDPOINT constructor. These “getters” will later be called whenever ENDPOINT.getData() is used in the sketch. In fact these custom functions are automatically called by the SWAP library to automate things like sending info messages after receiving SWAP queries for instance so that the end user has not to worry about dealing with the basic mechanisms of the SWAP protocol.

Then the new endpoints are declared as part of the global array of endpoints (epTable):

/**
* Initialize table of endpoints
*/
ENDPOINT *epTable[] = {
&epProductCode,
&epHwVersion,
&epFwVersion,
&epSysState,
&epCarrierFreq,
&epFreqChannel,
&epSecuOption,
&epSecuNonce,
&epNetworkId,
&epDevAddress,
// Add here your custom endpoints
&epVoltSupply,
&epTempHum
};

And finally, both updater or getter functions are defined:

/**

* updtVoltSupply

* Measure voltage supply and update endpoint. Code inspired from

* http://code.google.com/p/tinkerit/wiki/SecretVoltmeter

* 'eId' Endpoint ID

const void updtVoltSupply(byte eId)

{

unsigned short result;

// Read 1.1V reference against AVcc

ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);

delay(2); // Wait for Vref to settle

ADCSRA |= _BV(ADSC); // Convert

while (bit_is_set(ADCSRA,ADSC));

result = ADCL;

result |= ADCH << 8;

result = 1126400L / result; // Back-calculate AVcc in mV

/**

* endpoint[eId]->member can be replaced by epVoltSupply.member in this case since

* no other endpoint is going to use "updtVoltSupply" as "updater" function

// Update endpoint value

epTable[eId]->value[0] = (result >> 8) & 0xFF;

epTable[eId]->value[1] = result & 0xFF;

}

/**

* updtTempHum

* Measure humidity and temperature and update endpoint

* 'eId' Endpoint ID

const void updtTempHum(byte eId)

{

int result;

if ((result = dht11_ReadTempHum()) < 0)

return;

// Update endpoint value

epTempHum.value[0] = (result >> 8) & 0xFF;

epTempHum.value[1] = result & 0xFF;

}

SWAP device management tool

2011-03-25T14:33:00.000+01:00

I've been intensively working during this week, developing a simple configuration tool for my wireless network. It happened that I found I was wasting some of my time in basic operations like changing addresses, network id's and frequency channels. For every intervention I had to manually send SWAP commands from minicom, a bit hard when you're doing these changes a dozen of times per day. Finally, this management tool will simplify my life, at least along my developments.

Figure 1: SWAP Device Management Tool

This tool has been entirely developed using Java ME under Netbeans. This means that it should work on either Linux, Mac or Windows. I admit that this application may have been developed using other cross-platform languages like C++, Python or Ruby. It just happens that Java provides me a good compromise between fast-delivery and good integration with third-party UML tools. On the other hand, this development has been the perfect excuse for creating two Java libraries for the panStamp project:

jcc11xx is a java library for communicating with a panStamp connected to a computer USB port and running the modem application. This library provides the necessary classes and methods to transmit and receive wireless CC11XX packets in an asynchronous way.

jswap is a Java library, sitting on top of jcc11xx, that implements the SWAP protocol layer and some other smart features like a basic XML parser and a device/endpoint management platform. This library may seem a little overkilled for the basic management tool but I had other projects in mind. In particular, I've been always thinking in this library as a way of providing wireless SWAP connectivity for Home Automation, HVAC and Home Theater software. Once jswap get to a complete stage, I'll surely start a new project consisting in a new generation of opnodes for wireless networks.

Figure 2: Java SWAP stack

Back to the management tool, there is still some work to do, mainly in how custom configurations are stored in the computer and also in the way device product codes are translated into something readable and understandable by the end user. By the way, developing such automatic identification algorithm will bring me to other needs, like the one of having to identify device resources (endpoints) and inherent functionalities. All this just after receiving an eight-byte product code (standard endpoint 0) wirelessly.

Piping wireless packets to the computer

2011-03-22T08:44:00.000+01:00

The computer gateway will be one of the key pieces of the panStamp ecosystem. In order to communicate with the panStamps from my PC, I've developed an Arduino application that basically converts wireless packets to ASCII strings and vice-versa. Since I need to configure some parameters such as device address, carrier frequency and channel, this gateway has also been programmed to accept a set of AT commands.

Figure 1: panStamp mounted on the USB board working as serial modem

One of the important things about this gateway is that is does not implement the SWAP stack itself. Instead of this, the “modem” simply pipes raw wireless packets to the computer, making it compatible with other wireless protocols. Later, we'll have to develop an implementation of the SWAP protocol for PC, where computation resources and disk space are something unlimited compared to Atmega's.

Another advantage of working with ASCII packets and AT commands is that anyone can access the modem from a serial terminal such as hyperterminal (for Windows) or minicom (for Linux). Apart from this, ASCCI strings also simplify the integration from custom applications, making the use of additional drivers and libraries almost unnecessary.

Figure 2 : minicom in the process of capturing some wireless packets

The above screenshot shows minicom receiving frames from a mote. Taking one of those frames, we can de-compose it as follows:

(D730)0001001E00010A0CA4

0xD7 is the RSSI value whilst receiving the frame, coded as the CC1101 datasheet indicates.

0x30 is the LQI alue (7 bits), as explained in the CC1101 datasheet too.

0x00 is the destination address. This packet has been broadcasted then, as specified by the SWAP protocol.

0x01 is the address of the source device or mote

0x00 is the value of the hop counter (4 bits) and the security option (4 bits). In other words, this packet has never been repeated and includes no security protection.

0x1E is the cyclic nonce. Even if it's not taken into account (security option = 0), every information packet being transmitted makes this counter increment.

0x00 is the function code, indicating that the packet is a SWAP information message, reporting the value of an endpoint

0x01 is the address of the device actually owning the endpoint. This tells us that the device that owns the endpoint is also the one having sent the info packet.

0x0A is the index of the endpoint. Endpoint address (0x01) and endpoint index (0x0A) make a unique endpoint code within the wireless network: 0x010A.

0x0CA4 is the value of the endpoint. This 2-byte digit particularly shows the voltage supply on the remote device (0x0CA4 hex = 3236 dec = 32.36 VDC).

What is the next step? I'm already working on a PC tool for configuring SWAP motes wirelessly without having to handwrite command frames from the serial terminal. This tool may also derive into some kind of diagnosis application for testing remote motes and helping developers in their projects. Meanwhile, I have a good excuse for developing a SWAP Java library.

panStamp library now available on Google Code

2011-03-18T10:20:00.001+01:00

A first version of the panStamp library has been recently uploaded to Google Code. This library has a GPL license so anyone could use it for their projects, commercial or not, free of charge.

SVN repository on Google Code: http://panstamp.googlecode.com/svn

From the panStamp library we may use just the CC1101 driver or the complete application stack, including SWAP and the endpoint management system. In the next days I'll also try to show some examples of real applications in order to give a better understanding about the way to interface with the library

Figure 1: UML diagram of the panStamp library v0.0.1

As for the final size of the binaries, an Arduino sketch implementing a simple basic SWAP-enabled sensor, with integrated endpoint management system, takes around 5 KB of flash (of 30 KB available in the Atmega328p) and will take no more than 725 bytes of RAM (of 2 KB available in the Atmega328p). Given that the Arduino bootloader needs 2 KB of flash, our sketch should still run on an Atmega88 without problems.

SWAP, a very tiny protocol for constrained wireless M2M networks: basic SWAP endpoints

2011-03-16T17:56:00.000+01:00

In order to set up a basic endpoint reference, at least for the common configuration options, any SWAP device should provide support for the following endpoints:

Product code (8 bytes): Each type of device is defined by a unique product identifier. This endpoint may be queried by other wireless nodes as a way to discover the device capabilities. A central repository containing XML definitions for each product ID may be also maintained, allowing the creation of automatic mechanisms on internet-enabled controllers.

Each product code is composed by a manufacturer id and a product id. No need to produce then unique device id's (MAC), just a unique product code for each product type.

Figure 1: Product code

Hardware version (4 bytes): Hardware version of the device.

Firmware version (4 bytes): Firmware version of the device.

System state (1 byte): Working state of the device. This endpoint can be queried or controlled so that different working modes can be entered wirelessly, including reseting the remote node.

Carrier Frequency (1 byte): This endpoint will be used to switch between the different carrier frequencies available on the device (basically between 868 MHz and 915 MHz). Modulation type will be always GFSK for SWAP.

Frequency channel (1 byte): RF channel.

Security option (1 byte): Type of encryption algorithm applied on each data packet. It should be equal to 0 if security is disabled.

Security nonce (1 byte): Current value of the cyclic nonce. If security is enabled, this endpoint should be queried before sending a command to the device. The reported nonce value would then be used in the subsequent command in order for the command to pass the protection against playback transmissions.

Network identifier (2 bytes): Custom 2-byte code used as synchronization word in a common network. In order to communicate with each other, all devices in the same wireless network must use the same network id.

Device address (1 byte): Unique device address within the network. This address must be comprised between 1 and 255, being 0 reserved as broadcast address.

These fixed endpoints will have to be defined and indexed following the above order. Any custom endpoint would be added at the end of that table.

The advantage of this solution is that any endpoint, including configuration parameters and regular endpoints would be queried and modified in the same way. This said, a proper endpoint management layer would free the protocol stack from having to address configuration operations, reducing the size of the resulting code and simplifying the work on future extensions. Almost anything in a device can be treated as an endpoint: IO's, configuration registers, setpoints, special programmings, diagnosis flags, etc. Then it's just an issue of making those endpoints readable only or modifiable.

Figure 2: architecture of the panStamp library

The final panStamp library will provide all the necessary functions to develop SWAP-enabled devices, battery-operated or not, capable to handle commands, queries and information packets, without having to deal with the protocol details. The following piece of code implements a battery-operated sensor device that sends an ADC value (epTable[10]) every eight seconds, sleeping the rest of the time:

#include "eptable.h"
#include "panstamp.h"

void setup()
{
panstamp.init();
}

void loop()
{
epTable[10]->getData();
panstamp.sleepFor(WDTO_8S);
}

Example 1: Arduino sketch of a simple battery-operated transmitter

For those wanting to directly interface with the CC1101 driver, the panStamp library will also provide lower-level methods like “CC1101::sendData” or “CC1101::receiveData”, allowing the creation of custom proprietary protocols and avoiding the use of the current endpoint management system.

SWAP, a very tiny protocol for constrained wireless M2M networks: packet format

2011-03-14T11:17:00.006+01:00

Having listed our requirements in the precedent post, designing our protocol has been just an issue of applying logics and dimensioning frame fields. At this stage, we should still decide some of the technical aspects around the protocol such as data rates, maximum hop count allowed and data encryptions. However, the rest is quite clear so far.

First of all, our SWAP frames had to fit into the original CC11XX packet structure in order to take advantage of the full list of features provided by the TI IC's. The following picture shows the SWAP frame format compared with the original CC11XX frame:

Figure 1: SWAP packet structure

The above packet structure will be constant, regardless of the type of message (function), optimizing the frame parser significantly. In fact, the retained frame structure has been specially designed to simplify the protocol stack and reduce the amount of lines of code. Device addresses are 1-byte fields, taking advantage of the automatic address filter provided by the CC1101 chip. Thus, the microcontroller has not to worry about checking and discarding messages addressed to other devices. 0 is the broadcast address, as marked by the CC1101 data sheet.

Regarding the sub-addressing, that is the way device resources are addressed, SWAP is endpoint oriented, each endpoint being identified by a unique ID within the wireless node. Every parameter in a node may become an endpoint, including configuration parameters so that they may be addressed and controlled in the same way other regular endpoints (ADC inputs, binary outputs, etc) are treated. Again, this policy provides an extra degree of simplicity to the protocol since no special configuration function has to be created. Besides, this makes the protocol extremely flexible and powerful as new features may be added in the future without having to change the frame format or the protocol itself.

Every SWAP frame will contain the following fields:

Preamble (preamble, 4 bytes): It's a typical 10101010... preamble sent to mark the beginning of the wireless frame.
Network Identifier (network id, 2+2 bytes): Each wireless network is identified by its own 2-byte id. Since this identifier sits on the CC1101 synchronization field, the network id is duplicated in order to provide better consistency to the packet.
Data Length (len, 1 byte): Length of the CC1101 data field. This length is later used to calculate the actual length of the endpoint value.
Destination Address (dest addr, 1 byte): address of the targeted device. Broadcast address = 0.
Source Address (src addr, 1 byte): Address of the transmitter.
Repeater hop (hop, 4 bits): Amount of times that each message is repeated. Original value = 0.
Security option (secu, 4 bits): Encryption method used. Default value = 0 (no encryption).
Cyclic nonce (nonce, 1 byte): Value incremented on each device each time an information message is sent. This mechanism acts as a protection against playback attacks. Default value = 0.
Function code (function, 1 byte):

Function = 0: Information packet. This packet contains information about an endpoint value on the transmitter. It may be sent periodically, as a response to an external query or as result of an internal event. Information frames are always broadcasted (destination address = 0) so that other nodes can be notified about endpoint changes from the transmitter.

Function = 1: Query packet. IT requests information (endpoint value) on the destination device. Once received by the destination node, it has to broadcast an information packet about the endpoint being queried. Query packets are the only exception to the above frame format, not transporting any data field

Function = 2: Command packet. Commands are sent to change endpoint values on the receiver. In order to minimize transmission explosions and avoid packet collisions, we should broadcast commands and queries only in case of punctual necessity.

Endpoint Address (ep addr, 1 byte): Address of the device containing the endpoint being queried or controlled. This address has not necessarily to be the same than the destination address since SWAP allows querying a device (data recorder or central controller) about and endpoint contained in a third wireless node. This feature should be specially useful to get values from any battery-operated device, typically sleeping during long periods of time.
Endpoint Identifier (ep id, 1 byte): Each endpoint is identified by its own 1-byte ID. This ID will be later used to index the endpoint in a global table by the protocol stack.
Endpoint value (endpoint value, n bytes): This is a variable length field. Each endpoint will have a its own length, depending on the nature of its value. This length may be calculated following a basic formula:

Length of the value = Data Length – 6

SWAP is contents-agnostic. This means that SWAP frames do not contain any information about the type of endpoint value being transported. As result, the receiver has to know how to decode the received value by its own means. This philosophy has its own pros and cons but, in general, abstract protocols are easier to maintain and provide extra flexibility. The reduced plug&playability is maybe the main drawback of such protocols.

Cyclic Redundancy Check (crc, 2 bytes): 16-bit CRC automatically added by the CC1101 chip.

In summary, this protocol should give us a good result in terms of compactness, flexibility and speed. In a future post I'll try to document my first impressions regarding the size of the protocol stack, performance and integration with real applications.

Swapping wireless data

2011-03-10T13:35:00.002+01:00

After highlighting our need for a wireless protocol in the precedent post, I've been carefully thinking about the way to proceed. Finally, I've taken the decision to create a custom protocol, something really simple and usable for generic M2M needs. We specially need a very lightweight protocol, simple to implement, flexible, robust and capable to fit into the list of features provided by the CC1101 chip.

Figure 1: First panStamp boards

After working with dozens of M2M protocols, mainly for wired systems, I've learned some useful things that may be applied to our wireless protocol. Flexibility is a concept rarely wanted in protocols nowadays. Instead, “plug and play” is showed as the ultimate goal for any communication technology. I personally think that a correct balance between both requirements can give the optimum result, mainly for general-purpose systems where application variables are not known at the time of designing the communication schema. The following list shows our requirements in terms of communications:

Our communication frames must fit into the CC11XX packet structure. This requirement may seem obvious but the CC11XX chips provide some useful filters and smart functions based on the contents of each data packet, and these features may result useless if the final protocol frames do not respect some basic rules.
We just need a peer-to-peer protocol, not a wireless mesh technology. Mesh systems entail maintaining routing tables and this usually requires more RAM. Instead, we want a flexible agnostic P2P protocol capable to do relatively complex things without having to invest resources for maintaining wireless infrastructures.
Our protocol must allow some basic encryption algorithm and a defensive mechanism against replay attacks. Then, the user may decide to use these features or not, depending on his requirements in terms of security and confidentiality.
Networks should be identified by custom ID's in order to minimize collisions and interferences from other neighbour networks. This feature would also allow creating multiple networks into a common building or area.
Our protocol must be very simple and allow an extremely compact implementation. Although our prototypes are initially using Atmega328p's (32KB of flash), we should be able to reuse the communication stack on Atmega168p's (16 KB) and Atmega88p's (8 KB).
Our protocol will be free and open source. We'd really like to see ports of this protocol stack for other microntroller platforms, like Microchip PIC's, TI MSP430's, generic 8051's, etc. In fact one of the first non-Arduino ports could be done for my Texas Instruments ez430-Chronos.
Our protocol must allow accessing off-line data through some external data recorders. Mobile devices like the ez-Chronos, may want to read some battery-operated device that could be sleeping at the moment of sending the query. Instead, the Chronos could send the query to a central node (data recorder) that would be permanently listening the channel for news from those battery-based sensors. In a typical mesh network, the coordinator would be this central node.
Our protocol must be contents-agnostic. From my experience when I worked with Modbus - an old boy from the 70's - I learned that abstract protocols provide an extra degree of flexibility and compactness. Any M2M information, including the most exotic one, can fit in a row of bytes. No need to create function profiles or heavy data dictionaries. At the end, the ultimate application, the one that really needs to decode the received data, has just to know the way to do it, maybe through the use of XML-based product definitions. This ultimate application will be running on a computer most of the times. Computers have the power, memory and disk space to do this kind of things whilst the wireless nodes can concentrate on transmitting and receiving data following their own formats.
Our protocol should be endpoint-based. We don't want to work with fixed-length registers as Modbus does. Instead, we''ll create variable-length endpoints at start-up time, addressable by a unique ID within the network.
Every device developed will contain a unique identifier (common for all devices of this type). This identifier will be used by the “ultimate” applications to decoded the endpoint values.

Well, we have a good list of requirements. I've already started working on the protocol schema, called SWAP (Simple Wireless Abstract Protocol) from now on. I expect to come back to this blog with a presentation of the protocol in a few days, so please hold the line :-) Thanks for your time!

Wireless protocol. The way to talk with other devices

2011-03-09T09:57:00.000+01:00

The precedent post showed the need for the panStamps to communicate with other wireless devices. The target of this project is not to provide just a CC1101 driver for DIY arduino projects but also develop the necessary libraries and tools to create a complete wireless ecosystem. Therefore, the course of the panStamp project will be accompanied by the development of a series of libraries and applications, being the CC1101 arduino driver the first of them.

Figure 1: panStamp stack

Once assumed that we need a protocol, which one could we use for the panStamp project? I've been doing the search for some time but I've not found any open protocol, compatible with the CC1101 interface, with the sufficient popularity to be considered as a standard. This leads us to consider the creation of a custom protocol for this project, specially adapted to take advantage of the features provided by the CC1101 IC.

TI ez430-Chronos

2011-03-08T17:13:00.000+01:00

This post doesn't want to be a true review about the ez430-Chronos. Internet is full of these reviews and other resources related to this interesting gadget. AFAIK, this is the only programmable wireless watch currently available in the market. Texas Instruments sells this watch as a way of promoting their cc430 wireless microcontrollers in form of development kit. This kit contains not only the Chronos watch but also a programming interface and a CC1111-based wireless stick, probably capable to act as RF gateway for SmartRF Studio. Not bad at all for USD49, shipping costs included.

Besides the available on board sensors (temperature sensor, barometer and accelerometer), the low-power CC430F6137 has an internal CC1101 RF front-end. Thus, our panStamps will be able to natively communicate with this device, taking advantage of the full list of features provided by the CC1101 IC. Regarding the development tools, there is MSPGCC4, a gcc-based compiler for the ez430 microcontroller and a specific open-source project called OpenChronos about the Chronos. All these free resources can be used to develop applications without size limitations for this wireless watch.

I've just ordered one of these kits. If the results are satisfactory, we may work on a standard firmware for the Chronos, something configurable via USB or RF so that other users would be able to join the Chronos to their panStamp networks without having to write a single line of code for the ez430. For this purpose, the Chronos may act as a kind of data browser or something similar

But, how could panStamps and ez430-Chronos' talk together? It's obvious that we'll need a common protocol for the wireless data exchange, but which one? This is a different subject and will be discussed in the next post. Stay tuned!

Multiple access, collision avoidance

2011-03-07T09:03:00.002+01:00

Avoiding packet collisions is one of the main worries when designing wireless systems. The radio-frequency space is usually crowded since ISM bands are very popular nowadays. On the other hand, implementing collision-avoidance systems depends on the features provided by each RF IC most of the times. Fortunately, CC11xx interfaces do include a listen-before-talk mechanism called Clear Channel Assessment (CCA). From the CC1101 datasheet:

“The Clear Channel Assessment (CCA) is used to indicate if the current channel is free or busy”

Any of the CC1101 GDO pins can be configure to show the current CCA state. Even better, the CC1101 includes a feature that forces it to complete transmissions only if the channel is clear. The following piece of code, taken from the CC1101 library currently being developed, shows the final function responsible of transmitting packets between panStamps:

 * sendData

 * 

 * Send data packet via RF

 * 

 * 'packet'    Packet to be transmitted

 *

 *  Return:

 *    True if the transmission succeeds

 *    False otherwise

 */

boolean CC1101::sendData(CCPACKET packet)

{

  // Enter RX state

  cmdStrobe(CC1101_SRX);



  // Check that the RX state has been entered

  while (readStatusReg(CC1101_MARCSTATE) != 0x0D)

    delay(1);

  delayMicroseconds(500);

  

  // Set data length at the first position of the TX FIFO

  writeReg(CC1101_TXFIFO,  packet.length);

  // Write data into the TX FIFO

  writeBurstReg(CC1101_TXFIFO, packet.data, packet.length);



  // CCA enabled: will enter TX state only if the channel is clear

  cmdStrobe(CC1101_STX);

  

  // Check that TX state is being entered (state = RXTX_SETTLING)

  if(readStatusReg(CC1101_MARCSTATE) != 0x15)

    return false;



  // Wait for the sync word to be transmitted

  wait_GDO0_high();

  // Wait until the end of the packet transmission

  wait_GDO0_low();



  // Flush TX FIFO

  cmdStrobe(CC1101_SFTX);

  

  // Enter back into RX state

  setRxState();

  

  //cCheck that the TX FIFO is empty

  if((readStatusReg(CC1101_TXBYTES) & 0x7F) == 0)

    return true;



  return false;

}

CC1101::sendData(CCPACKET packet) can be cyclically called until the transmission is actually completed. Each transmission will be started only if the channel is free.

Power consumption

2011-03-05T18:53:00.001+01:00

Instead of trying to get long transmission lengths, panStamps have been specially designed to consume low currents and sleep during periods of inactivity. For the current test, one of the stamps has been programmed to send a message, then sleep for 8 seconds, then wake up and send a message again; all this in a cyclic manner. The result is more than good: 5 uA during sleep (8 sec) and 2.5 mA at the moment of transmitting (0.15 sec approx).

Video showing packet reception (console on the right) on panStamp A and packet transmission (current meter on the left) from panStamp B.

Atmega's watchdog is used to periodically wake up the microcontroller from Power-Down state, the lowest power mode available on the Atmegas. Enabling the watchdog is actually adding some additional microamps to the bill; if we wanted to still reduce the current consumption, we could use Timer 2 instead of the watchdog, with an external 32.768 Khz crystal connected to the TOSC pins. According to the datasheet, we could switch from 5 uA to around 1 uA in Power-Save mode using Timer 2!

Arduino code used to put the panStamp in sleep mode:

/**
* sleepFor
*
* Put panStamp into Power-down state during "time".
* This function uses the internal watchdog timer in order to exit (interrupt)
* from the power-down state
*
* 'time' Sleeping time:
* WDTO_15MS = 15 ms
* WDTO_30MS = 30 ms
* WDTO_60MS = 60 ms
* WDTO_120MS = 120 ms
* WDTO_250MS = 250 ms
* WDTO_500MS = 500 ms
* WDTO_1S = 1 s
* WDTO_2S = 2 s
* WDTO_4S = 4 s
* WDTO_8S = 8 s
*/
void PANSTAMP::sleepFor(byte time)
{
// Power-down CC1101
cc1101.setPowerDownState();

// Power-down panStamp
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_enable();
setup_watchdog(time);
delayMicroseconds(10);
// Disable ADC
ADCSRA &= ~(1 << ADEN);
// Unpower functions
PRR = 0xFF;
// Enter sleep mode
sleep_mode();

// ZZZZZZZZ...

// Exit from sleep
sleep_disable();
wdt_disable();
// Re-enable functions
power_all_enable();
// Enable ADC
ADCSRA |= (1 << ADEN);
// Reset CC1101
cc1101.reset();
}

It's obvious that only battery-operated applications are interested in achieving so low consumptions. As an example, I've calculated the expected autonomy of the above application (WDT enabled) when powering the board from a couple of 1.5 AA batteries. The nominal charge of an AA battery (1.5 V) is around 2500 mA. If we connect the batteries directly to the panStamp, the panStamp will work only whilst the batteries are able to provide 2.7 V or more. This means that only a fraction of the charge – let's say 50% of the nominal charge - will be used for powering the boards. The rest will remain into the batteries. OK, so let's assume we have 1250 mAh of charge. With all those mAh available, we'll get the following numbers:

The panStamp sleeps (5 uA) during 8 sec → 98.33% of an hour

The panStamp transmits (2.5 mA) during 0.15 sec → 1.67% of an hour

The above percentages give us 0.0466 mAh, that means more than 3 years of autonomy when powering the board directly from the couple of AA batteries. All this with the watchdog enabled and powering the boards without an intermediate step-up regulator capable to drain the batteries below 2.7 V.

Transmission distances

2011-03-05T17:49:00.000+01:00

Both transmitters are equipped with simple wire antennas (82 mm, ¼ wave for 868 MHz). Under particular outdoor urban conditions, we've got transmission distances of more than 200 meters without loosing a single packet!

We should still check these distances under true open field conditions, without near buildings, trees and vehicles surrounding the transmission area. By the moment, results are quite satisfactory, given that these modules have not been designed with the idea of communicating over long distances. Anyway, I feel that we could even improve these distances on future prototypes, just adding bigger ground planes and better tuning the RF filter.

More tests coming soon!

panStamp board schematics

2011-03-05T11:44:00.000+01:00

Schematics are quite simple: the atmega connected to the CC1101 interface via SPI, RF balum, filter, de-coupling capacitors and some few more passives. This simplicity allows 2-layer designs and this is the case for the current prototypes.

Figure 1: Microcontroller and external pins

Figure 2: RF circuitry

However, next versions will be 4-layer surely. Working on 4 layers will let us create an intermediate continuous ground plane, closer to the top component layer. That should give us a better RF performance. As for the PCB thickness, the thinner is the board the smaller is the distance between ground plane and signal tracks so the lower is the line impedance of those tracks. This is specially important when designing RF tracks with given impedances.

Back to the above design, what could we improve for the next prototypes?

Well, there seems to be a problem on the current design that affects the firmware upload. The Arduino bootloader may be enabling the CC1101 interface during the bootstrap process, perhaps generating some undesirable SPI traffic. All this may be causing the bootload communication problems. Anyway, there are still a lot of tests to be done but I think that I'll add, at least, some in-line and pull-up/down resistors to the SPI lines in order to firmly settle those lines during the firmware upload. On the other hand, I may take a look at the Arduino bootloader too I guess.

First prototypes!

2011-03-03T23:13:00.001+01:00

This is not the finest work that the project deserves but I have my limitations when soldering small pitches by hand. Final prototypes and production runs will be totally outsourced so I'll surely want to mount smaller packages, mainly for the Atmega (QFN instead of TQFP) and the passives (0402 instead of 0603). That should let me reduce the size of the panStamp board too, maybe from DIP28 (0.6 in) to a DIP24 (0.6 in) package.

I really like the DIP format. You can plug it onto a bread board, solder components and wires directly to it or grip probes without having to use a mother board. For this first design, I decided to make all Atmega's ports available from the external pins, including the TOSC ones so I may solder a 32.768 KHz crystal for driving Timer 2 or plug an external MHz crystal when the precision or speed of the internal RC oscillator is not sufficient.

The current version of panStamp can be powered from 2.8 to 3.6 regulated VDC. This is not a tremendous voltage range but I have plans to pair the panStamp with an external NCP1400-based board in order to provide better performance for battery-powered applications. Xmegas are a better choice for this kind of battery-operated situations but Arduino does not support Xtmegas AFAIK. Anyway, even without the NCP1400 regulator the panStamp board can operated from a pair of AA/AAA batteries or a coin cell. Not so bad!

panStamp should run from its internal 8 MHz RC oscillator. That will free the TOSC pins for RTC purposes and save some space on the board too. In those cases where speed is really an issue, an external clock can be connected to the board. Powering the board at 3.3 VDC reduces the crystal choice up to 12 MHz or so according to the datasheet but maybe 3.6 VDC would let us use a 16 MHz crystal, the most common crystal valueused in Arduino designs.. By the moment, my initial tests are showing that the internal 8 MHz oscillator is more than enough for driving the CC1101 chip.

I've fabricated a couple of mother boards with USB interface for programming the stamps and acting as serial gateway. The final version will probably show a pendrive from-factor. At the current stage I just needed some extra space for soldering sensors and connecting probes.

Well, it's time now to start developing a CC1101 library for Arduino. Stay tuned for the next episode.

Texas Instruments CC1101 retained

2011-03-02T18:49:00.002+01:00

I've decided that the TI CC1101 IC is a good solution for the panStamp project in terms of wireless communication. There are basically four factors that have led me take such decision:

It's a very popular IC, widely available from most electronic suppliers. It's moreover used in thousands of commercial products.
Price is under $4 each unit in small quantities.
CC11XX IC's implement different kind of modulation mechanisms: FSK, GFSK, OOK and ASK. This will let the panStamps communicate with a huge amount of commercial products, including low-cost home automation equipment and weather stations.
The CC1101 can operate n the 315/433/868/915 MHz ISM/SRD bands . Thus, this version of panStamp will be a sub-1GHz one, extending communication distances and avoiding the most complex RF design issues.
It provides sufficient smartness to do most of the communication work in the chip, including automatic CRC calculation, address filtering, RSSI and LQI values and a Clear Channel Assessment (CCA) mechanism. CCA is specially interesting when you want to minimize packet collisions.

(Picture obtained from Digikey)

But before retaining this IC, I considered other alternatives as Atmel's 802.15.4 interfaces (AT86RF2XX), Texas Instruments' (CC25XX) and Silabs' SI443X RF transceivers, very good options all of them. I strongly recommend taking a look at Freaklabs for anyone wanting to dive into the low-power wireless panorama. The author of this great website frequently publishes reviews about the latest low-power RF devices and IC's. A very good learning resource indeed.

At the end, the CC1101 appeared as a war veteran, with lots of available resources in the net and with serious expectations to still soldier on for years. Now it's time to start designing!

panStamp Arduino

2011-03-01T23:58:00.002+01:00

Arduino has been proven to be a very popular platform with thousands of adopters around the world. There is a huge amount of libraries, tutorials and sketches developed for the very diverse Arduino boards. The IDE is simple and popular; it runs under Windows, Linux and Mac and its installation is done in a breeze. This popularity has encouraged lots of independent developers to create new arduino boards for very different applications. Arduino will definitely be a good solution for the panStamp project, the perfect compromise between my needs in terms of low-level development and the interests of the final user/developers.

Arduino uses basically C++ as programming language. It re-uses avr-gcc's libraries and provides new ones, offering high-level interfaces for most common applications. It's indeed a real success, the Arduino community has gained a major popularity among the embedded world and seem to have taken an important advantage with regards to other similar solutions, maybe because it's free and open source.

Once Arduino has been retained as programming platform, we'll obviously need to mount an Atmega on our board; not an issue, atmegas are great flexible-robust 8-bit microcontrollers with sufficient RAM memory and flash space, more than enough for most wireless applications.

What about the RF side? Which RF front-end should we use? There is no definitive response to this question in my opinion. Each solution will provide special good performances in different areas, for specific solutions. Mesh, no mesh? 802.15.4 or not? Zigbee, 6LowPAN, no stack at all? Many questions that will find an answer in the next post.

panStamp project: main goals

2011-03-01T23:03:00.003+01:00

Welcome to the panStamp blog !

This is my first post so I'll try to introduce the project and summarize its main goals in order for the subsequent posts to seat on well reasoned basis. I don't mean that everything is clear at this very primary stage but, behind the multiple unknown variables that decorate the future of this project there are some solid ideas that will help me bring it to an useful and productive end.

In some way, this weblog will try to relate the progresses of the panStamp project, from its conception up to the commercial release. Having to write about my daily work, about my ideas and decisions may help me take the necessary pause between milestones and, at the same time, let me open a window to new fresh ideas.

First of all, what does “panStamp” stand for? The first part of the word, “pan”, stands for “Personal Area Network” whilst “Stamp” is a recurrent term given to small microprocessed boards. These stamp boards usually adopt small-factor sizes, similar to postal stamps so the term is quite appropriate after all. On the other hand, from wikipedia:

“A WPAN (wireless personal area network) is a personal area network - a network for interconnecting devices centered around an individual person's workspace“.

Once the “panStam” term justified let's dive into the main goals of the project:

Create a complete ecosystem of wireless devices, capable to communicate with real things, the whole integrable with other RF or IP equipments.
Develop small OEM boards with the necessary components to start playing with low-power RF projects easily. This will include the development of mother boards, libraries, drivers and PC applications.
Use open source tools during the complete development of the project. This requirement aims to facilitate the cooperation of other developers and reduce the learning curve for future customers/adopters of the solution.
Develop the associated firmware and libraries under popular programming languages, from popular IDE's

Fig 1. Example of low-power wireless + IP ecosystem

All the above goals will surely evolve into finer requirements during the next weeks. Nevertheless, this post does not pretend to become the actual project plan – this is just a first introductory post. Please stay tuned for the rest.