Engineering

Electrical & Software Engineering

Prototype Development

<p>If you read our blog regularly, you know that&nbsp;Delve&nbsp;is big on prototyping and testing. For us, it really comes down to failing, which we see as a good thing. (As you can see below, Thomas Edison agrees.)</p>
<p>You want to fail quickly and early so you can come up with a successful solution instead of spending a lot of time and effort pursuing a non-starter. To fail early, test early and often. This’ll leave you with plenty of time to pivot.</p>

<p>By 2030, 75% of all devices may be IoT. Explore our content series of what every product developer needs to know.</p>

Don't Miss: On-Ramp to IoT Series

Pt2 thomas edison quote

<h2>Types of Prototypes</h2>
<p>There are a lot technical aspects to consider when you’re making an interactive prototype. I’ll go into those below, but first I wanted to point out that when you’re designing a connected device, there’s a lot of testing you can do before you get to the production-grade prototype. You don’t need a working, interactive prototype to start testing (and failing). Here are a few examples of different fidelity levels of prototypes you can use to test early on in your IoT product development:</p>

Pt2 inline fidelities

<h3>Low Fidelity</h3>
<p>The lowest form of prototype is the paper prototype, pictured top left. It lets you get something together to start testing interactions with users really quickly.</p>
<h3>Low-Medium Fidelity</h3>
<p>The prototype pictured top-right is for a coffee maker with an interactive, embedded touchscreen. Here we’ve set up the prototype to work so users can interact with both the physical and digital aspects of its interface even though they have yet to be developed. The physical and digital aspects are represented in this prototype by a cup, a water carafe, and a simple wireframe we developed in Axure that’s running on an iPhone.</p>
<h3>Medium-High Fidelity</h3>
<p>The bottom-left photo shows an interactive prototype of a device with an embedded touchscreen, but the screen is not yet integrated into the device itself. In this case we created the wireframe of an onboarding walkthrough in Axure and slipped an iPhone inside an actual model of the device to let people interact with it in a realistic way.</p>
<h3>High Fidelity</h3>
<p>The bottom-right picture in the grid is an example of the highest level of fidelity, which looks, feels, and responds to the user like the actual device — and lets us really understand what’s working and what’s not.</p>
<h2>Technology: How Will You Get Connected?</h2>
<p>There are quite a few things to think about before you start prototyping: size, power, costs, connectivity, durability — all above and beyond the user interface you intend to support. Again, it helps to spend enough time upfront to clearly understand the end user’s needs and what problem(s) your users want to solve. People tend to want to jump right in and work on a prototype, but first you have to do enough research to know you’re solving the right problems.</p>
<p>Security is another strategic decision. How much security are you (or your client) willing to pay for? Nothing is perfectly secure, but security issues can be hard to fix once you are exposed and the product has shipped. Encrypted communication is becoming a requirement in IoT devices.</p>

<p>Of course, one of the larger considerations for an IoT device is how it will actually connect to the Internet. The methodologies currently in vogue and garnering all the attention are WiFi, Bluetooth, ZigBee, and cellular radio. That said, there are many factors to consider and there is no one cookie-cutter approach. The method you choose needs to be project-specific.</p>

Pt2 how to connect

