Machine to machine communication (M2M) – What is it good for?

m2m communication

Practicalities

It’s been a while since we first started the design of our radar technology and in the early days communicating with the devices (either for configuration or data collection purposes) meant making a trip out with a laptop and a USB cable.  In the real word, this turns out not to be a not entirely practical solution, the logistics of supporting a device where the end user may be in the remote highlands of Scotland and the vendor in the sunny climes of Cornwall dictate that there has to be better solution.

Talking machines

Before we get to the final solution, it’s important to understand all communication options.  Some end users may not be constrained by such large distances but still find that having to physically connect to the device is a pain.  In these situations, Bluetooth provides a “low range” wireless communication system.  Configuration and data downloads can be achieved by simply being near the device (~10m), although not as quick for data downloads as USB, it has the convenience that on a cold and wet winters day the user can remain inside their vehicle while retrieving data.

Clearly this doesn’t solve the distance issue, but it does break the requirement of a physical connection between the end user and the device.

The Internet

The ultimate solution comes in the form of the internet, by providing a device with the ability to connect to the internet you instantly break the requirement for the end user to have physical access to the device.

The answer is to use a modem.  Modern cellular modems are actually much more than a simple modem, they’re actually full blown mobile phones that are capable of not only sending data, but can also be used for sending and receiving the ubiquitous text message (SMS).

Our solution allows devices to be contacted, configured and data to be downloaded from the comfort of your desk, no more trips out modify a setting or to collect the latest batch of data, this saves time and money!

Bits and Bytes

Because in the early days we relied on a (fast) USB connection to collect data from a device we didn’t feel that it was necessary to provide a “data format” that was particularly sparse, that is to say that the data collected from our radars is and always has been in a human readable format.

This becomes more of an issue when the connection speed drops and this is what happens when you bring a modem into the equation.  In addition to a much lower data transfer rate (think back to the early days of analogue modems!) cellular modems also suffer from latency, think of this as the delay from “A” asking a question and “B” hearing it and then “B” responding and “A” hearing the response.  Latency and not data transfer is your biggest enemy.

We went back to the drawing board and managed not only to drastically shrink the size of our data files (but still remain in a plain text format and still human readable) but we also set about splitting our dataset so that the device generated a new set of data for each day, this immediately opened up the possibility of only transferring data that you need.  Some of our competitors devices store data in one huge monolithic block, if you want the data for tuesday 3 weeks ago, then you have to retrieve all the data from the device, you could literally be sitting there for hours.

With our system, you connect to the device and retrieve only the data you’re interested in, if you only want the last 2 days worth of data then you can simply just download that data.  If you want to know what the traffic was like on this day 3 years ago, again fine, just download that single days worth of data.

It was important that we kept data in a human readable format, human readable text files have a couple of huge advantages over proprietary binary formats:

  1. They’re readable without any special tools, you have the option of using the raw data in your own tools.
  2. They’re almost immune to corruptions, a single byte corruption in a human readable file simply means that the line that contains the corruption is the only one affected, it’s trivial to ignore that data.  A single byte corruption in a binary format could render the entire dataset invalid and you won’t know until you’ve downloaded all the data and then either been informed that the data is corrupt or the import application crashes.

Bliss

Rather surprisingly we’re rather shocked that most vendors seem to think that binary file formats are the solution, but we’ve found that with careful design of the file format and the transfer protocol you can literally have the best of all worlds.

It’s also important to remember that our devices use a MicroSD card to store their data, from the factory we supply a 2GB card which in the most extreme of data capture situations allows for 20 years worth of data to be stored.