Prototype 5 (advanced Raspberry Pi hat PCB)

[corrados]

Vision

The vision of Edrumulus prototype 5 is to develop a complete open hardware/open source e-drum module which works without the need of installing any development software like the Adruino IDE to flash the ESP32.

Hardware Milestones

• Create the schematics and PCB.
• Order the PCBs and parts.
• Solder the all parts.
• Verify the flashing of the ESP32.

Hardware

The base hardware is a Raspberry Pi 4 (8 GB) which runs Drumgizmo and a script to drive an LCD display and manages some hardware buttons. For the audio output, either a HifiBerry or similar hat can be used or an external USB audio card. On top of that, the Edrumulus hat is stacked. To be able to stack the display/button hat on top of that, no ESP32 developer board is used but a ESP32-WROOM-32UE component and also an angled DB25 trigger connector.

A separate 3.3 V power supply and some more capacitors shall be used to isolate the voltage dividers for the ADCs bias from the noisy ESP32 3.3 V branch. This is to reduce the ADC noise and spikes of the ESP32.

Maybe hard wire some (maybe three) ESP32 GPIO ports to a defined high/low sequence to be able to identify the prototype in the Edrumulus firmware.

Recommendations for the hardware design:

• Use 0603 instead of 1206 component size.
• Use 4 layers instead of just 2. Arrange things so that the analog power and ground planes are separate from digital power and ground planes. They should only be connected at one point (ie. at the esp32). Optionally, put ground on the top and bottom layers and keep your signal layers all internal (will require stitching caps and might require more layers).
• Use better placement of the ESP32, orienting the esp32 adc pins close to where they need to go. Prioritize the adc path which should ease the layout.
• Orient the DB25 so that the signal pins are not facing the esp32. The ground pins now attach to an internal ground layer that doesn't have any breaks in it. Shrink the pads on all layers except the bottom (where it's soldered) to the minimum annular ring allowed by the board vendor to have room to route the traces between the connector pins.
• Place the two bias resistors on alternate sides of the board close to the ADC pins. GND and 3.3V shall be very close to the bias resistors.
• Use anti-aliasing filter for each adc input, i.e., use a capacitor in parallel to the lower bias resistor (we need a capacitor right on the adc pin). Place the bias cap close to the top bias resistor. The size of that cap depends on the application. With 22k bias resistors, the required cap is 2.2nF which gives a corner frequency of about 8kHz.
• The 100k doesn't need to be close to the bias resistors (and the ESP32) but should have a short trace to the connector to avoid having an antenna.
• Regarding caps for voltage regulators, follow the datasheets. Do not use electrolytic or tantalum for the large caps but ceramic or X7R, or NP0/C0G material. Add voltage ratings on the caps (e.g., 6.3V cap used at 5V probably has half of it's nominal capacitance). Not use a smaller capacitor than 0603 and use 50V caps.
• Replace the Schottky diodes by normal diodes.
• Add ferrite beads (net tie) at the inputs and outputs of the regulators for the ability of added filtering.
• Do not interrupt the ground plane with traces (must be continous to form a low impedance path for high frequency signals).
• Use a good common mode choke on power and ground in to the board to avoid hum (either opto-isolate the pins connected to the pi or common mode choke on every signal/ground pair from the DB25). Is this a must have or can we start without it? -> To be discussed.

Software

A Python script shall manage the LCD and hardware buttons. It shall also automatically flash the ESP32 module with the current Edrumulus firmware via UART serial communication.

If possible, an iso image for an SD card shall be generated which has the Python script, the Drumgizmo software, some Drumgizmo drum kits and the ESP32 firmware included so that a user of this prototype simply flashes that iso image on his SD card, plugs it in the Raspberry Pi and everything is automatically set up.

Challenges

• A power supply for the ESP32-WROOM-32UE must be developed. Maybe try to reduce the 3.3 V noise as much as possible to further reduce the ADC noise. The separate power supply for the ADC bias must have very low noise. Since the current drawn by the network is low, it should be fairly easy to fulfill this task.

• The ESP32-WROOM-32UE needs to be flashed via UART by using a defined GPIO high/low sequence. The idea is to connect these ESP32 GPIOs to some Raspberry Pi GPIOs so that the Python script is able to control the flashing correctly using the Espressif flash tool and a firmware binary generated from an official Edrumulus release.

• We want to support two more trigger inputs compared to the previous prototype 4. This together with the additional capacitors will make it challenging to place and route all components on the PCB. To make it easier, both sides of the PCB shall be used to place components and the component size shall be smaller.

Remote debugging

Since there is no USB connection to the ESP32 anymore, we need a way to stream the debug outputs from the Raspberry Pi to a remote Linux PC. This is one possibility:

• On the Raspberry Pi:

  • stty 115200 -F /dev/serial0

• On the remote Linux:

  • ssh -t -t pi@[IP address] tail -f /dev/serial0 > test.txt
  • End transmission with Ctrl+c after a while
  • Open Octave and run: x=load('test.txt','-ascii');figure;plot(x)
  • Here is how it looks like:
    

[corrados]

Here is an early 3D model of the Edrumulus hat:

[corrados]

To be able to flash the ESP32 WROOM module, I want to use the Raspberry Pi GPIO outputs to control the strapping pins:

The 10 k resistors are to make sure the pins are set to the correct level for normal operation (enable low, boot high). The enable will be set to high in the Python script which is running on the Raspberry Pi after boot up of the Pi.

When flashing, the Raspberry Pi reboots the ESP32 while setting ESP-GPIO0 to low (entering flash mode).

Do you think this will work? Any comments?

[corrados]

Additional info: The Raspberry Pi GPIO ports 9 and 4 are chosen since 9 is default LOW and 4 is default HIGH when the Pi boots up. The Pi GPIOs 2, 3, 5, 6, 16 and 18-21 should not be used because they are used by the HifiBerry boards.

[corrados]

Here is the newest definition for the GPIO port usage of the Raspberry Pi:

2    reserved (HifiBerry)
3    reserved (HifiBerry)
4    Edrumulus
17   LCD Takt (E)
18   reserved (HifiBerry)
27   LCD Register (RS)
22   LCD Daten 4 (D4)
23   LCD Daten 5 (D5)
24   LCD Daten 6 (D6)
10   LCD Daten 7 (D7)
9    Edrumulus
25   Button 1
11   Button 2
8    Button 3
7    Button 4
5    reserved (HifiBerry)
6    reserved (HifiBerry)
12   Button 5
13   Button 6
19   reserved (HifiBerry)
16   reserved (HifiBerry)
26
20   reserved (HifiBerry)
21   reserved (HifiBerry)

[thijstriemstra]

Do you think this will work? Any comments?
use the Raspberry Pi GPIO outputs to control the strapping pins

It think that'll work but I'd rather keep the pin connections between rpi and esp32 to a minimum to reduce any risk of noise, but perhaps they can be turned off completely after " the Raspberry Pi reboots the ESP32 while setting ESP-GPIO0 to low (entering flash mode)."

[corrados]

Thanks. Have you experience with flashing such units?

[thijstriemstra]

Thanks. Have you experience with flashing such units?

No (not yet).

[corrados]

For the ESP32 power supply I do not want to take any risk and use the same AMS1117 as the development boards typically use. For the low noise power supply for the ADC bias, I use the MCP1754S:

Since the ADC bias network only needs about 2 mA of current, we could additionally add a resistor in front of the regulator to create a low-pass filter with a low cut-off frequency. But I am not sure if that is required.

Any comments on that?

[jstma]

Do you have calipers, or a ruler that you can measure the thickness of the plastic with?

I made a picture of my prototype where you can see how much space we have available.

Right I see the problem. Consider the possible arrangements.

Option one is like your prototype, a male header strip is inserted from the bottom side and soldered on the top side. It looks like this (kinda, no monospace fonts it seems):

=========edrumulus pcb===========
hhhh  (2.5mm)
 p p
 p p
 p p

Where "h" is the plastic header I've been asking about and "p" are the pins.

Option two uses a "extension header" inserted from the top side and soldered on the bottom side:

hhhh
hhhh
hhhh
=========edrumulus pcb===========
 p p
 p p
 p p

Without the plastic header on the bottom side, the edrumulus pcb would sit 2.5mm closer. Of course, if you use the same size standoff in both cases, the edrumlus pcb will always be at the same height and I don't need to care about the height of parts that are shorter than 2.5mm.

Option three uses surface mount headers on both sides:

 hhhh
 hhhh
 hhhh
**    **
=========edrumulus pcb===========
**    **     (surface mount pins)
 hhhh  (2.5mm + smt pads)
  p p
  p p
  p p

Option four is similar to option 1, but uses a surface mount header:

=========edrumulus pcb===========
**    **     (surface mount pins)
 hhhh  (2.5mm + smt pads)
  p p
  p p
  p p

The smt pins add additional height. That might explain why I see different height standoffs available for the Rpi: 11mm and 16mm.

I looked at a few different fan hats and some use option two and some use option three.

I think I need to move the ESP32 away from J2 so that it can accommodate options one or three. In any case, as long as you buy standoffs that support option one, then I don't have to care about parts on the underside of the board as long as they are less than 2.5mm tall.

Or a usb sound card chip soldered to a pi hat. Provided usb is available on the 40 pin header.

As far as I know the Raspberry Pi header does not have USB.

Well it's a little uglier, but a short usb cable could work in the same enclosure. They make some neat FFC usb cables, like this:

https://www.aliexpress.com/item/1005002442780622.html

This hat could also be used in it's own enclosure. Would use a codec like the CM6400. It's available on aliexpress.

Galvanically isolated from power and inputs/outputs. Balanced inputs/outputs. It would be immune to hum. I like the idea. Not cheap though.

Could turn this into a simple "isolated usb adapter". Then used with isolation transformers like this, you could get the same performance. It's hard to find a good one, but they are available so may not need to make one.

If you use a low common mode power supply AND isolation transformers to any connect audio inputs that should handle most cases of hum. However, if there is common mode coming in from the unbalanced piezo wiring (say from fluorescent lights), then the only fix will be to additionally galvanically isolate the usb sound card.

Anyway, it might be worthwhile putting this information somewhere easy to find if you have to deal with hum problems.

[corrados]

The prototype you can see in my picture actually uses an "extension header" but I have cut to male pins on the top because I could not use them with this prototype anyway because there is the ESP32 developer board in the way (which will not be the case with the new prototype 5 anymore). I insert the male header strip from the bottom side and solder it on the top side. Then I have the male header pins on the top side of the PCB and on the bottom side I have the female connector which is connected to the male header pins on the Raspberry Pi.
I need stacking headers or "extension headers" to be able to stack my display/button PCB on top of the Edrumulus PCB.

Would use a codec like the CM6400.

Yes, there are a lot of options to use any free space on the Edrumulus PCB. But I would actually not put an audio codec on it. I prefer to use an USB audio card or an additional stacking header like the HifiBerry board. Let's keep the Edrumulus PCB to implement it's core functionality and this is the triggering of the pads. Any additional components increase the complexity of soldering the PCB and also may increase the sources of noise which could be picked up by the trigger input traces. As you previously said, we first should try to get the very best ADC performance out of the ESP32. If we are happy with the performance, we can try to reduce the number of components or add other things like an audio codec. But I see these things as a next step, i.e., another different prototype which is based on this one. Do you agree with that?

[jstma]

The prototype you can see in my picture actually uses an "extension header" but I have cut to male pins on the top because I could not use them with this prototype anyway because there is the ESP32 developer board in the way (which will not be the case with the new prototype 5 anymore). I insert the male header strip from the bottom side and solder it on the top side. Then I have the male header pins on the top side of the PCB and on the bottom side I have the female connector which is connected to the male header pins on the Raspberry Pi. I need stacking headers or "extension headers" to be able to stack my display/button PCB on top of the Edrumulus PCB.

Do you have a link to the extension header?

It seems to me that the whole ecosystem would be designed around a common board to board distance. However, unless the through hole extension header accounts for the height of the surface mount header, different standoffs need to be used.

The key parameter here is the mating length of the extension header. This could allow you to raise the edrumulus board to deal with any component clearances. In the worst case. I'm chasing a good layout here and moving the regulator to the bottom side might help.

So with the right standoff, the board could plug in, but there will be a couple mm of the male header pins from the lower board showing. You might only need to add a couple of washers. So I'll assume that any part on the board (except for the esp32) is fair gaime for the bottom side.

Would use a codec like the CM6400.

But I see these things as a next step, i.e., another different prototype which is based on this one. Do you agree with that?

Yup. I was just talking out loud as it were ;) I think a usb sound card with a usb isolator and isolation transformers as I mentioned above would be a decent solution. Requires testing, of course, It's just bulky and doesn't fit in the same box. I think it would be good if you put that information somewhere easy to find.

