All components have been secured, and CaribouLite production continues. Unfortunately, we have had to delay delivery of CaribouLites until October. Those are the words we have been unable to say until now. We waited to be 100% sure, but, as of today, this has became our optimistic reality. Thank you for your patience! See below for the gruesome details…

Long Story Short(ish)

It is a well known fact that many projects are delayed due to current global challenges: a lack of silicon and labor availability are affecting production timelines and product releases all over the world. We were initially so naive as to take for granted our ability to source all components needed for the project, and we never seriously considered the risk of labor shortages.

Our first marathon started in the middle of January when we finalized our design validation and started sourcing components. The PCB production was planned to start the middle of February, and assembly procedures in March. A reasonable plan. Or so we thought.

The first component that hit us in the face was Mouser P/N: LDL212PV33R. That’s the main (STMicro) 3.3 V @ 1.2 A-max LDO, which is a tiny, $0.30 component that supplies the 3.3 V consumers on board. This component became unavailable until…well, forever. Next came the modem (Mouser P/N: AT86RF215-ZU), then the FPGA (Mouser P/N: ICE40LP1K-W84), then another LDO (Mouser P/N: TLV7111225DSER). Same story: Q3 2023 if we’re lucky. Other components followed, including some passive components. You get the picture.

Every project has those moments of despair, where it seems like all the forces are directed against the project’s success. Looking back at similar situations, there are always solutions to be found, and such moments are not a time to give up. Those solutions often wait for the right time to pop up, and only do so after we’ve shed enough blood, sweat, and tears trying to solving them. Every engineer is familiar with moments like this. The best strategy is to improve your position with regard to production, taking one step at a time toward fulfillment, and using available time to redesign and test where necessary. In our case, we had to take the following steps:

1. Making a list of the most problematic components for which a redesign was not risky
2. Finding alternatives. (In most cases, no perfect alternative was unavailable, which meant redesigns and layout changes were required. And of course some components, such as the FPGA and the Mixer, had no viable alternatives.)
3. Designing a new revision
4. Manufacturing some prototypes
5. Testing those prototypes (again)
6. Keeping the faith...

This simple philosophy—taking one step forward, solving issues iteratively, and continuing to move forward—is difficult and expensive, but at least one thing was obvious: it was the right thing to do because it was the only thing to do.

So we made the necessary changes, but we still couldn’t gamble on securing replacement components without testing the resulting boards. And so Revision 2.6 was born. It was submitted for production, with a new (On Semiconductors) LDO, replacement passives, a different TCXO, etc. Then the COVID shutdown in China stepped into the plot. Fortunately, our CM (kudos to MakerFabs!), made extra effort, and the work was done in six weeks (including components sourcing). The boards were ready, thanks in part to FPGAs and TCXO chips pulled from previous prototypes and carefully re-soldered onto the new boards. (Remember? No FPGAs and no TCXOs in the nearest future…) We tested the new boards and found them to be working as expected.

At that point, we ordered the new replacement components. It felt good. Our preliminary conclusions were…

1. Never take a component's availability for granted. Always design the footprint to be as versatile as possible. For instance, we could make the TCXO footprint to fit differently sized TCXOs, expanding the supply for that particular component. This is not a silver bullet though, and it also jeopardizes the component's solderability during reflow (statistically speaking).
2. Whenever possible, order the chosen components for the production phase even before testing them. Easy to say, but very difficult to implement. In some cases, a single component may contribute up to 10% of the board's total production cost. Thus, this suggestion often requires a careful and substantial provisioning of funds for risk reduction.

At any rate, that optimistic moment lasted less than a day. We were still missing a significant number of very problematic components. And thus began…

The Second Marathon

After an exhaustive search, with a deeper understanding of the situation, and thanks in part to a 25-column spreadsheet, we began to control the situation instead of being controlled by it.

We classified each component based on its level of risk:

• Category 0: No risk. More than two different replacements exist and the component is generally available (somewhere).
• Category 1: The components are currently available in large volumes but may disappear, but replacements exist. Not a showstopper.
• Category 2: The components are not currently available but are expected to arrive soon (<2 months). You never know the level of competition for parts like this or how much of the incoming quantity has been pre-ordered by someone else.
• Category 3: The components are not available and are not going to be available ever. (For our purposes, we regard anything after 2023 as "never.")

For Category 0 and Category 1, all is well.