<h3>WiFi</h3>
<p><strong>Good for:</strong> If you want to use the existing infrastructure and you have a little bit more power. In order to stay connected to a WiFi platform you have to keep sending data, i.e. using more power. Otherwise the local infrastructure will toss you out and it takes a significant amount of time and power to reconnect. For that reason, it’s not as well suited for battery-powered devices, such as wearables.</p>
<p><strong>Drawbacks</strong>: WiFi requires a bit more setup in order to get the device onto local WiFi infrastructure, and the stack involved in WiFi is more complicated and requires more memory. The cost is moderate — WiFi can cost around five to ten dollars in volume. What you pay for in terms of power and memory, though, you get back in speed.</p>
<p><strong>Benefits:</strong> WiFi does come with benefits like increased bandwidth and independence from cell phone or gateway devices, so it works well for things like refrigerators, thermostats, and sprinkler systems. These are stationary, plugged-in devices and appliances that require a higher bandwidth connection or constant connection to the Internet and don’t need a gateway. The increased bandwidth makes WiFi a good choice for higher performance applications, like cameras and higher-rate data collection applications. In these cases, there’s really no substitute. WiFi can be hundreds to thousands of times faster.</p>
<h3>Bluetooth</h3>
<p><strong>Good for:</strong> A device you want to connect to the Internet through, say, your cell phone or another connected device, but that requires a gateway application for real Internet connectivity. Bluetooth has low power consumption compared to WiFi and cellular options. It’s getting a lot of traction in the healthcare field for things like insulin pumps. It offers ‘beacon’ proximity detection that is gaining popularity in location-aware services—in retail and other applications. Since it works well for proximity detection and tracking, it’s a popular choice for fitness trackers. Google has an ‘<a href="http://venturebeat.com/2015/07/14/google-embraces-bluetooth-low-energy-beacons-launches-open-format-eddystone-apis-and-management-tools/">Eddystone</a>‘ reference platform that is demonstrating beacons in embedded applications.</p>
<p><strong>Drawbacks:</strong> The range isn’t great, and with the new Bluetooth low energy, there are limited mesh capabilities or networking capabilities—and only if the device is using proprietary communication stacks. It’s also not a great choice in high-traffic areas because it’s not particularly reliable, but the cost is very low. In some implementations, it’s as little as $1.50 for small to medium volume applications.</p>
<h3>ZigBee</h3>
<p><strong>Good for:</strong> A lot of things. More home automation and industrial control applications are opting to connect through ZigBee, a mesh networking standard that sits on top of an 802.15.4 physical radio. It allows each device to connect to other devices without a router, and it self repairs the network connection by automatically routing through the best possible path.</p>
<p>We’re seeing it used in industrial valve and temperature collection, data collection, and home automation applications like door locks, thermostats, and window breakage sensors. There are several other competing standards for protocol stacks on top of 802.15.4 radios, but ZigBee is a leading communications stack option. We wouldn’t be surprised to see it expand dramatically, especially with the <a href="http://threadgroup.org/">Thread Group</a>‘s recent release of a protocol specifically for home automation that may replace ZigBee on 802.15.4.</p>
<p><strong>Benefits:</strong> It’s relatively low cost and usually runs from a dollar to a few dollars at high volumes. So it’s a bit more expensive than Bluetooth but less expensive than WiFi, and it’s pretty flexible. The mesh radio allows you to send data over pretty long distances for very low power, so it’s good for low battery-power applications. Common uses include valves, temperature sensors, and controls in building control and lighting.</p>
<p><strong>Drawbacks:</strong> There are a lot of different protocols and people are rolling out their own protocols to handle security across the mesh. The best security protocol for ZigBee isn’t exactly clear yet, but I believe that’s one of the things the Thread Group wants to address.</p>
<h3>Cellular Radio</h3>
<p><strong>Good for:</strong> When you have a remote application that needs to connect to the Internet, cellular radio is pretty much the only way to go. Cellular radio is the last stop if you don’t have any other methodologies for getting connected—when you don’t have WiFi, a Bluetooth connection to a cell phone, or a gateway. It’s being used for applications like animal tracking, radio dog collars, that sort of thing.</p>
<p><strong>Drawbacks:</strong> High cost—cellular radio can be as high as eighteen to twenty dollars at volume—and high power requirements. It can be used for battery-powered applications, but it is not well-suited for long-term disconnected devices. There are also certification issues. To work with carriers, certification and approvals can cost upwards of $100k and take months to process. It also has service contract requirements so there is a yearly fee associated with keeping cellular radio devices connected.</p>
<h2>Technology: How Will You Communicate with the Cloud?</h2>
<p>Once you’ve figured out how your device is going to connect to the Internet, you have to decide which language it will use to communicate with the cloud. There are so many options out there right now—and so many ways you can put them together. The best option varies from case to case. Sometimes a cloud provider might require a specific language or there might be an existing standard for a system you’re trying to work with. Often it comes down to the cost model differences, and what’s familiar to you and your development team. Some methodologies that are popular right now are JSON, MQTT, CoAP, XMPP, SOAP, and REST:</p>

Pt2 Io T How to Communicate

