Inside every electronic device sold today – whether it’s a coffee maker, phone, automobile, or Mars Rover – is an embedded solution, or a combination of hardware and software that makes the thing run.
Electronics evolve quickly, and the options for these embedded solutions can sometimes be dizzying; an alphabet soup of ARM processors, Flash, RAM, USB, WiFi, Zigbee, BLE, Networking stacks, GPS, LiPo chargers, batteries, sensors, accelerometers, and the like – the underpinnings that make up a system and support the features of the end product.
The clients we partner with often begin a project with a fixed idea of which embedded solution they need for their device. But, like any of us, they are often limited by what they know, by what they’ve already used, or by what they’ve heard of. (If you’ve never worked with near field communication before, swiping your phone instead of fumbling for a debit card sounds somewhat outlandish.)
The Solution Is Hiding In Plain Sight
It’s our job to draw out the real needs of the people who’ll be using the device to prescribe the best, simplest solutions for the overall task – and the ones that will still be best and simplest a year from now. How do we do that, and if you’re building a connected device, how can you do that?
Our process is always to start with how the device will be used and then work backwards. How will the overall system integrate with databases, other devices, and online cloud services?
The common denominator for all our projects is that the product experience drives the technical approach rather than the technical approach driving the product experience.
From there you can determine communication requirements – does it need to talk to anything else? What kind of data and speed do you need, and how efficient can you make it? Once you know that, you can move on to the hardware balancing act and prescribe a solution that has, in most cases, been hiding in plain sight all along.
To show how this works in real life, here are a few examples of embedded product challenges featuring common requirements: wireless technology, video compression, and charging.
#1 – A Wireless Technology Challenge:
They thought it was a cellular radio problem. We realized it needed a mesh networking solution.
The product was an outdoor device that periodically needed service. The client wanted the unit to be able to call for servicing instead of needing to be checked manually by a person. So they asked us to redesign an older generation modem used by the unit to make the connection. This product usually worked in tandem with a bunch of other, identical units in a wide area. The client wanted every unit to have its own modem so it could call back to a central base. But cellular modems are expensive.
A-Ha! Moment: When we learned each unit would probably be within a thousand feet of another, we realized we could link them using inexpensive Zigbee mesh radios. Using a singular cellular modem bridge unit to connect the entire array would cut the price of each unit by almost $20, and still not lose the feature.
Big Picture: What’s the right wireless technology for a device? Bluetooth or dedicated radio might be better done with WiFi; or what you thought was radio frequency ID (RFID) could actually be near field communication. There are a lot of different wireless options, prices are dropping dramatically, and fewer Federal Communications Commission certification problems these days. Choices used to be a or b, but now the line is blurred and has a lot to do with how low power, low cost you want to be – what and where the device really needs to communicate.
Here’s another example where the purpose of the data allowed a different communication technique.
#2 – A Video Compression Challenge
Video surveillance isn’t a movie. So why would you compress it like one?
Video surveillance is purely utilitarian, providing a visual record in case of a crime or mishap. Most video surveillance today is recorded and compressed the same way a movie would be, using H.264 MPEG-4 encoding. H.264 requires a lot of processing power and memory to compress, but very little to decompress. The minimal processing for decompression is done intentionally to make it fast and easy for people to stream movies over the Internet or DVD, using inexpensive devices – tablets, phones, inexpensive PCs.
A-Ha! Moment: Video surveillance isn’t the latest Netflix series waiting to be binge-watched, so why record and compress it that way? It only needs to be reviewed by a few people, and only if something particular happens. Those reviewing surveillance video don’t care much about a moving picture – they just need to see quality images of the important moments, which are a tiny fraction of the total amount recorded.
For a client focused on surveillance, why not use an inexpensive compression technique that doesn’t require a lot of processing power? The newer JPEG system used by Google maps, satellite imagery systems, and digital x-ray machines gives high-quality static frames and is much cheaper to implement, in terms of memory, and processing power; it costs less per camera, and still provides better evidentiary content than video compressed by throwing away frame differences. The end user can access individual frames quickly – and make decisions quickly – without having to load clips of video.
Big Picture: Start with the use cases, and where the value in the solution lies. Keep the purpose of the data in mind, and how it is used, when you consider storage and processing options. Substantially cut the cost, power consumption, and processing in your embedded solution, and put that money in the bank. Or put it elsewhere in the system where it can give more return.
#3 – A Charging Challenge
USB charging is dandy, but an old-fashioned adapter is quicker.
A client wanted his automation control system to charge using USB, since it had extra charging ports built in for the customer to use. But USB chargers generally max out at about 2 amps. It takes a long time to charge the system at 2 amps and doesn’t leave much left over. No other devices could be plugged into the system at the same time, and it would require USB negotiation circuitry on the input and outputs to help it decide how to intelligently distribute the power.
A-Ha! Moment: We convinced our client that using a simple 4 amp, 5V power adapter would charge the system much faster and less expensively, and provide the same features for less money – albeit not in as slick a manner. The intelligence wasn’t needed, as long as we had enough power, and didn’t mind using a different power source.
The Big Picture: Don’t write off ‘old-fashioned’ technology just because it’s old. Oftentimes the simpler solution is the best one. In this case, it was faster and cheaper.
Solving the Riddle
These three examples should give you an idea of how the best, simplest embedded solution can often surprise you. Of course, every product development riddle needs to be assessed as a singular case, dependent on many factors:
- Context of the product in the use cases;
- Stepping back to assess the whole system from a perspective that integrates industrial and interaction design, research, and engineering;
- Costs in the system and of the product;
- Manufacturing constraints;
- IP considerations;
- Time for development / time to market, and so on.
Being smart and agile about making decisions is required. So is stepping back to look at the whole instead of wasting time fixating on the parts. Look to the product experience to drive the technical approach. Most of the time, this points to the best solution.
Learn more about our electrical engineering expertise.