Hum is the kind of problem that will bite you in the backside when you least expect it. You may build up an edrumlus board and at home there's no hint of hum. But then you take your kit somewhere to jam and suddenly you have hum that ruins your day.

I bought my son a squier "strat" guitar when he was learning to play. That guitar had awful hum connected to the crappy amp. So I bought a Roland Micro Cube thinking the hum would go away on batteries. It didn't. I stripped the guitar down to pieces and lined all the cavities with aluminum foil. This made the hum much much quieter, but it's still there. Unless you put the strat into position 4 (ie. humbucker mode) where the hum is completely gone.

What I don't understand is why amplifier manufacturers don't add a transformer to the input. It would be cheap for them to do it. With a simple switch, the transformer could be bypassed. Frustrating. Anyway, that's the end of my rant ;p

[corrados]

Do you have a link to the extension header?

RPI HEADER 40 (I have given that link already in my post above)
Since the data sheet does not give much data, I have shot some more pictures of it:

So with the right standoff, the board could plug in, but there will be a couple mm of the male header pins from the lower board showing. You might only need to add a couple of washers. So I'll assume that any part on the board (except for the esp32) is fair gaime for the bottom side.

This sounds totally reasonable. The question is how high these parts on the bottom side are? If we have electrolytic caps which are very high of coils, that may be a problem. SMD caps should not be a problem, especially if they are close to the header and not at the same location where the Raspberry Pi CPU is located (i.e. in the middle of the PCB).
BTW, from the attached picture you can see that the male header pins on the Raspberry Pi are quite short.

