posted by Dick Selwood
I am sure that it is not April 1st, so the release I got last week from Nordic Semiconductor has to be legitimate. A company in Slovenia is using one of Nordics chips to provide communication between the cooking hob and pot and pan lids.
"In operation, the IQcook hob continuously monitors sensors embedded into the pot and pan lids (any type of cookware suitable for induction hobs can be used on the IQcook appliance) to allow automatic optimization and automation of the five most common types of hob-based cooking process: steam cooking, cooking with large amounts of water (e.g. pasta or soup), slow cooking (e.g. stews), deep frying, and grilling. After selecting the desired cooking mode, the sensor installed on the pot/pan lid is activated by a simple touch."
And I thought the barbecue sensor and iPhone app was a culinary step t.o far
posted by Bryon Moyer
I can’t decide whether this is a post about technology or language. I guess it’s some of both.
A company called 1248 has announced an access point, called HyperWeave, featuring the 6LoWPAN protocol so as to bring IP all the way out to the “edge”. The first thing we need to clarify is what “edge” means. In other contexts, it refers to some mid-way point between, say, your phone and the very core of the network backbone. It’s essentially where you enter the backbone (or at least that’s how I interpret it).
That’s not what they mean here. The idea here is that the “edge” really is the edge of the complete network: the sensors gathering data. The problem posed is that traditional WiFi has required too much power, and therefore isn’t an option. By introducing 6LoWPAN into the picture, an IPv6 capability can be taken all the way to these power-stingy devices.
Now, we’ve seen before that WiFi modules are being used at the edge already, but that tends to be indoors or somewhere that has ready power. If the sensor or device has to rely on batteries or scavenged power in some far-flung locale, well, then WiFi becomes a challenge – and that’s what HyperWeave is intended to address.
They’ve also taken pains to make it easy to integrate the access points into enterprise networks so that the IT folks can manage whatever the access point is talking to. Because it’s IP-based (and can support IPv4 as well, if necessary), then it plays nicely with the rest of the network. No translation is required from some other IoT-style protocol.
My only other language kvetch is the use of “IoT-enable” as a verb in the release. I’ll simply leave it as, “Please… no…” (I know; we’re engineers; we butcher the language daily…)
You can read more about it in their announcement.
posted by Bryon Moyer
There are a couple of things going on in the world of the Internet of Things (IoT). One is abstraction and reuse: no one wants to re-invent WiFi or security or the many other things that have to be plugged together in order to get a device to connect to the Cloud. So complete packages that include support for all of these basics are becoming more common.
But there’s also a meeting of minds happening (or not): Micrium, a provider of real-time OSes (and supporting goodies) notes that embedded programmers primarily use C, occasionally broadening out into C++ or even Java as needs dictate and as space and performance allow. Cloud programmers, by contrast, tend to use things like HTML, Ruby, and have a much greater reliance on C++ and Java.
So… what happens when the low-level device programmer needs to write code that accesses the Cloud?
This is part of the motivation for Micrium’s Spectrum package. It includes their µC/OS-II (or –III) RTOS and stacks for network and IoT protocols. There’s also a Java virtual machine (VM) for deeply-embedded applications (running about 40K of code) – and an interface to Cloud services.
They’ve structured the Java VM so that it doesn’t require a separate core; it can reside on a single core with other code, which means less hardware is needed.
As to the Cloud interface, they’re working with a company called 2lemetry. The details are a bit vague (welcome to the IoT), but this appears to act as an aggregator for interfacing with the formal Cloud. The way they describe it, the Cloud is set up for relatively few high-bandwidth connections from things like phones and tablets. That’s as distinct from how sensor-enabled Things work, with many low-bandwidth connections. This intermediate layer appears to pull together and pre-digest data for interaction with the Cloud.
I haven’t seen an arrangement like that proposed before for the consumer IoT (CIoT) (although it might be buried implicitly in some of the platforms). It does resemble some of what goes on in the Industrial IoT (IIoT), with its greater reliance on hubs and gateways and brokers (literally or implicitly, via protocols like DDS) to filter data before sending it to the Cloud. But in this case, it would appear that this gateway function actually resides in the cloud, not locally.
The following graphic illustrates the content and relationships between the various Spectrum elements.
Image courtesy Micrium
You can find out more in their announcement.