Dear Subscriber,
Today, I would like to give you a glimpse at the Pipo software design and structure.

Pipo aims to become a flexible and versatile acquisition platform which can be ported and reused, not only for creative applications, but also for a wide range of use cases requiring fast and low-latency sensor data acquisition on a computer or Raspberry Pi, with a user-friendly data format.

Approach

To achieve this, the firmware has been designed to be as generic and reusable as possible. Only a small section of code is specific to the sensor in use. This makes it easy to port a new sensor or input layout with Pipo. This modularity also means that any enhancement made on the generic part can be a benefit to all modules right away.

Currently, each input stream is handled as a seperate channel and the generic framework adapts to the number of channels, making it a very flexible setup.

Data Flow

If we zoom in on a channel data stream, you can see that it goes through multiple processing steps, which can be represented at a high level by the diagram below. First, the raw sensor data is acquired and converted into a chosen unit. Then the raw value is conditioned, cleaned, and preprocessed to get translated into a message in the desired output format, scale, and type.

A selection of input filters are available to easily adapt to various sensor behavior. These steps can be configured for each channel individually and are stored in a JSON configuration file on the filesystem. This allows you to store multiple configurations. The web interface exposes a sub-set of these settings which are relevant to the user to customize.

Tasks and Cores

Since Pipo aims to be as fast as possible while keeping latency low, it takes advantage of the dual core capability of the Esp32-s3 to distribute the tasks over the two cpu cores. This way, one core can be dedicated to real-time tasks, while the other one can deal with all the other tasks which are not time sensitive.

For Pipo, Core 1 is dedicated to the real-time work (which consists of doing all the data stream work we mentioned above). On the other hand, Core 0 mostly handles the web server which runs the user interface, as well as monitoring the battery and blinking LEDs. This way, the real-time activities are not slowed down by the other tasks the chip has to handle.

Using such task distribution with a generic backbone offers a good balance between project growth, re-usability, and performance.

Pipo is also currently experimenting with output features to grow as a full-fledge wireless I/O framework in the future, which could be ported to many dual core chips from the Arduino ecosystem.

As always, if you have any questions, feel free to ask them on Discord, the campaign question form, or reach me on Instagram. Meanwhile, don’t hesitate to talk about Pipo with people around you, it’s a great support to the campaign !