Talk to an engineer
For IoT device vendors

Your IoT product starts on a dev kit. Make sure it ends as a managed fleet.

Most device programmes prototype brilliantly and stall at scale: no management client, no conformance evidence, no fleet operations story. Here is the path that avoids that, starting with hardware you can order today.

At a glance Prototype on a DigiKey-stocked dev kit, embed Friendly's production LwM2M client while the schematic is still soft, verify against the specifications, and operate the fleet on One-IoT. One path, no gaps.
Step one: hardware

Start with a kit you can order today

All stocked at DigiKey with same-day shipping. Pick by target silicon and connectivity; every one of these runs a Friendly Ultra Series client.

Nordic Semiconductor

nRF9151 DK

The development kit for the nRF9151 SiP: LTE-M, NB-IoT, GNSS and DECT NR+ in one module. The default choice for cellular IoT products with battery budgets.

LTE-MNB-IoTGNSSDECT NR+
Order at DigiKey
Nordic Semiconductor

Thingy:91 X

Battery-powered prototyping platform on the nRF9151 with environmental sensors, accelerometer and Wi-Fi locationing: a field trial in a matchbox.

LTE-MNB-IoTSensorsWi-Fi locate
Order at DigiKey
STMicroelectronics

B-L475E-IOT01A Discovery

The STM32L4 IoT node: eight sensors, Wi-Fi, BLE and sub-GHz on one board, Arm Mbed enabled. Ideal for sensor-rich product exploration before custom hardware.

STM32L4Wi-FiBLEMbed
Order at DigiKey
STMicroelectronics

NUCLEO-WL55JC1

STM32WL Nucleo with LoRa and sub-GHz radio on the MCU die itself. The starting point for LPWAN metering and long-life sensing designs.

STM32WLLoRaSub-GHz
Order at DigiKey
Silicon Labs

EFR32xG24 Dev Kit

The xG24-DK2601B: 802.15.4, BLE and Matter-capable multiprotocol radio with on-board sensors and AI/ML acceleration for edge inference.

802.15.4BLEMatterML core
Order at DigiKey
Silicon Labs

EFR32xG28 Pro Kit

Sub-GHz plus 2.4 GHz for long-range mesh and Wi-SUN class designs: smart metering and street-scale infrastructure territory.

Sub-GHzWi-SUNBLE
Order at DigiKey
Linux-class compute, for the UltraPRO tier

Building a gateway instead of a sensor? Start with an i.MX EVK

NXP's DigiKey catalogue is stronger in processor evaluation kits than in a single all-in-one cellular devkit: these are compute and software platforms, not certified radios. Pair one with an M.2 B-key or USB cellular module for the modem path.

NXP Semiconductors

i.MX 8M Plus EVK

8MPLUSLPD4-EVK. The strongest NXP core for industrial IoT, vision and machine-learning headroom: the best fit where Linux application space, containers, local analytics or higher-throughput cellular backhaul are expected.

NPUVisionYoctoCortex-A53
Order at DigiKey
NXP Semiconductors

i.MX 93 EVK

MCIMX93-EVK. A secure, power-efficient edge and gateway evaluation platform; the better architectural target for a lower-power, security-forward product line than the 8M Plus.

EdgeLockCortex-A55Yocto
Order at DigiKey
NXP Semiconductors

FRDM-IMX93

The low-cost route to i.MX 93 software and BSP bring-up before committing to the full EVK. Useful for early application work; not the primary fixture for modem integration and carrier-style testing.

i.MX 93Low costBSP bring-up
Order at DigiKey
Before you order: check the modem path None of these EVKs are confirmed to ship with an integrated certified cellular module. Verify against the board manual before committing to a design: USB topology and any PCIe routing to the M.2 socket, 3.3 V power budget for the modem, SIM or eSIM access, modem reset and power control, and antenna/mechanical clearance.

DigiKey, Nordic Semiconductor, STMicroelectronics, Silicon Labs and NXP Semiconductors are trademarks of their respective owners. Links open the DigiKey catalogue; availability, lead time and pricing are DigiKey's.

From kit to product

What ships on this stack

The nine kits above are the starting point for these product categories today. Each maps to a kit, a connectivity choice and the Ultra Series tier that fits the footprint.

Smart water metering network with level and leak monitoring
NUCLEO-WL55JC1 / nRF9151 DK

Water and energy metering

UltraMIN in the pull-FOTA tier for meter NICs on a long battery budget, over LoRaWAN behind a concentrator or direct NB-IoT.

Precision agriculture irrigation sensors on a farm network
NUCLEO-WL55JC1

Precision agriculture

Soil, irrigation and crop sensors on STM32WL's sub-GHz radio: long range, queue mode for deployments between service visits.

Cold chain temperature compliance monitoring for pharma and vaccine logistics
Thingy:91 X

