Connecting Networked Devices

Chapter 4. The Physical Environment

At the prototyping stage, the physical environment your device operates in is fairly benign: an air-conditioned office or a lab. However, once out in the world, your final product may face an unforgiving environment: dust, vibration, exposure to elements, and even wear and tear from users.

Physical Environment

When designing the prototype, it’s important to consider where it will eventually be installed. Will it be inside or outside? If inside, what sort of environment will it face? While an office environment may be temperature regulated, a factory floor may suffer extremes of heat or cold. If installed outside, there will be a large variation in temperature over the course of a year, or even over the course of each day. The device needs to be able to cope with the expected maximum and minimum temperature extremes and rapid variations between extremes.

Beyond the temperature, your device may have to face other factors. Perhaps your device’s operating environment is subject to moisture and dust. If so, the device enclosure needs to be sealed against water ingress, with external physical ports covered for when they are not in use.

When your prototype has progressed beyond the breadboard stage, it’s important to take it to the physical environment in which it will normally operate.

Consider the Enclosure

Thanks to advanced manufacturing technology, it’s become easy, and scalable to a certain point, to manufacture one, one hundred, or even one thousand of something. The tools that now make prototyping easier—tools like 3D printers, CNC mills, and laser cutters—scale poorly beyond thousands of units. But most contract manufacturers regard orders of thousands, or even tens of thousands, of units as “low volume” or “short runs” and charge a premium.

For production runs of consumer products parts, 3D printing or CNC milling is usually too slow. But for industrial scenarios, where you might only build dozens of devices at a time, and where there is a lot of customization, these advanced manufacturing solutions might be just right.

For runs of hundreds or thousands, there are companies, like Protomold, that do provide service to companies needing small orders. They typically use molds made from aluminum, rather than steel, so your tooling cost is typically less expensive. However, these sorts of molds will have much shorter lifespans, which won’t be a problem if you need to customize each run anyhow.

Good contract manufacturers are hard to find. If you are manufacturing in larger quantities, ask your potential manufacturers to do a detailed design for manufacturability (DFM) analysis of your product. They should be able to take your Gerber, CAD, and other design files and give you detailed feedback about how each part will be made, and any potential issues around building them, as well as ways to change the design to make it easier to manufacture. This can potentially save a large amount of money by cutting manufacturing times.

Heating and Cooling

Electronics generate heat. When overheating, some processors will throttle performance to stay within their ideal temperature range. Some processors will operate so far below their normal performance level that you’ll notice the speed difference.

In some situations, electronics used in embedded devices can make do with passive cooling using small heat sinks. But in other situations, active cooling may be necessary. While fan cooling is traditionally thought of as noisy—laptops and microwave ovens spring to mind—operating a modern, low-speed (under 2,000 RPM) DC-powered ball-bearing brushless fan at the low end of its voltage range will result in sound levels less that 16 to 18 dB. At these levels, the fan noise is inaudible from more than a meter away.

Even if operated at low speeds, small fans also may lead to dust accumulation inside the device, which can reduce cooling efficiency.

Alternatives to fans do exist. If you need to move large amounts of heat away from a component, you could use a Peltier cooler. Conversely, in those circumstances where the electronics need to be heated, rather than cooled, a Peltier heater can be used. The need to heat the electronics can occur if the device is meant to operate unprotected at high altitudes, or in colder climates. However, care must be taken when designing heating systems, as the electronics will self-heat in many circumstances. Left “on,” many systems will generate enough heat from operation to stay in operation if protected from other factors by a good enclosure.

Enclosures

While human interface requirements will often drive the look and feel of an enclosure, the underlying requirements of the environment in which the device operates have to be taken into account.

A good place to start when thinking about designing enclosures, especially for industrial use, are companies like Polycase, which stocks a range of pre-built plastic enclosures and may be able to customize them with cutouts for little additional cost.

If the device is to operate for extended periods in an isolated location, you may wish to think about adding additional environmental sensors inside your enclosure to provide a self-monitoring capability to your device. You may even need to enable it to “call for help” if it determines that conditions are starting to get outside of its operating range before a failure occurs. A machine learning platform such as ThingWorx Analytics can apply machine learning to anomaly detection.

Power Requirements

The main consideration regarding power requirements is whether the device will operate on or off the power grid. If the device is designed to operate on electrical grid power, then considerations must be given to power efficiency (an inefficient power supply will waste money and generate excess heat).

