editor's blog
Subscribe Now

A Tale of Two Networks

I was talking to Atmel the other day – they had announced the release of their ATPL230 power line communication (PLC) chip, which was filling in of one of the squares in the strategy that we reported on some months ago. PLC is one of the ways in which smart meters can communicate back with the utility. But when you look at Atmel’s overall communication strategy for smart energy devices, there are other options, including Zigbee, but notably not including WiFi or Bluetooth.

This may look simply like yet another battle in the wireless world, but there’s more to the story than that. First, the inclusion of Zigbee has less to do with technology than you might think. In fact, it’s partly a money story – and it almost sounds like a strategy determined by tactical dollars. As Atmel describes it, some years ago, stimulus dollars were available. Without going into the details, putting Zigbee into smart meters was a “future-proofing” step that made those stimulus funds available. Now the Department of Energy recommends (although doesn’t require, since it’s not a safety issue) Zigbee for “smart energy” home use.

But the other thing that occurred to me is that “smart energy” and “smart homes,” which would appear to be versions of the same thing, have more nuance in them as well. “Smart” tends to mean “connected,” and the smart home has lots of connected items in it. Thermostats are frequently cited as examples, but so are refrigerators and dryers and door locks.

But there are two things going on here. “Smart energy” tends to refer to energy-related devices that communicate on the utility’s network. And they do so via protocols like PLC and Zigbee. The kinds of devices that qualify as “smart energy” obviously include smart meters and other equipment dedicated to the efficient delivery of electrical energy.

But utilities also want to be able to reach into homes and factories and tinker with usage to optimize energy consumption when supplies are tight. That clearly means turning down the thermostat, but it could also mean communication with appliances that consume lots of energy, and whose use involves options, like your clothes dryer.

Would the utility actually try to reach in and prevent you from drying your clothes when energy use peaks? Perhaps not. Might a dryer manufacturer elect to include a feature that allows the utility to display current electricity pricing in an era of demand-based pricing so that you can decide whether to dry now or later? Possibly.

But there’s another aspect of the smart home, and that’s the ability to connect items to the cloud and to smartphones or computers. Yup, the Internet of Things (IoT). This is a completely separate network from the one the utilities use for smart energy. And they tend to use WiFi or Bluetooth Smart because that’s what’s in phones and computers.

So, in theory, a thermostat following the DoE-recommended approach could communicate with the utility via Zigbee and with the IoT via WiFi. The dryer could communicate via Zigbee to receive electric pricing – or it’s possible – even likely – that the utilities would also place that pricing information in the Cloud, accessed using WiFi.

According to Atmel, much of the smart-meter Zigbee capability out there now via is unused within the home. It’s clearly available for connecting outwards towards the utility, but to access nodes inside the home, the meter could also use WiFi or Bluetooth. You could even argue that it would be much more efficient to do it that way, since the smart meter would be the single transition point between the utility network and the home/IoT network. The alternative would be to require numerous devices in the house – thermostats, dryers, anything that may need to talk to the utility – to have both radios so that they can talk both to the utilities and the IoT.Drawing.png

 

All of this is, of course, still in play, so there’s no one “right way” to implement this. And yes, I keep coming back to this wireless question, not so much because I have a preferred “winner,” but because it seems to be a confusing space, and I look for those occasional refreshing moments of clarity.

Leave a Reply

featured blogs
Dec 1, 2020
If you'€™d asked me at the beginning of 2020 as to the chances of my replicating an 1820 Welsh dresser, I would have said '€œzero,'€ which just goes to show how little I know....
Dec 1, 2020
More package designers these days, with the increasing component counts and more complicated electrical constraints, are shifting to using a front-end schematic capture tool. As with IC and PCB... [[ Click on the title to access the full blog on the Cadence Community site. ]...
Dec 1, 2020
UCLA’s Maxx Tepper gives us a brief overview of the Ocean High-Throughput processor to be used in the upgrade of the real-time event selection system of the CMS experiment at the CERN LHC (Large Hadron Collider). The board incorporates Samtec FireFly'„¢ optical cable ...
Nov 25, 2020
[From the last episode: We looked at what it takes to generate data that can be used to train machine-learning .] We take a break from learning how IoT technology works for one of our occasional posts on how IoT technology is used. In this case, we look at trucking fleet mana...

featured video

AI SoC Chats: Protecting Data with Security IP

Sponsored by Synopsys

Understand the threat profiles and security trends for AI SoC applications, including how laws and regulations are changing to protect the private information and data of users. Secure boot, secure debug, and secure communication for neural network engines is critical. Learn how DesignWare Security IP and Hardware Root of Trust can help designers create a secure enclave on the SoC and update software remotely.

Click here for more information about Security IP

featured paper

Keys to quick success using high-speed data converters

Sponsored by Texas Instruments

Whether you’re designing an aerospace system, test and measurement equipment or automotive lidar AFE, hardware designers using high-speed data converters face tough challenges with high-frequency inputs, outputs, clock rates and digital interface. Issues might include connecting with your field-programmable gate array, being confident that your first design pass will work or determining how to best model the system before building it. In this article, we take a look at each of these challenges.

Click here to download the whitepaper

Featured Chalk Talk

Introducing Google Coral

Sponsored by Mouser Electronics and Google

AI inference at the edge is exploding right now. Numerous designs that can’t use cloud processing for AI tasks need high-performance, low-power AI acceleration right in their embedded designs. Wouldn’t it be cool if those designs could have their own little Google TPU? In this episode of Chalk Talk, Amelia Dalton chats with James McKurkin of Google about the Google Coral edge TPU.

More information about Coral System on Module