Author Archives: nicolacimmino


The first release of msgp2p is ready to roll out and, with this, all building blocks of iotp2p are ready. This means I can soon concentrate on purely iotp2p issues.

msgp2p in its current form is not much more than a mock-up but it servers the purpose and allows to define the interfaces and test. msgp2p has a simple mission allow to exchange messages between two entities just knowing a globally unique long ID, no central servers, no firewall configurations no IPs nothing else than the address.

The closest existing solution is Bit Torrent Sync, which allows two or more folders to synchronize just by assigning an arbitrary long unique ID to each. msgp2p leverages on this at the moment to exchange messages encapsulating them in files that are then synchronized. The solution though is meat for files synchronization and not real time messaging so lag is an issue.

I decided to have a first beta of msgp2p in this way anyway so that the interfaces with the rest of the iotp2p system could be defined and development in other areas continued.

msgp2p is available in github and you can find in the readme information on how to use it. 


LoP-RAN up and running


This blog has been silent quite some time now. Work on iotp2p, in a sense, was paused but only to work full time on LoP-RAN. LoP-RAN is a spin-off project of iotp2p that will provide low power, low cost access to Internet for the iotp2p nodes. I thought it made sense to keep that project separate as it is a solution that can be used independently of iotp2p. A lot has been going on in LoP-RAN, you can see the current documentation in the project Wiki.

The picture in this post shows an Access Point (the box with the red and green LEDs), a node and a Linux shell pinging the node. The Access Point is a box that provides Internet connectivity to LoP-RAN. What you see in the picture is only the RF Modem, the USB cable goes to a Raspberry PI that does the actual Ethernet and IP heavy lift. The node is what you have seen before only now it’s fully IP enabled! It leases its own IP Address, replies to ping requests, can listen on any amount of UDP ports and can send UDP packets. Additionally it can now make HTTP (GET only) requests and discover its own public transport address performing a query against a STUN server.

All in all the main ingredients needed to support iotp2p are there. In the original plan, as can be seen also from iotp2p github repository, I was going for a more simple approach in which the Access Point was going to do the actual iotp2p networking and the nodes were getting just a plain serial connection to the Acess Point. The features of LoP-RAN mean though that  any node can be seen simply as another IP enabled host, this should allow to leverage on existing solutions and to build a more flexible system fully IP based.

In case you like LoP-RAN before you go and try to stream a movie through it remember these are anyway low power nodes and the throughput is extremely limited (128 bytes packets per 250mS slot at the time being), this is because the nodes are sleeping most of the time and only briefly wakeup every 250mS. In fact if you squint your eyes enough you might be able to see in the ping screenshot that the RTT is about 500mS, which is essentially all coming from the average 250mS per packet to go through. Slots will shrink in future but I don’t think the benefit will be used to reduce latency but rather to allow more nodes and bigger power savings. After all 250mS latency is more than reasonable for the applications iotp2p is intended for.

One final word about LoP-RAN nodes. They can either act as modems for an host application, for instance a small micro controller or they can act alone as SmartNodes. In the first case the host application can control the node with a serial connection and simple AT commands, much like it happens in any embedded communication module such as Bluetooth, ZigBee or GSM modules. In the case the node is acting has a SmartNode it has an internal scheduler that can run tasks in intervals from 5 seconds to 24hours. Tasks can be anything from sampling an analog or digital input to sending UDP packets or HTTP requests containing sampled data. It can also perform similar actions in response to an input level change or data received from the network. So, for instance, you could turn on a LED by sending a certain UDP packet to the node IP Address or you could have an HTTP ReST API invoked every time a door opens.

I will next iron out instabilities in LoP-RAN and enhance the the SmarNode mode.

Three nodes getting in sync with an AP

Three nodes getting in sync with an AP

This weekend I have been working on the BCH code and I finally I have multiple nodes detecting the AP and performing internal clock sync and ranging.

DHTs and ranging

The project starts to move forward on two fronts namely moving the tracking of the nodes to a more distributed solution and the radio interface has improved with this weekend experiments on ranging.