If the device is to operate off grid, the required battery life will be the driving factor behind many design decisions. Large batteries will not only heavily influence the size and weight of the device, but they are also expensive and will have a dramatic influence on the bill-of-material cost of the device. Shipping costs may also be affected, as some shipping methods cannot be used with some commonly used batteries such as Lithium-ion. If you will be using solar panels with rechargeable batteries, you need to factor those into the design.

The primary power drain for most connected devices will be its radio. Therefore, anything you can do to reduce this can in turn lead directly back to a smaller battery, and lower bill-of-material costs. The choice of radio may well be determined by the power requirements. For instance, typically Bluetooth LE radios operate with power draws of less than 15 mA, while WiFi radios more typically require from 80 to 200 mA to operate. That can make a dramatic difference to the power consumption of a device.

Deep Sleep and Duty Cycle

In practice, many connected devices do not need to be connected to the Internet at all times. Therefore one common practice when working with “use everywhere” boards (discussed on page 15), which have often been designed to be used off-grid, is to use the deep sleep capabilities of the microprocessor.

For instance, the power consumption of the ESP8266 SoC drops from a typical 80 mA in operation, down to well under 10 mA while in sleep mode. This figure can be brought (much) lower by eliminating power-hungry additions like power LEDs attached to many of the breakout boards using the chip, down into the μA range. Using a 10 percent duty cycle and the sleep capabilities of the ESP8266 means that a 200 mA battery, which would normally be exhausted in just over 2 hours of normal operation, can be stretched to last over a day. If deployed outside, even a small solar panel can be used to keep the battery topped off, allowing for long duration operation of the device.

Some chips, like the ESP8266, include wake-from-sleep on interrupt capability. With this feature, battery life can be extended even longer as remote devices can be woken up only if “something interesting” happens.

Connectivity

One issue that usually won’t be encountered by your prototypes is a hostile radio environment. WiFi, Bluetooth, ZigBee radios, and several other standards all operate at or around the 2.4 GHz bands. This means that in deployment where there are lots of radios in operation, your device might suffer from poor throughput or other connectivity issues. To some extent this can be alleviated by intelligently choosing bands that are uncongested, but in the end there is only so much that can be done.

You therefore may have to consider communications protocols that are robust against data loss and disruption. The Space Communications and Networking team at NASA has done a lot of informative work on disruption tolerant networking (DTN) standards. In addition to the basic store-and-forward internetworking service, DTN also provides efficient reliability, security, in-order delivery, duplicate suppression, class of service (prioritization), remote management, rate buffering, and data accounting, all over possibly asymmetric and time-disjoint paths. Applications including file transfer, messaging, and streaming audio and video can all be implemented on top of DTN.

Another issue which may affect connectivity of your device includes accounting for motion. Is the device statically installed or in a movable enclosure? Or is it installed in a location that will itself move (e.g., under the hood of a truck)? If the device is intended to move, then DTN may prove to be a viable option, or alternatively more than one radio may be required to give multiple routes out to the Internet. For example, primary WiFi networking may be shut down when the connected device detects that it has left the area of WiFi coverage and a backup WAN connection enabled (see “Wide Area Networks” for options). If available, a low-powered secondary WAN radio is preferable. (The Netherlands has just become the first country to roll out a low data rate [LoRa] mobile communications network throughout the country.)

Storage

Beyond connectivity there is also the issue of local storage. In a unique (for modern times) situation, hardware resources are scarce on embedded platforms. How much application memory (RAM) and persistent storage (e.g., flash memory) is needed by your use case? If you make use of DTN, will longer term storage increase due to caching? It is difficult to discuss storage in general terms, as the need for onboard storage will vary dramatically with usage, but it should be factored into your design from the start, using estimates of your projected data throughput.

Where Does the Data Go?

When thinking about storage you should also consider how and where the data is going to be processed. While it may seem initially convenient to send all the data off to a remote cloud for analysis and storage, as the number of devices scales, that can become on onerous burden. An additional consideration is that you never have better context for data than at the moment of collection. Reconstructing that context later (or elsewhere) tends to be expensive, if not outright impossible. Instead of streaming every bit of information up to the cloud, make as many decisions as you can locally (on the device), process the data as much as possible without losing important details, and send only the data you need up to the cloud. This will not only save energy, but will save any costs associated with data transfer (which is particularly important when dealing with a cellular connection).