In the latest edition of EETimes Magazine, on page 10 under the title 'Android aims for greater
unity, USB support' is the following: "Google is expected to release opensource code late this year for a 915-MHz wireless mesh protocol that will be a low-cost alternative to ZigBee or Z-Wave. It could require as little as 16 kbytes of RAM and 32 kbytes of flash, enabling a 30 percent lower bill of materials than for ZigBee Pro.
The Google protocol will enable frequency hopping and ride on top of the 6LoWPAN(IPv6 over Low-Power Wireless Personal Area Networks) spec from the Internet Engineering Task Force."
Is NXP also behind this Goolge@Home wireless interface?
It would make sense since they're already in the NFC-wallet business with Google.
It's great to see a big manufacturer that not only innovates in the crowded field of SSL; but also understands that ZigBee stacks were engineered to empower utilities, NOT the consumer. Technically, ZigBee is very constrained and complex, resilience and security don't justify that kind of control over the flow of information in the Smart Grid. It would be like an ISP trying to set the rules inside every single LAN (from the IP addressing, to the ACLs inside a firewall) deployed.
IEEE 802.15.4 and 6lowPAN (with IPv6) makes a lot more of sense because the consumer retains control of the HAN. And because is IP-based, much of the infrastructure needed is already there.
The HAN gateway will simply have an inside 6lowPAN interface and an outside ZigBee SE 2.0 interface, using a modular connector like U-SNAP.
Another key enabler of NXP's GreenChip technology is SOI. If you're wondering why they need SOI in a lightbulb, here's a link to a recent piece that explains it:
I don't think this is only about controlling/ dimming light bulbs using portable devices such as smart phones. But this looks to me, NXP is taking one step forward to build solutions which could be seamlessly integrated with the smart-grid technologies in near future. What do you think?
This idea of wireless remote dimming is age old. Nevertheless, it is a good idea if executed well. But, adding it on to CFL controllers is a mistake. There will be no CFL-s in use 2-3 years from now. I have thrown out all of them from my house. They do not only contain mercury (which I do not want anywhere close to my children), but also are a sham as far as op life is concerned. I have rarely had one that lasted longer than about a year (two years max in rare cases) in a downward facing can applications, which is where most of them were used in my house.
Of course NXP and other manufacturers like to sell something which is "one per bulb" rather than "one per switch" or "one per room" - because there is a larger multiplier and a need to replace periodically. If this is such a good idea then why not either have a detachable ballast with it in (so when the CFL bit blows you dont have to replace the intelligent ballast) OR doe the signalling on the power wires and eliminate the whole wireless element altogether.
So here's the basic problem: You have to add additional circuitry to a CFL bulb which increases the price. So now you have a light bulb priced between a "dumb" CFL and an LED. On top of that, you have a "smart" CFL that is constantly drawing power to maintain a processor (not a controller), which makes the smart bulb as much as 25 percent less efficient than a dumb one. Why wouldn't you just control the lighting at the switch? It would be more power efficient and eliminate costs.
NXP has gone full circle.
Philips, along with Westinghouse and General Electric started out making light bulbs. Light bulbs led to vacuum tubes, which lead to electronics, which lead to NXP, a spinoff of Philips.
Now NXP is back to light bulbs again.
Battar "I don't seem to have any problems with the conventional wall mounted on/off controlling my lights", I see a major cost problem. When I want to add a new light I have to not only wire power to the lamp but also wire to a switch. This may involve damaging walls etc.
If I can buy a 1$ device to do the same and more then I do like it.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...