Saturday, July 30, 2022

XM8 as a vocoder

I have thought about the posibility of using the XM8 as a vocoder for a long time, but had decided to not go ahead with it due to the added complexity.

However, while designing the voice cards I realised that by just adding tiny modifications, I could at least leave the door open to adding a vocoder daughterboard later. Let me explain.

Vocoder architecture

A vocoder has some central components. First of all, it takes two inputs:

 - one (usually a voice) that is analysed for frequency content by dividing the input into frequency bands using bandpass filters. The amplitude of each band is captured using an envelope follower.

- another one (usually an instrument sound rich in harmonics) which is divided into the same frequency bands as the first one, and where the amplitude is controlled by the amplitude of the first input.

The effect is that the second input "mimics" the first, making the instrument "talk".

In addition to the inputs, a noise source is used, and amplitude is sampled (analog sample and hold) at intervals set by a variable clock.

Here is the block schematics of the classic ETI Vocoder DIY kit:


It has three main parts - analysis and synthesis at the top, and sound generation at the bottom. The two oscillators are used in place of the second input.

How to implement this in the XM8

Now, we would need to implement the whole analysis, sample and hold and voiced/unvoiced detection on the daughterboard. The output from the board would be 16 CVs that can control VCAs. 

The second input will be either 
- External audio - if we want to use a different source for our "instrument"
- Output from the low pass filter on voice card 1 - that way we can use everything on the voice card except the state variable filter as a mono synth. 

We would then feed the second input as External input to all voice cards. By sending the input directly to the SVF - this is already part of the architecture - we can use the SVF in place of the second block of band pass filters in the schema above. The cutoff frequency for each filter is fixed and can be calibrated (part of the existing design) digitally. As an added bonus, the cutoff frequency may be moved to change the voice pitch (or even invert or reorder the bands).

There are two additional important things in the ETI vocoder design:
 - the first and last frequency bands are made using low pass and high pass filtering respectively. Fortunately, this is supported by the SVF.
- every second band is phase inverted. This is also supported by our architecture.

Changes needed to the voice cards

- Add a CV input going to the SVF. 
- Add an output from the low pass filter (pre VCA), this will be used on the first voice card to use as the second input.

Changes needed to the main/input board

- Add a switch between external input and voice card 1 LPF output (this is a good idea anyway)
- Add a switch between this input and a third input used for vocoder noise source. This would be controlled by the voiced/unvoiced detector on the vocoder analysis board.
- CV outputs going to the vocoder board to control voice input volume etc.
- Chaining between synths - either we need a separate analysis board on synth two or we need 8 VCA inputs. We need a separate Ext audio out, tapped after ext audio mux, to send voice card 1/noise to second synth.