[corrados]

I just saw that there are longer stacking headers available. Unfortunately, this one does not allow a second hat to be stacked on top of the Edrumulus hat. But since there are longer headers available, I assume that you can find one which has extended length but also allow to stack another hat on top of it (i.e. the male pins on the other side of the PCB are longer than the one linked above).

[jstma]

I fixed my kicad libraries by uninstalling kicad, deleting all the kicad files under .config and .local, and then reinstalling kicad. Then it prompted me to copy the libraries. I guess it was picking up an old kicad 5 config or something.

Unfortunately the grid has changed in kicad. None of the grid settings are lining up with any of the component centres that I previously placed. Reverting to the repository version of the project hasn't fixed it. I'm surprised this isn't stored with the pcb file.

Can you tell me what your grid settings are? It's under View->Grid Properties.

What's strange is that even if I move through the different grid options, none of the component centres land on a grid. So maybe the grid origin is not right? If I set the grid to 0.250 in then the horizontal spacing looks right for the pi header. But the grid is not vertically centred in the holes.

Is your grid origin not 0?

What was the first thing you placed? I can make an educated guess, but I don't want to break anything.

Btw the holes at the four corners of the board are circles drawn on the board outline (edge cuts) layer. That is weird. Why not use a mounting hole?

[corrados]

