Building a Multi-connectivity Cold Chain Monitor with Arduino UNO SPE Shield and SG Wireless F1 EVK

Authored by SG Wireless, as published on RS DesignSpark.

Pharmaceutical cold chains are unforgiving. Vaccines, biologics, and temperature-sensitive medicines must remain within tightly controlled environmental limits during storage and transit. A few degrees outside specification, when sustained long enough, can render an entire batch unusable.

For developers, the challenge isn’t in building a monitoring system — it’s in designing one that’s low-power, industrially robust, network-flexible, and scalable across warehouses, trucks, and distribution hubs.

In this demo, we built a scalable cold chain monitoring architecture using:

• Arduino UNO SPE Shield for industrial sensor acquisition
• SG Wireless F1 EVK as a multi-connectivity bridge
  • Cat-M1
  • NB-IoT
• LoRaWAN via The Things Network
• Arduino Cloud for visualisation and automation

We break down how this works and why this architecture translates well from prototype to real deployment.

1. Edge Acquisition: Industrial-Ready Sensor Networking

At the edge layer, the system separates sensing from connectivity.

The Arduino UNO handles deterministic polling of environmental sensors (temperature, humidity, pressure). Instead of directly attaching a radio module, we introduced the UNO SPE Shield, which adds industrial-grade physical interfaces:

• 10BASE-T1S Single Pair Ethernet
  • 10 Mbps
  • Up to 8 nodes
  • 25 m reach
  • Power over Data Line (PoDL)
• RS-485
  • Up to 1200 m range
  • Multi-drop support (up to 80 nodes)
  • Built-in termination and biasing

This supports cold storage environments where:

• Sensors may be distributed across racks or large cold rooms
• Cable runs are long
• Electrical noise is non-trivial
• Reliability matters more than minimal BOM cost

By using SPE or RS-485, we decouple sensor placement from radio placement so that the sensor bus scales independently inside the storage environment, while connectivity is handled separately.

From a design perspective, this modularity reduces redesign effort when scaling from one cold room to an entire facility.

2. The Connectivity Bridge: Why the SG Wireless F1 EVK Is Central to the Design

Once sensor data is collected, it moves beyond the local bus through the SG Wireless F1 EVK, which plays a more strategic role than simply providing a channel for LoRaWAN connectivity.

Cold chain deployments are not network-uniform. Some examples are warehouses with private LoRaWAN coverage, trucks in transit requiring cellular connectivity, and temporary storage sites with limited infrastructure.

Designing separate hardware for each scenario creates fragmentation, as firmware diverges, inventory grows, and maintenance becomes complex.

The F1 EVK addresses this by integrating multiple connectivity options into a single platform:

• LoRaWAN (primary in this demo)
• LTE Cat-M1 / NB-IoT
• Wi-Fi
• BLE (for provisioning or local configuration)

The hardware is designed around a connectivity abstraction layer, instead of a single transport method. Architecturally, this means:

• The same hardware platform can operate in a warehouse and in transit
• Network strategy becomes a configuration decision, not a hardware redesign
• Redundancy can be built in from the start

In this demo, LoRaWAN serves as the primary uplink because of its long range and low power profile, ideal for distributed warehouse nodes. But because the hardware is not locked into that choice, this flexibility makes the F1 EVK a true connectivity bridge rather than a single-purpose radio.

The rest of the system can evolve without touching this layer.

3. From Uplink to Action: LoRaWAN, TTN, and Cloud Logic

Telemetry from the F1 EVK is transmitted via LoRaWAN to The Things Network (TTN), then forwarded to Arduino Cloud.

LoRaWAN is particularly well suited for cold chain monitoring because it provides:

• Long-range indoor coverage
• Low power consumption
• Secure device-level provisioning
• Reliable uplink for small, periodic payloads

Once data reaches Arduino Cloud, the system transitions from monitoring to decision-making. In addition to displaying temperature values, the cloud layer enables:

• Real-time dashboards (gauges and time-series charts)
• Historical logging for compliance records
• Threshold-based alerts (email/webhooks)
• Remote device management and OTA updates

For example:

If temperature deviation > +2 °C for 5 minutes → Trigger alert
If deviation persists → Log compliance event

This is the difference between passive telemetry and active risk mitigation. Operationally, alerts allow corrective action before batch loss occur, and in a regulated environment, historical logs provide an audit-ready trail.