IoT product development, from concept to a certified product in series production.

An IoT product is engineered for the constraints of the finished device: deployment environment, autonomy, connectivity, footprint and certification. A development board (Arduino, Raspberry Pi, a vendor evaluation kit) is excellent for proving a concept and unfit for industrial deployment. It is not built for -40 °C to +85 °C, humidity, vibration and electromagnetic interference, it carries bill-of-materials waste that every unit shipped will pay for, and it brings no certification story.

At AESTECHNO, with over 10 years of experience in electronic design, we take the whole path: electronics, firmware, enclosure integration, the mobile app when the product needs one, industrialization and the certification campaign. The four constraints that decide a connected product, autonomy, radio, compliance and security, are locked at the schematic phase or paid for later in respins. Our complete method is published: IoT electronics design, from concept to certified product.

The wireless protocol decides range, throughput, energy budget, infrastructure cost and, in the end, whether the product is economically viable. We arbitrate it from the use case (indoor or outdoor, mains or battery, mobility, network coverage) rather than from the chip the team already knows. LoRaWAN reaches 2 to 15 km at 0.3 to 50 kbps on a private gateway or an operator network, Bluetooth LE covers 10 to 50 m at up to 2 Mbps against a phone or a gateway, NB-IoT and LTE-M give national coverage against a subscription, Wi-Fi gives throughput and costs power.

Our portfolio covers the whole radio layer across customer projects: Bluetooth Classic, BLE and 5.4 PAwR, Wi-Fi, LoRa and LoRaWAN, RFID, 5G and LTE-M. That breadth is what lets us arbitrate without commercial bias. On the Bluetooth side we developed a custom PAwR protocol on a Nordic module synchronising 100 devices below 5 µs. Many products end up combining two radios, BLE for local configuration and an LPWAN link for telemetry. See LoRaWAN, NB-IoT and Sigfox compared and Bluetooth 5.4 PAwR.

Autonomy decides whether an unattended sensor is viable, and the usual way to get it wrong is to compute it from datasheet averages. For us the datasheet figure is a target, never the field truth. We profile the complete duty cycle, sleep, wake, acquisition, processing and RF transmit, on a Nordic PPK2, and we resolve deep-sleep and quiescent currents down to the picoamp on a Keithley DMM7510 where the profiler reaches its precision limit.

What the profile surfaces is rarely what the team expected. On a recent project we measured 4.2 µA of sleep current against 0.9 µA quoted in the datasheet, an excess traced to a pull-up resistor left active by firmware, and a single misconfigured GPIO can multiply sleep current by ten. Peak currents matter as much: an RF burst can demand several hundred milliamps for a few milliseconds, and the cell has to deliver it. We have designed many products integrating batteries and Battery Management Systems, from primary lithium to rechargeable cells with protection, balancing and fuel gauge. See embedded power management and battery life.

Antenna integration is one of the most frequent and most expensive mistakes in IoT design, because a design that measures well on the bench can fail once it sits in the production housing. The ground plane is part of the antenna system and its size and shape drive match and radiation efficiency, keep-out zones have to hold with no track, no copper pour and no component inside them, and some plastic formulations detune an antenna too, while a metal enclosure calls for an external antenna or a properly designed RF window.

We characterise the antenna on every IoT prototype before production: reflection coefficient (S11) measured on a Keysight vector network analyser, bandwidth checked, radiation validated in real conditions with the production enclosure rather than a prototype one. On a recent project we measured a 4 dB loss in radiated efficiency between the bare board and the same board inside its enclosure, traced to a metallised paint layer the mechanical team added late. We have led RF projects up to 10 GHz. See RF design and antennas.

IP65 and IP67 housings are required outdoors and in industrial settings, and they remove airflow completely. Heat then has to leave through the board and the enclosure walls, which is a schematic and routing decision rather than something to discover when the first prototype drifts or a component fails early.

The strategies we deploy: thermal analysis run during design instead of after a failed prototype, component derating against the manufacturer curves for the junction temperature the sealed enclosure will actually impose, use of the PCB itself as a heat sink through copper pours, thermal vias and exposed pads, and firmware-side thermal throttling or adaptive duty cycle when continuous operation would overheat the product. Temperature behaviour is then validated in our -40 / +85 °C climatic chamber. See our mechanical integration expertise.

The step from a working prototype to series production is where connected-product projects meet their unplanned costs. IoT boards usually combine dense digital, sensitive analog sensing and an RF section on one PCB, which makes design for manufacturing sharper than usual: board outline and mounting holes drawn for efficient panelisation, placement that respects the assembler rules on spacing, orientation and fiducials, an assembly sequence planned when surface-mount and through-hole are mixed, and test points on rails, buses and the RF path that automated test equipment can actually reach.

The production test bench is the piece most often pushed to the end of the project, and it is the piece that sets ramp-up speed. It has to verify rails, sensor reads, RF power and sensitivity and peripheral communication, return an automatic pass or fail with no operator judgement, and run in seconds rather than minutes, which means pogo-pin contact points planned in the routing from the start. Firmware provisioning follows the same logic: per-device identity, cryptographic keys and calibration data have to be generated, stored and injected on the line, with a version check built into the bench. See DFM for electronics and our industrialization expertise.

Regulatory certification is mandatory for any IoT product placed on a market, and most of its outcome is decided long before the laboratory visit. We fold RED 2014/53/EU requirements into the first schematic review, because the directive covers radio performance, EMC and safety at the same time and all three have to be planned from project start. Radiated and conducted emissions are pre-checked before the accredited lab, with the working target being real margin on the EN 55032 Class B limits rather than a bare pass.

A Bluetooth or Wi-Fi module that is already CE and FCC certified makes host product approval significantly simpler, but it does not certify the end product: the module approval covers the module, and the complete device still goes through EMC testing. Technical documentation (schematics, test reports, RF exposure assessments) is built up across the design rather than assembled in a rush at the end. Every project we have taken to certification passed first time: a 100% success rate on CE/FCC certifications. See CE and RED certification for IoT products.

A connected product is attacked on three fronts: the hardware (firmware extraction, a debug bus left open), the network (interception, command injection) and the update path (forged firmware). Security is a property of the architecture, not a feature to ship later. We anchor secure boot in hardware, sign OTA images (MCUboot on MCU, RAUC on embedded Linux), run TLS 1.3 on network traffic, store secrets in a secure element and disable JTAG and SWD in production, aligned with ETSI EN 303 645 for consumer products and IEC 62443-4-2 for industrial ones.

Longevity is the same discipline applied to the bill of materials. A product that stays in the field for years outlasts several component life cycles, so lifecycle status is checked before a part is designed in, parts already flagged NRND or end-of-life are avoided, critical parts get a qualified second source, and a hardware abstraction layer in firmware keeps a sensor or MCU swap to a small change. We have carried clients through real shortages, finding viable alternatives and, when none existed, redesigning the product. See industrial IoT cybersecurity.