A four channel mux may be used, if we let the vocoder analysis board control A1 and input noise to input 3 and 4, the mainboard may control A0 to switch between external input and voice card 1 LPF. A1 would then effectively override the two inputs (and should have a pulldown resistor so that it is disabled if no vocoder daughterboard is fitted.


Usage: LPF filter VCA must be turned down on all voices, and Ext in turned up and connected to SVF for all. Voice card 1 may be used as input to the other sources.

As one XM8 probably ends up having only 8 voices, we need to chain two to get a full 16 band vocoder. Here is one way of doing that:

We need to have a single analysis board to be able to detect voiced/unvoiced properly. Bus chaining requires level matching between the synths, so ext bus input should probably have VCAs.

Things to test

I am unsure of the steepness of the bandpass in the ETI vocoder. The SVF has a 12dB bandpass.

Update: According to the Deliyannis bpf docs, one filter has 12dB cutoff, so two must have 24dB. That means that we may have to run the audio through both the LPF and the SVF (as HPF).

Deliyannis band pass filter

While reading about the human voice filter bank in the VP-330 (on the Oakleysound site) i realised that the ETI bandpass filter is called a Deliyannis bandpass filter or resonator, a calculator can be found here: 

https://www.changpuak.ch/electronics/Deliyannis_Bandpass.php

http://earmark.net/gesr/opamp/bpf.htm

Thursday, July 28, 2022

Teensy 4.0 bottom pins - finding a suitable header and connector

If I'm to use the Teensy 4.0 as my voice controller MCU, I need to use the 10 additional pins on the back to get to the second SPI.

This means I either have to solder pins to the 10 pads, or use a breakout board with castellated connections like https://forum.pjrc.com/threads/57672-Another-Teensy-4-0-Breakout-Board?highlight=Teensy+4.0+rear+pins

If I am to solder pins, I need to make sure that I can find a matching mating connector. As the SMD pin header is higher, the mating connector needs to be lower. Also, the pins need to be short enough to fit the connector.

I measured the pre-soldered pins on the Teensy, the bottom plastic is 2.54mm high, the pin is 5mm.

Normally, mating connectors for the single rows are 8.5mm high, with some saying that the pins may be 6.6mm long.

I am going to try out the following:

Pins (from Farnell):
Samtec TSM-105-04-L-DV
These have a 0.15" (3.81mm) height before the pins, or 1.27mm more than the ones on the Teensy. The pins are 3.05mm, which is a bit on the short side.


Update: Samtec TSM-105-01-F-DV has a pin height of 5.84 which may be more suitable.

GCT BG050-10A-0-0450-0737-0350-L-D
These have a height of 3.5mm before the pins, but the pins are 4.5mm. That looks very promising. Unfortunately, ordering these in Norway incurs a $13 fee because they are only in stock in the US.
F = 3.5mm, D=4.5mm


Female connectors (from Farnell):
Amphenol 76342-305LF
This is a 7mm high receptacle. combined with the GCT connector it would give a total height of 10.5mm, as opposed to the 11.04mm of the side connectors, leaving a 0.5mm gap. This is probably fine. Combined with the Samtec one the gap is reduced to 0.2mm, but the short pins (3mm) may not be long enough. The max pin length is not stated but from the "normal" connector we can guess around 4.9mm.



AMP 215307-5
Similarly, a 7mm high receptacle. Max pin length is not stated for this one either, but it says that the connection point is 2.2mm into the connector which is a tad too long for the 3mm Samtec pins.


From JLCPCB:
I managed to find a couple of 7mm headers from JLCPCB as well:

Liansheng FH-00097
part C2829902, though only 8 are in stock right now:

Wcon 2171-210SG0CUNT3
part C721788 - unfortunately, the mating position is  3.57mm down which again may be too far for the pins.

I will order the Farnell ones shortly to test.

Update:  Results from Farnell

14 pin socket:
Part 1593466 / 2212-14SG-85 
May pull pins 0.8mm out and still have good contact. Tested using pins that protude about 5.66mm and has 2.54mm plastic at the bottom

When pressed together, pins and header measure 10.87mm. Header is 8.42.

10 way SMD
Pins: 3551099 / Samtec TSM-105-01-F-DV (NB: F, not L). Plastic + bent pins measure 3.86mm. The pins measure 5.68mm so the total height is 9.66mm

Header: 1098050 / Amphenol 76342-305LF. Measures 6.97mm. Pins may be pulled out at least 1mm and still have good fit. Height with pins is 10.85mm

Header: 3419216 / AMP 215307-5. Measures 6.96mm. Pins may be pulled out at least 2mm and still have good fit. Height with pins is 10.84mm. Has a very nice, tight fit

Conclusion: The combination of either of the headers with the SMD pins will work, and the height is damn near spot on when used with the 14 pin socket and standard pins!

I still have the GCT BG050-10A-0-0450-0737-0350-L-D on order and will add the results when they get here, but it seems the Samtec ones work nicely.

Update 2:
Pins: 1798977 / GCT BG050-10A-0-0450-0737-0350-L-D. Plastic + bent pins measure 3.65mm. 

Combined with header the total is 10.62. The pins are at least 1mm shorter than the Samtec ones. They still fit quite well even when pulled back 0.2mm

Pins: 3585115 / Samtec TSM-105-04-L-DV. Pins above plastic is 3mm, which is too short to be comfortable. I would not recommend this.

Final conclusion:

The clear winner is the Samtec TSM-105-01-F-DV pins with either of the two headers. Since I've bought enough of the GCT pins already, and they work fairly well, I will go with those. The price is also between half and 1/3 of the Samtec, so if you're in the US they are probably a lot cheaper. Since I had to pay extra they are more or less the same. Had I not bought them I would have gone with the Samtec.

Both SHOULD work with the LCPCB headers too.

Tuesday, July 26, 2022

Itsy bitsy Teensy trouble - with Slave SPI

This is another one of those posts mostly meant for myself.

I've been hitting my head against the wall for four days, trying to get Slave SPI working on a Teensy 4.0, with a Teensy 4.1 as the master.

I started out with the https://github.com/tonton81/SPISlave_T4 library (and https://forum.pjrc.com/threads/66389-SPISlave_T4) , but could not make it work, so I stripped it down to the minimum. After a while (after removing a while-loop from the ISR) I got some response. However, it was not stable and it seemed like it would only receive every second byte.

After a lot more troubleshooting I got it working on every transfer, but only if writing 0 to the TX buffer. Any other values would give different troubles.

In the end, it turned out to most likely be a combination of things - mixing up MOSI and MISO pins as well as wrong impedance settings on the pins. Removing and attaching probes to the pins also made stuff fail.

Anyway, next time I would check the following:

- Make sure CFG1 is set to full duplex (00 or 11) 

- Check crossed vs straight connections between MISO and MOSI, matching CFG1

- Connect/disconnect logic probes on MISO/MOSI (works when bytes go missing)

- Make sure master deasserts PCS between frames, I wrote 16 bits without rising the PCS (or rather, rising for a too short time) between blocks of 8 bits when frame size was 8 bit.

- Make sure master speed is > 1MHz

I have yet to find a completely stable solution and I am worried that connecting multiple slaves to the same master may not work as intended. 

Learned

Anyway, here are some of the things I learned:

- The minimum SPI speed on the Teensy is 1MHz (without doing special stuff)

- To set SPI in slave mode: set bit 1 in CFG1 to 0 and update Clock gating register for the appropriate LPSPI, for example CCM_CCGR1 |= (3UL << 6); (lpspi4_clk_enable)

- When CFG1 bits 25-24 are 00, MOSI on the master connects to MISO on the slave and vice versa.

- When CFG1 bits 25-24 are 11, MOSI on the master connects to MOSI on the slave (and MISO to MISO).

- When communicating between two Teensy 4.x, the pin impedance must be changed on both slave and master. For example: 

IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_01 = IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE;

- Even when changing the impedance, I needed to experiment with connecting/disconnecting the logic probes.

- TX buffer empty flag is set immediately after the last TXFIFO byte is shifted out, at the same time an RX interrupt is triggered (if RXWATER is 0).

- The SPI documentation talks about different size descriptions:

    - Transfer - when sending data - Transfer complete IR is triggered when all data in TXFIFO has been sent (FIFO is empty)

    - Word - Up to 32bits, 0-padded if less than 32 bits received. FIFOs are 16 words long.

    - Frame - Frame complete IR is triggered when PCS (chip select) goes high (deasserts). A Frame may be from 8bits long, length must be divisible by 2 and may be longer than 32bits (span multiple words). If word length is reached, the frame is split across multiple words in the RXFIFO.

- TDF and RDF - Transmit and Receive Data flags are set by the system and reset by reading from/writing to the TX and RXFIFOs, not by clearing interrupt flags.

- The SPI slave example sets IER bit 1 which is Transmit Data Interrupt. It will be triggered when the number of bytes in the TXFIFO is less than TXWATER. With TXWATER 0 this will be triggered at the same time a byte is received. I don't understand why this is chosen instead of for example FCF.

- The SPI slave library, and also the more elaborate example at https://github.com/tonton81/SPI_MSTransfer_T4, uses a lot of looping and waiting inside the ISR, which cannot be a good way of doing things...

- With an 8bit frame and a single byte in the TX buffer, the following are set on RX: Frame completed, Word completed, RX data ready, TX data ready. RXFIFO in FSR is incremented. If another byte is received before a new byte is written to TX, we get a TX underrun.

Symptoms

Here are some of the symptoms I experienced:

- Missing or erroneous slave sends when anything but 0 was written to TDR - i suspect that we tried writing and reading from the same pins and that messed up stuff, though not entirely sure WHAT was going on.

- TX buffer underruns even if I wrote to the output buffer every time a byte was received

- Elements in the TX buffer disappeared (even if length was correct) as verified by logic probes. 

- When writing the same bytes over and over to TX, the same bytes disappeared every time.

- Swapping master and slave made DIFFERENT bytes disappear.

- Missing RX, some of the received bytes never ended up in the RXFIFO

- All receives worked when I only wrote 0 to TX buffer.

- It looked like I needed to receive 16bits and/or only every second byte was received.

- When unplugging either the MISO or MOSI cable, sends started working perfectly

- Removing probes sometimes made stuff work - but only after powercycling the Teensys.



Test code

My slave test code can be found at

https://github.com/xonik/teensy-spislave-test

Master code is

#include <SPI.h>

SPISettings settings(10000000, MSBFIRST, SPI_MODE0);


void setup() {

  IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_01 = IOMUXC_PAD_DSE(7) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; 

  IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_02 = IOMUXC_PAD_DSE(7) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; 

  IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_03 = IOMUXC_PAD_DSE(7) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; 

  IOMUXC_SW_PAD_CTL_PAD_GPIO_B0_00 = IOMUXC_PAD_DSE(7) | IOMUXC_PAD_SPEED(3) | IOMUXC_PAD_PKE; 


  Serial.begin(1000000);

  pinMode (10, OUTPUT);

  digitalWriteFast(10,HIGH);

  Serial.println("SPI Starting");


  SPI.begin();   

  SPI.beginTransaction(settings);  

}


void loop() {

  digitalWriteFast(1,HIGH);

  digitalWriteFast(1,LOW); 

  delay(500);


  digitalWriteFast(10,LOW);

  Serial.println(SPI.transfer(0xAA));

  digitalWriteFast(10,HIGH);  

}


Thursday, July 21, 2022

DAC8565

I had some DAC8565 (quad 16bit DAC) breakout boards made at JLCPCB, and just tested them, they work fine.

The datasheet says that SPI speed for < 3.6V Vdd is limited to 25MHz, above that it's 50MHz. I am able to run the SPI at 45MHz at 3v3 though, and it seems stable. 50MHz does NOT work.

Here are my connections for using the internal 2.5V reference. It is especially important to note that the VrefL must be connected to ground even if using the internal reference:

1: VoutA
2: VoutB
3: VrefOut: 150nF to GND
4: AVdd: 3v3 + 100nF decoupling cap to GND
5: VrefL: GND
6: GND
7: VoutC
8: VoutD
9: !SYNC: SPI CS
10: SCLK: SCLK
11: Din: MOSI
12 IOVdd: 3v3
13: !RST: 3v3
14: RSTSEL: GND (binary input)
15: !ENABLE: GND
16: LDAC: GND or pin on MCU if doing hardware LDAC, this can also be done using a command.



Wednesday, July 6, 2022

Teensy 4.x SPI

I did some testing of the hardware SPI support yesterday, to try to get async send working.

I thought that async sends were not implemented since all posts were discussions about how hard it was to use DMA etc etc. Turns out I've misunderstood. 8bit-per-byte is fully supported using the callback version of SPI.transfer!  When saying that 16bit (and more) transfers were not supported, they mean that 16bits per byte (or sending strings of 16bit ints) is not supported.

I only discovered this after trying to understand what was done in the example from Garug in this post: https://forum.pjrc.com/threads/67247-Teensy-4-0-DMA-SPI/page2

I deleted everything special and it still worked. Here are some outputs:


My main loop output without any SPI sends running, to see what speed I can get without anything else interfering.



Normal "one byte per transfer", blocking SPI makes the main loop output grind to a halt

SPI transfer using callbacks. Main loop speed is almost the same as with no load :-D (Spi transfers 0x00 and 0xFF which is shown as the slow output on line 2



Changed to transferring 8bytes at a time, to measure the delay between transfers.


8 byte transfers but with changing speeds between 2 and 8MHz. There is not much overhead doing the switch.

Retriggering send from callback

This seems to work fine:


Moving the start/end transaction so that it only happens when we need a speed change saves us a little time between blocks:


We still get a 1.5uS "penalty" here, which amount to 96uS per 64 blocks sent. In this time period, it looks like the SPI actually blocks the main thread too. That's not good. I have to look for ways to increase the speed here, but we're using attachImmediate which supposedly is the fastest callback.

Things to look at:
- There is a lot to save by writing a custom version of

 bool SPIClass::transfer(const void *buf, void *retbuf, size_t count, EventResponderRef event_responder) {

(found on line 1199 in SPI.cpp), one that does not use an EventResponder callback and that skips a lot of the checking the library version does. 

The best thing would be to make a version that does not require an interrupt for every three bytes sent, which controls the chip select/sync pin by itself. 

Update:
I've managed to do async SPI with 24bit transfers and automatic CS switching. This probably means I can update all 4 channels of the DAC in one go, I just need to make it async. Since I was only sending 3 bytes, doing DMA transfers were costly and unnecessary.

As for Teensy 4.0 vs 4.1: The 4.1 has three CS pins connected to the default SPI port, meaning I can switch between them. 4.0 on the other hand has only one. BUT - If I can manage to turn OFF CS handling after writing to DAC, I can do DCO CS manually. I will only write one 24bit block to DCOs so I would have had to do config changes between sends anyway.

Also, I discovered that the Teensy 4.0 actually exposes all four SPI1 pins after all (MISO1 and CS1 as pin 0 and 1) so I can use any of the two ports for either slave or master functionality.

Update:

From top: SPI Clock, Data out, CS for fast moving data (50MHz), CS for slow data (4MHz, a few glitches that probably are just from the probes), Interrupt indication (yellow) and main loop indication (blue).

The image above shows that background SPI transfers are working as they should, with speed and CS switching. Main loop speed is 20MHz approx. 

Updating 4 DAC channels, including time spent in ISR, takes 3uS. Updating two DCOs take 13,7. In total, 61.7uS for 64 channels + 2 DCOs. 

The max update speed is thus 1 000 000 / 61.7 = 16.2kHz when the DAC bus runs at 50MHz. 

Reducing speed to 25MHz makes the total time 93,7uS and the throughput drops to 10.6kHz which is a bit too slow.

Moving the DCO updates to a separate bus would mean DAC transfers at 25MHz would take 80uS giving us a throughput of 12.5kHz. That would be sufficient. 

If we choose to upgrade to an 8 channel DAC running at 50MHz we would get a total of 53,7uS for a speed of 18.6kHz.

Monday, July 4, 2022

Teensy 4.x and communication

The voice controller card needs to communicate both with the master controller and with its peripherials.

Master controller should use the voice card as slave and needs a hardware SPI to do so properly. Hopefully, one master may control multiple voice cards simultaneously if we just buffer the SPI output.

The voice card controller needs to control these three:

The CV DAC

Currently, this is done in software, at 50MHz. This eats up a lot of clock cycles. Instead, we should look into using DMA backed SPI - that would let us send 24bit in the background without blocking the controller:

 https://forum.pjrc.com/threads/67247-Teensy-4-0-DMA-SPI

Update: 

Using SPI.transfer((void *)txBuffer, nullptr, 8, callbackHandlerFast); sends a whole buffer in the background and may be exactly what we need.

The DCOs

These are connected to the hardware SPI today, but runs at max 4MHz, which means moving them to software would block for even longer periods than the DACs. Not entirely sure what to do here, perhaps some timer based scheme, or perhaps we can change the SPI speed and use the same SPI as for DAC?

I should really look into SPI transactions for this.

https://forum.pjrc.com/threads/57754-Teensy-4-0-SPI-Clock-Speed

Update: 

Switching transfer speed is painless and costs next to nothing. Using 

SPI.beginTransaction(fastSettings);

where fastSettings sets speed etc: 

SPISettings     fastSettings(8000000, MSBFIRST, SPI_MODE0);

This means that DAC and DCOs can share SPI bus.

Port expanders

Right now I use SPI for this, but I will move these to PCA95xx, I2C chips. We don't need high speed here so freeing up SPI from this task is good. Port expander changes will always (?) be on-demand so it doesn't matter that much if they block for a tiny amount of time.

Audio daughterboard

I have yet to try this, but it runs from a combo of I2S and I2C. Both are available and there is a separate I2C that can be used if I don't want to combine it with the port expanders even though the bus is just that, a bus.

Hardware

My current voice card uses a Teensy 4.1. It has SPI (SPI0) and SPI1 exposed as pins, and two I2C-busses readily available. SPI2 is used for SD card and memory on the teensy itself. I may be able to solder stuff directly to the pads but not sure how easy it will be to use them. 

The Teensy 4.0 only exposes SPI (0) as a pin, but adding SPI1 is not too hard. SPI2 is also available but requires soldering wires. It can be done but I would prefer not to.

Going with the Teensy 4.0 would save significant physical space on the voice card, and it is also about 50% cheaper than the 4.1 (with ethernet). I would however lose the posibility of using on board PSRAM and extra flash memory which MAY be nice if using an audio daughterboard?


Friday, July 1, 2022

Fatar Keybeds - where to buy

 So, I already have two fatar keybeds for my DIY projects, one 4 octaves and one 5, both bought from Doepfer. Unfortunately, none of them have aftertouch which I feel is a need for my big polyphonic - not because I will be able to utilise it myself, but since it feels weird building such a great big machine without it.

I did some googling yesterday and came across a few sources that may or may not be able to supply such a thing, more specifically a Fatar TP/9s 61keys keybed with aftertouch:

New Groove

https://www.newgroove.it/acquista/produttore/fatar/

Italian site, has exactly what I need but not sure if they ship outside of EU. 

Synthtaste

https://www.synthtaste.com/en/shop

Sells a kit for the OB-Xa etc that may be used, but is very expensive. Perhaps it is possible to ask for a keybed only.

TechsMechs - Lars Erlandsson

https://techsmechsvintagesynth.com/products/tm-8-oberheim-ob-x-xa-8-keyboard-replacement-kit

Swedish tech that also sells an OB-Xa kit. I have emailed him asking for a keybed only, and whether or not the keybed comes with aftertouch. We'll see.


I found New Groove and TechsMechs through this post: https://modwiggler.com/forum/viewtopic.php?t=241329


Spares can be found here: https://www.synth-parts.com/en/products/keyboard/fatar-keyboards/?p=1