A modular approach for hifi audio projects powered by the new Teensy 3.6
Quick update before the Best Product deadline:
The CORE module is done (at least on paper), the PSU module is almost done (I got to find a nice position for the power connectors for the submodules), while the INPUT and OUTPUT modules are yet under schematic review. I am also thinking of making a single supply version of the analog interfaces modules, but not now.
About the business plan required for the deadline: I have no idea how to make one. I've seen online that to make a proper one I should basically be ready for production, which is totally not the case since I still have to order my first batch of prototypes. Nonetheless, I have a plan in my mind that it's quite easy to follow and I hope it will be counted as a "business plan" at least for the sake of the contest (I know I have to make a proper one since I got to make a crowdfunding):
My plan is to start making the CORE module through a crowdfunding campaign, to sell it as a higher quality alternative to the Teensy Audio Board; ideally I will offer several modules on the campaign, to give the users several donation incentives (e.g. : first incentive is for one CORE module, second incentive is for one CORE module + PSU + simple analog IO interface, third incentive is for one CORE module + PSU + simple analog IO + pro level analog IO, fourth incentive is for 2 CORE modules + PSU etc etc), but I must be realistic and accept the fact that I may not be able to develop all these modules in time for a campaign.
As soon as the campaign ends I will keep producing boards either in house (if the demand will not be huge) or through external sources. To produce the boards in house I will need to buy some tools (namely: pick n place, reflow oven).
Also, when the campaign ends I will spend the next 6 months to provide support for the modules produced during the campaign, through the means of a forum of some sort.
After the first 6 months, I will reduce the support time (in hope that 6 months of user base support will cover 99% of the necessary support information for everyone) and resume development of new modules (IOAPEX, PRO PSU, single supply analog IO interface, etc.).
This will eventually reiterate.
In a nutshell my idea of business is as follow:
-Make some MATT modules prototypes
-Make a crowdfunding to kickstart production of said modules
-At end of campaign, provide 6 months of support to said modules (or less if most of the support information has already been covered) while continuing production (in house or external fabs)
-When support phase is over, I will start development of new MATT modules
-After 6 months of prototyping and preparation, make a new crowdfunding campaign to kickstart production of new MATT modules
I am also considering hiring someone in the future, either to help me with in house production, or to help me with the crowdfunding campaign (probably both). I will also have to invest on marketing/advertisement to make a proper campaign.
quick updates on the project:
I am almost done with the layout of the CORE module, then I'll move on to the PSU and to the analog IO interfaces, then I'll start ordering some protos.
As soon as I finish a module I'll update GitHub and here accordingly, with 3D renderings of the PCBs as well.
MATT is going to be a commercial project.
My goal is to make a crowdfunding out of this and try to earn a living by producing MATT and future modules for it.
Some parts of MATT's hardware will be delicate and will require careful PCB layout considerations, and to make my design easier through all the different supplies involved as well as to reduce noise in the analog domain due to interferences from digital traces, I will probably use more than 8 layers PCBs, which is not exactly affordable for everyone anyways. So I am thinking of not releasing the layouts, at least of the CORE.
But I would release the schematics for reference, for anyone to hack around it.
I am also thinking of releasing the binary for the Xilinx CPLD, but not the source of the VHDL. This may change in the future; also, for all the VHDL/Verilog hackers out there, a programming header will most probably be present on the final IOAPEX module, so if you want to upload your own code feel free :)
All the code to drive all functionalities will be open source. Open sourcing the code is a must in order to give back something to the Teensy community, but also to enable users to develop all kinds of custom submodules.
I would like to keep the focus of users on the creation of new submodules, which are the real key element of this project.
The base specs for modules, as well as barebones versions of modules, will be fully open source and open hardware.
The analog IO modules could be made easily by using perfboard; eg. a JFET buffer for a guitar. I will use standard 0.1 inch headers wherever possible, and I will try to keep their spacing in 0.1 inch multiples. As long as the max. output value of the module respects the specs of the CORE onboard input module, anything goes.
Same thing for the IOAPEX modules: the IOAPEX is in fact designed specifically to keep the external components to a minimum. As already explained, each type of sensor will require only 1 mux, and maybe a couple of passives. I will release base layouts for digital in only modules, digital out only modules, and analog in only modules.
I was also thinking of making the easiest module, that is one module with one mux, a jumper to select its operation (analog, digital in, digital out), and then 16 plated thru holes to connect to anything an user would like to.
Let's not forget that every submodule could be used with ANYTHING else, really. In the end these will just be muxes and switches. You want a simple button matrix to use with your Arduino? Get the first mulitplexer example sketch you can find online and plug your arduino to the module through its provided pin header and voilà
Some of MATT's design files will not be open, I know, but its key part will be fully open, giving the users simpler ways and tools to make custom and powerful audio solutions.
MATT will be composed of 3 main modules (CORE, POWER, IOAPEX), plus an ecosystem of submodules.
Some of the submodules I will/would design are as follows.
For the IOAPEX submodules, the limit is one's imagination. I was already thinking of making a Minimoog mockup control interface and plug it in the IOAPEX, or a Rebirth hardware clone... I would really love to bring something like that around as a demo :)
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.
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.
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).
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.
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.
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.
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...Read more »
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.
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:
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.
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.
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.
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.