Who is this talk for?

• People building early stage IoT Hardware

Who is this talk for?

• Firmware Engineers

• Hardware Engineers

• Cloud / IoT Engineers

IoT Hardware Is Simple

• The functionality is often simple
• Take a reading, send it to the cloud
• Control a physical device from afar

Putting it all together is

not simple

Before Rev A

Lines of Communication

• Important that everyone is on the same page

• Rev A shouldn't be a throwaway

  • "We'll just try it and see what happens"

  • Rev A choices have long term implications

• All teams should be part of the design review and planning process

Goal Setting

• What are you trying to prove out with Rev A?

• What constraints can be relaxed in the first rev?

  • Space 

  • Cost

  • Part selection

• How many revisions are you planning to do?

Create a test plan for Rev A

The difference between screwing around and science is writing it down.

~Adam Savage

Before Rev A

HW Design Planning

What should you

look for in a HW design review?

Flexibility

• Multiple footprints

• Standardized interfaces (Click, PMOD)

• Configuration options / In-situ measurements

Visibility

• LEDs

• Test Points

• Screens (even temporary)

• Accessible/Extra UARTs

Accessibility

• Programming Headers

• Large pads to solder to

  • Especially on fine pitch or BGA parts

• All unused pins broken out to GPIO

Clarity of Documentation

• Notations on the schematic

  • Clear numbering system

  • Clear pin names

  • Images

• Markings on the PCB

Before Rev A

FW Design Planning

Part Choice

RTOS Choice

Ecosystem Choice

Abstraction Layers
and Peripherals

Pin Planning

• Once you know what's available to you, it's important to discuss where and how those signals will be used.

• Especially for critical buses that might have signal integrity requirements.

• Finding parts that have re-assignable pins is great, but make sure you find out which are the most flexible and which have requirements.

Before Rev A

Cloud Design Planning

First and foremost:

Can you send an OTA update?

Where is your data going?

How are you going to be able to access that data?

During Rev A

The goal of testing is to squeeze as much functionality out of the revision as possible

Testing tools

Power-on

Selftest

Testing tools

Configuration Tools

Changing device configuration with (Zephyr) menuconfig

Configuration Tools

Managing device configuration remotely using Golioth settings service

Troubleshooting methods

The key to troubleshooting IoT problems is checking up and down the OSI model

Troubleshooting tools

Troubleshooting tools

Thread-aware debugging

with Segger Ozone

Troubleshooting tools

Segger SystemView

Troubleshooting tools

Troubleshooting connectivity with the Hologram dashboard

Troubleshooting tools

Tracking device logs over cellular using

the Golioth Console

Troubleshooting tools

Mapping output data from your platform with a tool like Grafana

After Rev A

Check your testing plan

Did you cover everything?

You did have a testing plan, right?

The difference between screwing around and science is writing it down.

~Adam Savage

Capture your Rev B changes

Time to start the next rev!

Case Study

What does hardware look like if it's perpetually at Rev A?

Aludel + Ostentus

Specs at a glance

• Based around Feather form factor microcontroller dev board

• Two MikroBus Click Headers

• Interstitial PCB (Aludel Mini) contains power switching and interfacing between feather form factor and MikroBus Click Headers

• Two QWIIC/STEMMA (i2c + power) headers for additional extensibility

• Standard case form factor with standard inserts for flexibility

Why did we do it?

• In a low volume, high mix environment, it makes sense to index for maximum swappability.

• This includes being able to swap for

  • Micros

  • Sensors

  • Displays

• We also weren't working towards a commercial deployment.

This means it's more of a dev platform than a Rev A

Over-index for swappability?

Some missing constraints, but not a lot

Maximally abstracted interfaces

Things we could have done better

Accessibility

The programming header is not accessible when the case is assembled. Luckily we have OTA from day one...

Over-indexing for space savings

Tight Spaces

Normally Rev A prototypes aren't trying to fit into an artificially small space. In our case (ha), we were trying to minimize the size of the Rev A box, simply because the off-the-shelf boards took up additional room.

Things we could "get" in Rev B

• Massive amount of space savings from reduced board count / standardized headers.

• More pins available on the chosen microcontroller -- reduced to fit to a standard feather form factor.

• Single board layout.

• Cost optimized BOM.

• Water-tight enclosure.

• Optimized power setup.

We build Reference Designs

Thank you for attending/watching!