Things Connected for Local Authorities

One of the big projects of the last year has been running an innovation programme for Digital Catapult and four Local Authorities – Croydon, Suffolk, Sutton and Thurrock. The innovation programme was part of the Catapult’s excellent ThingsConnected programme – which aims to stimulate more UK interest in LPWAN, because we are woefully behind some of our European neighbours.

Group photo
The innovative UK businesses involved in the programme

Each of the councils put forward a specific challenge, and the idea was to invite UK businesses to work with the councils to understand the challenges in more depth, and then propose solutions to the challenges using LPWAN technology – LoRaWAN, Nwave, Sigfox, etc. The winning ideas would then be implemented in the borough for a live trial. Continue reading “Things Connected for Local Authorities”

Things Connected innovation programme

Since last summer I’ve been helping Digital Catapult with their Things Connected programme – an intervention to encourage UK business to learn about LPWAN technology and how it can work for their organisation.

In the last quarter of 2017 I organised and ran an innovation programme for small businesses working on LPWAN solutions for social housing and independent living use cases. These are two areas that councils believe have potential to benefit from the Internet of Things, and LPWAN in particular. Continue reading “Things Connected innovation programme”

Thingitude has graduated!

Digital Catapult is a government funded non-profit company that aims to grow the UK economy by encouraging digital innovation in specific areas it has targeted. One such area is the LPWAN technologies that are of growing importance in the Internet of Things.

This year the Catapult ran its first Things Connected innovation programme for startups and SMEs – giving access to their London LoRaWAN network and support in developing products, providing a showcase and introductions to potential clients, partners etc.

Thingitude applied and was accepted onto the programme, and over the first half of the year we developed a method for enabling LoRaWAN solutions to work across multiple networks (write-ups here and here) and got several devices working on The Things Network and Things Connected. Continue reading “Thingitude has graduated!”

Roaming across LoRaWAN networks, part 2

The application end

Quick recap – In the absence of a UK-wide LoRaWAN network I am looking into the feasibility of developing a LoRaWAN based IoT solution that can work across a patchwork of LoRaWAN networks.

The previous article focused on making the Long Range VAN device – a burglar alarm for white van drivers everywhere – able to roam between different LoRaWAN networks. I am testing with The Things Network in Reading and Things Connected in London.
This article looks at the application end. My application, which receives alerts and GPS position from the van alarm will need to collect messages from different networks and relay then to the van owner.

The Things Network publishes data using MQTT. Things Connected used a different technique – it sends json data to your web server. Either way you need to have a message collector running on your server to listen out for new messages, and then process them appropriately.

On my device I control the structure of the payload (GPS co-ords), but I have little control over the structure of the LoRaWAN message I receive at the app end. There are differences between the two networks in message structure, although they are both essentially JSON format. It would be interesting to try this with Stream Technologies’ implementation of LoRaWAN, or LorIoT to see how much variety exists in message structure between networks.

At the device end I configured the device to use the same device EUI, but I don’t know if this would be permissible on all LoRaWAN networks. It feels prudent to allow for the possibility that different networks may have different device EUIs for the same physical device. An alternative approach would be to include an ID in the payload that we use instead of the device EUI. The significant downside to this alternative is that it increases the message size, which will increase the airtime usage per message, and therefore gobble up the 1% duty cycle more quickly. In my judgement it is better to keep the payload small and do the extra work within the collector.

For the purposes of proving the roaming capability I have written 2 collectors in Node.js, one listening to each network. Each collector converts the received data into a common format JSON document which is inserted into my Mongo database. My app is thereby oblivious to the fact that the data arrived over more than one network. It works with multiple devices on these 2 specific networks for one application. I could write a third collector for say Stream Technologies, and a fourth…

It strikes me that I (or you) could design and write a more general collector that could work for multiple devices and multiple networks for multiple applications and multiple databases. This feels to me like it could be a useful service to offer. I wonder whether there would be sufficient benefit and interest in such a middleware service for IoT application providers who don’t really want to worry about whose LoRaWAN network their clients have installed?

But wouldn’t it be better if the LoRaWAN specification supported roaming so we didn’t need to worry about this stuff? Hmm, maybe it’s in the post…

Roaming across LoRaWAN networks

I am a roaming journeyman, I roam from town to town,
And when I get a job of work I’m willing to sit down.
With my bundle on my shoulder, with my stick all in my hand,
And it’s round the country I will go, like a roaming journeyman.

Tom Willett – The Roving Journeyman

Spring is here, Morris Men are celebrating May Day and folk music is in the air, so you’ll forgive me if my mind turns to roaming…

…of course I mean roaming LoRaWAN devices – I’m a happily married man these days, haven’t you heard?! Continue reading “Roaming across LoRaWAN networks”