But let’s start from the tracking, I have met during the week a with a former colleague and we have been talking about DHTs and the overall idea of the project. The more I think about it the more I like the idea to ditch the current solution based on DNS, mainly cause to assign a node to a domain you still need to have a domain or have access to the tracker for a domain someone is allowing you to use, that’s way too complicated. After all iotp2p started to take form in my head when I was blown away by the simplicity of use of BitTorrent Sync and using a decentralized trackers network would give exactly the same ease of use.

Coming to the radio interface I have started to experiment with ranging. Ranging is the operation a node performs when it enters the network and attempts to establish what is the minimum needed power to reach the inner node. Using the minimum needed power is beneficial both for battery consumption and for interference reduction.  First tests show that the maximum 0dBm power is seldom needed if not in the most far corners of the apartment and that within a room the lower -18dBm most of the time sufficient.

Finally I have started to migrate the radio access stuff to a separate repository as I think it could be reused in other projects as well since it has nothing iotp2p specific even though it still is fully part of iotp2p.

A CO2 sensor with a ReST HTTP interface

I was polishing the modules code during the holidays and I thought it was time to get a feeling of how using these modules in practice feels. So I set out to build a simple CO2 sensor that exposes the latest reading through a ReST HTTP interface.

The idea is to have one node, based on an Arduino, to measure the CO2 and send the readings to another node that provides the ReST HTTP interface. The first node would access the network trough a low power RF link while the second node would run on a Raspberry PI.

For the hardware I just hooked up an Arduino Nano, an NRF24L01+ breakout board and an analog CO2 sensor. The result can be seen in the picture. It’s not a work of beauty but that was not my aim. Also it’s powered from a USB wall-wart as I didn’t go and tweak the code for low power consumption for now.


As far as code is concerned I adapted the “ardunode” code to read the sensor and add the reading to the sent message. I didn’t make a specific application for the node in the “examples” folder has the “ardunode” code is still in need of lot of development. I then copied the skeleton python node “pynode” and implemented the message handling to parse the CO2 level from the message. I then added the ReST HTTP resource using “flask”. “flask” is a great library, with few lines of code the ReST HTTP server was up and running. The code is in Github in the examples folder under CO2_ReST_endpoint, in the development branch (here)

Overall the experience was positive, it took under one hour to wrap up the hardware and adapt the existing modules to a working contraption that is now reporting regularly CO2 readings from my room and can be accessed trough a ReST HTTP query.

Too bad the scheduler code in the Access Point is not ready yet, so I cannot run more than one node using the RAN as they would both end up in the same radio slot.  But that’s work in progress! I was positively surprised anyway at the NRF24L01+ handling of the concurrent transmissions when I attempted to run two nodes, I always got consistently either the traffic from one node or another depending on which one was more near to the receiver. I haven’t found a spot where they would totally block each other or messages would be corrupted.

I witnessed today something that should inspire anyone working in the design of something, no matter what that is. An elder was sitting in a coffee shop and produced a smart phone from her purse to show to another person how to use Whatsapp.  She then proceeded unlocking the other person phone, a different model, to show there was also the same application installed.

From a design standpoint this can mean only one thing: the user mental model is fully reflected in the final product in every aspect. The touchscreen paradigm, the clear, simple and single goal of an application made this possible. Remove any of these from the equation and you are back to an unusable geeks’ only toy that won’t impress any grandma.

This is the spirit in which iotp2p was born, anyone regardless of education, technical inclination and expertise should be able to control his home heating system or trigger his greenhouse watering system from anywhere in the world or what else if they wish to do so.



Brainstorming in the nature


This weekend I went to a cottage somewhere in the middle of nowhere in Lapland, and spent some time there enjoying the fireplace and brainstorming ideas for iotp2p. Some new stuff for the trackers and especially the authentication came out. Message validation is now changed to use an HMAC, as I feared simply chaining the secret key with the message and then hashing has its weak points, HMAC does a much better job so it’s the way to go.

A general rule I have learned is that when it comes to security you should avoid rolling your own, even when it seems that what you do is perfectly safe.


All in all I think it was a good weekend, connection was practically non existent but I could work locally and relax reading in front of fire. Updated docs in github soon.


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.