<h4>JSON</h4>
<p>JSON (JavaScript Object Notation) is simply a lightweight data transport using JavaScript. It’s basically key value pairs, and it’s well supported but not very defined in terms of a dictionary of ‘standard’ key types for a lot of applications. There’s not a good consensus for a particular application, say home automation, that has a well-published spec everybody is signed up to. That could be said for most of the rest of the competing standards as well, though. They’re all competing for space in what’s coming up with home automation, and IoT in general.</p>
<h4>MQTT & XMPP</h4>
<p>MQTT, or Message Queue Telemetry Transport, is more of binary format whereas JSON is more of an English-readable format. This makes MQTT more lightweight in communication costs. MQTT has the publish-and-subscribe mechanism, and it needs a small broker service in the protocol stack in order to handle this, but generally it’s very small and responsive. Extensible Message and Presence Protocols (XMPP) is very similar to MQTT.</p>
<h4>CoAP & SOAP</h4>
<p>Then there is Constrained Application Protocol, or CoAP. This is a well-defined request-response protocol, and it’s gained a lot of traction recently. It’s showing up in a lot of different places, more in industrial automation. SOAP, Simple Object Application Protocol, is simply another methodology for transferring lots of data over existing HTTP, using an XML-similar text format.<br></p>

<p>Delve has developed a wide range of products in the IoT category, from wearables to home automation devices to medical tools to connected appliances.</p>

Services Page: IoT Product Design and Development

<h4>REST</h4>
<p>All of these methodologies are using essentially REST, Representational State Transfer, a software architecture style that really works well over the Web and Internet in general. It can use existing connection methods, server technologies, and parsing methods.</p>
<p>All of these work in the same Web space and allow us to communicate with the cloud. Once you’ve chosen how to connect and communicate, your next decision is <a href="https://www.delve.com/insights/on-ramp-to-iot-selecting-a-cloud-provider" target="_blank">Selecting a Cloud Provider.</a></p>

<p><strong>Learn more about&nbsp;<a href="https://www.delve.com/services/iot-product-design" target="_blank">IoT Product Design & Development Services at Delve.</a></strong></p>

SEO Text: IoT Products

Newsletter Signup: Digital-Physical Product Development (icon visual)

Pt2 thomas edison HERO

<p><strong>When you’re designing a connected device, there’s a lot of testing you can do before you get to the production-grade prototype. Here are a few examples of different fidelity levels of prototypes you can use to test early on in your IoT product development.</strong></p>

Contact Us | General (Let's build something together)

Industrial / Commercial Products

Consumer Products

Home

Insights

On-Ramp to IoT: Getting Connected and Communicating

Breadcrumbs

A full-service product design and strategic innovation consultancy.

Delve

When you’re designing a connected device, there’s a lot of testing you can do before you get to the production-grade prototype. Here are a few examples of different fidelity levels of prototypes you can use to test early on in your IoT product development.

When you’re designing a connected device, there’s a lot of testing you can do before you get to the production-grade prototype. Here are a few examples of…

description

generator

kSwNn6qD4B-4HloWnWMUBWQNpBx2_mPi3nMqgsh6ato

google-site-verification

connected, device, there’s, testing, fidelity, levels, prototypes, test, early, designing, production-grade, different, product, you’re, prototype

keywords

https://cms.delve.com/assets/images/_1200x630_crop_center-center_82_none/Pt2_thomas-edison-HERO.jpg?mtime=1701287187

https://linkedin.com/company/delvedesign/

https://www.delve.com/insights/on-ramp-to-iot-getting-connected-and-communicating

referrer

robots

twitter:card

twitter:creator

twitter:description

https://cms.delve.com/assets/images/_800x418_crop_center-center_82_none/Pt2_thomas-edison-HERO.jpg?mtime=1701287187

twitter:image

twitter:image:alt

twitter:image:height

twitter:image:width

twitter:site

twitter:title

{"title":{"title":"On-Ramp to IoT: Getting Connected and Communicating | Delve"}}

Get Technical

Privacy Policy

FCOI Policy

Services

Case Studies

Testimonials

What We Do

About Us

Our People

Join Our Team

Careers

Newsroom

Who We Are

Boston

Madison

Philadelphia

San Francisco

Our Studios

Partner with Delve

Contact Us

Contact

<p>Vamsee Pamula, Founder &amp; President, Baebies</p>

Read informative articles from Delve's team of experts. Discover innovative strategies and insights about product design, engineering, and development.

Delve Insights: Product Innovation & Development Blog

innovation, product, design, advice, development

https://cms.delve.com/assets/images/_1200x630_crop_center-center_82_none/Delve_titlecard.png?mtime=1654035558

https://cms.delve.com/assets/images/_800x418_crop_center-center_82_none/Delve_titlecard.png?mtime=1654035558

On-Ramp to IoT: Getting Connected and Communicating

On-Ramp to IoT: Getting Connected and Communicating

Related Insights