Between Category 2 and Category 3, the latter is easier to deal with: find replacements if they exist and purchase them with spares no matter the price. It’s a race. Others try to source these components as well, and we’d better be first in line. So that’s what we did, without even waiting for further testing. We managed to source TCXOs and modem’s different variants and sizes from Mouser, DigiKey, and Richardson. All in separate reels. We also ordered other missing components such as the ESD diodes, the transistors, and the low-voltage (Texas Instruments) LDOs in high volumes from different sources, just to be sure.

Category 2 - We sourced the vast majority of these components from Mouser Electronics. According to the current status, and following the work done to minimize component-sourcing time, our latest lead time is around the end-of-July. We are going to wait for them. There is really no other reasonable option. Regardless of this decision—and due in part to the level of paranoia we have developed lately—some components have been double sourced to ensure that we can receive them in full reels rather than as cut tape, which would impose a greater workload on our CM.

Reels have begun to arrive and are piling up, which is great. But we still needed to test the replacements again, and here comes yet another surprise factor we had not previously considered: Moisture Sensitivity Level (MSL). The reels we ordered are sealed for production. Once opened, the MSL-3 level package, for instance, needs to be reflowed within the next seven days. Otherwise CaribouLite becomes a popcorn board (and not a tasty one…).

MSL - a Short Explanation

Electronic components generally have an MSL level which denotes the period during which these component may be exposed to room conditions (~30°C and ~60% relative humidity). The component plastic packaging absorbs moisture. When a standard reflow assembly process imposes a large temperature gradient on a component, that trapped moisture quickly evaporates within the package and can damage or crack the component from the inside. So MSL in general means that you should not expose the components to room conditions for longer than a given period of time before reflow, otherwise (statistically speaking) many bad thing can happen.

But we still needed to test the replacements, so we unsealed the smallest reel, knowing that doing so would require our CM to bake those components for eight hours prior to assembly in order to remove any moisture from the components.

Manufacturing is an epic endeavor that has become even more epic over the past few years. We’re making excellent progress but we need to ask for a little more patience as we continue marching toward our goal.

Software

ADS-B Software

An ADS-B receiver for 1090 MHz was modified to support CaribouLite. The original files were sourced from Dump1090 Github. The current version can be found on GitHub

This example is a good reference point for C/C++ developers using the SoapySDR API. It conforms to a neat standard way of designing streamed IQ signals with the following structure:

// INCLUDES
...

// SUPPORTING FUNCTIONS
// ====================
Func1()
{

}

Func1()
{

}

// LOOP
// ====
SoapyProcessingLoop(...)
{
    activate_channel(...)
    while (as long as the process lives)
    {
        buffer <- readStream()
        external_processing(buffer)
    }
    deactivate_channel(...)
}

// SETUP
// =====
main(...)
{
    std::string argStr = "driver=Cariboulite,channel=HiF";
    try 
    {
        1. Make the device according to argStr
        2. Configure the channel
        3. Run the soapy-processing loop "SoapyProcessingLoop"
        4. Deconfigure device
        5. Dispose device
    }
    catch
    {
        Handle Problems
    }
}

The external processing was sourced almost entirely from the dump1090 project with minor modifications and adaptations. You can see the current program output below:

Better Support for SoapySDR

To support a variety of third-party SDR packages, we started by developing an internal API (called "caribouliteapi") then ported SoapySDR’s API to work with it. SoapySDR’s API supports multiple channels per device, which is quite handy when dealing with a multi-channel SDR (like CaribouLite, which has two channels). Unfortunately, this kind of support doesn’t generally bubble up to many third-party packages, which typically regard each device as a single channel device when working with Soapy-API.

Modifying third-party software is possible but it’s no easy task, so we decided to identify each channel within the CaribouLite as a separate device with a separate (unique) serial number. As a result, when you use SDR++ (for instance), you will see two devices in its list (typically "CaribouLite-S1G" for the sub-GHz channel and "CaribouLite-HiF" for the high-frequency channel). The python API works the same.

Python Synth

You can find a few python-specific scripts that we use to verify the API and for hardware testing in the /examples/python folder of our GitHub repo.

The screenshot below shows a signal-generation UI that addresses both channels. Designed for testing CW generation, it is handy for signal generation, self-testing, and troubleshooting.

GNU Radio Support and More

We have begun porting libcariboulite to GNU Radio. It’s a work in progress, and you can find our working directory for this port in the /software/gr-cariboulite folder of our GitHub repo.

The Linux driver (kernel module) we currently use for CaribouLite is still the original Raspbian SMI version, though we embedded the optional updated driver within the libcariboulite package. It remains a work in progress, however, and it breaks occasionally. For testing purposes, we continue to work with the original kernel module.