Tweet

May 2017
Interview

AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)



 

Jeff WoodardEMAIL INTERVIEWJeff Woodard and Ken Sinclair

Jeff Woodard, VP of New Business Development, Glow Labs

Jeff rounds out the Glow Labs leadership with his combination of strong technical knowledge and excellent communication skills. He translates the clients needs to the technical team and ensures they are collaborating to achieve project goals.  He has a B.A., Ecological and Evolutionary Biology with a Minor in Computer Science and a Certificate in Energy. University of Colorado at Boulder.


Company Exclusively Develops IoT Products

We advertise ourselves as a one stop shop for IoT product development. There are a lot of steps in making a connected device, but you can't start the development process without a good plan in place.

Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]

SinclairHow will the growth of IoT affect the automated building market? Aren't automated buildings already using IoT technology?

Woodard:  Yep, automated buildings are using IoT devices right now. Connected lights, thermostats, motor actuators, etc. are all examples of IoT devices. But building automation can be limited by the high upfront cost of buying and installing the products available today, especially if the building is not new construction and the new wire has to be pulled.

The growth of IoT stands to make automated buildings more achievable by driving down costs for connecting devices with new wireless standards and advances in production efficiency. A new technology developed for the home, or a smart city, could disrupt building automation with a reliable and affordable wireless alternative to something like BACnet. Additionally, with all the great minds entering the IoT space, we can expect new and unique features to become available that change how building automation operates today. Think about how people tracking through facial recognition or proximity sensors could be used to alter the HVAC schedule or security system of an automated building.

SinclairWhat excites you most about the IoT market?

Woodard:  Probably the rapid pace at which it changes. When I started in IoT, NB-IoT and LTE Cat-M weren't even a blip on my radar. Now, they're poised to disrupt the entire LPWAN market with a roll-out on existing carrier networks like Verizon and T-Mobile through what's basically a software update. When I get into the office in the morning, after drinking my coffee and clearing the inbox, I spend an hour reading the latest IoT news. This space is constantly changing, and I have to stay on top of the latest technologies to do my job.

A second exciting factor is the volume and magnitude of disruption that IoT brings with it. IoT devices can enhance efficiency, security, and safety across so many industries.  I learn about a few new use cases for IoT every day.
 
SinclairYour company exclusively develops IoT products for others. How do you approach the development process?

Woodard:  We advertise ourselves as a one stop shop for IoT product development. There are a lot of steps in making a connected device, but you can't start the development process without a good plan in place. I consult with our potential clients on their idea before the engineering begins. Is it technologically viable today? Does it solve a real problem? What's a worst case scenario BOM cost, and will consumers pay a high enough premium for your product to justify that BOM? We answer these questions together. I know the IoT space, but I usually don't know the industry they're coming from and targeting as well as they do.

Once we've established market viability and clear product goals, we start looking at the best technology to achieve those goals. If their product will be wireless, we have to pick from a myriad of available wireless protocols to connect their device. We look at battery-operated vs. powered and how that affects the product constraints.

When we have a rough idea of the technology we'll use for the product, we start modelling the device to make sure we can fit the necessary electronics in an aesthetically pleasing case.

The next step is engineering the electronics. We generally use a local PCB production facility to rapidly test and modify our PCB designs. Time to market is very important in an industry that moves this quickly.

Occasionally, we deal with a client who has the engineering expertise to create great products, but they need help with the firmware and software to control those products. We'll jump right into the software design and create beta mobile apps or cloud servers if applicable. Firmware must be stress tested and optimized for efficiency, but we generally consider embedded firmware to be the easy part.

Depending on the client, we finish the project with functional prototypes that get them in front of investors or production ready products that are manufactured overseas. For the latter, we build the relationship between the client and the production facility and hand off any technical files the production facility needs to produce at scale.

[an error occurred while processing this directive]SinclairHow do you select a wireless standard for new IoT products with so many competing protocols?

Woodard:  It's not an easy process because there is no wireless IoT standard that's perfect for every product. The variety of wireless standards is both a blessing and a curse.

I'm giving you the short answer here; the actual process would be way too long for this interview. I start by looking at where the products will be used. Will it be used in just one building? City? Nationwide? If it's just being used in a home or small building, short range or mesh wireless protocols are a great option. Nationwide deployment opens the debate about cellular vs. proprietary networks (like SigFox) which each have their own advantages.

Next, we look at the data constraints of the product. Something that's transmitting an audio file back to the cloud like Amazon's Echo needs a high bandwidth protocol like Wi-Fi to achieve that. A simple sensor transmitting bytes of data at regular intervals can use a much lower bandwidth protocol.

Similar to data constraints, power constraints play a big role. Devices that are small and need to last for years require platforms that allow the MCU to sleep when it's not in use. BLE is a great example of this; it's just regular Bluetooth that sleeps between transmissions. Generally, higher frequency standards require a higher power draw to stay on the network (but not always). An interesting standard is EnOcean, which actually harvest energy and boasts a 10+ year battery life. We've never used EnOcean, but we're itching to take on a project that requires that technology.

Finally, we look at the security constraints of the product. We take the security of all IoT devices seriously, but some products require a higher level of security than others. We make sure to pick or modify a platform, so it meets the security requirements of the project.

Generally, picking between standards is about compromise. It's unlikely you'll find a standard which fits your needs perfectly, and you'll find many that "could work." We always find the best possible compromises and present the client with clear options and the pros/cons of each one. You can learn more about wireless standards by checking out this table we made to compare them.


  footer

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources