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.
posted by Bryon Moyer
We’ve spent a lot of time on sensor fusion here, and there are three players that routinely come up: Hillcrest Labs, Movea, and Sensor Platforms. Frankly, the first two have featured somewhat more prominently because they do more selling of “shrink-wrapped” product (for lack of a better word), while Sensor Platforms has tended to play closer to the vest, working with specific clients to integrate their algorithms. We did see them in QuickLogic’s FPGA sensor hub solution.
This week, they signed papers with Audience that will make them a part of Audience. If you’re not familiar with Audience (as I wasn’t), you might wonder what the heck is going on here. And if you’re a Sensor Platforms customer, you might wonder what this all means for you. Let’s address both of those.
First off, Audience makes chips that help your cell phone (or whatever) acquire the capacity for the “cocktail party” effect. In essence, they make chips that computationally implement what’s referred to as “Auditory Scene Analysis” (if you can handle the mixed metaphor of an auditory scene). This is the process by which our brains take all of the sounds we hear simultaneously – which are nothing but mixes of longitudinal air waves with complex harmonic content – and somehow figures out how to segregate the sounds, assigns them to sources, and, critically, lets us focus on one set over another even when both sets have inputs at the same frequencies.
This is the essence of the cocktail party effect, where dozens of conversations are going on simultaneously, all with voices in more or less the same range, and yet we can concentrate on one conversation without having it get jumbled up by the other conversations. Cell phones aren’t good at this, amplifying the voice as well as nearby traffic, that squalling brat, and that damn parakeet in the background.
You might think of the auditory scene as the set of other clues and cues that the brain uses – which these days would probably be called “context.” And if you’ve seen Sensor Platforms’ CTO Kevin Shaw speak, you know that they’re all about context. It’s the next big prize after simple sensor fusion. And apparently they’ve been working with Audience on algorithms. At which point Audience decided they liked the technology and ponied up some cash to own it.
So what does this mean for Sensor Platforms’ business and customers? In their conference call, Audience said that they’ll continue to service existing customers and contracts. Going forward, it sounds like they plan a dual strategy: continue selling the software algorithms while also working them into their chipsets.
There are certain businesses – military and medical were mentioned as examples – where they see the possibility of adding value, but they don’t plan to develop hardware. So they can service these markets with software.
For those markets they do serve with hardware, they see themselves having a power advantage because they have hardware accelerators for much of what they do – and it turns out that there was a big overlap between the accelerators they already have and those that would be needed to implement the Sensor Platforms algorithms.
It also sounds like they’re bought off on continuing with the Open Sensor Platform project that Sensor Platforms and ARM recently announced.
You can find out more in the official announcement.
posted by Bryon Moyer
We recently looked at Applied Materials’ solution to the challenges of lining small vias: using cobalt. But those are through-dielectric vias. What about through-silicon vias (TSVs)? After all, they can be a thousand times deeper than a standard via, so if a standard via is hard to cover, imagine how hard it must be for a TSV.
Of course, we’re talking a wider via, but AMAT says that standard physical vapor deposition (PVD) tools do an inadequate job of coating the TSVs when applying the barrier, for lots of the same reasons we discussed in the cobalt story.
Their solution to the TSV issue isn’t quite as radical as a new metal; it involves tightening up the angle of dispersion for the metals, providing better coverage. With better coverage, the barrier can also be made thinner, saving cost. A thinner layer is faster to deposit, improving throughput (and reducing cost).
(Image courtesy Applied Materials)
In addition, they’ve built a production-worthy chamber for use with titanium rather than the more typical “proven” tantalum. Titanium apparently being cheaper than tantalum. Both can be integrated with the copper seed.
You can read more about their Ventura PVD in their announcement.