Hardware: Is a 12 bit ADC sufficient?

[corrados]

In theory, a 12 bit ADC should give a dynamic range of 12*6 = 72 dB. This should be enough to correctly capture a piezo trigger signal. Unfortunately, with the current simple Edrumulus hardware design, it seems that the Roland PD-80R mesh pad has such a high output level so that the recorded signal is clipped. Clipping should always be avoided since algorithms like the positional sensing will most probably not work correctly on a clipped signal.

Tests should be done to lower the signal level which reaches the ADC. But if we lower the signal level, it may be that the hits with very low velocity may not be detectable anymore. We also have to consider some ADC noise which can be in the order of 1-3 bits. If we assume 3 bits, our dynamic range shrinks to a theoretical 54 dB. Still a lot...

An analog compression might be a solution to improve the situation. But this non-linearity may have an influence on the digital signal processing. So, maybe the non-linearity has to be compensated for in the digital domain.

[jstma]

According to the datasheet, the adc has 10.1 effective bits. That's roughly 60dB useful dynamic range. But this datasheet is rather light on details.

Another thing to keep in mind is that midi velocity is limited to 127 which is only 42dB of expression. Which means we need to map the drum head hits in a logarithmic manner. Having compression on the input of the adc could be one way to do that. And I think we need to keep the sensitivity high for low velocity hits.

Based on the waveform you recorded I see two things:

1. the impact
2. the drum head rebound

The impact is 'negative going' and well within the range of the adc. The rebound, however, is clipped. And I'm not sure we can guarantee capturing the rebound of every type of mesh head even with 16-bits of resolution.

Three solutions come to mind:

1. ignore the clipped part of the wave form (ie. improve positional sensing)
2. place something heavy on the drum head so that rebound is reduced.
3. analog compression on the front end.

[jstma]

Why should the audio recorder make a difference? They may adjust the normalization but they would not filter or calculate a noise reduction until you do not configure it manually.

I have no idea. That's just what I observed. And I don't trust pulse audio at all.

Keep in mind that what I am saying is that audacity when recording through pulse audio had a HIGHER noise floor than recording directly through alsa. I'll need to do some more experiments to confirm that, but it could have something to do with audacity recording a stereo wav form rather than mono. Alsa records mono directly.

Also I have no idea if pulse is recoding at 8kHz then resampling to 44.1kHz for it's internal bus, and then resampling to 8kHz again for output to Audacity.

The signal I recorded seems to be normalized to 2^15. If I correct for the normalization and plot the data, I get correct peak values at around +-2048. So, the following code should give the correct result:

Wait a second.

Firstly, the data in the wav container is not normalized to anything. All we did was take a 12 bit number and stuff it into a signed 16 bit container.

Secondly, the adc is giving out values of 4000+ which means the wav container scaling is 1:1. I saw that printed from the serial port.

Thirdly, 2^12 = 4096. So theoretically, the DAC should output 12 bits and it does.

Why do you keep throwing the number 2048 around? Am I missing something?

x=audioread('teensy4_0_noise_test.wav');x = x-mean(x);x = x * 32768;10 * log10(var(x(400000:end, 1))/(2048^2))

which is: -59.22

And was recorded with audacity? With pulse too?

[corrados]

Thirdly, 2^12 = 4096. So theoretically, the DAC should output 12 bits and it does. Why do you keep throwing the number 2048 around? Am I missing something?

We use a bias voltage for the input and therefore the maximum amplitude we can get is just half the range of the ADC which is 4096/2 = 2048.

[corrados]

Firstly, the data in the wav container is not normalized to anything. All we did was take a 12 bit number and stuff it into a signed 16 bit container. Secondly, the adc is giving out values of 4000+ which means the wav container scaling is 1:1. I saw that printed from the serial port.

First, I did x = x-mean(x) which means I now get a signal from -[max amplitude] to +[max amplitude]. Then I plotted the x and looked what the maximum value of the clipped peak is. Then I tried out the factor 2^15 and then the clipped peak was at +-2048. So, I concluded that this is the correct factor.