Cold chain compliance

UltraMIN loggers over LTE-M/NB-IoT track temperature excursions with the same registration and Send-operation objects the fleet already manages.

Micromobility e-bike fleet with connected asset tracking
Thingy:91 X / nRF9151 DK

Micromobility and asset tracking

Battery-powered trackers using Wi-Fi locationing and GNSS from the same SiP, queue mode buffering position reports through radio dead zones.

Connected health remote patient monitoring wearable device
nRF9151 DK

Connected health and wearables

DECT NR+ or cellular connectivity in one module for wearables and home monitors, where certification evidence matters as much as the firmware.

Smart grid edge substation sensors and renewables telemetry
EFR32xG28 Pro Kit

Smart grid edge

Sub-GHz and Wi-SUN-class mesh for substation and street-scale sensors, bridged into the fleet through the LwM2M gateway object once the design matures past the kit.

Smart building access control and unattended retail devices
EFR32xG24 Dev Kit

Smart building and unattended retail

Matter-capable access, occupancy and vending endpoints, with the on-board ML core ready for the edge inferencing covered further down this page.

Industrial predictive maintenance sensors on factory equipment
B-L475E-IOT01A

Industrial predictive maintenance

Eight on-board sensors and Wi-Fi/BLE for vibration and condition monitoring, proven on the Discovery kit before the custom board exists.

Cellular industrial gateway bridging SCADA and legacy plant into a management platform
NXP i.MX 93 / i.MX 8M Plus EVK

Cellular gateway and industrial backhaul

UltraPRO on Yocto Linux, with cellular added over the EVK's M.2 socket: the UltraPRO-class hardware behind the eSIM steering and edge AI sections further down this page.

Authorised distribution

Friendly IoT products, stocked where you already buy

Friendly's embedded clients, verification instruments and platform subscriptions are available through our authorised distribution partner, alongside the silicon they run on.

DigiKey

Authorised distribution partner. Global electronic component distribution: the dev kits on this page, the modules they graduate to, and Friendly's device-side products, all in one basket with same-day shipping.

Visit DigiKey
Meshed Technology, Inc.

Managing agent: Meshed Technology, Inc. IP-connected device specialists managing the Friendly product line within the DigiKey programme: solution design, integration support and channel enablement.

Visit Meshed Technology →
Step two: the path

The IoT Journey, applied to your product

  1. Prototype on the kit

    Prove the sensing, the power budget and the radio on DigiKey hardware before any custom board exists.

  2. Embed the client early

    Drop UltraMIN (C, constrained MCU) or UltraPRO (C++, gateway-class) onto the kit. Bootstrap, DTLS security and FOTA behaviour become properties of the design, not retrofits.

  3. Plan connectivity for the product's life

    eSIM SGP.32 so operators can change under the fleet; PSM/eDRX tuning so batteries last the contract; NTN fallback where assets roam.

  4. Verify and harden before certification

    Protocol conformance and security scrutiny on the bench, so the operator lab confirms what you already know.

  5. Operate on One-IoT

    The same platform runs your pilot and your millionth unit: onboarding, FOTA campaigns, diagnostics, analytics and multi-tenant customer views.

Talk to a Friendly engineer

Tell us the product you are building; we will map the Journey onto it: client sizing, connectivity plan and a management architecture.

Submissions route to Friendly's CRM. No newsletter, no drip by default.

Stage 04, in depth

The stage where IoT programmes usually die

Between "it works on my bench" and "the operator certified it" sits the gap that costs device programmes their year. Three failure patterns account for most of it.

Certification roulette

No vendor-neutral pre-certification tool exists for LwM2M's CoAP/DTLS stack, so vendors discover conformance failures at the MNO lab, after weeks of scheduling lead time, then rejoin the queue.

Regulation moving underneath

EU CRA, UK PSTI and ETSI EN 303 645 add a second compliance target that shifts while the product is still in development. Evidence has to be produced, not asserted.

Field failures with no witness

When a fleet misbehaves, the packet capture that would explain it was never taken, and the engineer who could read it is three time zones away.

The bench

IoT Protocol Tester

Run the operator lab's tests before the operator lab does. OMA Enabler Test Specification conformance across LwM2M v1.0 to v1.2 (v2.0 on track), over CoAP/UDP with DTLS 1.2, PSK, RPK and X.509, including RFC 9146 Connection ID.

  • Conformance suites for bootstrap, registration, device management, information reporting, composite operations and security
  • Compliance packs mapped to EU CRA, UK PSTI, ETSI EN 303 645, NIST IR 8259A/8425 and OWASP IoT Top 10, with per-control verdicts
  • Signed, deterministic reports: a CI artefact is byte-identical to a hand-run one, ready for certification submission
  • MNO certification content packs (AT&T, Verizon, Deutsche Telekom, GSMA TS.34/35) on the roadmap
