LoRaWAN - implementation of a proof of concept solution

The challenge

The innovation team has been involved in a POC for a client.  The POC is pretty simple - asset tracking - start with 50 assets.  Many customers want to know where assets are.  In our situation we needed to find these on a daily basis - we are talking about ladders.  This customer is unique, where the plant they want to track assets on is quite large, square km in fact.  A square km is huge and we might be dealing with more than 1km2, perhaps 4 or 8.  you can easily cover 1000 acres, probably closer to 2000 acres with a single aerial.  I'm guessing that if you were out of town, the theoretical radius of 7km (pie x radius squared) = 37807 acres.  I'm saying that you need to test your aerial placement and property to know exactly how far you will get.

Our challenge was to choose a technology that could facilitate this process.  A little about the assets we are tracking, they do not have a power supply.  We wanted as little maintenance as possible from a device perspective.  It would of course be good to have OTA, as this is critical functionality if you want to change some internal device configuration.  More about this later.

We wanted the solution to be as inexpensive as possible too, as paying for 50 sim cards, data plans and more might be a little prohibitive.  The other factor of course is that 4G enabled devices are pretty expensive in terms of battery - so this was not going to be good from a maintenance perspective.   We did not want to be chasing these devices around the plant to replace batteries.

The solution

We decided that LoRaWAN would be a good solution.  This is known to use extremely low power and provide the type of throughput that we wanted.  We looked into device manufacturers and wanted a device that has a GPS capability.  You can get LoRaWAN devices that have built in GPS, but others will triangulate based upon the accurate GPS location of at least 3 aerials.  LoRaWAN works like your own cellphone tower.  So you buy a gateway and some devices and program them to talk.  This is a secure protocol, each device has a certificate installed and communicates only the encrypted messages - therefore eaves dropping is really irrelevant unless someone has your keys. 

You can see from the above that we made a purchase from the iot-store.  The exact device is this one:  https://www.iot-store.com.au/products/outdoor-lorawan-gateway-rak7249-sx1301-openwrt .  This was chosen as it has wireless and 4G capability, which is favuorable for secure sites.   There are no holes in the client network for the transfer of the data.

We are essentially sending the data directly to google cloud from the gateway.  And then we use the amazing tools available to us there (in terms of IoT HUB, pub/sub, firebase and more).  The solution has been completely decoupled from any ERP, but can be plugged in very easily using google pub/sub.

We are able to see easily where all of the devices are.  We can search certain attributes and see only the assets that match your criteria.  We have some historical views and some heat maps, which are amazing.  

We are using GPS data types, these enable us to do simple triggers on the back-end tables - enabling us to geo-fence or trigger alerts on distance traveled.

Below is how I tested the range of the devices.  I'm in urban Melbourne and got some fairly good reception for about 1.5km.  I was expecting a lot more.

You can see that I've done LoRaRUN also, to test the device.  We programmed the device to send a message every minute (so you'll see how slow I run - 5min km's).  The map below is the history of one of the devices.

 

It's interesting to note that there are some dead points, to assist with this you are going to need a couple of aerials I believe.  Multiple gateways will assist with the dead spots that you see above.

A funny story is that I also tried to test the range of the devices with my drone.  This was highly unsuccessful, as the drone's crash sensors were picking up the lorawan device and the drone was flying erratically.  I would not recommend that!

The good thing about using the drone, was that there are no dead-spots with the reception, therefore the range could be tested clearly.

Below you can see how the yabby LoRaWAN (with GPS) device (we are partnering with digitalmatter) for their hardware.  It's been reliable so far and suits the Australian conditions.   We mounted them high on the ladders to maximise the chance that they would get signal.  We also needed to be careful about being away from where feet or hands were and that they were not a hazard of any type.  We were happy with the results on a number of ladders.

Another nice thing about the yabby, is that it takes AAA batteries.  When we choose an update every 24 hours, or on movement (once movement has stopped for X seconds), the yabby can get a fix for the GPS (a battery intensive operation) and then send the location.  Pretty cool that you can schedule this or base it on the internal movement sensors.   Each yabby cost about 90 Australian dollars, these prices are bound to come down - but you need to be tracking an asset that has some inherit value.

Above is some of the configuration options that you get for the yabby.  Note that this can be done OTA too.  A cable can flash one of these bad boys in about 4 seconds, so we get our fleet done pretty quickly.

Some more details - allowing people to upload pictures of the asset and then see the historical movements.

Below is the history marker map, which plots all of the historical locations of the device

Here we have a heat map of where the device has been.

Conclusion

We were able to get a pretty nice proof of concept for LoRaWAN and GPS tracking of devices for a reasonable cost.  We are looking at about 7K of hardware and then some services.  If you are a large mine, processing plant or port - you could also track valuable assets within the range of the LoRaWAN network that you establish.  It's an incredible technology that will allow you an inexpensive solution with very low (to no) ongoing charges.

In this type of deployment, you don't need servers.  You don't need holes in your network, you get signals that allow you to save money and hopefully make better decisions.  You'll find things quicker, you'll choose the right tool for the right job, not just the closest one.  The data is available natively on a mobile device too!

Lessons for me:

• OTA is critical for the devices, don't have problems in the field and not be able to make changes
• ensure that your battery life and settings have been road tested
• additional aerials are going to assist with "Dead spots"
• don't home-brew everything
• lora-alliance might be appropriate with the right security
• Test as much as possible
• Keep your corporate network separate
• have a test device with a high update speed (every minute)
• Good mapping and instant feedback, "strategic" storage of data

JDE?

This is my JDE blog, so lets cover it off.  This portal could easily be used with Cafe1 to provide realtime location data (and historical data) for any asset in E1.  You could easily map this back to JDE a number of ways.  All of the expensive bulk data is going to be in google cloud storage, if you want to do statistical or big data analysis down the track.  Very low cost and ready for big data.   You could easily write JDE programs that would update any of the OTA settings (just say you wanted to update the idle time for a device, this could be done with JDE and orchestration).  

You could also use pub/sub from google and display notifications in JDE, but let's be honest - if we were using pub/sub, we'd probably use email or text message.

We can build up a solution like this for you - totally turn key.  You install the gateway (or two) and you get your devices and website, all pre-programmed and ready to go.

Of course I'm talking about GPS data, this could be temp, pressure - anything.  email me if you  need to know more!