'Hier' An SMS alerting geofence for Mediatek LinkIt ONE

This project uses the onboard GPS and GPRS functionality of the Mediatek LinkIt ONE to publish its current location over a PubNub real-time data stream channel.

A script running on a webserver subscribes to this PubNub channel.

This webserver displays a page to the web browser (laptop, tablet, smartphone etc.) containing a Google Map with map markers visually indicating the current known location of :

(1) The LinkIt ONE(s) [project coded to handle many units]

(2) The web browser [reliance upon browser supporting geolocation]

The distance between the LinkIt ONE under scrutiny and the web browser is computed.

Using a hard-coded geofence value, if the difference between the two is greater than this geofence the webserver publishes a message across a "private" PubNub channel that only the receiving unit subscribes to, notifying that there's been a perimeter breach and to send an SMS alert to a predefined cell number alerting a human.

We don't want to initiate an SMS send *every* time we get a breach notification, these units are constantly updating their location data, so a timer is kept to see if 5 earth minutes have elapsed since the last SMS send. We always send on the first notification!

The rationale behind this being if your child/suitcase/patient is still in breach after the first SMS 5 minutes ago, you probably need reminding to get closer, quicker!

**NB** The webserver could initiate the SMS alert itself, reducing the need for this "private back-channel" communication, however, I wanted to use the GSM capability of the LinkIt ONE, having already invested in a SIM for data connectivity.

For the system overview diagram I used Dia http://dia-installer.de/

Step 1: Project requirements

HARDWARE

**************

1 x MediaTek LinkIt ONE [hereafter "MTKLIO"]

Comes complete with antennae for GPS, GSM/GPRS, WiFi/Bluetooth and a rechargeable battery to make your project truly portable.

1 x USB cable

Used for board powering, battery charging and programming/debugging.

1 x Standard-sized SIM card capable of 2G

Not PIN locked.

SOFTWARE

*************

The following developer accounts are useful:

MediaTek Cloud Sandbox https://mcs.mediatek.com/

PubNub.com https://www.pubnub.com

Google Dev Console

These are needed to obtain API keys that must be communicated across the network when attempting to access a service, such as Google Maps, also the dashboard/console functionality is useful during development.

In addition, I used a Ubidots http://ubidots.com account as it offered SMS alerts when I failed to get the onboard GSM working for this project.

Project replication would also require a web host to run the script on. This is where we point our browser when needing to look at the Map and its markers.

All code here:

https://github.com/PicoPixie/Hier

Step 2: Application

This project is a "sheepdog and flock" model.

Communication over the PubNub network features Many-to-1 and 1-to-1 channels.

The MTKLIO(s), [the sheep in the model], periodically publish their unique IDs and location over one channel subscribed to by the webserver [the sheepdog in the model].

The webserver only communicates privately with the MTKLIO(s) on their "own" channel requesting they send an SMS alert of their own geofence breach.

Possible applications would include any inventory or livestock policing; With the addition of a wearable harness and enclosure, this project would allow the bearer freedom within a "safe" radius of a supervising smartphone!

The images at this step show early stage PubNub testing: simply sending the LatLng coords back to the unit that reported them. Serial output images show the async nature of the PubNub real time data stream, any code you script has to be able to handle that.

Step 3: Limitations

There are many agents at play in this project:

(1) The MTKLIO(s), require a GPS "fix" to publish their location, the number of satellites seen and fixed at any one time will be influenced by various factors such as whether the unit is indoors or outdoors, having clear skies etc. The more satellites we can get a fix on, the more accurate the location reporting.

(2) Data communication is performed over GPRS (i.e a cellular network, it's why we need the SIM) and is subject to the unit getting a signal "in the field".

(3) The unit is powered by a rechargable battery when deployed, power levels will suffer with continued GPS usage.

(4) Messages travel across third-party channels (i.e PubNub data stream), although I've never found this to be anything other than resilient, robust and lightening fast![*]

(5) If the supervising web browser is accessing over a cable modem the location data obtained isn't very accurate and in the case of a small fence radius, may give false positives when calculating if a unit is out-of-range.

The images at this step show serial output (useful to know what the device is doing at any given time when debugging) and the dropping out and auto re-connection of a channel during testing. You can clearly see the unit receiving a "breach" notification, followed by an "OK" as the number of satellites seen varied.

[*] during testing I've found that failing to hook-up with a channel [either publish() or subscribe()] seven (7) consecutive times will make the unit "hang". I'm guessing here, but it's probably a security defence at PubNub's end to protect the integrity of the stream network(?)

Step 4: Conclusion

I'm a little bit disappointed I didn't get the MTKLIO unit to send its own SMS as initially planned, and had to use a third-party service (UbiDots) for this element of the project. This workaround meant I wasn't able to send the alerting unit ID in the message which is essential if the project is to scale well. Googling shows this GSM problem to be quite a common issue, (Mediatek forums are on Stack Overflow).

I scripted a basic sketch that did nothing but try to send one SMS to my phone, but even that failed for me.

I thought maybe there was an unread queue on the SIM that might have been blocking somehow, so I wrote a quick 'n' dirty interrogator (GitHub link) using the serial port to first read and then flush them out the queue. Even though there were a couple of unreads from my service provider this didn't help with my problem.

The SIM worked just fine in a 3G dongle the other side of the desk.

The MTKLIO SDK is Windows only, you need to install this "on top" of the standard Windows Arduino IDE.

I've been developing using a VM just fine, ensure you redirect the USB device.

There are plenty instructions out there regarding getting your dev environment setup. Be sure to follow them. That said, developing a project for the MTKLIO will be familiar ground for anyone used to working with Arduino UNO. Except the MTKLIO has all this connectivity built right in, no additional shields required!

You'll find that Windows will randomly drop the comm port when/after uploading code to the board, yes, even after you've followed the setup instructions regarding the windows comm port driver; This is also a known issue.

As with anything, remember Google is your friend, your issue won't be alien.

Happy Hacking!