Monthly Archives: January 2014

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.