Monthly Archives: March 2014

LoP-RAN up and running

Node_AP_Ping

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.

Advertisements