[corrados]

BTW, the dynamic we can use for Edrumulus is even much worse. We cannot use the average power of the noise but we have to define a threshold power. If the signal is above that threshold, we declare it as a valid stick hit to the pad. As a result, we have to consider the peaks of the noise, not the average. So, we actually have to calculate:

x=audioread('teensy4_0_noise_test.wav');x = x-mean(x);x = x * 32768;20 * log10(max(abs(x(400000:end, 1)))/2048)

Which is approx. -44 dB. So we have 15 dB less dynamic, actually.

[corrados]

BTW 2, note that the maximum noise amplitude value highly depending on the current interference situation. Do not take the -44 dB too seriously. If I switch on the lights, I could get much higher noise peak values.

[jstma]

Okay we're talking about two different things.

I'm trying to see if the adc meets it's own spec.
You're trying to see if the adc meets edrumulus' needs.

I think the adc meets it's own spec so there's not much more to say about that.

You make a good point about the threshold power. I measure a similar difference:

 x=audioread('teensy4_0_gnd_test_x8_8pads.wav');

20*log10(max(x)/mean(x))
ans =  15.543

I don't think 44dB is enough dynamic range.

eDRUMin seems to work fine. Though he's using a Teensy 3.x of some kinda. With the 3.2 he could have 16-bit adc with pga giving 13 ENOB instead 10 and the ability to maximize the dynamic range with the pga.

[corrados]

eXadrums is using an external ADC and does all the processing on the Raspberry Pi. Edrumulus uses a microcontroller with an integrated ADC and does everything on the microcontroller. If you propose to use a Teensy 3.x, I assume that you do not have enough hourse power to do all the necessary calculations on the Teensy. So, a third option is needed (similar to what eDRUMin does): Use the microcontroller with its integrated ADC and just capture the multichannel audio as it would be an external sound card. The actually signal processing can then be done on a Raspberry Pi or any other regular PC.

[jstma]

It doesn't seem as though the teensy 4 adc is up to the task. Unless there was some sort of "super resolution" algorithm we can run given the nature of the noise and the nature of the signal. I've never had any success doing that.

The other option would be analog compression and make that 100K resistor something like 1M.

eXaDrums is using MCP3008 (I think) which is only 10-bit and at 10kHz sampling rate.

eDRUMin sends midi out over usb so certainly all the processing is done on whatever processor he's using. If he's using 2 microcontrollers and the teensy 3.2 strictly for the adcs, that's not a bad option either. It's only $20 and plugs right in with header pins. I'd need to take a hard look at that adc before going that route though. The point is that 16-bit adc is much much better than 12-bit adc.

The plan has always been to use a microcontroller for this job. Either using onboard adc or using external adc. So nothing's changed.

[jstma]

I did some research on adc inputs. Found this document

Seems like an op-amp is necessary. And I'll bring up this thread again with appropriate quoting:

 The design I have now is simple and it's works okay, but there's not a whole lot of information
 I pull out the data because it's so noisy and I've missing half the signal. 
...
I've basically turned a Teensy 3.2 into a digital scope and I send transient data to an application
I coded and display the waveform on my screen. Here's a sample of a transient from a mesh drum pad.
The signal is sampled every 50 microseconds.
...
You need to be reading each piezo at least 5 times / millisecond. I currently manage about
9 times / millisecond on eDRUMin devices.

So it seems he had a noisy signal and cleaned it up by buffering the piezo. In reality, he's likely driving the adc input properly now.

I don't see how that's going to change the 15dB noise peaks when I have the adc input directly connected to ground, but maybe that case doesn't really matter. The adc needs to be biased to read positive and negative swings and then an opamp circuit might improve the noisy input.

BTW the latency of eDRUMin is supposedly 3ms according to the FAQ:

How much latency is there?
It takes about 3ms for USB MIDI data to enter into a DAW. The total latency you can expect
will be 3ms plus the output latency of your audio hardware.

[jstma]