On each gain change, I have to remix the entire drum kit. I did not want to do this for this quick video recording.

It sounds like you need to fix that...

Yes, it's already on my TODO list.

The ideal device would have a wifi interface for configuration, use ble midi to my phone, and be battery powered. That doesn't sound like edrumulus though...

Sounds exactly like Edrumulus to me :-). The ESP32 has bluetooth and I have already successfully tested BLE MIDI. You don't need Wifi since Edrumulus is entirely configured via MIDI. And the ESP32 is an IoT device which makes it perfectly suited for running on batteries.

[jstma]

The ESP32 has bluetooth and I have already successfully tested BLE MIDI. You don't need Wifi since Edrumulus is entirely configured via MIDI.

See, this is what I was alluding to. According to your link, bluetooth affected the adc. I mean it's the most common complaint about adc and esp32. I don't think shielding will fix that. And even though the traces are shielded by ground plane on prototype5, it's not something we can test with the integrated antenna version of the esp32 - I didn't allow for it to fit. But it might if I tried.

As for working as an IoT device, that board layout I just did isn't set up for that. And I don't really need so many inputs. 1/4" jacks would be preferred. I only need 2 zones (kick and snare) and maybe a hiihat controller if positional sensing on my practice pad could be used to fake a hihat pad. Still a small 3 zone + hihat would be useful for any micro kit. Would be fun to work on. If there were 4 stereo jacks total, you could get 6 zones plus hihat. There might be a way to split that hihat input into a zone + hihat too. And it could be small.

