>> Connecting low power devices to
the Cloud is something critical to lots of businesses these days.
But it's not always simple because you have different protocols,
different technologies, different servers.
Part of it is a company offering
an interesting solution to streamline,
connecting all these low power devices to Azure.
Jim Wert is here to tell us
everything you need to know about this solution.
That's today on the IoT show.
[MUSIC]
>> Hi, everyone. This is the IOT.
I'm Olivier, your host and today we'll be
talking about connecting low power devices to Azure.
For that, we have Jim with us. Jim, how are you?
>> Hey, Olivier. Thanks for having me.
I'm doing pretty good.
>> Where are you calling us from?
>> Calling from Ottawa, Canada.
>> How's the weather up there these days?
>> Not a little brisk today for for June.
>> A little brisk. I think we are
feeling the same thing here in the Seattle area. It's fresh.
I wish the the actual spring or summer is coming.
Anyhow, so who is Jim and what are you doing in life, sir?
>> I'm CTO at a company called Tartabit.
We formed two years ago to specifically address the problem of
connecting low power wide area assets into the Azure ecosystem.
Now you know what is low power wide area?
Well, if you understand the space,
let's say if you have a Cat 1, Cat 3,
anything cellular that might be
a connected camera or a high end kiosk,
there are great SDK is available from
Microsoft to get you connected into the Azure ecosystem.
The problem is what happens when you're trying to do
a solution without TCat-M, narrowband IoT,
satellite, LoRa,
you're using a device at
a half mega month data plan
and you're trying to get a five year battery life.
The reality is that the existing SDKs and
tools are just not conducive for these types of solutions.
What we've done is we've implemented a wide variety of
the most popular industry standard communication tools for
these low power devices and integrated them into a single platform
to really accelerate customers
integrating into the Azure ecosystem.
>> That's great because at the end of the day,
when we're talking about IoT and especially the things in IoT,
a lot of them are things that are run on
batteries or things that are just tiny sensors,
and you were saying that's the SDK that we have for
connecting devices to Azure.
There are definitely software as to case that run on OSs,
whether they're real time OSs or bigger ones.
This time your sensors might not even have an OS in them
to just communicating through these different types of networks.
From your experience and because you're in the industry,
what's the percentage of these things,
as part of the IoT would be considered low power?
Is it like a tiny percentage or is
it the vast majority of these devices?
>> If I play the game in that you have to talk the balance
between the business side and the actual technology.
The low power devices more than likely make
up a majority of the number of units that are out in the field.
But these are the units that are extremely cheap across the stack.
They send data once per day, once per hour.
The device may only be 20 or $30.
From a revenue perspective,
there's far more money in the high end device space.
You want to buy a $1500 connected camera or do you want to
buy a $25 asset tracking sensor?
Depending on how you look at it, volume wise,
the low power devices is a huge part of
the industry value to the industry
that the higher consumption devices still are
a bigger portion of the market from a revenue perspective.
>> That makes sense and so if I bring up this slide,
these various devices connect using different technologies.
Tell me a bit about, before you show me,
how are you guys reconciling the formats of data?
Because like every single of these protocols have their own way of
formatting the data from the sensor all the way up to behind,
say, a gateway or something.
How are you guys reconciling all of that
to make sense of the data for Azure?
>> Our approach is that we
have our southbound and our northbound connections.
Southbound might be a connector for lightweight M-M,
very popular in the cellular connected space or
connectivity to one of the major LNS providers in the lower space.
Northbound to be connections into Azure IoT hub or
IoT central or digital twins or Azure Data Explorer.
In the middle is the essence of our technology,
which is a low code scripting layer
where you can import templates and rapidly create
applications to map the data model coming out of
the device into a data model
that the northbound application understands.
>> Well, I think you need to show us a little,
you came with some demos and we want to talk
about some of these protocols with actual examples.
>> Yeah, let's see.
Here we are at the IoT bridge,
as always, we start by signing in.
What we're going to do is we're going to start by looking at
something using lightweight M-M.
Lightweight M-M is protocol that is highly constrained.
It runs over co-ep and UDP.
It uses DTLS for the security.
You can see we are a neutral platform,
so we have devices from many different manufacturers connected.
These basically represent connected devices.
Some are physical, some are virtual.
We can delve into these devices and you can see the data model.
If you come from the Iot hub space,
you may be aware of DTL modeling
and being able to create a representation of your device.
Lightweight M-M has its own modeling framework
that's designed to help optimize the communications.
But you can get an indication for the type of
data that might come off of one of these devices.
I can see information about the manufacturer.
In this case, I'm looking at a device from Nordic Semiconductor.
It has numerous sensors available on it
that can provide all sorts of information.
A gas resistance, maybe
something more relatable to everybody, temperature sensors.
This information all comes through the standard model.
Now the question is, how do we get
this data into something more usable?
For that, we'll look at
the low code piece that stitches our solutions together.
>> Here we have what we call our triggers,
that low code element that
goes and puts the different pieces together.
Let's start here by looking at how
we can send data to IoT Central.
Here we have a trigger process,
lightweight end to end data.
What is this? Let's take a
second and look at the anatomy of what we're doing here.
I'm looking at an event and it
could be a event coming from the North.
Maybe somebody changed to Azure Digital Twin,
maybe I'm receiving something from
IoT hub or it could be a data coming from a device.
In this case, I could catch when
the device registers to my server,
I could catch when data arrives.
In this case, I'm looking for data,
and if I browse the events coming in,
we can see samples of what's coming off this device.
Here is data from the gas resistance sensor.
Now, in this case we're seeing it from
a different device than we were looking at
before so we're we're seeing simulated data.
But you can see the format that it comes in and all these numbers,
you say, boy, what is all that?
This is all part of
the naming scheme of that is part of light weight into app.
At the end of the day, what am I trained to do though I am
taking this in this data model that
comes from the device and I'm using
our low code layer to match this application to
a specific DTDL model so that I can send
the data to IoT Central and then at
the end I call my magic functions.
Take some of this data and update it.
Do a twin update and then send the rest is telemetry.
Here we are in my IoT Central account and
where you notice we're looking at the same device,
the nordicsemi-thingy 91 and I can see now
my data coming in and if you remember
the data format we were using before,
you're now looking at it in
a completely different format because this is what
matches the DTDL model that I happen to be using right now.
We can see the data coming in.
We can go and view the sensor data and the location on the map.
We have everything coming in from this particular device.
Whether it's the Nordic device,
whether it's a different device,
it all comes through in the the exact same way.
>> You just showed us ingesting
a Libyan term and you're saying you're supporting other protocols.
Do you want to show us an example real quick?
Because LoRaWAN actually, I'm curious to
see how that looks like as well,
because it's not the same data format.
I'm curious to see how that conversion activator looks for LORA.
>> Very good question. Let me
go back and close out of here and we'll
switch over to look at a LORA use case.
Here now we can see that I
have a number of different devices connected.
The unique attribute here is actually
these devices are connected on a wide variety of networks.
I have a bunch of devices connected on helium.
I have devices connected on senet,
I have devices connected on things network,
I have devices connected on [inaudible].
We support a wide variety of LA connections natively,
and part of our magic is providing
that normalized decoding and management of that data.
If we look at any one of these particular devices we
can see that I'm identifying it by its device EUI the
way you identify a LORA device and I then simply pick what
its device type is from my library of
over 400 different devices that we have available.
In this case, it's a brown object locator.
If I go and I look at the events that are coming off this device,
we can see that I get a bunch of information from the LORA server.
In this case, it's a helium gateway.
But the most important thing is that I'm getting my data in
already decoded so that I can simply take this now and again,
map it into my Northbound application.
In this case, let's maybe look at sending the data into
a a Azure Data Explorer or custom database. What am I doing?
Now, exactly the same model as before.
Instead of looking at lightweight and m data,
I'm looking for LoRaWAN uplink messages,
what am I going to do?
Well, If I have decoded data,
I'm going to look and if I know, if I have it, let's say,
an industrial tracker or an object locator,
I can go and build up my record
and send this data on to our Azure Kusto database.
Here we can see
an example of an application where I'm getting my data in.
I can do all diagnostics and what
might be available if we go look at, let's say,
one of those object locators,
it hasn't exactly moved in there,
it's located at my my home.
But we see the telemetry coming from this device.
We can see all the information and again there
was no customization required,
no extra Azure functions.
Everything is direct from our platform into the database.
>> I like it a lot.
You just demonstrated something super
interesting just in the context of LORA's,
the fact that you're supporting
so many different platforms that are used today by our customers.
The point I want to make here is that brownfield scenarios,
scenarios where you need to identify
existing infrastructure and connect them to
the Cloud to extend functionality,
extract insights and so on.
These are already existing, right?
People are using LoRaWAN today within LAS and then they're
doing the decoding and then they're
using their own custom application.
You can just plug it at that level.
You don't require a customer to go and change
their way they're dealing with devices
or the existing infrastructure, correct?
>> Correct. We've seen where we're moving away
from the vertical IoT applications,
and IoT is now everywhere.
Every aspect of your enterprise application in your,
let's say the visibility of
the society information needs to be pervasive, "Hey,
we need to get some of the data into
Microsoft Dynamics for real time ticket creation.
Hey, finance needs mileage from the vehicles broken down by
State so that they can pay the road taxes.
The operations group wants to know what devices have low batteries
so that they can schedule maintenance crews to go fix it."
Each of these is a completely different system
selected by a completely different view,
but it all needs access to that same fundamental IoT data.
This is where we've really
excelled at helping customers get the data,
where they need to get it in a highly reliable,
robust way and that really cut out a lot of
the middleware that was typically required for these solutions.
>> I like the pivot you're proposing, which is,
we've been talking a lot about connecting
assets to the Cloud using Cloud gateway,
which in our case call Azure IoT hub and power IoT Central.
Instead of telling people and customers,
"Hey you absolutely have to go to
that one Cloud gateway for devices."
Well, some devices will definitely be able to go
directly to that Cloud gateway was using our as the case.
But as a matter of fact if you have an L&S and
a LORAWAN infrastructure or
LWM infrastructure or when you have
the device management and connectivity taking care of,
you don't need to have get a new Cloud device gateway.
What you need is to pivot around the data itself and translating
the data from one format to
the one that is understood by the Cloud services, right?
>> Correct. I would still say more than half of
our Northbound connections are to IoT hub.
Customers didn't like the uniformity,
because even if they have multiple types of assets,
maybe there it's a utility and the substations all
report in with high end industrial PCs and logic controllers,
and those all report up to
IoT hub they want their low power assets
that are tracking the service trucks
to report through common infrastructure as well.
We're not trying to bypass things like IoT have in all cases,
but we're trying to give people that path
to get the data where it needs to go,
because sometimes it's as easy as saying,
well okay, the bulk of my data is going to IoT hub.
But for some security analysis,
we also want to tap the data going into log analytics or we
need this data getting dumped on to a separate event hub.
It is multiplex as needed.
>> Nice, I love it.
Jim, this was a great demo.
Great insights into the solution.
How does it present itself for our customers?
I think it's on the marketplace?
>> The great thing is we make it super easy to get started.
It's available on the marketplace.
Free trial is available.
You can get started with our SAS and in
a few minutes all resolves through your existing Azure account.
If you're a customer who may need more security, more control,
we do offer a private instances that can be launched
in your own Azure tenant so that you have complete control.
We have no access compatible with private networks,
utility networks, and the like.
We have a lot of different ways to do business,
and we're very excited with our relationship with Microsoft.
>> Love it. Just brought it down
here and you were showing at the same time as well
the marketplace entry so people can go and trade
for free on their Azure subscription.
That's akam.ms/iotshow/TartabitIoTBridge.
That's the name of that module in the marketplace.
Jim, thanks a lot for your time today.
I hope to see you soon on the Eye Show again?
>> Thank you, Olivier.
I hope to be back again.
>> You will, for sure. Thanks, everyone,
for tuning in and you on The Eye Show. Bye.
[MUSIC]