posted by Bryon Moyer
Seems we have so many ways of detecting the magnetic fields around us! And now we have yet another.
Some years back we covered a small company called Crocus, a maker of MRAM technology. Their MRAM cell consisted of two magnetic layers: a “pinned” reference layer and a programmable layer. The idea was that, when the layers are aligned, the tunneling resistance through the combined layers and a thin layer of dielectric between them was different from when they were anti-aligned.
So by programming the top layer to be either aligned or anti-aligned, you could store data and read it back by measuring the tunneling current through the cell (hence the resistance).
The “pinning” comes by placing the magnetic layer just over a material that, in bulk, wasn’t magnetic, but at a nano-structural level, consisted of alternating layers of atoms magnetized in opposite directions. Because they were alternating, they neutralized each other overall, but for something sitting right atop the material, it felt only the top layer, so it seemed to be magnetized. And this stabilized the magnetic layer to align and stay there.
The free layer also had a pinning material like this that stabilized it during use, but the write circuitry was able to overcome that (with the help of some heat) to allow that layer to be flipped.
So that was how it formed a memory.
Then they figured out how to do logic with it: by making both layers programmable, they could effectively implement XOR logic. Sounded interesting, although I haven’t seen any actual product come of this idea.
Now they’ve morphed things yet one more time. In this case, they’ve removed the pinning layer from the top and they’ve taken away all the write circuitry (a huge savings). Now that top layer can simply spin away according to whichever magnetic fields it happens to be in. Its direction can still be measured by checking the tunneling current.
These three configurations are illustrated in the following conceptual, super-simplified figure.
In the memory application, the current had two values – one for 1, the other for 0. In the magnetic field detector implementation, the current can take on a continuous range of values between the 1 and 0 values.
The benefits they tout include low-power sensing, linearity good enough not to need compensation, and the ability to operate as high as 250 °C.
This actually isn’t a new thing – they’ve apparently been quietly selling this stuff for a couple years, and just completed a new round of funding. But it seemed worth talking about as an example of technology being repurposed for new markets.
You can find out more on their site…
posted by Bryon Moyer
We’ve discussed Icon Labs’ Floodgate offering before – even in the context of the Internet of Things (IoT). So when they subsequently announced a Floodgate Security Manager for the IoT, I had to wonder how that was different from the Floodgate stuff they already had. A quick conversation with Icon Labs’ Alan Grau helped clarify the sitch.
The Floodgate suite we talked about before, even in the context of the IoT, is a full-up IT-oriented package running on servers. So in an IoT context, it would be a Cloud package. Specifically, it’s not running on a resource-constrained device.
The new Floodgate Security Manager, by contrast, is intended to be run on miserly IoT edge nodes. That means a few changes from their prior suite. First, the obvious: resources. And there are a number of things on a server – anti-virus management, Windows update management, and such – that don’t apply to an edge node. So those server-oriented functions were pared away.
The other major difference is the protocol support. Servers tend to speak in heavy, feature-rich protocols like AMQP. Edge nodes, on the other hand, use simpler protocols like MQTT and CoAP. The new Floodgate offering has been adapted to those protocols. Not only does this align better with how edge nodes communicate, but it also supports the constrained resource since, by definition and intent, these lightweight protocols require fewer resources to implement (at the expense of many features that an AMQP would have).
You can find out more in their announcement…
(Image courtesy Icon Labs)
posted by Bryon Moyer
Internet of Things (IoT) platforms have been a thing since we started talking about the IoT way back with our coverage of Ayla Networks. The idea is to provide all the pieces necessary for assembling an IoT application.
Problem is, “platform” is an incredibly overloaded term. In our context, it can mean an offering that includes everything you need, or it can mean a framework for interconnecting pieces (pieces not necessarily included). It may even refer only to a portion of an IoT installation, like wireless communication.
Redpine, known generally for its WiFi technology, has recently announced its own platform, which they call WyzBee. They appear to be targeting it largely at the Maker community, which is distinguished by diligent individuals off in garages and sheds with limited resources and negotiating leverage. The platform is being positioned as complete, womb to tomb, soup to nuts.
Not only are there Redpine-originated Things, but it has a design environment where you can create your production design – PC board and all.
What makes this stand out is the level of hardware integration they’ve provided – which they refer to as future-proofing. The platform implements WiFi (“n”, both bands), Bluetooth LE, and ZigBee. The IP commonality afforded by 6LoWPAN in the otherwise non-IP Bluetooth and ZigBee networks helps tie this together into something more than just a board with three random radios on it.
The other integration they’ve provided in their SoC is Twitter and Facebook connectivity. This was apparently a difficult thing to get right. They’ve also implemented direct connectivity to a variety of Cloud services, meaning that applications can access them without a separate external proxy.
Network nodes can communicate using CoAP, MQTT, email, and texts. Security is bolstered by a hardware PUF: a physically unclonable function that establishes the device ID for binding purposes as well as supporting key generation for encryption and authentication.
(Image courtesy Redpine)
You can read more about it in their announcement.