I have a handlful of these ESP32 D1 Mini boards and I have this battery [shield] (https://www.aliexpress.com/item/32850023830.html), and I even have a few small 600mAh lipo battery packs . All the pieces needed for a noisy prototype... I could spin a board to hold the jacks and the esp32 board + battery shield. Only use the quietest adc pins (assuming some are quieter). Hmm...

Are any of the adc pins less noisy with regards to bluetooth noise?

As for configuration over midi, that would truly suck on a phone. But I suppose I could use a laptop for initial configuration. What linux apps will work?

Aside from that, I couldn't find any ble midi apps for android. I did find this library which could be integrated into the right app. If there's something open source for android that I didn't see.

I'm unexpectedly excited about the idea for a small 3 zone + hihat battery powered ble device to 'electrify' my practice pad.

[corrados]

The ESP32 has bluetooth and I have already successfully tested BLE MIDI. You don't need Wifi since Edrumulus is entirely configured via MIDI.

See, this is what I was alluding to. According to your link, bluetooth affected the adc. I mean it's the most common complaint about adc and esp32. I don't think shielding will fix that. And even though the traces are shielded by ground plane on prototype5, it's not something we can test with the integrated antenna version of the esp32 - I didn't allow for it to fit. But it might if I tried.

I just did a quick test with BLE MIDI and unfortunately, it does not work anymore :-(. It crashes all the time. When I did the test with BLE MIDI a long time ago, I did not use all ESP32 CPU cores. Maybe this is the issue...

Are any of the adc pins less noisy with regards to bluetooth noise?

I haven't done a lot of tests back then. I just wanted to see if BLE MIDI would work and it did (sort of ;-) ).

I'm unexpectedly excited about the idea for a small 3 zone + hihat battery powered ble device to 'electrify' my practice pad.

Unfortunately, I can no longer recommend to do it. The current Edrumulus firmware is no longer compatible to BLE MIDI and to get it running again, I fear, a lot of changes to the software have to be done...

[jstma]

I just did a quick test with BLE MIDI and unfortunately, it does not work anymore :-(. It crashes all the time. When I did the test with BLE MIDI a long time ago, I did not use all ESP32 CPU cores. Maybe this is the issue...

Are you using both ADCs too? I know wifi needs ADC1, but I don't know if bluetooth does.

But do you need to use both cores for a smaller number of inputs? Even if you are using both cores, the work will be lower with fewer inputs.

Unfortunately, I can no longer recommend to do it. The current Edrumulus firmware is no longer compatible to BLE MIDI and to get it running again, I fear, a lot of changes to the software have to be done...

Well if I feel the urge, I'll take a look.

[corrados]

Are you using both ADCs too?

Yes, I do.

But do you need to use both cores for a smaller number of inputs? Even if you are using both cores, the work will be lower with fewer inputs.

Actually, it is just guessing that the usage of both cores are the cause of the crash. Maybe it is something completely different which is causing the crash.

[thijstriemstra]

What I'd really like to see is an I2C port (for an OLED display) and a rotary encoder with push button using a Schmitt trigger circuit (74HC14N), e.g:

This would make it possible to create a basic interface for the various Edrumulus parameters (which I'd happily work on and do a proof of concept in a pull request).

https://github.com/madhephaestus/ESP32Encoder is a very reliable rotary encoder library for this because it uses "the ESP32 pulse counter hardware peripheral".

Or is this something a separate esp32 device should be used for, due to processing power constraints etc

[corrados]

I was also thinking about a rotary encoder. But this would be attached to the Raspberry Pi and not the ESP32.

[corrados]

BTW, this is the new file a recently added for controlling the ESP32 from the Raspberry Pi. This Python script will support my front panel board I created as a Pi hat stacked on top of the Edrumulus hat. If all boards work as expected, I can then move my focus away from hardware development to the software development again.

[corrados]

It seems to be pretty easy to support a rotary encoder with a Python script, see this link.

[corrados]

This library also looks promising.

[corrados]

@jstma I want to support a prototype board identification which is based on GPIO states. That way the software can auto detect the type of prototype board it is running on and configuring the pad-to-GPIO assignments automatically. Therefore I need to make slight modifications to your prototype 5:

This is the current state:

I need to switch the LED GPIO from IO5 to IO21 and I need to connect IO 5, 18, 19, 22 and 23 to GND:

I have done the change to the schematics:
edrumulus.zip

I think I could also do the changes to the PCB layout but I do not want to destroy anything of what you have created. Could you assist me with that?

[corrados]

It's progressing again. I finally received the conductive glue:

[corrados]

@jstma, I have a very unexpected result. I have soldered only the very essential parts where I also did not solder the additional voltage regulator for the bias resistors but took the ESP32 3.3V instead. Here are the pictures of the PCB with which I have done my test:


As you can see, no caps other than the essential two 22u for the voltage regulator are installed. Only the resistors. Here is the result of the ADC capture:

As you can see, it looks almost perfect. No spikes, just little noise (similar to the previous prototype 5 PCB I soldered with all parts).
Do you have an explanation for that behavior? It seems all the other parts are not necessary when using your PCB design...

[jstma]

Well I just followed best practices for pcb layout. The digital and analogue grounds are somewhat separate. The traces are short where they need to be. The traces are buried between ground planes. That doesn't explain the results though.

The esp32 board has a ground plane. That pad is exposed on the bottom, but it also connects at 3 pins on the esp32 board. Only 2 of those three pins are connected, plus the exposed pad in this case (though it may not be required).

The current path right now goes through the esp32 to the ground underneath the esp32. The bias resistors also go to the same place before joining the digital ground (ie. the rpi ground) at the two esp32 ground pins. The thought was to provide a path for the digital currents that doesn't affect the adc current.

I think you should put the DB25 connector on this board as is, load edrumulus, and play. See if it works as good as the previous protoype 5.

[corrados]

The largest peaks I have always seen with prototypes which use the ESP32 developer board. And these are powered by the USB cable which also does the MIDI signal transport. And on the developer board there is a USB-to-serial converter which may have an influence. Maybe these two things introduce a lot of the spices.
Prototype 5 is the first prototype which uses the pure ESP32 WROOM unit. Maybe this is the main reason why prototype 5 is so much better than the others.

I think you should put the DB25 connector on this board as is, load edrumulus, and play. See if it works as good as the previous protoype 5.

Since I have all the parts anyway, I'll solder them on the board. I don't think these will make the performance worse but they may suppress some very rare electrical interference which is desired.

[jstma]

Well it's a good sign that the esp32 modules perform better. Perhaps it's worth investigating another prototype with these bare esp32 modules. We can filter the crap out of the power coming in from the PC over usb.

Noise spikes from the usb power if connected to a PC is certainly plausible. You should see them with an oscilloscope. Every PC will be different too.

I mentioned before that there is less than ideal routing on the demo boards I have (D1 Mini). So it could be a combination of things.

[jstma]

@corrados I'm wondering how you've made out with the prototypes, in general. Are you using Prototype 5 at all?

I was also thinking about the ESP32-S3. I saw it mentioned in another discussion. This has a bluetooth radio and it would be good to know if Prototype 5 was quiet because it omitted the bluetooth antenna.

[corrados]

I mostly use Prototype 4 for development because it directly connects to the PC via USB. I have two Prototypes 5 (one with Raspi 3B+ and one with Raspi 4, 8 GB). These two, I only use seldom, actually.