Monthly Archives: November 2013

An introduction

I have been talking, eating and breathing iotp2p for so long now that I even forgot someone might not know what it is all about. I think this short presentation, taken from the iotp2p introduction document, should be also in this blog for the benefits of newcomers wondering what this is all about.

iotp2p aims at becoming an open and interoperable standard that allows devices of any size, complexity and purpose to communicate. iotp2p wants to remove the fragmentation of the market that will be inevitably brought by closed non interoperable systems as more and more vendors bring their own solutions to the market. The tell-tales are all there already now, you can purchase lamps that are controlled by their companion mobile phone application but you need a different application to control another vendor’s lamp. Applications might be or might be not available for your specific phone operating system and you wonder what will happen when the company that sold you that lamp will shutdown their servers.

The paradigm iotp2p is closest to, not technically but from a user perspective, is email. email is open and truly interoperable. If I know a person’s email address I can communicate with that person, no matter what my email provider his, no matter what software on what platform I want to use. If that person changes email provider I only need to be notified of his new email address, I don’t need to change my software or provider as well.

The IoT is, currently, going more in the direction chats went. Chat platforms have always been fragmented since their inception. If you know a person on a certain chat service you need to create an account on that chat service in order to talk, if the person changes chat service you need to follow as well to keep in touch. XMPP came, later to the rescue, and iotp2p is, paradigm wise not technically, also similar to that. In the first stages in fact iotp2p was going to use in fact an extension of XMPP, some requirements that were later identified could not be properly fulfilled though, so iotp2p in its current shape arose.

iotp2p brings benefits to the consumer that can control all his appliances and sensors from a single application, or few dedicated applications. Consumer can also switch freely between available applications and hardware vendors without rendering useless the already purchased hardware.

But also vendors have their share of benefits since they get ready libraries, a ready infrastructure and ecosystem of control applications so they don’t need to create everything by themselves. A vendor that makes remotely controlled lamps will only have to do what it does best: the lamps. There will be already applications on the market, for all platforms, that are able to control that lamp. So while the competitors will be struggling getting the application for this or that phone model to at least behave decently another vendor will be ready to ship his product. In future, when new platforms will be available, he will not need to maintain his old software in order to keep existing customers able to use the product.

This is nothing new, mobile phone vendors include email clients in their software, they don’t create a new messaging platform, it just didn’t happen yet for the IoT.

Open vs Closed loop Toff control

Now that RAN (Radio Access Network) rel.0 specs start to take shape it was time to verify practically that low spec hardware could deliver enough processing power and, especially, accuracy to implement the proposed specs.

The first aspect that I decided to tackle, since it appears to be the most critical, is that of time offset (Toff). Toff is a measure of how far into the assigned time slot (or out of it) a node is transmitting. This has implications also on the receiving since the node needs to wake up at the correct time in order to be able to catch messages destined to it.

Toff, just to recall from the RAN.0 specs, is a value that expresses ho many mS off the center of the assigned slot is the start of a message. A value of Toff between +/-50mS yields an ACK of the message while values outside that range will cause a NACK. In open loop control there is no such feedback and the node just compensates for timing changes it knows about and re-syncs to the BCH if it gets a NACK (or often re-syncs enough to avoid NACKs). In closed loop mode the AP is reporting Toff at every ACK/NACK so the node can adjust its timers.

The target processor for this testing was an ATMega 168.

I first tested anĀ  open loop control of Toff purely based on the node compensating the errors in the sleep duration and the variations of the duration of the transmit phase. Variations of transmit phase duration can be easily compensated as during the active phase the MCU is running on a relatively stable crystal clock, so internal timers can be used to gauge the phase duration. The problem comes with the sleep phase. First of all internal timers are not running, so we have no idea of how long we have been sleeping and, secondly, even if they did the only variation in sleep time is due to clock accuracy, so that cannot be corrected using timers that are run by the clock itself.

To test the open loop Toff control I manually first calibrated the sleep cycle to compensate for error in the sleep phase duration. This would, eventually, be feasible also in production by having an automated calibration phase. At a constant room temperature all is good with this method. Issues though come, as I suspected, with temperature variations. When the ATMega is in power down mode it only runs an internal 168KHz RC oscillator which, due to the fact it is an RC oscillator, is very susceptible to temperature drift. In fact warming up the node gently just a 10-15 degrees sent the sync all over the place. The node would recover sync only by re-syncing to the BCH but with just 15 degrees temperature change the original calibration value was so much off that re-sync to the BCH would be needed every few seconds. It could be possible to keep the Toff control in open loop probably for a system that is never in sleep mode, such as a node powered from the grid, in this case the node would be much more stable in temperature and re-sync to the BCH could be afforded at any time. For a node that makes use of sleep temperature changes would require it to probably re-sync with the BCH at every transmission/reception which, in some cases, might even be acceptable but would surely take a toll on battery usage.

I then moved forward to test the closed loop alternative which, as could be expected, proved to be much more stable for a large temperature range. Sudden temperature changes will still cause a single message to get out of the slot and being rejected but after that following messages will be in sync. So closed loop control of Toff is a viable way of keeping low power nodes in sync with the network.

Based on the results of these trials I will propose to mandate closed loop Toff control already in release 0 of iotp2p RAN, leaving eventually open the possibility for the nodes to ignore Toff reports if they wish, and can afford, to re-sync with the BCH at every frame.

Testing low power modes

Today I got the first battery operated prototype running. The ATMega and the radio are now in power down most of the time and the micro is awaken with a watchdog interrupt every 8 seconds. The watchdog uses the internal 128KHz oscillator, so the power consumption is much reduced during sleep. From first tests waking the radio, doing the required business to send a message and put everything back to sleep takes about 100mS, which gives a sleep to awake ratio of about 80/1. The test started at 21:00 of November 21st, let’s see what can we get from two CR2032. There is surely a lot to be still optimized, but this will serve as a baseline for future improvement.

First battery operated node prototype

First battery operated node prototype

The NRF24L01+ and the antenna visible on this side, the Arduino Mini Pro is hot glued on the other side. Power is from two CR2032 for this first experiment.

First message trough the net

Last night I got the first message going trough the all messaging chain including radio network entry of a low power RF node, location registration and discovery of the two peers on the tracker net.

This is a milestone that requires to stop development and specifications writing to take care to make this project more public. I have already a rough web page at that is in dire need of cleanup but I thought it was also a good time to get a blog going so the tools to inform about the project progress would be in place already now.

The next step is to update some of the basic protocols documentation and publish it in the public wiki on Github.

I personally also take the chance with this first post to wish this project to be successful and truly shape the future of the IoT in a decentralized and open way so that all stakeholders will have their benefits.