The POWER module will provide a stable supply for the CORE, IOAPEX, and submodules, either through a DC wall wart supply, PoE, or AC.

The module will provide up to 12 W operating with a DC supply or with PoE, and up to 120 W? with an AC plug. I put a question mark because I yet have to design this module.

Supply for everything

The module will provide a 12 V DC supply to the CORE module, through its connector; the CORE onboard PSU will accept a wide range of inputs voltage so the POWER module could also use different supplies for that.

PoE

A PoE module (like the Silvertel Ag9900) would provide up to 12 V @ 1 A, and 9 or 12 V (DC) could be easily obtainable with a wall wart psu (like the ones for guitar pedals). The PoE module can be used along an Ethernet module like the Wiznet W5500, which is already supported by the Teensy 3.x. The PoE module could be made as a submodule, due to the relatively high cost of the components (some users won't necessarily need PoE and Ethernet).

Why AC?

The AC plug would be used to power a high voltage, high current PSU to drive multiple preamps and power stages, in order to be able to use vacuum tubes circuit, or loudspeakers. The voltage and current specs of this part of the PSU have yet to be defined since they would depend from the voltage/current levels needed by preamp and poweramps stages that I still have to design. I would also like to have a way for users to modify the voltage output of this supply using a trimmer maybe, so that users could design their own modules. I found this little project that could help me understand how to design a nice PSU for tubes.

Optional connectors

Sub-modules that may require higher supply voltages could take their supplies from the POWER module through a cable connector, instead of using the dual 15 V supply on the CORE module.

I would like to keep this module as big as the CORE one; I don't want a full setup with all three modules to be too bulky. I have to check how much power I can get out of the module while keeping size relatively small.

The IOAPEX module is a port expander that provides control of up to 256 digital inputs (e.g. buttons), 256 digital outputs (e.g. LEDs), 256 analog inputs (e.g. potentiometers, FSRs), and maybe 16 CV/gate signals.

One CPLD to rule them all

IOAPEX is an acronym for Input Output and Analog Port EXpander. It uses a CPLD as a SPI interface between a microcontroller and a parallel interface, to control 16 bit multiplexers. The CPLD code will fit a XC9572XL-5-VQ64.

The multiplexers will be soldered on the submodules that the user will connect to the IOAPEX. One mux can be used to control one of the following types of sensors: inputs, outputs, analog.

So for example, if on one submodule I would like to have 16 buttons, with 1 LED near each button, and 16 potentiometers, I would need 3 muxes on my submodule.

The SPI interface of the IOAPEX accepts 16 bits words, and produces 16 bits words as well.

The IOAPEX is designed to send and receive streams of 16x16 bits words. Each bit in a word represents the state of one digital IO, and for every word the IOAPEX changes the selected digital IO through the parallel mux interface. The IOAPEX counts the words it receives to control the state of the submodules muxes. The IOAPEX presents a RESET pin to reset that counter. So, in a case of initialization the first word sent to the IOAPEX will contain the data to present on the 1st digital output of every module, while the first word received will contain the state of the 1st digital input of every module.

In a digital IO only use-case, a theoretical update frequency limit for all 256 IOs is around 104KHz, or 1 uS delay.

The software controlling the IOAPEX will make use of the Teensy 3.6 hardware CS SPI module to tune the performance, as well as DMA access.

Analog muxing

The CPLD is also connecterd to an external analog multiplexer controlled by the same digital IO interface, that is used to make again a 16x16 mux in front of one Teensy 3.6 ADC pin.

The use of the ADC is different. Every 16 bit word transfered through the SPI interface activates the next input on the currently selected analog module. This means that after 256 words, that is after 16 full updates of the digital IO section, we will have sampled all 256 analog inputs.

The minimum time to send/receive 16 bits through the Teensy 3.6 SPI is 18 SPI clock cycles (max 30 MHz), that is 600 ns. The minimum time to read one 8 bit sample from the ADC is 5 us + 5 bus clock cycles (60 MHz) + 24 ADCK clock cycles. Setting the ADC clock to 60 MHz takes 5.48 uS of sample time. Summing the two sampling periods and multiplying that by 16 gives us the actual time to update one analog module and all digital IO modules: (5.483 uS + 0.6 uS) * 16 = 6.083 uS * 16 = 97.328 uS, that makes around 10 KHz (10.274535 KHz) of update frequency for all digital IO. For all 256 analog inputs it would require 16 times that again, that means we could have an analog sampling frequency of 642.1584 Hz; Nyquist says that we can sample signals as much as half of that, so around 321.0792 Hz; this means that there would be a 3.11496 ms delay between every sample on the analog inputs, or a 6.229 ms delay if an average of two samples is done. This should be a reasonable value for controls such as potentiometers, force sensing resistors.

If we reduce the number of analog input (192, 128, or 64 max. analog inputs) we could have 2.3658 ms delay for 192 inputs, 1.5572 ms delay for 128 inputs and 0.778624 mS for 64 max. analog inputs. I should consider an option to set this through some pins on the CPLD, in fact I should have at least three pins available.

64 analog inputs sampled at 2568.633 Hz are still plenty of sensors at a decent frequency for human interfaces: for example, a 4x4 FSR matrix, a 37 keys keyboard ( 3 octaves + one key), and there would still be 11 left, like 3 for a pitch bend and modulation control, and 8 generic pots, assignable to filters or whatever.

Using less inputs also allows to spend less on connectors :D I could easily fab the board without the connectors and provide an option to buy the needed amount of connectors (in multiple of fours for example).

CV/Gate OUT? No CV IN?

The same controls to select for 64, 128, 192 and 256 analog inputs could also be used to select between 4, 8, 12 or 16 cv/gate signals by multiplexing the DAC pin. Two DACs could be used in parallel and linked thru the DMA, right after the ADC read. This Teensy forum post says that the DAC bandwidth is way higher than reported in the specs, because it depends on how fast you can write to the DAC registers. Using the DAC will surely add a delay but let's not keep it in count for now, hoping that it will be as small as possible. I would like to use a smaller amount of CV/gate signals to have a better bandwidth out of them: if I can update the DACs once every full analog module is read, with 64 analog inputs we could have 4 (or 2x4 if two DACs are used) output channels sampled at 10.274 KHz. Adding a low pass filter near the Nyquist frequency would yield around up to 4 KHz signal. 8 CVs (or 2x8) scale to 5.137 KHz fs, 2.568 KHz fN, around 2 KHz filter; 12 (or 2x12) CVs scale to 3.424 KHz, 1.71 KHz fN, aroujnd 1 KHz filter, and finally 16 (or 2x1 CVs) scale to 2.568 KHz fs, 1284.25 KHz fN, maybe I can still get around 1 KHz of clean signal.

The CV looks really promising only if used in a 4 channel config, or 2x2 channel in case of a teensy 3.6 for double bandwidth. My plan to include the +/- 15V supplies on the IOAPEX is in the event of using the CV/Gate. A nice gain stage could be implemented in front of a Teensy DAC pin to convert its signal from the Teensy's voltage reference level to more professional level, like +/5 V, +/-10 V, or +5V, +10 V, etc. The DAC's resolution is 12 bit so there should be enough digital headroom for precision. Maybe the best option would be to have one buffer in front of each CV/gate signal. I would like the output to work well for both DC and AC. In case of DC signals I need the buffer to keep the same value it received from the DAC on its output jack, long enough for the IOAPEX to finish its CV update cycle and send the next sample out.

A CV in could be implemented in the same way on the analog input modules. A buffer circuit could be put on the module's output to decrease the expected cg/gate input signal (again around +/5 V or +/10 V, or 5 V, etc) to the Teensy ADC voltage range. The sampling frequencies restrictions explained before would still apply.

Connectors connectors

There will be 16 connectors on the IOAPEX for each type of submodule, that makes 3 rows of 16 connectors. Each connector will have these pins (not in this order): GND, 5V, 3.3V, 4 pins for the mux control pins, 1 pin for the mux common pin. I could add+15 V, -15 V (for analog io?). This would either need either 8 or 10 pins connectors.

LED driving

I am thinking of implementing a constant current LED driver directly on the IOAPEX for each output module, with its current modifiable by a resistor (to drive more or less current in different types of LEDs). Maybe the whole system will be fast enough for a decent software PWM. This would also keep the design easier.

The math given some paragraphs before shows a full digital IO update frequency of 10.274 KHz. This gives a PWM frequency of max 5.137 KHz. Consider that for every update, only one LED per module is on. So if we turn one output ON and OFF every sample the output will be ON for 6.0833 uS, OFF for 1/5137 KHz *2 - 6.0833 uS = 383.2489 uS time. That is, the duty cycle of a software PWM would be 1/32 -> 3.125% duty cycle. Maybe there's a way to buffer this kinda like in the CV case to let this output stay on long enough before the next sample arrives. Using LEDs in this way should reduce power consumption since not all LEDs can be on at the same time.

The CORE module is the central part of the project, so it has to be as functional as possible in order to mantain a wide range of use-cases spectrum even when used as a standalone module.

This will be achieved by using high quality and versatile components.

Teensy 3.6 or Teensy 3.2? Maybe both

The CORE will be designed with a bias towards the Teensy 3.6, but retrocompatibility with the smaller Teensy 3.2 is an option. One of the downsides of using the Teensy 3.2 in this context is the lack of multiple SPI ports. MATT will have at least 4 devices on SPI busses, including but not limited to:

• a TFT ILI9341 based display (library optimized for SPI0 with FIFO)
• a Wiznet Ethernet module (library also optimized for SPI0 with FIFO)
• the AK4621EF codec (SPI1 or SPI2 on Teensy 3.6, forced to SPI0 on Teensy 3.2)
• the IOAPEX module (SPI1 or SPI2 on Teensy 3.6, forced to SPI0 on Teensy 3.2)

Plus, a lot of the SPI0 hardware CS pins, which are mandatory for the use with at least the display and the IOAPEX module, are taken by other functionalities (like I2S pins).

The Teensy might need to be permanently attached to the CORE module since some backside pins may be used (such as the D+/D- line for the USB connector), but a breakout of the Teensy pins will be available, as well as a USB type B plug for power and data transfer. The use of the USB EHCI in the Teensy 3.6 is an option, maybe in the form of a second USB type B plug, or maybe leaving bare PTHs on the board.

Power supply

The USB 5V supply will power a 5 V to 5 V dc-dc converter for a clean, stable, reliable 5 V supply. This clean 5V will then power a SMPS that generates a +15 V rail and a -15 V rail. These rails will be used to supply all analog-only circuitry (such as ADC input filters, DAC output filters, ADC buffers and DAC buffers, etc.) in the CORE module. Using these supplies on the IOAPEX module may be an option. Also, an option for a +48 Phantom power supply is considered. Finally, battery powered operation may also be an option.

CODEC

The CODEC on the CORE module will be an AK4621EF, with differential inputs, differential outputs, support for up to 192 KHz @ 24 bit resolution, and very high SNR and THD ratings. It needs to be connected via SPI to the Teensy for its control interface. You can check its datasheet for further details.

Analog section

Using a powerful dual supply allows the design of a flexible analog section, which sports 4 Neutrik combo XLR+TRS connectors and optional amplification modules connectors. Every channel will have a balanced/unbalanced switch, a XLR/TRS switch, and a onboard/addon module selector.

The on board ADC filter and buffer accepts balanced signals up to 40 Vpp / 14.14 Vrms and unbalanced signals up to 20 Vpp / 7.07 Vrms, it then scales the signals down to its full scale input of 5.658 Vpp / 2 Vrms.

The on board DAC filter and buffer outputs a full scale balanced 5.658 Vpp / 2 Vrms signal, it then scales it to balanced 40 Vpp / 14.14 Vrms or unbalanced 20 Vpp / 7.07 Vrms. The CODEC serial interface allows for a digital output attenuator with 256+16 levels, for attenuation range from 0dB to -72 dB to mute.

The presence of a dual supply on the addon amplifcation modules connectors allows users and designers to implement custom preamp or final modules tailored to their needs. Sub-modules including but not limited to mic preamps, guitar or bass preamps, phono preamps, headphones amplifiers, speaker amplifiers could be easily implemented. Also, the presence of an high voltage supply on the POWER module will enable users to design more demanding solutions, such as loudspeaker or tube preamps.

In the next logs we will discuss the specs of the POWER and IOAPEX modules.

We will also discuss the sub-modules that will contribute to specific functionalities of MATT, such as analog submodules for the CORE, io modules for the IOAPEX, etc.