Hello supporters and backers!

CaribouLite finished production. The testing is delayed due to Covid in China, as the testing process requires a human in the loop. We intended to supply the boards by Christmas, but unfortunately we missed this goal, and the supply will be delayed a little further to February (hoping for the health and well-being of our contract manufacturer’s workers).

Open Source Production and Testing

To fully comply with the "open source hardware" concept, we decided to open the production and testing process. Call it an "Open Source Production".

As we all understand now, the complexity of a hardware product is not necessarily about the idea or the prototype implementation. It is mostly about production and manufacturing. Within the production process, there is the important stage of "testing and programming" that verifies each board to be supplied to a customer. The main goal is to perform the fastest test procedure that minimizes the chance of supplying a faulty board to virtually zero. The secondary important goal is to learn the product and the production process’s mass volume issues to improve yield and quality in subsequent batches.

This process needs to be built carefully to support both of those important goals, without making the testing process too long and expensive. Additional goals of a well-designed production process are simplicity (building a simple-to-operate tester), visibility (letting engineers see the process to efficiently support the production process when an exception occurs), along with others.

In the following video links, you can see the latest batches of CaribouLite. Currently, all the boards are fully assembled (SMT and TH), and all additional material is ready for packaging. The testing procedures and equipment have been in our CM’s premises during the last month, but we are still missing the operating personnel due to the COVID outbreak in China. As it seems, this will be resolved in the following few days.

Assembled CaribouLites

Videos:

1. CaribouLites (full version) after the reflow process:

2. AOI processing (Automatic Optical Inspection):

3. Solder Paste:

4. Pick & Place:

The testing process includes the following stages:

1. Visual inspection
2. Mounting the boards on the tester
3. Power testing and analysis
4. Programming the Unique Identity and device tree
5. Digital functional testing - FPGA, I/O, LEDs, Modem, Mixer, Communication, SMI
6. Analog testing - radio loopback testing, RX (RSSI) and TX power testing, IQ imbalance calibration, and programming.
7. Un-mounting, capping, and packing.

The whole process should take around 2-3 min per board, and we hope this goal shall be reached to support the fastest finalization of the process (~2-3 8-hour work days)

To support the above goals, the testing and programming process is registered in a dedicated GitHub repository. This repository shall be open to the public shortly, and it already contains the following sub-directories:

1. boards - a sub-dir with the testing results of every CaribouLite produced, its UUID, and the tester that was involved, in a YAML format.
2. testers - with the identities and statuses of the testing equipment
3. scripts - contains the analysis and monitoring python scripts to support the learning and visualization of the testing
4. events - in this directory we may want to put an event log. Currently, it's just a provision for future expansion.

Once this repository is open to the public, everyone will be able to search their CaribouLite board (based on its unique identification - GUID) and find its testing log and history. In addition, we plan to analyze the results and learn from the process, on the build quality, numerical results (current, power, etc.), and testing timeline - all of which are registered and pushed to the git repo.

By doing this, we’ve created open-source production data. We hope it will be interesting to you to explore.

The Open Source Tester Components

In addition to the software (currently in the "develop-R1" branch - to be merged back to "main"), we built a dedicated power testing and monitoring hat. Then we realized that it also should be open-sourced as it can be a very useful tool for the Raspberry Pi community (and the RPI-like board users - Jetson-Nano, etc.). It is called the "RPI-HAT-Power-Monitor" or just "hat-powermon".

Power Monitor Assembly with a HAT

It sits between the HAT and the RPI 40-pin connector and is in charge of:

1. Supplying 5V voltage to the HAT.
2. Turn on / off the power as needed.
3. Provide all information about temperature, short circuit, fault, power, voltage, and current levels - to the RPI through the I2C interface.
4. To pass through all 40-pin header signals through it (except the 5 V rail).
5. To provide an efficient rule-based "fuse" whenever the HAT is faulty or malfunctioning due to improper use. For instance, if a short circuit is detected, power is shut off immediately and the fault condition is registered in its register map.
6. Protecting the tester base (Raspberry Pi-like boards) electrically and mechanically. If some of the pins of the hat-powermon are damaged - we replace this "powermon" board and the base tester remains intact.

It has C/C++/Python APIs through the I2C interface. See the repository at: https://github.com/cariboulabs/rpi_hat_power_monitor.git

Assemble it, use it, modify it as needed, and have fun with it.

Software Update

A New Kernel Module

As you may have noticed, the CaribouLite main software repository has been split into a separate branch called "develop-R1". This branch is the most up-to-date code base and is going to be merged later on in the main branch.

In this branch, we rethought many parts of the software and firmware. We introduced a new SMI kernel driver that was designed with versatility in mind. It supports the ability to stream asynchronously and can be easily adapted to other HATs. That’s why we built it on top of the existing Broadcomm’s official bc2835_smi kernel module. Our module - smi_stream_dev - replaces the legacy bcm2835_smi_dev driver and adds to it "poll", and "select" APIs, KFIFO support for low latency DMA configuration upon transmission events, and more.

The resulting device can be accessed through the "/dev" directory, and it is backward compatible with the older device driver.

To support the streaming API and improve streaming speed, the User-Mode SMI drivers were also redesigned and split into the generic stream driver and the CaribouLite-specific functionality.

CLI-like Board Testing Application

The CaribouLite software package basically contains the following:

1. Firmware - for the FPGA
2. Kernel Drivers
3. C/C++ API (static/dynamic)
4. SoapySDR API + Shared Object (SO)
5. Various Utilities

Within the "Various Utilities," we have compilation/deployment supporting software and scripts, testing and production application, and examples with C / Python.

Recently, we added a CLI-like user-prompting application - cariboulite_app that gives the user the ability to access the CaribouLite inner parameters and functions. Most of its functionality can be accessed, of course, through the C API, but we wanted to give a mixture of "examples" and "testing" capabilities in an SSH terminal.

With it, you can output signals of different power levels, read and write registers and check FPGA’s inner states. It also provides good coding references and snippets for those who would like to access CaribouLite through its C-API.

SoapyAPI and SoapySDRServer

Once we started testing various SoapySDR-Based custom software (C++) demodulators and signal processing, we thought - can we develop the algorithms on a PC and deploy them on an RPI? An RPI4 is a real workhorse, but it can never compete with a modern PC. In addition, we may want to have a remote development but use better-debugging capabilities than an RPI can provide.

To cope with this, we gave a try to the SoapySDRServer, and it worked like magic. Imagine… You put deploy an RPI + CaribouLite on your roof, close to the antenna. Connect a 1Gbit Ethernet cable to it (or just count on the WiFi). Prepare a cup of coffee with milk, and develop Python / C++ algorithms on your PC, having debugging, visualization, MATLAB, or Python NumPy crunching numbers on your PC rather than in the RPI. Then, after the algorithms are ready, you deploy them on the RPI and run them.

Once you run the SoapySDRServer on your RPI, upon a request from a distant computer, it streams all IQ and metadata through its network interfaces (UDP I suppose). Kudos to the Soapy team, https://github.com/pothosware/SoapyRemote.git

And one more thing… the GnuRadio Soapy plugin also works pretty well, out of the box, thus it is fully usable with CaribouLite. And the SoapyRemote can also be used for that.

Conclusion

We are super-excited and waiting for the CaribouLites to be supplied as soon as possible, and are very optimistic about the following month to finalize the process with our CM. They are doing their best, having completed the assembly process with minimal manpower, and we are grateful for that!

And we would like to wish you a great new year!!!