The microscope

DevGuard

An embedded-protocol capability sniffer that watches the device stack live and turns raw behaviour into findings an engineer can act on, in one pipeline:

Sniff→ Detect→ Classify→ Root-cause→ AutoFix
  • Wire-level observation of CoAP, DTLS and LwM2M semantics with sub-second ingestion, dedup and correlation into incidents
  • Staged AI analysis: triage separates real from noise, root-cause analysis follows, fix generation proposes the change
  • Deviation and security-conformance detectors fingerprint what the device actually implements versus what it claims
  • Source-cited root cause and auto-fix pull requests: early access, arriving in stages

Together they close Stage 04 of the Journey: the bench proves the device against the specification, the microscope explains the device to its own engineers. What you certify is what you manufacture.

Battery-budget engineering

Every radio-on millisecond has a battery cost

PSM, eDRX and full module power-off are firmware decisions, not modem defaults. The client has to sleep the same way the hardware does, and wake up without re-paying for a handshake it already had.

Power stateWhat stays activeWakes onFits
Connected DRXRadio listening every DRX cycleContinuous scheduled trafficActive FOTA campaigns, bursty telemetry windows
eDRX (extended DRX)Radio wakes on an extended NB-IoT/LTE-M paging cycleScheduled paging windowDevices that need a downlink within seconds to minutes, not immediately
PSM (Power Saving Mode)Modem and radio fully off between the active timer and the periodic TAUDevice-initiated, on its own scheduleLong-life battery sensors with no inbound urgency
Hard module power-offModem de-energised by firmware, context lostFirmware-scheduled boot and re-attachExtreme duty cycles, e.g. a once-daily meter read, where even PSM leakage is unaffordable

Queue mode

Both tiers

Send and Notify operations buffer while the device sleeps and flush on the next wake, so the server never times out a device that is doing exactly what its power budget asked it to do.

DTLS Connection ID

RFC 9146

The session resumes on a fixed CID instead of the network 5-tuple, so a PSM wake or a NAT rebind costs one UDP round trip, not a fresh DTLS handshake with its asymmetric crypto and radio-on time.

Delta FOTA

UltraPRO

BSDIFF/VCDIFF ships the difference between firmware versions, not the whole image; fewer bytes over the air is the same variable as fewer milliseconds of radio-on time.

Block-wise, resumable transfer

Both tiers

A duty-cycle device pauses a large CoAP transfer, sleeps on schedule and resumes on the next wake, rather than staying awake to finish a monolithic file.

The point that matters: the expensive event is never the sleep, it is the wake. Everything above exists to make a wake cost one small, predictable exchange instead of a renegotiation.

Failsafe connectivity

Plan the operator relationship as a fleet decision, not a soldering decision

A dev kit ships with one SIM and one operator. A product with a multi-year field life needs a way to change that without a truck roll. SGP.32 makes the profile a managed object; multi-profile steering is how the fleet survives an operator outage or a coverage gap.

eIM fleet steering policy Product IPAd eUICC UltraPRO client Objects 504 / 3443 Operator A profile enabled Operator B profile standby ESipa over LwM2M or direct RSP Steering is a campaign: enable, disable and swap profiles in waves, with the same canary discipline as firmware.
  • SGP.32 v1.2 implemented in UltraPRO today: LwM2M Objects 504 and 3443, the ESipa/ASN.1 codec, embedded IPAd, over LwM2M or direct RSP transport
  • Vendor adapter seams for Thales, G+D, Kigen and Jasper eUICC back-ends, so the profile source is not locked in at board layout
  • Dual-profile survivability: a standby cellular profile carries the events that cannot wait for a primary operator outage to clear
  • Steering runs as a fleet campaign, waves, canaries and rollback, from the same console as FOTA, not a one-off AT command
  • Constrained UltraMIN sensors, most of the kits above, hold a single provisioned profile; on-board profile steering is a UltraPRO, gateway-class capability today, the same one shipping on Friendly's edge gateway products and the natural fit for the i.MX 93 and i.MX 8M Plus EVKs once a cellular modem is on the M.2 socket

For the architect: decide at design time whether the product needs on-board profile steering, which means specifying a UltraPRO-class MCU and an IPAd-capable eUICC, or whether a single locked profile is enough. That decision is far cheaper before the board is laid out than after.

Edge intelligence

Inference on the kit, managed like firmware

The EFR32xG24's on-board ML core is not a demo feature. UltraPRO Edge AI treats a deployed model the same way it treats a firmware image: versioned, monitored and rolled back through the fleet, not pushed by hand.

Capture→ Preprocess→ Infer→ Publish result→ Report to fleet

Inference on the device

UltraPRO Edge AI

