posted by Bryon Moyer
Today we talk IoT enablement. Two sources with different goals.
The first one is a platform called iChipNet from ConnectOne (we’ve seen their modules before). And it’s brought to you by a concern for interoperability, which they see as a big barrier to IoT adoption.
When we think “interop,” often we think about hardware compatibility – sensors from different sources working with hubs and brokers and what not, humming away like a well-tuned orchestra. But it’s more than that: much of ConnectOne’s emphasis is on the ability to connect with the Cloud.
The platform consists of:
- Internet controller chips
- Ethernet modules
- WiFi modules
- A hub (which is one of their modules configured as a WiFi access point); connects to the router via Ethernet
- A Cloud solution
- A smartphone app library
The first three are for Things; the hub is optional; and the last two are to bridge the difficulties they say customers encounter trying to get the whole system working. With the hub, it’s possible to have a kit produced for customers where all of the modules and the hub have their WiFi network information preloaded at the factory so that there’s absolutely no setup required by customers.
The Cloud solution consists of a gateway simply to get communication going. There are no “big data” analysis packs or anything involved (they’re not disallowed; they’re just not provided by ConnectOne). The messaging protocol they use*is proprietary; it’s something they’ve used internally for about 15 years. Because all such details are abstracted under their API, it doesn’t matter to their target customer. There are no pre-defined “objects.”
Meanwhile, Konekt has announced a starter kit for getting devices wireless access through cellular technology (standard cellular, not something like SIGFOX). Called Konekt Dash, it’s a board that can connect directly to cellular service that they’ve pre-provisioned (they’re reselling existing cellular services). Once a designer is up and running, if they want, they can use an API to manage their own cellular service in a sophisticated way between multiple carriers.
They include various “shields” (plug-in modules) for sensors as well as for power options. The platform is hardware-agnostic, meaning that they can plug their “Global SIM” into Arduino, Raspberry Pi, and BeagleBoard hardware.
The slightly odd thing is that they’re billed as a “newly-funded” company – and yet the news is that they’re running a Kickstarter campaign. Why would they do that if they’re funded? For the same reason that many people do – not for the money, but to get feedback and a sense of demand.
*Look for much more on messaging protocols next Monday.
(Image courtesy ConnectOne)
posted by Bryon Moyer
So you run across an announcement from Imec that they’ve presented a circuit at ISSCC that involves tuning to match changing antenna impedances in cell phones. And if you’ve been hanging out in the same places I have, you might have the following reaction: “Hey, this is what some MEMS guys are doing as well! Fight! Fight! Fight!”
Turns out it’s not quite that simple. I’d feel like it was just another day of me discovering yet another knowledge gap, but I wasn’t the only one conflating two concepts. Conversations with Cavendish Kinetics and WiSpry helped me pry the two issues apart.
You may recall coverage we’ve done of both WiSpry and Cavendish Kinetics on the MEMS side and Peregrine on the SoS side. They make capacitor arrays that can be configured as variable capacitors. The first two guys use MEMS switches; Peregrine uses electrical.
What problems do they solve? They help tune the antenna as conditions drift on the phone (grip changes etc.). In fact, even this conflates two things, as we covered before: both matching changing antenna impedances and recentering the resonance of the antenna to ensure that the strongest possible signals enter the phone.
Critically, that frequency centering can’t be done too tightly: full duplex on your cellphone is achieved by placing receive and transmit on two slightly different frequencies so that they don’t interfere with each other. So the antenna response has to be wide enough to provide good performance at both frequencies.
Meanwhile, Imec is actually working on something different. The duplexer in the phone separates out the receive and transmit signal paths. Filters are typically implemented using relatively bulky surface acoustic wave (SAW) or thin-film bulk acoustic resonator ((T)FBAR) devices. Imec wanted to try instead to use an electrical-balancing (EB) technique, with the initial goal of simplifying the circuit.
The high-level concept they’re exploring was actually used in the original telephone: taking a combined full duplex signal, consisting of mixed receive and transmit, and subtracting out the transmit signal (which you know because you’re at its origin) to get the pure receive signal. While that was a simple thing on old phones at voice frequency, it’s apparently not so easy up in the many-megahertz range with changing conditions. The three challenges in particular are isolation between receive and transmit, linearity, and insertion loss – and managing these in the face of changing antenna impedance.
In this particular project, Imec tackled the linearity and insertion loss as a step towards a commercially-viable EB duplexer. This is distinct from optimizing the antenna; they’re complementary solutions.
That’s all well and good, but there’s more promise if this all works out. If you can effectively isolate receive and transmit through subtraction, then you no longer need to place the signals on different frequencies. In fact, there was a paper presented at ISSCC by Columbia University that claims to have done just that: run receive and transmit at the same frequency. (Unfortunately I missed ISSCC this year due to illness and didn’t see the presentation; I received no response to a request for more information from Columbia).
And here’s the big payoff: if we can combine signals at one frequency, then instead of receive on one and transmit on the other, we can have both on both – we’ve doubled our capacity just like that.
So a relatively obscure-sounding topic (believe me, reading the Imec paper got me lost pretty quickly) may turn out to have rather astonishing consequences. We might eventually return to the old telephone approach that used to work so well.
The Imec paper can be found here (behind a paywall).
(Image courtesty Imec)
posted by Kevin Morris
Multiple financial news sources are reporting today that talks between Intel and Altera have ended. According to multiple sources, Altera declined Intel's offer and the two companies have ended negotiations.
For the rest of the FPGA industry, this may be a bit of a disappointment. Other FPGA vendors we've talked with were optimistic that an Intel takeover of Altera would be good for the other FPGA players - altering and narrowing Altera's focus, creating uncertainty among Altera's existing customers, and disrupting the company's existing development projects. Now, apparently, they'll have to continue to compete with the Altera they already know.
This does not change our view that FPGAs and heterogeneous/hybrid processing pairing FPGA fabric with conventional processors will soon revolutionize the data center in terms of performance per watt. It does mean that the competition to win that emerging market will be more open and exciting.
We will now resume our regularly-scheduled programming.