posted by Bryon Moyer
A bit over a year ago, we looked at startup Plunify, who was marketing cloud-based FPGA tool instantiations. I talked to them again at the recent DAC, and they appear to be carrying out the typical modern startup roadmap, where you start with something, find out what people really do with it, and then use that information to drive new, and sometimes wholly different, products.
What they learned with their original offering was that the analytics module was really popular. So they figured out how to harness the information to help automate FPGA design optimization in the FPGA tools.
The result is called InTime, and it rides over the top of the Altera and Xilinx tools. It does a series of builds, watching the results, and then making recommendations to the designer as to which settings and constraints will provide the best results. Notably, it doesn’t touch the RTL, so this is about matching up the existing design with the tool in the most effective way.
This isn’t a typical design space exploration platform, which tends to have an element of random. This is a directed algorithm that looks at the results of the original full runs and then uses those analytics to refine the settings and constraints to achieve results that they claim to be 30-40% better than what design space exploration provides.
Not only does it improve the design at hand, but they say it can learn over time. If you’re using the cloud, then the global tool accumulates the learning, improving over time. One thing that’s changed from their original offering, however, is the cloud focus. While still available, too many companies are reluctant to go to the cloud, so they also support local instantiation. When implemented locally, the learning will accrue to the benefit of all local designs.
You can learn more in their recent announcement.
posted by Bryon Moyer
We’ve seen gesture recognition before, and the two major modes, if you will, are using cameras (either 2- or 3-D) to “see” and interpret gestures and using inertial sensors to detect hand motion and infer gestures.
Thalmic is about to launch its own gesture control armband, but they rely on a completely different source of information for detecting gestures: muscle movements. Or, more accurately, the electrical signals that govern muscle movement.
The measurement technique is called “electromyography” (EMG), and the device they’re building is called the Myo. While it does contain an inertial sensor, they say that they can detect much more subtle gestures by reading the muscles and cross-referencing that information with that of the IMU, making outsized gesturing less necessary. They claim that the EMG readings are impervious to sweat, dryness, heat, hair, and differences in muscle tone.
Each device contains 8 EMG sensors plus an IMU, some computing capability, and Bluetooth LE. The signals are processed in the armband; the output is an event representing a classified gesture. All of the usable gestures are pre-defined; they’re keeping the number of gestures to a small number.
While the gestures are fixed, their meanings aren’t. Application developers can use their SDK to assign specific semantics for the gestures within their applications. It’s even possible to fuse the events from two different armbands (one on each arm) for more complex two-handed gesturing.
I talked to them in May at the Embedded Vision Summit (ironic); at that time they had alpha samples out for developers. They recently announced the final design, slimming down and changing the look as compared to the alpha armband. In the process, they had to redo some of the electronics to accommodate the shape – and, according to their blog, they’ve improved the electrical performance in the process. Final devices are now expected to ship in September.
This doesn’t strike me as something you’d just wear around; it’s still pretty bulky as an accessory. But using it specifically as an input device for things like gaming is an interesting twist. It will also be interesting to see what new roles EMG may provide in future devices.
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.