posted by Bryon Moyer
Yet another Internet of Things (IoT) “platform” was announced recently: the RuBAN platform by Davra Networks. I enclosed the term in quotes not to question specifically whether this is a platform, but just as a reminder that the term “platform” means little – or perhaps it means too much, since there are many of them, and they’re all different in function and scope.
RuBAN targets not the Consumer IoT (CIoT), nor does it address the manufacturing side of IIoT. They do target Things that haven’t been connected before, relying on whatever instrumentation or data generation is already there (in other words, they don’t provide the sensors) – consistent with the brownfield approach we discussed the other day.
Examples of the applications on which they’re focusing are fleet management, mass transit ticketing and maintenance, oil/gas/mining, and security. The common denominators here are far-flung, distributed, and, often, mobile. As such, the cellular network plays an important part, much as we saw with Jasper the other day.
Davra’s direct customers will not be the owners of these networks, but rather the VARs building the networks and services. It’s a development environment intended for rapid deployment. The idea is to have a high-level way to quickly assemble rules, establish reporting, and devise alerts using point-and-click/drag-and-drop methodologies rather than detailed programming.
It’s an all-software solution, with gateways providing the key functionality. The gateways implement a “fog” function, executing rules and filtering data into the cloud. Each vehicle in a fleet, for example, may have a single gateway that channels location information (especially when establishing a geo-fence) or engine and other vehicle performance data for transmission into the cloud, where big-data functions can take over.
You can read more in their announcement, but, as with most platforms, a conversation will probably be needed to get the nitty-gritty details.
posted by Bryon Moyer
We met PowerByProxi recently when discussing wireless battery charging options. Well, they’ve recently announced what they claim to be a couple of milestones both in distance and charging power.
The distance metric has them able to charge in the “z” direction up to 30 mm away. That’s 3 cm; roughly an inch and a half. Which doesn’t actually seem that far, but, critically, since they can penetrate various construction materials, this means they can go through counters and tables (much as we discussed in the WiTricity case).
More significantly, they’ve upped their charging power to what they say is an industry-leading 7.5 W. Those of you who know phone power systems in detail may note that, at least as PowerByProxi tells it, the power management ICs (PMICs) throttle wireless charging power to 3.5 or 5 W to avoid overheating. (No such limit is placed on wired charging.)
Given that fact, you might wonder how PowerByProxi tested this out (short of designing their own PMIC): they did it by adding a dummy load to the phone to pull extra power. Their goal is that, by demonstrating 7.5-W charging (per receiver, or device being charged), future PMICs can eliminate the limit, allowing faster charging.
They also announced a “personal charger” in the shape of a bowl. This was a prototype demonstrating that phones or wearable gadgetry could be simply dropped into the bowl, without any careful positioning, and they would be properly charged.
They’re targeting this for the new Qi v1.2 protocol, which uses the lower-frequency 200 kHz range, even though PowerByProxi makes charging systems at other frequencies (they’re not firmly wedded to one format).
You can read more about their developments in their announcement.
posted by Bryon Moyer
When we talk about the Internet of Things (IoT), we’re talking about communication. But, for much of the discussion – in particular, for the consumer IoT (CIoT) – we end up focusing on WiFi, BlueTooth, and wired technologies (with TCP or UDP over IP assumed if you’re going over the internet to the Cloud).
But for industrial settings (the so-called industrial IoT, or IIoT), there’s one more critical wireless technology that we might not think about because it’s hard to imagine how it would work for the CIoT. (And it sounds really expensive.) It’s the mobile network.
We lowly consumers have started to watch our data more carefully now that caps are in place, but, other than that, we don’t think much about the data we send across. Heck, we have few tools for watching how much data we’re using; for instance, we have no way of gauging in advance just how much data we might be chewing up when accessing a particular website. So we just browse (and hopefully we don’t cringe when the bill comes).
And most of us have only a phone; we don’t connect other things to the cellular network because that would mean expensive new charges and, in most cases, a separate phone number for each Thing. Who needs that?
Well, as it turns out, industrial users have a different model. And by “industrial,” don’t think dark, dirty, greasy buildings with sparks and flames and incessant, threatening rumblings. Think open sky, fresh air, miles from civilization and, critically, from a WiFi or BlueTooth access point. You’re now on a farm in the middle of Montana, and “your” tractor needs to talk to the Mothership (as we’ll see in a future piece, your tractor may no longer be your tractor in future business models).
Or perhaps it’s a mining operation (yeah, probably need to rethink the fresh air thing for that). The common denominator is that you’re far enough away from things that cellular is your only option. (And you’re not so far out that you can’t even get that…)
As Jasper (the IoT Jasper, not the EDA Jasper recently bought by Cadence) tells it, industrial folks work with their cellular providers in a very different manner from the rest of us. When we use the cell network to get to the internet, we go through a shared gateway, referred to via an “access point name” (APN). But some businesses have custom APNs – and, while we sit here locked into our two-year contracts, they can programmatically go in and change their plans at pretty much any time.
Just spitting out a few bytes at a time? Go set the plan to something cheap. But when the weekly upload is scheduled, then, before doing the upload, you go in and change to a better plan for more data, upload the data, and then change the plan back. And all done without the need to talk to some customer service person that’s going to try to upsell all the way. Totally different world.
But here’s the deal: apparently each mobile carrier operates a bit differently. It’s not like there’s a global standard regarding the details of how you interact with these guys. And it’s complicated. (Of course.) So Jasper has built a layer that abstracts away the details of interconnecting with different operators into a single, unified API. This effectively becomes part of your transport layer, allowing more generic data handling above it. You can deal with the cellular network in the abstract, and the Jasper platform manages the details required for each carrier. Jasper says that they have relationships with 19 different carriers.
The Jasper technology includes the ability to manage and observe what’s going on with respect to the connections, and you can set up rules to automate different aspects. But, to be clear, these rules are different from those you might see in other so-called platforms. Many platforms offer the ability to set up business rules at a high level, and that’s not what this is. These are lower-level connection-oriented rules. A task management example Jasper provided was to set a rule that wakes a node up at 4 AM, sends a predefined bunch of data, and then goes back to sleep. Or it could watch to see if two simultaneous sessions happen – which might indicate a problem.
Jasper and ILS just announced a collaboration; what’s happening here is that Jasper is helping ILS by handling the mobile piece of the network.
Now… if you look at Jasper’s website, it’s pretty broad-sounding. And I started to wonder whether they actually competed with ILS in some respects. Turns out that. no, Jasper is specifically about the mobile network part; nothing else. (I found that out through a conversation, not from the website.)
In that conversation, they noted that cellular might be chosen even when other options are available. Jasper’s Macario Namie described one installation where a copier was going in, and the copier-maker wanted to charge by the copy – meaning they needed direct data access to the copier (one of those new business model things).
Problem is, trying to get in through the normal wired network (or WiFi) meant punching a hole through the firewall – which requires IT support and might fail when things are reconfigured. So instead, they put a cell radio on the copier and went that way. Problem solved.
You can read more about the ILS/Jasper collaboration in their announcement.