I think in order to evaluate if the noise performance changes if an opamp is added, we can test it with a simple voltage divider as long as we adhere to the 'rules' in that "Precision Applications Seminar". To do that we'll work from this drawing:

And we will attempt to solve for Ras and Cas.

I've been looking over the teensy 4 datasheet. Assuming 16 channels at 8kHz we're looking at 7812ns or less adc time. Assuming no averaging. With 8x hardware averaging it becomes 976ns or less.

Here I'm calling adc time = (Csamp + Cconv)/fadc. Csamp and Cconv are paired, 8 options total. fadc can be 20, 30, or 40 MHz.
The smallest interval for (Csamp+Cconv) is 30 clocks and the longest is 74 clocks. Which yields the following ranges:

(Csamp+Cconv)        20M     30M     40M
 (2+28) = 30        1500    1000     750  (ns)
(24+50) = 74        3700    2500    1850  (ns)

If the target is 976ns then the 30MHz clock won't work. Though with a 1000ns adc time, you arrive at 7.8125KHz which is probably fine.

From the datasheet, Cadin = 2pF. Now

Cas = 20*Cadin
For 12 bit accuracy, 9 time constants are required minimum but 13 time constants are recommended.
Ras = tsamp / (13*Cas*fadc)

Cas = 40pF (we'll round up to 47pF)
tsamp = Csamp/Fadc = 2/30MHz 
Ras = 2/(13*47pF*30MHz) = 109 ohms (round to 110 ohms)

The circuit to test for peak noise would then be a voltage divider made from two 110 ohm resistors and a 47pF cap. If we put two 110 ohm in series that's 220 ohms on 3.3V is 15mA. Hopefully the teensy can do that for at least 1 input.

I don't have parts to test this today, but if the peak noise goes down with the proposed circuit then we know why the noise is so high and what we need to do to fix it.

It's worth noting that if we turn off averaging we get a longer sampling time which will allow a larger resistance. We'd have the option of 20MHz clock and Csamp of 24 clocks making Ras = 24/(1347pF20MHz) = 1963 ohms. The noise spikes should come down, but rms noise will go up.

Step 1 is to see if anything changes at all.

[corrados]

a voltage divider made from two 110 ohm resistors and a 47pF cap

Wow, 47 pF is very small. Do you think this small capacitor will do any observable difference? Would be interesting to know.

It's worth noting that if we turn off averaging we get a longer sampling time which will allow a larger resistance. [...] The noise spikes should come down, but rms noise will go up.

You should definitely try that out. What I did to get to my hardware design was to define that the serial resistor should be as large as possible because of the piezos but small enough to detect the rim switch. 100 kOhms seemed to be a good compromise. Then I tried out different voltage divider resistors until the pad with the hottest signal could be captured without too much clipping (as we have found out recently, for the PD-80R the design seems not to be optimal). That yield the two 22 kOhms resistors. Then, as a next step, I tweaked the ADC parameters assuming the hardware design is fix.

If you now optimize the hardware design and ADC parameters together, you might find a better overall sweet spot.

[jstma]

a voltage divider made from two 110 ohm resistors and a 47pF cap

Wow, 47 pF is very small. Do you think this small capacitor will do any observable difference? Would be interesting to know.

Indeed. The capacitance inside the ADC is quite small (only 2pF). I have no idea if it will work, but TI knows their stuff. Assuming I didn't make any mistakes that is ;p

It's worth noting that if we turn off averaging we get a longer sampling time which will allow a larger resistance. [...] The noise spikes should come down, but rms noise will go up.

You should definitely try that out. What I did to get to my hardware design was to define that the serial resistor should be as large as possible because of the piezos but small enough to detect the rim switch. 100 kOhms seemed to be a good compromise. Then I tried out different voltage divider resistors until the pad with the hottest signal could be captured without too much clipping (as we have found out recently, for the PD-80R the design seems not to be optimal). That yield the two 22 kOhms resistors. Then, as a next step, I tweaked the ADC parameters assuming the hardware design is fix.

About the bias resistors (the 22k resistors). Did making those resistors smaller reduce the piezo voltage? Making them larger increased the piezo voltage? If so, then they are just part of the piezo load and it makes sense. If not, then it would be good to understand it.

If you now optimize the hardware design and ADC parameters together, you might find a better overall sweet spot.

It's not so much about optimizing the design. We've got a noise problem. If the noise is from the input then we can fix it. If the noise is from the teensy layout or power supplies, then it's not fixable. I hope it's something we can fix. Losing 15dB of dynamic range due to noise peaks is pretty lousy. If we can even get 6dB back it would be an improvement.

[corrados]

About the bias resistors (the 22k resistors). Did making those resistors smaller reduce the piezo voltage?

Yes, they did. The 100 kOhms resistor and 22 kOhms resistor are basically a voltage divider.

[jstma]

This test uses 22k bias resistors. I just wanted to get a feel for what all the options were.

There are a few clocks available on Teensy 4.

ADC_CONVERSION_SPEED::LOW_SPEED: 20MHz
ADC_CONVERSION_SPEED::MED_SPEED:  30MHz
ADC_CONVERSION_SPEED::HIGH_SPEED:  40MHz
ADC_CONVERSION_SPEED::ADACK_10:  10MHZ async
ADC_CONVERSION_SPEED::ADACK_20:  20MHz async

And sample times.

                                        time per sample (ns)
ADC_SAMPLING_SPEED Csamp Cconv Sum  10MHz  20MHz  30MHz  40MHz
VERY_LOW_SPEED       24   50    74   7400   3700   2466   1850
LOW_SPEED            20   46    66   6600   3300   2200   1650
LOW_MED_SPEED        16   42    58   5800   2900   1933   1450
MED_SPEED            12   38    50   5000   2500   1667   1250
MED_HIGH_SPEED        8   34    42   4200   2100   1400   1050
HIGH_SPEED            6   32    38   3800   1900   1267    950
HIGH_VERY_HIGH_SPEED  4   30    34   3400   1700   1134    850
VERY_HIGH_SPEED       2   28    30   3000   1500   1000    750

There are 2 adc's so it should be possible to MUX 8 channels on each adc for 16 channels. Or 4 channels on each adc for 8 channels.
These are the required sample times including hardware averaging:

                         1ch       4ch       8ch
8kHz sample rate  1x = 125000 ns  31250 ns  15625 ns
                  4x =  31000 nS   7750 ns   3875 ns
                  8x =  15000 nS   3750 ns   1875 ns
                 16x =   7800 nS   1950 ns    975 ns
                 32x =   3900 nS    975 ns    487 ns

Based on these numbers we have a limited choice of "time per sample" with different hardware averaging.

32x with 8 channels (487 ns) is not possible.

16x with 8 channels (975 ns) or 32x with 4 channels (975 ns) is possible with
ADC_CONVERSION_SPEED::HIGH_SPEED (40MHz)
ADC_SAMPLING_SPEED:HIGH_SPEED (38 cycles)
at 950ns

8x with 8 channels (1875 ns)
ADC_CONVERSION_SPEED::LOW_SPEED (20MHz)
ADC_CONVERSION_SPEED::ADACK_20 (20MHz)
ADC_SAMPLING_SPEED:HIGH_VERY_HIGH_SPEED (34 cycles)
at 1700ns

AN5250 mentions that:

Design firmware to use minimum disturbance from microcontroller
during ADC conversion - digital silence.

Use of ADC internal asynchronous clock as ADC clock will greatly
reduce the digital noise coupled to the ADC.

If possible, let ADC convert samples in low power mode.

So let's test a single channel.

Recorded with:
arecord -D hw:2,0 -f S16_LE -r 8000 -c 1 -d 5 file.wav

ADC_SAMPLING_SPEED::VERY_LOW_SPEED (74)
ADC_CONVERSION_SPEED::ADACK_10

x = audioread('teensy4_0_bias_vls_adack10.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -76.112
20*log10(max(abs(x)))
ans = -55.241

ADC_SAMPLING_SPEED::VERY_HIGH_SPEED (30)
ADC_CONVERSION_SPEED::ADACK_10

x = audioread('teensy4_0_bias_vhs_adack10.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -85.472
20*log10(max(abs(x)))
ans = -64.768

ADC_CONVERSION_SPEED::HIGH_SPEED  (40MHz)
ADC_SAMPLING_SPEED:HIGH_SPEED (38 cycles)

x = audioread('teensy4_0_bias_hs_40MHz_16x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -96.280
20*log10(max(abs(x)))
ans = -80.853

x = audioread('teensy4_0_bias_hs_40MHz_32x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -98.535
20*log10(max(abs(x)))
ans = -81.152

ADC_SAMPLING_SPEED::VERY_HIGH_SPEED (30) [1]
ADC_CONVERSION_SPEED::LOW_SPEED (20MHz)

x = audioread('teensy4_0_bias_vhs_20MHz.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -87.593
20*log10(max(abs(x)))
ans = -64.483

x = audioread('teensy4_0_bias_vhs_20MHz_4x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -89.682
20*log10(max(abs(x)))
ans = -70.237

x = audioread('teensy4_0_bias_vhs_20MHz_8x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -91.945
20*log10(max(abs(x)))
ans = -77.396

x = audioread('teensy4_0_bias_vhs_20MHz_16x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -94.685
20*log10(max(abs(x)))
ans = -81.636

x = audioread('teensy4_0_bias_vhs_20MHz_32x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -98.567
20*log10(max(abs(x)))
ans = -84.051

ADC_SAMPLING_SPEED::VERY_HIGH_SPEED (30) [1]
ADC_CONVERSION_SPEED::ADACK_20

x = audioread('teensy4_0_bias_vhs_adack20.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -87.688
20*log10(max(abs(x)))
ans = -67.514

x = audioread('teensy4_0_bias_vhs_adack20_4x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -91.427
20*log10(max(abs(x)))
ans = -73.252

x = audioread('teensy4_0_bias_vhs_adack20_8x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -93.660
20*log10(max(abs(x)))
ans = -78.906

x = audioread('teensy4_0_bias_vhs_adack20_16x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -95.639
20*log10(max(abs(x)))
ans = -78.916

x = audioread('teensy4_0_bias_vhs_adack20_32x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -97.244
20*log10(max(abs(x)))
ans = -81.571


[1] Not quite ADC_SAMPLING_SPEED:HIGH_VERY_HIGH_SPEED (34 cycles)

[corrados]

What do you conclude from all these numbers?

[jstma]

Mostly I conclude that the adc is noisy.

There are a lot of configurations that give noise peaks at -81dB (not adjusted for 12 bit) with averaging. The best performance comes from: very high sampling rate, 20MHz clock, and 32x hardware averaging. It's maybe 3dB better which isn't enough and we can't do 32x anyway.

The async clock was quieter without averaging. Looking at the 20MHz LOW_SPEED clock, it was the same rms noise level, but 3dB more peak than ADACK_20. That trend continued until 16x sampling where the LOW_SPEED clock became the queiter by 3dB. I'm not sure what that means. It could be a mistake on my part.

More depressing is that I hooked up the 110R/47pF test and the results were:

x = audioread('teensy4_0_bias_100R_47pF_vhs_20MHz_32x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -91.619
20*log10(max(abs(x)))
ans = -77.525  (was -84.051)

x = audioread('teensy4_0_bias_100R_47pF_vhs_adack20_32x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -94.074
20*log10(max(abs(x)))
ans = -79.871 (was -81.571)

These peaks are actually noisier than the other resistor divider without a cap.

The settings currently used by edrumulus (high speed for both conversion and sampling, 8x average):

x = audioread('teensy4_0_bias_100R_47pF_hs_40MHz_8x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -87.530
20*log10(max(abs(x)))
ans = -72.645

Unfortunately I don't have an older measurement of that so it's hard to compare. I don't think it's any better.

We can compare the 16x sampling case though:

x = audioread('teensy4_0_bias_100R_47pF_hs_40MHz_16x.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -88.612 (was -96.280)
20*log10(max(abs(x)))
ans = -75.465  (was  -80.853)

As you can see the new bias configuration is significantly worse for both rms noise and peaks. The question is why?

It's possible that being on the breadboard is part of the problem here. Ground is very far away. If we can understand why it got worse, maybe we can get better by doing the opposite.

Actually, maybe the problem is noise on the 3v3. Lower bias resistors would allow higher noise current to pass by the adc pin. Maybe, I don't know if I'm talking nonsense here. Bedtime.

The recordings I made were only 5s long. I don't know if that's enough to capture the random peaks. It's 40000 samples though so should represent a good number.

[jstma]

It's probably using a simple LDO regulator (a linear regulator). I don't see enough parts on the board for a dc-dc either. Typically LDOs are not noisy. I'll have to find a teensy 4 schematic and do some investigation.

[corrados]

You are right, it's a LDO regulator (see, e.g., the schematic at the bottom of this page).

[jstma]

The teensy 4.x uses a TLV75733 which is a linear regulator. It REQUIRES a 1uF or greater input capacitor and a 0.47uF output capacitor
minimum and 200uF max for proper operation.

If you consider the screenshot:

the schematic has 3 problems:

1. the input capacitors are too small. There should be a 1uF capacitor RIGHT at the input pin. Instead there are two 0.22uF caps and a 2.2uF cap over at the usb input (too far away). The bigger the better here because it affects PSRR (power supply rejection).

2. there is significant output capacitance, but it should be RIGHT at the output pin. Looking at the layout those caps are too far away from the TLV75733 to be useful.

3. the adc input voltage appears to be connected directly to the 3.3V plane. There really should be a ferrite bead and capacitor right at the VDD_ADC pin.

Given what I've seen, the noise is likely coming into the adc through the power supply. Terrible design.

I would not have designed that linear regulator that way at all. I've seen lots of problems when the input/output capacitors aren't as close
to the IC as possible. Without a ferrite/cap on the ADC, there's no way to power the ADC with clean power. The datasheet for the cpu even recommends the ferrite (100R at 100MHz).

The teensy 3.2/3.5 appear to have the capacitors properly placed on the linear regulator. And the ADC power supply even has a ferrite/cap. Far better design!

The teensy 4.x has a terrible ADC circuit. You'll have to figure out a software solution if you can.

In the meantime, I'm going to research adcs to use the teensy 4.x with spi. That's the only real solution.

[corrados]

The teensy 3.2/3.5 appear to have the capacitors properly placed on the linear regulator. And the ADC power supply even has a ferrite/cap. Far better design!

What about the Teensy 3.6? According to the comparison, it is much faster than the 3.5. It seems to be overclockable , has 16 bits ADC and is maybe fast enough to run the trigger algorithms in real-time.

The teensy 4.x has a terrible ADC circuit. You'll have to figure out a software solution if you can.

Yes, this is what I already did with my software spike cancellation algorithm. BTW, the ESP32 is much much worse in this regard.

In the meantime, I'm going to research adcs to use the teensy 4.x with spi. That's the only real solution.

Really? If you use an external ADC via SPI, I would not use a microcontroller but a Raspberry Pi instead as eXadrum does.

The reason I chose a microcontroller was because it has a lot of ADC inputs and it is cheap :-).

[jstma]

The teensy 3.2/3.5 appear to have the capacitors properly placed on the linear regulator. And the ADC power supply even has a ferrite/cap. Far better design!

What about the Teensy 3.6? According to the comparison, it is much faster than the 3.5. It seems to be overclockable , has 16 bits ADC and is maybe fast enough to run the trigger algorithms in real-time.

Seems like 3.6 and 3.5 share the same schematic.

In the meantime, I'm going to research adcs to use the teensy 4.x with spi. That's the only real solution.

Really? If you use an external ADC via SPI, I would not use a microcontroller but a Raspberry Pi instead as eXadrum does.

Well I already have the teensy 4.x and an esp32. Ideally, the esp32 can be used via spi because then there's the option for ble midi and a web interface for config. And it's cheap.

Then any usb host can be used including an rpi.

The reason I chose a microcontroller was because it has a lot of ADC inputs and it is cheap :-).

Fair enough. Cheap doesn't always get the job done though.

[jstma]

Got my hands on a teensy 3.6 a couple days ago (never knew digikey had stock). Spent some time patching in usb audio recording to evaluate the adc. The teensy3 code is a little different (doesn't use usb2) and I broke the serial upgrade, but can still put code on it by pressing the button on the teensy.

I see some work has gone on to make things work for the teensy 3.6, but I haven't pulled any edrumulus code since October. My first and only priority is to measure the adc, so here's what I did:

adc_obj.adc0->setResolution      ( 16 ); 
adc_obj.adc0->setAveraging       ( 16 );
adc_obj.adc0->setConversionSpeed ( ADC_CONVERSION_SPEED::HIGH_SPEED_16BITS );
adc_obj.adc0->setSamplingSpeed   ( ADC_SAMPLING_SPEED::VERY_HIGH_SPEED );

adc_obj.adc1->setResolution      ( 16 ); 
adc_obj.adc1->setAveraging       ( 16 );
adc_obj.adc1->setConversionSpeed ( ADC_CONVERSION_SPEED::HIGH_SPEED_16BITS );
adc_obj.adc1->setSamplingSpeed   ( ADC_SAMPLING_SPEED::VERY_HIGH_SPEED );

I have no idea yet if those settings are adequate or not. At some point I will dig into it, but wanted to share some first results. Also, I subtract half the range before sending it out over usb and that is different than before. But it's more correct for the wav container.

uint16_t val = adc_obj.analogRead( A9 );
// a val of 0x8000 is half way between Vref and 0
val -= 0x8000;
write_audio_buf(val);

Finally, recordings are made with:

arecord -D hw:2,0 -f S16_LE -r 8000 -c 1 -d 90 file.wav

First I tested with the input pin (A9) connected to AGnd (pin 2).

x = audioread('teensy3_6_noise_test_agnd.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -136.09
20*log10(max(abs(x)))
ans = -90.309

Next, I tested with the input pin (A9) connected to 3.3V.

x = audioread('teensy3_6_noise_test_3v3.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -Inf
20*log10(max(abs(x)))
ans = -Inf

Not sure that's a meaningful test, but all the noise must be generating voltages beyond the maximum value?

Then I tested with 110k ohm resistors connected from A9 to both 3v3 and AGnd forming a voltage divider.

x = audioread('teensy3_6_noise_test_rdiv.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -85.869
20*log10(max(abs(x)))
ans = -67.632

Then I connected a wire from AGnd to a piezo.

x = audioread('teensy3_6_noise_test_rdiv_piezo_gnd.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -79.496
20*log10(max(abs(x)))
ans = -58.896

Then I connected the other end of the piezo to A9.

x = audioread('teensy3_6_noise_test_rdiv_piezo.wav');
x -= mean(x);
10*log10(meansq(x))
ans = -75.562
20*log10(max(abs(x)))
ans = -57.303

The noise increases considerably just by adding a wire to AGnd. That's not too suprising given the fact that this is on a breadboard with a long wire. Adding the rest of the piezo circuit didn't really change the peaks, but the noise floor came up 6dB.

Going back to your recording on teensy 4 with piezo connected:

x = audioread('teensy4_0_noise_test.wav');
x=x(40000:end);
x-=mean(x);
10*log10(meansq(x))
ans = -83.269
octave:126> 20*log10(max(abs(x)))
ans = -67.471

At first glance the teensy 3.6 seems worse than the teensy 4. However, the teensy 4 is 12-bit in a 16-bit container. Meaning the max possible level for 12-bit is actually -18dB not 0. So the effective range is -18 - -67 = 49 dB for the teensy 4 vs 57 dB for the teensy 3.6.

Looks promising. I'll need to do some more tests looking at the conversion time. Though there are 22 adc available and to use them all, conversions will need to be complete in less than 5.68 uS.

[corrados]

I bought a Yamaha DTX Multi12 [...] My KT10 pedal also didn't work well [...] I was able to adjust the threshold and curves to get a usable result, but there's a serious loss of dynamics. And this was the same experience I had with edrumulus

I have kicked around the idea of building some active circuits (that require power) to address these issues.

Teensy 3.6, 22k resistors, and a KT10 kick trigger. The peak level from the piezo was significantly lower than full scale.

I could take a recording of some kind for you. As long

After reading your posts again, I think it is not necessary to record data. I now think that your KT-10 must be defect in some way. I was searching for "KT-10 compatibility" in Google and in all posts I found, they claim that the KT-10 has a very good compatibility to all sorts of drum modules. And they use the KT-10 without an amplifier on a normal trigger input.

The ultimate test would be to borrow another KT-10 and compare it to yours.

[jstma]

The ultimate test would be to borrow another KT-10 and compare it to yours.

As it turns out, I have two. They both behave the same. Both were purchased at the same time. Both were new in boxes that hadn't been opened. I find it hard to believe they are both defective.

I will refer you to the user guide for clues, but it says:

In order to take full advantage of the KT-10’s capabilities, adjust the sound module’s Sensitivity (PAD SENS)” and “Threshold” values to approximately 10. For details on how to make these settings, refer to the owner’s manual of your sound module.

I have no idea what those settings do for Roland equipment. Do they mean anything to you?

They also have connection guides to a few different Roland devices, where they set the device type to KD-120, but don't give further details on configuration.

If you’re using KT-10 pedals for double kick drums, the output level will be lower than when only one is used. Adjust the trigger parameter of your sound module.

I use one for auxilliary percussion, like cowbell. I don't use it for double bass, but I daisychained both to my M12 and yes the level is markedly lower; it's unplayable.

[corrados]

As it turns out, I have two. They both behave the same.

Wow, that is very unexpected.

I have no idea what those settings do for Roland equipment. Do they mean anything to you?

On my Roland TD-27, if I adjust the threshold, it seems to lower MIDI values are no longer used. They seem to be "masked out". The Threshold ranges from 1 to 31 and the Sensitivity from 1 to 32. A value of 10 for the Sensitivity sounds to me like a pretty high value, assuming that a value of 1 uses the complete dynamic of the ADC and a value of 31 has no dynamic at all.

I remember changing the resistors from 22K to something else (100K, 1M, I don't recall) and it got better, but I still had to stomp on the pedal rather hard to get good peaks.

This is so weird... Maybe I have the possibility to borrow one KT-10 from a colleague of mine but he is off the office for some time so, this will take some time. But I am really interested to test this kick pad with my current Edrumulus prototype.

[jstma]

On my dtx m12, the settings I have are:

KU100 kick pad type
gain: 65 (out of 127)

So the KT-10 needs half of the available gain. But what the real values means is up for debate. If they have a sufficiently low noise floor than it may just be digital gain.

I don't know if this helps you, but the trigger screen for the m12 sets things up a little different than Roland I think. There is a gain that is applied, (0 to 127) then you can apply a curve. You can also set velocity and level minimum (0) and maximum (127).

It's hard to see, but this is the only screenshot I could find online. I made it larger and augmented it with some text (in red):

The velocity curves are soft2, soft1, linear, hard1, and hard2. The one selected is hard2.

I guess Level Min is equivalent to a threshold.

[corrados]

Thank you for the additional information. I think the easiest way to debug the issue is that I borrow the KT-10 and try it out myself.

@corrados, If you have specific questions, I'm happy to help.

I have created this new forum thread where I want to discuss the hardware design of the new prototype. It would be nice if you could comment on my design in that forum.