# Cacao - Multi-Channel Signal Acquisition Board

Cacao is a compact 12-channel audio-frequency signal-acquisition board built around the RP2350. It explores how modern, accessible components can consolidate multi-channel acquisition, buffering, storage, and Ethernet communication onto a single 80 x 50 mm PCB.

![CACAO Board](figures/Assembled.jpeg)
![Cacao PCB - 3D render](figures/Recto.png)
![Cacao PCB - 3D render](figures/Verso.png)

(On the real pic you can see pretty obvious shorts on different chips, the board was just out of the oven and the shorts were dealt with before first bring up)

## Overview

Cacao was developed independently as a proof of concept alongside an industrial R&D internship. The project acts as a technical calling card: a complete architecture, schematic, and dense PCB layout designed to demonstrate what can be achieved with a modern microcontroller and cost-effective audio-conversion hardware.

Twelve differential audio inputs are digitized by three TLV320ADC5140 ADCs at 44.1 kHz. The RP2350 collects and processes the resulting data before sending it over 100BASE-TX Ethernet through a W5500 or storing it locally on a microSD card.

## Key Features

- RP2350 in the 80-pin package with internal flash
- 12 differential audio-input channels
- Three TLV320ADC5140 four-channel ADCs synchronized by a 2.5 ppm clock
- 44.1 kHz acquisition with planned 12- or 16-bit sample handling
- W5500-based 100BASE-TX Ethernet output
- 8 MB external RAM for acquisition buffering
- MicroSD storage for standalone data capture
- USB-C 5 V power input
- 3.3 V buck supply for the digital electronics
- Separate low-noise 3.3 V analog rail using an LP5907MFX-3.3/NOPB LDO
- Four-layer, 80 x 50 mm PCB with more than 200 components
- Components on both sides, with most passive components placed on the back

The Micro-USB connectors are used as compact keyed connectors for the differential analog channels and their 5 V amplifier supply. They are **not USB data ports**.

## Engineering Focus

The principal layout challenge was integrating 12 analog channels, three synchronized ADCs, local buffering, storage, Ethernet, and the required power architecture within an 80 x 50 mm footprint. Particular attention was given to separating low-noise analog supplies from the general digital rail, maintaining clean reference and return paths, and placing a large number of passive components without increasing the board area.

An alternative future configuration could replace the W5500 and external RAM with a W6300 connected through QSPI, reducing the number of separate devices while retaining high-speed Ethernet communication.

The firmware will have to be as efficient as possible to allow 10-12 channels at the same time to be sampled and transferred to the W5500.

## Assembly

V1's PCB's were manufactured by the company Aisler. It was a first test for me and I liked the service a lot.

PCB's arrived naked and I assembled three prototypes by hand at school where we have small manually controlled "pick and places" machines that help speed up the process of compared to using tweazers to place components.

![CACAO Board](figures/Bare_PCB.jpeg)

![CACAO Board](figures/Compare.png)

On the top you can see the bare PCB and on the bottom you can see a fully assembled board next to the boards she is supposed to compete against. (The others are blurred as they are property of the company I worked in but they are the boards that are doing 12X less work as cacao does)

## Project Status

V1.0 has been received and assembled. It is currently in testing but I can already say that :

+ All power buses are operational
+ Ethernet works with PIO SPI instead of native SPI 
+ RP2350 can be flashed using the USB and SWD
+ All ADC's are working and be communicated with
+ After modifiying the micro USB connection data can be read from ADC's to the Rp2350 and then to USB or Ethernet

So basically all the main features are working.

Here is what cannot be tested 

+ The RAM has not been installed as all of its wiring is wrong and a PIO implementation could work but not fast enough for my use case so it will need to wait for a new version
+ The SD card port was not received

Here is what is still in testing 

+ Actual throughput limit through the W5500 with the reduced SPI bandwidth
+ Quantifying the signal integrity coming from the analog capture. (it is looking pretty good on my first tests)

## known V1 issues

The first version as always has problems and here are the known issues that will be fixed in version V1.1 or V2 depending on how much changes are needed after the full testing of V1 goes.

### Bad selection of Rp2350 ports

That is a pretty embarassing issue but it is not fatal. I put a bit too much faith into the internal GPIO MUX of the Rp2350 and did not respect the rules about SPI pin selection.

First of all, all pins of a SPI bus need to be connected to the same SPI port, but there only are a few pins that are actually connected to a SPI port and even then not all of these pins can be used for everything. You cannot put MOSI or SCLK on any pin of the SPI port.

Also an other issue, QSPI cannot be rerouted to any pin. The QSPI bus is only available from the QSPI specified pins which is something I missed unfortunately for the external RAM.

The RAM needs to be totally rerouted, 5/6 pins are wrong and need to be changed :

```
RAM_QSD3 not to GPIO 16 but to QSPI_SD3
RAM_QSD2 not to GPIO 17 but to QSPI_SD2
RAM_QSD1 not to GPIO 18 but to QSPI_SD1
RAM_QSD0 not to GPIO 19 but to QSPI_SD0
RAM_QSCLK not to GPIO 20 but to QSPI_SCLK
```

This is extremely embarassing as the pins are even labeled, I should have seen this before sending the files to production.

The W5500 connection needs to be rerouted as such :

```
ETH_CS GPIO28 to GPIO29
ETH_SCLK GPIO29 to GPIO30
ETH_MISO GPIO30 to GPIO28
```

And for the SD card it's just completely wrong.

Thankfully these issues do not prevent testing as the PIO blocks can be used to create homemade SPI with custom pins, but performances will not be as the same level as they would have been with native SPI. That is why on the first batch, the RAM was not even soldered as it was not very useful to use even with PIO in my use case.

### Wrong micro USB pinout

This one looks stupid too but actually is not that ridiculous. It could have been avoided but it is not completely stupid.

The préamp that is supposed to be plugged into the cacao board is a custom solution that only uses the micro usb port and not protocol or guidelines. 

During the design, I put 5V on the VBUS pin and GND on the GND pin. How foolish of me to not check that the designers of the AMP might have wired it completely differently putting 5V on the GND pin and GND on pin 4...

So all 12 channels actually are not powering the pre amp and are getting a signal that is waaaay too weak to be used.

A test was done by removing one port and wiring a new port with botch wire in the right order and then it worked perfectly.

So for a new version you would have to make these changes :

```
uUsb Pin 1 VBUS -> GND
uUSB Pin 4 NC -> GND (the actual GND used by the preamp)
uUSB Pin 5 GND -> 5V
```

It took longer that I want to admit to diagnose this as the signal was not truely 0. I was just getting a very weak signal but tapping the mic still gave some signal. And of course the preamp has no power on LED or anything.

But for now it looks like the only issues of V1 are pin assignement and that with those sorted the all system should work perfectly and with much better performance.