A Lucid device does not need to be “large”! But what do we mean by “large” or “small”? This article reviews how small a Lucid device could be, what the constraining factors are, and a worked example.

How do we measure size?

Size of a computing product can be measured in different ways and therefore the generic term is ambiguous. However, the various metrics normally scale in similar ways – a physically large server will usually be fast and have lots of memory and disk space so we can easily say it’s “big” compared to an embedded device.

At the other end of the scale, a physically small device may be constrained by its memory size and non-volatile storage and so is undoubtedly “small”. It’s the smaller devices which are of interest for this article because in Operational Technology (OT) applications smaller is better. Devices can fit into constrained enclosures; also, they can be manufactured more cheaply which is important if you’re building (or buying) thousands of them for a project.

Here are some metrics we might use to measure “size” for a Lucid-capable device:

• Physical size. An obvious one really and the first that may come to mind. The limiting factor usually these days is not the electronics but the requirements to have batteries, connectors, enclosures etc. and their commensurate size
• Disk space. Specifically, the size required to store the application. The selection of the operating system will have a large bearing on this too as it will have a significant footprint.
• The memory required to run the Lucid-capable application
• Processor capability. Probably not a big issue these days as a “standard” telemetry application shouldn’t be particularly computationally intensive.
• Security support. Does the device include hardware acceleration or secure storage to assist with the handling of protocols such as TLS?
• Power consumption. Of interest, especially for battery-powered devices which are common in the telemetry space. Obviously, the lower the power, the longer the battery life. Can the application run in low power modes, if they are offered by the chipset?

There is also “code size” – the amount of disk space required for the code, prior to compilation. Normally compiling and building the application isn’t done on the target platform itself so doesn’t contribute towards the overall size budget. However, it’s useful to understand the approximate size to give an idea of complexity of the codebase.

What are the components that influence the size of a Lucid Device?

There are some things that a Lucid device needs to run which prevent devices being too small!

Internet Protocol

Internet Protocol (IP) network access: Lucid uses MQTT, MQTT uses IP, so there must be an IP stack on the device. This means a device of must have a certain minimum capability and might rule out very small devices that don’t support IP.

Communications

There must be some form of communications out of the device to permit IP access to brokers and hence Supervisory Applications (SAs).

We have written another article on the types of communications that can be used for Lucid.

However, communications chips or solutions integrated with the processor will add physical size and power consumption to a solution.

MQTT

An implementation of MQTT is required and this will occupy code space on the device. Small implementations are available, but some resources will be required.

JSON

Lucid uses JavaScript Object Notation (JSON) to code data within the MQTT payload. Therefore, a JSON code library will be required. It’s possible to develop such a library from scratch but there are plenty of open source ones. It will occupy some of the code memory, although less than other aspects.

Security

Lucid optionally uses security to ensure that devices can be appropriately protected. Security is implemented in Lucid using TLS, which requires a reasonably large extension to the IP stack. The device may also need cryptographic storage for its keys and cryptographic acceleration. These may come at the cost of both physical size and code size due to the necessary APIs.

A worked example

To allow some idea of what a Lucid implementation might look like on a smaller device, we provide a high level worked example of combining the elements above to produce a working Azent implementation.

The example uses the Azent Lucid stack for Field Devices produced by Terzo Digital. Azent is provided with some sample code for deployment on specific platforms. In this example the sample code for a Raspberry Pi is used. Raspberry Pi’s use a Linux variant as their operating system which is multi-purpose and is more than what is required for a Lucid application. It comes with TCP/IP capability, so we don’t need to add that separately.

Figure 1 – A photo of the Raspberry Pi and Enviro+ boards which use Azent to act as a Lucid Field Device

The actual Raspberry Pi used in the working example is a Raspberry Pi Zero 2 W with a Pimoroni Enviro+ attached to give it a range of changing sensor values, and runs:

• Raspbian GNU/Linux operating system version 11.9 (Bullseye) based on Debian
• Quad-core 64 bit ARM Cortex-A53 processor
• 512MB of SDRAM memory
• An 8GB MicroSD card

We’ll use the option MQTT and JSON stacks that are provided with the Azent example. For reference these elements use space as approximated by the table below:

For this worked example, these elements are all compiled together to produce a single executable. The executable size on disk is 225 KB which is a great deal less than the size of the disk at around 0.003% of the disk space.

The “top” command on the Raspberry Pi shows information relating to running processes. The virtual memory “top” reports the application using is around 2084 KB which is only 0.4% of the available memory. The “azent” process shows that it is normally using 0% of processor load with an occasional increase to 1%.

Even this incredibly simplistic look at device utilisation, which makes no attempt at optimisation, shows that the size of disk, processor load and memory used, hardly trouble the Raspberry Pi device. This low utilisation is expected to remain the same as development is moved onto lower power devices.

A second worked example

A second example of a small Lucid implementation, courtesy of Gavin Rawson of Ovarro, is based on an ESP32 microcontroller, which is programmed using the Arduino development environment.

Figure 2 Photos of the Gavin Rawson/Ovarro test device which implements Lucid on Arduino to allow device testing.

The example is based on a bespoke ‘Proof of Concept’ Lucid implementation, using generic Arduino libraries for TCP/IP, MQTT and JSON, and device specific libraries for a number of I2C sensors used for testing, including temperature, light level, proximity, gesture and general analog / digital I/O.

The ESP32 device used in the working example is a Lilygo T-DisplayS3 Amoled :

• Arduino 2.3.2 IDE
• ESP32-S3R8 Dual-core LX7 microprocessor
• 16MB of Flash RAM
• 8Mb PSRAM
• Integrated WiFi
• Integrated Amoled 240×536 display

Lucid application metrics :

• Developed using the Arduino IDE
• Sketch uses 919,049 bytes (29%) of program storage space (Maximum is 3,145,728 bytes)
• Global variables use 47,628 bytes (14%) of dynamic memory, leaving 280,052 bytes for local variables (Maximum is 327,680 bytes)

The Lucid application runs a 0.5 second I2C IO and display loop, and 5 second update for Lucid data publishing.

How small could other devices be?

The above examples shows that Lucid can be implemented on relatively modest platforms without extensive work to optimise and reduce the size of the resulting product. In both cases device utilisation is relatively low leaving headroom for further development.

It would be possible to reduce the footprint of the first device with further engineering. Some areas which could be considered include:

• A different operating system. Linux is a full-blown multi-purpose desktop operating system and provides far more features than are required for a single-application embedded device. A more tailored operating system would have a much smaller footprint.
• Reducing the point database size. The Azent stack has a large database to cater for many points. Most devices won’t need to reserve such a large space and so the memory footprint could be reduced in this area.

Summary

In this article we have looked at how small a Lucid device could be and the factors that might stop the device being really tiny. It turns out that chips which are capable of implementing everything that Lucid can throw at them are very small and it’s the other aspects of the device (battery, enclosure etc) which are the limiting factors.

Mark Davison (Terzo Digital), Neil Tubman (Terzo Digital), Gavin Rawson (Ovarro) and Dave Howarth (NWL)

June 2025

Terzo Digital and NWL have collaborated on a number of articles about Lucid in support of the protocol. You find find a list of those articles with a brief summary of their contents here.