A backend abstraction over TensorFlow Lite Micro and ONNX Runtime, on CPU everywhere and on the silicon's own ML core or NPU where the SDK exposes one, including the EFR32xG24's.

Models as managed objects

Object 33410

A dedicated Edge-AI object with 36+ resources exposes model identity, version, health and inference statistics to whatever server terminates the client.

Deployment with discipline

SOTA campaigns

Models ship through the same Object 9 software campaigns as any package: canary devices first, waves after, abort conditions armed before the fleet sees a bad model.

Sized for the tier it ships on

Design preview

UltraMIN-class sensors report inference results as normal telemetry objects; the model lifecycle layer above is a UltraPRO, gateway-class capability today, the class of hardware the i.MX 8M Plus EVK's own NPU is built for.

Step three: the suite

What Friendly puts around your product

Ultra Series LwM2M clients

On the device

UltraMIN for MCUs measured in kilobytes; UltraPRO for gateways in modern C++. Bootstrap, PSK/certificate security, delta FOTA, queue mode.

Verification and hardening

Early access

Conformance against the specifications operators certify to, plus security scrutiny of the stack, before the field runs the test for you.

One-IoT™ DMP

The fleet

Onboarding, FOTA campaigns, diagnostics, rules and analytics from pilot to tens of millions, on-prem or cloud.

Application enablement

On top

REST, Kafka and AI-tooling interfaces so your customers' dashboards and systems build on the fleet.

One kit, three job descriptions

What each seat on the programme actually gets

The architect, the electronics designer and the firmware engineer are solving different problems on the same board. Here is what Friendly puts in front of each of them.

Owns the fleet architecture

IoT Architect

Decides the client tier, the connectivity plan and the management plane once, then holds every product team to it.

  • One protocol engine across UltraMIN and UltraPRO: the same wire behaviour from a coin-cell sensor to a rack-mount router simplifies the fleet-wide server contract
  • A connectivity plan that survives the product's life: SGP.32 multi-profile steering, NB-IoT/LTE-M/DECT NR+ on the nRF9151, LoRaWAN behind a concentrator, NTN as an advisory-stage fallback for roaming assets
  • The management plane terminates the same client wire behaviour from pilot to production, Advanced LwM2M Server or One-IoT DMP, without a migration project later
  • Signed Protocol Tester conformance reports as the certification submission artefact, not a claim on a slide
Owns the board and the power budget

Electronics Designer

Needs the silicon choice and the management client to be the same decision, not two separate risks.

  • 14 maintained ports, including nRF91, STM32 and Quectel targets, mean the dev kit's MCU and modem are already a supported client target, not a new integration
  • An entry footprint from around 30 KB flash and 8 KB RAM leaves room for sensor and radio drivers on the same constrained MCU: no separate management co-processor
  • PSM, eDRX and hard power-off each map to a client sleep state the schematic's power-gating already has to support
  • Security scales with the bill of materials: PSK on TinyDTLS runs software-only; RPK or X.509 on mbedTLS or wolfSSL when the board carries a secure element
Owns the port and the field behaviour

Firmware Engineer

Inherits the client, not just the specification, and has to make it behave in the field, not just on the bench.

  • A documented PAL template and a 1 to 3 day porting discipline against a working reference port, not a blank integration against the specification
  • Objects load from JSON at boot: a new OMA, IPSO or vendor object is a configuration change, not a rebuild and re-flash
  • FOTA that survives what actually happens in the field: SHA-256 integrity and resume-after-power-loss on UltraMIN; delta FOTA with A/B rollback and boot-verify on UltraPRO
  • Queue mode, PSM/eDRX awareness and DTLS Connection ID are already in the client: the sleep/wake state machine does not have to be invented against the protocol from scratch
Reference story

MetroIoT: a managed radar level sensor in days, not years

MetroIoT builds radar level sensors for water utilities: tank levels, river gauges and stormwater assets on NB-IoT. Their hardware was proven; their management story was not. Utility tenders were asking for LwM2M, FOTA evidence and a fleet operations plan, and the internal estimate for building that capability was measured in engineer-years.

"We had budgeted a year to become an LwM2M device company. With Friendly's embedded tool suite we had UltraMIN running on our sensor in two days, bootstrapped and registered against the platform by day four, and our first over-the-air firmware update on day nine. Days, not years, and the conformance report came out of the same toolchain we develop with."

David Roe · Managing Director, MetroIoT

"The part I did not expect: DevGuard watching our stack during integration caught a DTLS session-resumption bug that would have drained batteries in the field. That one finding paid for the programme."
9 daysfrom dev kit to first OTA firmware update
2 daysto UltraMIN running on the sensor MCU
15 yrbattery design life protected by queue mode and PSM tuning
Smart water metering network with level and leak monitoring City-wide water network telemetry on the management platform

Order the kit today. Bring us the product idea.

Book the engineering session