Happy 2022!

Hello backers, followers, and makers! In this update we would like to wish you a great new year. We wish 2022 to be a year of health and stability and we hope a lot more technologies, knowledge, and know-how shall be democratized for us to improve our lives, as a united global community of peoples. This update will cover the work we have conducted during the last couple of weeks on the software side - examples, manufacturing software, Linux modules, and more.

Software Development Update

The main issue we focused on during the last couple of weeks was: how are we going to make the SMI interface deterministic and real time? Working with 128Mbps of continues stream over a soft-real time operating system (such as Linux) is not an easy task. Once we face the goal of not dropping even a single I/Q sample due to OS scheduling lags, this task becomes even more difficult.

In general, Queue Theory provides us with the rules of thumb of M/M/1 Poison distribution arrivals and exponential distribution analysis times (birth-death Markovian process) systems. According to that thory, the sizes of the qeueus can be derived according to the acceptable probability of a dropped sample. To benchmark the end-to-end performance of the system against the theory, we measured the overall I/Q samples (32 bit each) rate of arrival and the numbers showed that a substantial number of samples had been dropped somewhere (!!). Instead of 4 MSPS flat, we got 3.90-3.95 MSPS on a RPI4B system.

Data is read by the user-space driver in batches (or chunks) from the SMI kernel driver and double buffered to be analyzed in parallel while the DMA fills the next buffer - a common practice in these matters. But there was a significant time gap between two concecutive DMA reads which caused the problem.

In addition, the SMI user-space driver implementation assumed asynchronious read/write capabilities from the hardware, using system-calls such as poll, select and aio_read. As always, assumption is the mother of all evil, and digging into the kernel device drives code left no choice but to tweak them and adapt them to:

1. have asynchronous functionality.
2. implement cyclic (recurring) DMA schema instead of a one-time DMA configuration that is time consuming and not adapted to fast streaming data. Currently each chunk finalization leads to DMA configuration, which requires the BCM-core's involvement. We don't want that - BCM should take care of the baseband processing and DMA should work on moving bits around.
3. Working with kfifo magical ring-buffer (queue) in the kernel level. This implementation of the simple FIFO element requires minimal management and is super-fast and lean.

Needless to say, the opportunity to tweak and modify the Linux device driver is always a pleasure. The modified async SMI driver is being developed under the new name smi_stream_dev and it already outperforms the regular kernel module on the Rx side, reaching the goal of zero dropped samples. Though we still have some work to be done on the Tx side.

For those trying to figure out how they can start developing kernel modules rather than relying on user-space applications, I recommand Linux Device Driver, 3rd Edition, O’Reilly which is available as an ebook. Keep in mind this book is not up to date with kernel >3.x but for most cases it provides a clear, hands-on understanding of the kernel module design.

Manufacturing Software Procedures

As part of the openness of CaribouLite, we decided to also provide the testing program used by our CMs for testing the newly produced CaribouLite board. This software is in charge of checking the board assembly, communication, and basic RF properties of each CaribouLite. It configures the EEPROM and generates a unique serial number for each board.

The software is not only intended for contract manufacturers. Anyone with a CaribouLite can re-flash and perform the testing procedures on their CaribouLite themselves. This software is now an integral part of the software elements in the libcariboulite library package.

Examples Folder

An examples directory has been added to the repository, currently containing two sub-directories:

1. python - Python scripts and examples
2. cpp - C/C++ programming examples using libcariboulite/soapy-caribou.

Within the CPP sub-dir, the first example application added is for ADS-B Mode-S signal analysis, based on the well known dump1090 software package.

Over time, these example directories will contain more code examples oriented to educational use cases. These code snippets will be the result of our own experimentation with CaribouLite so they’ll likely need a little tweaking to use them for other purposes.

Summary

Well, folks, we would like to again wish you a happy new year with lots of good news. We are getting into the final stages of our campaign. One week left and we are at the 90% mark. Make sure you secure your own CaribouLite before the prices increase on the post-campaign sales. Oh, and please keep posting interesting questions.

Thanks, David, CaribouLabs