2/5/2015– Kelsey Breseman
An expanding universe of connected devices means a huge influx of data– but how do you design to collect useful data, and then turn that data into insights? Jonathan Clark founded Sine-Wave Technologies in 2005 to help companies answer that question.
From deploying safety sensors in underground mines, to collecting data on commercial fishing vessels, to controlling vast swaths of highway signs, Jonathan has been working with companies to deploy unique, connected solutions across the industrial and enterprise space. An early supporter of Tessel, he kindly made the time to speak with me about the space he works in, and how the company now uses Tessel to prototype these solutions.
Kelsey: What does Sine-Wave Technologies do?
Jonathan: We’re focused on building a server-side platform to allow companies to build applications that take advantage of data that comes from the physical world.
We deploy smart devices to all over the physical world, especially in the enterprise. There’s tons of data out in the physical world, from tracking telematics data on moving vehicles, safety within a building, HVAC or lighting control, solar grids. Up until recently, it’s been very difficult to gather that data and to do anything meaningful with it.
We’ve created a server platform which allows you to take data from any device, over any network, and let you build applications that use that data to solve business problems.
Kelsey: Can you go into a little more detail about your stack? How does it work?
Jonathan: We’re a full cloud backend with analytics. We have a couple of different layers– an open SDK so you can plug in the MQTTs and CoAPs of the world, you can roll your own protocol, you can connect to a wireless mesh network based on 6LoWPAN, or you can connect to your standard Iridium satellite or cellular network and have it communicate to your device.
Above this layer is a database platform, where we’re storing all of the microtransactions coming from devices. Once we gather data, we normalize it into JSON. That allows us to deliver higher-order layers of functionality that all take advantage of this common data.
Then on top of that, analytics tools. How do you look at temporal data over time? How can we slice and dice the data? How can we build rules to react to things, to fire off events and triggers?
For example, let’s say you’ve got 8,000 thermostats deployed at a shopping chain all over the country. If we see that, generally speaking, the lights are left on for half an hour after everyone leaves and that increases the ambient temperature in the building unnecessarily. If the system was smart enough to shut the lights off, it will lower the ambient temperature by about two degrees, and if you do that, you’ll save an annual 6% in your heating costs. That’s the kind of application people want to build off of these datasets.
The platform does a lot of the trend analysis automatically. We’re a micro-transaction engine with tools that are constantly sifting and looking through your big data sets, and generating the trends.
Once you have the trends, you can have a human start to build algorithms against those trends and say, if I extract this piece of data from the billions of data points that come in, I can do something useful. I can save some money, or change the way we operate, or save a life.
Our real goal is to provide a common platform to bridge the gap between the physical and the virtual world. We want people to build real business apps, or connect to their existing applications that they have, like hook up to your ERP, or your SAP deployment, or your Oracle financials, and feed it the data that otherwise has been very expensive for companies to input manually and try to find.
Kelsey: When clients come to you, how do you help them solve their problems?
Jonathan: A lot of our clients have physical-world problems, and they come to us and ask, can you help us design an application that’s specific to this business problem?
We have a professional services team that will help prototype and design that application. A customer may have engineers on staff; if so, we’ll train up their engineers and maybe do some co-coding with them or provide them training materials, or make the first version of the app and then hand it off to them later on and they’ll maintain it and add new features.
That’s where your team comes in; we’ve been using Tessel for early prototypes. It’s super expensive for us to get a hardware company to take a little sensor and put it on a board, and write some low-level code to control it. It’s so much easier for us to have one of our software folks take something like the Tessel, and for an early prototype, write a little bit of code that speaks to our platform.
We can prototype in days what would usually take weeks, and show something to the customer. Rather than just the software app, Tessel has allowed us to really show off much more of the full stack at the prototype phase.
Kelsey: Can you give an example?
Jonathan: One of the examples that we’re using Tessel for is a customer who focuses on machine shops. There’s around 60,000 of these machine shops that do $15-25 million in business per year, all just in the US.
One of the problems with those machine shops is that they don’t know who’s working on what, without having a person walk around and physically see it. They don’t know which employees are working on what job, they don’t know which machines are down, and for what reason, or how much throughput those machines are producing.
This customer is going to market with something that will bring intelligence and get visibility into the people and the machines they are operating. We used your Bluetooth sensor to talk to an Android tablet that’s acting as the digital display at the machine to know how long that person is physically in proximity to that machine. That way, we can tell the ERP system to automatically log their hours for billing, tracking, etc.
Kelsey: What did you do before you used Tessel?
Jonathan: It was awful. Customers were typically heavily involved in having to build and design hardware. I’ve seen people spend millions on building out hardware and have to throw it away as it didn’t meet their requirements. I think that’s changing. Companies like Technical Machine are really proving that you can bring a software approach to an old, stodgy industry.
In the past, it was your classic companies that were building out boards, writing firmware, writing code for PIC microcontrollers, doing battery analysis– that stuff still goes on, but we didn’t have a good prototyping platform before.
You had to get the idea and requirements to the hardware guys, they would go off and perform some black magic for some extended period of time, and they’d come back with a product that was close to what you wanted, but it was never quite right.
It was difficult unless you fully and perfectly spec’d out the requirements. And as non-hardware folks, it was tough to spec the requirements, because the hardware people would always come back and tell us every reason why those requirements would never work.
Using Tessel, when we take it to our hardware partners, the requirements aren’t on paper anymore. They’re in code. We can hand them that code and a sample, and say, we want this, but we now need to make it low power, and vibration compliant, and it’s got to work in a waterproof case, and the radio needs to work underground, or in a noisy electrical environment.
And the hardware guys are great at doing that. They say, now I’ve got to go off and build an antenna that works next to a diesel motor, how am I going to do it? But it’s not a software problem anymore. It lets everyone focus on their core strengths.
Kelsey: What do you think is most exciting about getting all of these systems online?
Jonathan: Every other evolutionary step in computing before us, whether it was the PC, the internet itself, mobile– each one of those had a technology component. But more importantly, it changed the way we solve a given problem. At each evolutionary step, we’ve reduced the latency of the interaction, the time it takes to get data from the interaction itself.
The internet of things is trying to reduce that one more level. If we can have zero latency with all of the information in the things in the world, we can start solving problems differently.
For example, rather than doing an audit for your inventory in a warehouse every six months or every year, and finding out things are lost or stolen, if we extend the concept of the internet into your warehouse, we now have real-time access to that information. The concept of an audit goes away because you know when something’s moving or getting lost before it’s even happened.
Kelsey: What do you think is the biggest barrier to that connected future at the moment?
Jonathan: I think everybody’s wasting their time on only connectivity, trying to gather way too much data. I think you’re going to see a mountain of connection products, a lot of the internet of things platform products out there, are just a giant siphon of data or data repository or connector.
In my opinion, connectivity should be a given. Standards are evolving and will continue to evolve; that’s not the holy grail of this space. The holy grail is in the use of the data itself, in finding that digital needle in the haystack and putting it to use.
Connectivity is a means to an end. Device agnostic, network agnostic, we want great people to invent great hardware.
We want networks to evolve, we want their cost to be reduced, we want people to invent wonderful sensors, and then we want people to be able to take the data from those and build great applications.