Duppa I2C MIDI Controller – Part 3

This is a follow up post to Part 2 expanding on the code and adding in some of the alternative control options I mentioned.

• Part 1 – getting to know the devices and testing them out.
• Part 2 – adding MIDI to the LED ring and I2C encoder.
• Part 3 – adding normal encoder, plain potentiometer, and endless potentiometer control.
• Part 4 – revisits the idea with Waveshare Zero format devices and adds USB MIDI.

https://makertube.net/w/ncLFMqBwCUcrrM4r3mHJwd

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

Parts list

• Arduino Uno/Nano.
• DuPPa small RGB LED Ring.
• 10K potentiometer.
• KY-040 rotary encoder module.
• Bespoke hook-up wires (available from duppa.net).
• Breadboard and jumper wires.

The Circuit

This circuit shows all three control options on the same diagram, but naturally use whichever one you require. There are the following three options:

• Duppa I2C Encoder (from the previous project) on A4, A5 (SDA, SCL).
• Plain potentiometer on A0.
• Rotary encoder on D10, D11, D12.

In addition to the I2C LED Ring on A4, A5 (SDA, SCL) of course.

Here is a separate diagram for the endless potentiometer. I can be used alongside the above, but I’ve drawn it on its own for clarity.

Mine has the pins in the following order: Wiper A, GND, Wiper B, VCC.

The Code

This uses the code from Part 2 as a starting point and adds in some additional features.

The main aim is to add additional control options and then make them selectable in code. There are several definitions at the top of the file. One of them should be uncommented to enable that control option.

//#define CC_ENCODER
#define CC_POTENTIOMETER
//#define CC_I2CENCODER
//#define CC_ENDLESSPOT

Each control method will have some associated functions, but the interface will be hidden away behind these definitions and called from the main code, something like the following.

#ifdef CC_ENCODER
#include <librarycode.h>
... control specific definitions ....

void encSetup() {
// Control specific setup code
}

void encLoop() {
// Control specific loop code
}
#else
void encSetup() {}
void encLoop() {}
#endif

If that control option is not enabled, then it will just end up with the two empty functions.

Normal Potentiometer

This is fairly straightforward. I’m using the averaging technique I’ve mentioned before (details here) and include a counter so that the pot isn’t read on every scan, otherwise it slows down all other processing significantly.

The pot reading is scaled down to 7-bits from the default 10-bit value with a bitshift.

I’ve opted to have a jump if the CC value is updated over MIDI rather than anything more sophisticated, as that is probably the simplest.

All the same display options are available as used previously: one LED per CC; scaled to multiples of the ring size; or scaled to a single ring.

This works quite well with all of them, but probably makes most sense when the MIDI CC range is scaled to a single revolution of the LED ring.

CC_WRAP has no effect when used with a normal potentiometer, as the pot itself does not wrap around.

Rotary Encoder

This is using the same encoder library I’ve used before in my Arduino MIDI Rotary Encoder Controller. This makes the scanning code relatively straight forward.

I’ve refactored out the increment/decrement functions from the I2C encoder code into midiCCIncrement and midiCCDecrement, so these can now be used by both encoder options.

These encoder modules are often switched, but I’m not making use of the switch here.

Once again, all the same display options are available: one LED per CC; scaled to multiples of the ring size; or scaled to a single ring. CC_WRAP can be on or off.

Endless Potentiometer

There is a detailed discussion of how these work here: https://hackaday.io/project/171841-driveralgorithm-for-360-deg-endless-potentiometer
My initial thought was that I could just use one of the wipers, assuming it would go from 0 to full resistance and immediately back to zero, but they don’t – they gradually go from 0 to full resistance and then gradually back to 0 again. See the diagram in the above link.

This means that some processing is required to get a single reading out of them, so I ended up using a library from here:

• https://github.com/juanlittledevil/EndlessPotentiometer

Well actually, I ended up using the slight variant of the library as used on the “Ottopot” MIDI controller, which can be found here:

• https://codeberg.org/gerotakke/ottopot

In my case I just dropping in the endlesspotentiometer.cpp/h files into my Arduino sketch (swapping any includes from <> to “” in the process). There was one reference to main.h that needed removing, and it required a definition of MAX_POT_VALUE which is 1023 for an Arduino Uno.

Then the code is fairly straight forward as the library is able to give an indication of direction and how much the pot has moved.

One thing to watch out for – I wanted this to be able to act on midiCC in a relative manner, replication the benefits of an encoder, but with a potentiometer, so I needed to know how much the pot had changed and then add that to the current midiCC value, rather than set it directly.

To do this I allowed midiCCIncrement/Decrement to take a parameter – how far to increase or decrease midiCC.

The core code for handling the endless pot was thus:

endpot.updateValues(epot1.avgeAnalogRead(PIN_EALG_1),
                    epot2.avgeAnalogRead(PIN_EALG_2));
if (endpot.isMoving) {
  if (endpot.direction == endpot.CLOCKWISE) {
    midiCCIncrement(endpot.valueChanged);
  } else if (endpot.direction == endpot.COUNTER_CLOCKWISE) {
    midiCCDecrement(endpot.valueChanged);
  }
}

I also turned the potentiometer averaging code into a class of its own so I could also use it here for both analog readings of the endless pot.

It took a bit of experimentation with the sensitivity and threshold settings and how they interacted with the frequency of reading, but I’ve ended up with something that seems to work ok for me.

Summary

Although at the start I said that one of the options should be commented out to select it, in reality, if the devices are all on separate IO pins, then actually they can all be enabled at once.

And it does seem to work pretty well, with all four methods: I2C encoder, plain encoder, potentiometer – all interacting as you might expect they would.

Find it on GitHub here.

Closing Thoughts

I was quite surprised how usable everything was with all four input methods enabled. I probably wouldn’t recommend it for typical use, but it was a bit of fun.

It is particularly satisfying to sweep through the entire range using the pot with “one LED per CC” enabled, even though scaling a single ring to the potentiometers range makes more sense (to me).

At some point I will try to get several controls up and running.

Kevin

#arduinoNano #duppa #endlessPotentiometer #i2c #ifdef #midi #potentiometer #rgbLed #rotaryEncoder

Duppa I2C MIDI Controller – Part 2

This is a follow up post to Part 1 where I’m starting to look at MIDI applications and a range of control options.

• Part 1 – getting to know the devices and testing them out.
• Part 2 – adding MIDI to the LED ring and I2C encoder.
• Part 3 – adding normal encoder, plain potentiometer, and endless potentiometer control.
• Part 4 – revisits the idea with Waveshare Zero format devices and adds USB MIDI.

Since posting the first part, I’ve stumbled across a rather excellent DIY MIDI controller that uses 8 of these Duppa LED rings and 8 endless potentiometers (which I hadn’t realised was even a thing!). It is a fantastic build, based on a Teensy and PlatformIO and I totally recommend going and taking a look. Read about it here: https://gerotakke.de/ottopot/.

https://makertube.net/w/2oKgvpZ29L2oExanSaUXjE

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

Parts list

• Arduino Uno/Nano.
• DuPPa small RGB LED Ring.
• Mini I2C Encoder.
• Bespoke hook-up wires (available from duppa.net).
• Breadboard and jumper wires.

The Circuit

I eventually want to include various options for controlling the ring and MIDI:

• Duppa I2C rotary encoder.
• Plain rotary encoder.
• Simple potentiometer.
• Endless potentiometer.

I don’t have any endless potentiometers yet, they are something I’ve only recently found exist, but I’ll post again when I get a chance to try them!

The required connections, naturally, are quite different for each case:

• Duppa I2C encoder: connects to SDA/SCL.
• Plain rotary encoder: requires two digital IO pins.
• Simple potentiometer: requires a single analog input.
• Endless potentiometer: requires two analog inputs.

In this first post, I’m just looking at the same Duppa I2C Encoder and LED Ring that I used in Part 1 but am adding a 5V compatible MIDI module.

The Code

Once again, this is using the Duppa Arduino library: https://github.com/Fattoresaimon/ArduinoDuPPaLib/

CC, Pots, Encoders…

The biggest issue I find with attempting to develop a MIDI CC controller is where is the authoritative definition of what the CC value actually is? What do I mean by that? Well we have the value in the synthesizer, defined on power up or via the on-board controls. And then we have the setting in the external MIDI controller. Until the MIDI controller sends an updated value to the synth, these will be different. And if the value on the synth changes locally, e.g. using knobs or controls on the synth, then they will be out of sync.

I’ve not found an easy answer to this, but what I’m planning is having the CC controller receive MIDI CC messages as well as send them. This means that if the CC value is changed directly on the synth, if the synth transmits that over MIDI, then it will be received by the external controller which can update its own value accordingly.

One problem with this is that there are two types of hardware controller: relative or absolute.

A rotary encoder is a relative controller – it turns in a direction and the value will increase or decrease accordingly. If the internal knowledge of the CC value changes, the encoder will just continue to increase of decrease from that new value instead.

A potentiometer is (usually) an absolute controller – it turns and has a value. If the internal knowledge of the CC value changes, then unless you have a motorised potentiometer, it will still be in the same place so on turning there will be a jump in value from the stored value to the new setting of the potentiometer.

One option to deal with absolute values is to have the new position value only become relevant once the turning “catches up” with the internal value and the starts adjusting it from that point onwards. But this can create a disjoint between the user experience of turning the knob and it actually changing anything. But on the plus side, absolute values are “remembered” when powered off – providing the knobs are left in the same place.

I’m hoping to use the encoders as a pseudo potentiometer. But it isn’t going to be possible to have a complete rotation considered the same as a full sweep of a potentiometer, as that will be down to the number of “detents” per rotation and that won’t be anything like enough to support 128 MIDI CC values. But I do plan to indicate the value by LEDS, and use those to indicate the position in the full sweep. This will allow the starting point to change if a CC message is received.

One solution to this problem, and that used by the Ottopot controller mentioned at the start, is to use an endless potentiometer. This not-only allows a variable starting position, but it also represents a full-sweep of values with a single turn as per a simple potentiometer.

So when I get hold of some of those I’ll come back to revisit this code.

For this first version there is code for the I2C encoder implemented using the following functions:

• i2cEncSetup()
• i2cEncLoop()
• i2cEncIncrement()
• i2cEncDecrement()

These are based on the code I used in Part 1. The increment and decrement functions act on a global “midiCC” directly, which stores the CC value to use using the range of a single MIDI “byte” 0 to 127. There is a compilation option to allow wrapping around (between 0 and 127) or not.

MIDI Handler

The Arduino MIDI library is used for both send and receive and all MIDI functionality is wrapped up in the following functions:

• midiSetup()
• midiLoop()
• midiControlChange()

There are a few additional functions to give an optional LED indication of MIDI activity. Within the MIDI loop the midiCC value is checked and if it has changed then a MIDI control change message is transmitted:

void midiLoop() {
  MIDI.read();
  if (lastMidiCC != midiCC) {
    MIDI.sendControlChange(MIDI_CC, midiCC, MIDI_CHANNEL);
  }
}

There is an option to have software MIDI THRU enabled and this is handled as part of the MIDI.read() call. On setup midiControlChange() is installed as a handler function for MIDI CC messages and if the correct CC message is received on the correct MIDI channel then the midiCC value is updated directly.

One consequence of using midiCC directly and it being changed by either the encoder or from MIDI is that any change will also trigger the sending of the CC value out too.

This means that if MIDI THRU is enabled and a MIDI CC value is sent to the Arduino then it will almost certainly be sent back over MIDI twice – once as part of the THRU handling, and once as a consequence of it having changed the Arduino’s stored midiCC value.

LED Ring Indicator

The simplest implementation will be to scale the 24 LEDs of the ring to the 128 MIDI values and light up the LED that best represents the chosen value.

An alternative is to use one LED per MIDI CC value and allow the ring to loop round, possibly in a different colour. For 128 values across 24 LEDs this means there will be five full circles of the ring plus 8 more.

I’ve also provided the option to scale the MIDI CC values to a multiple of the LED ring so that the full MIDI 0..127 range wraps around back to 0 back at the start of the ring.

In the following, scalemax is the largest multiple of NUM_LEDS that will fit in 128, then the midiCC value is scaled to that new range and then used in the rest of the LED calculation.

int scalemax = 128 - 128 % NUM_LEDS;
int midiCC_scaled = (midiCC * scalemax / 128);
nextLed = midiCC_scaled % NUM_LEDS;
uint32_t col=0;
if (midiCC_scaled < NUM_LEDS) {
  col = 0x00003F;
} else if (midiCC_scaled < NUM_LEDS*2) {
  col = 0x003F3F;
} else if (midiCC_scaled < NUM_LEDS*3) {
  col = 0x003F00;
} else if (midiCC_scaled < NUM_LEDS*4) {
  col = 0x3F3F00;
} else if (midiCC_scaled < NUM_LEDS*5) {
  col = 0x3F0000;
} else {
  col = 0x3F003F;
}

One quirk to note is that the LEDs are numbered anti-clockwise, so at some point I’ll have to reverse the LED number when it comes to presenting an increasing CC value as a clockwise changing display.

I’d also like to have a bit of a lazy, dragging LED change, so I want to implement something that fades illuminated LEDs out as the value changes, leaving some kind of “tail” as the LED moves.

To do this, I’ve used an array to store the colour value used for any illuminated LEDs and then at regular intervals that colour is updated to fade back to OFF.

I’ve implemented a relatively simple fade – basically each of the R, G and B components of the colour is bit-shifted to the right by 1 on each “scan”. This has the effect of continually dividing the colour value by 2 until it reaches 0. The only thing to watch out for is that I don’t do this for the current illuminated LED.

Also note that I only pull out the most significant 7 bits of each 8 bit value (by & 0xFE) so that the shift doesn’t map the least significant bit of one value down into the next colour.

for (int i=0; i<NUM_LEDS; i++) {
  if (i != nextLed && ledMap[i] > 0) {
    uint32_t newcol = ((ledMap[i] & 0xFE0000) >> 1)
                    + ((ledMap[i] & 0x00FE00) >> 1)
                    + ((ledMap[i] & 0x0000FE) >> 1);
    LEDRingSmall.LEDRingSmall_Set_RGB(i, newcol);
    ledMap[i] = newcol;
  }
}

All the LED handling is wrapped up in the following functions:

• ledSetup()
• ledLoop()
• ledIndex()

The last function is responsible for swapping the LED numbers around to make them go clockwise. It isn’t as simple as doing NUMLEDS – led as I still want the first LED to be at “12 o’clock”, hence the function to return the correct index.

Find it on GitHub here.

Closing Thoughts

I am so pleased with that lazy LED change effect.

Having so many turns of the encoder isn’t particularly practical at the moment, but it does work. It is certainly good to have a few configuration options – especially the option to wrap around, as it takes quite a few turns to get from 0 to 127.

In a follow up post I’ll take a look at some of the other options, and when I get my endless encoders in the post that will definitely get a mention too.

I also want to wrap up the existing code somehow to allow for several LED CC controls if required and some kind of box might also be nice.

Kevin

#arduinoNano #duppa #i2c #midi #rgbLed #rotaryEncoder

EuroRack 6HP Arduino Mozzi Module – Basic VCO

This is the first project based on my EuroRack 6HP Arduino Mozzi Module. It is loosely based on HAGIWO’s Arduino Mozzi VCO Module.

https://makertube.net/w/hnocMAhYkajd8nX2vwuR2u

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

These are some previous posts for the main concepts used in this project:

• EuroRack 6HP MCU Experimenter Module Usage Notes.
• Arduino Multi-pot Mozzi FM Synthesis – Revisited

If you are new to Arduino, see the Getting Started pages.

Parts list

• Build EuroRack 6HP Arduino Mozzi Module
• Amplification
• CV sources

The Circuit

This uses the EuroRack 6HP Arduino Mozzi Module with the pots and jacks assigned as shown below.

The four potentiometers control the following:

• POT 1 – OSC 1 core frequency offset (from V/Oct CV).
• POT 2 – OSC 2 frequency ratio OSC1.
• POT 3 – Waveform for both oscillators: sine, triangle, saw, square.
• POT 4 – Octave: 1 lower, normal, 1 higher, 2 higher.

There are three CV inputs:

• V/Octave pitch.
• OSC1 vs OSC2 gain.
• Pitch modulation.

The Code

The code is inspired by that of HAGIWO’s Mozzi VCO, in that I’m using Mozzi with two oscillators, with multiple waveforms, and I’m using HAGIWO’s gain profile for CV. But I’ve added a few extras and have rewritten the core Mozzi code to hopefully be a little more optimal.

The main V/Oct calculation has to happen every scan and HAGIWO uses a look-up table in PROGMEM for the fractional voltages that correspond to each value of the ADC and then uses those in the standard Volts to frequency equation:

Freq = BaseFreq . 2^CV

For a 10-bit resolution (the resolution of the Arduino ADCs) this requires 1024 values across the whole 5V range. That equates to 4.8828mV per step (5/1024) and as full octave of 12 steps is 1V that equates to 83.3mV per semitone.

The various CV recommendations I’ve seen suggest using a BaseFreq equal to C4, which is 261.6256 Hz in the calculation unless it is for a LFO or clock in which case a BaseFreq of 2Hz is recommended – which corresponds to 120 bpm if used for a clock. The BaseFreq is the frequency used for 0V. Many analog synths will accept negative voltages to go lower, but as this is an Arduino it only supports 0V to 5V.

HAGIWO uses a table of float values and uses floating point arithmetic to work out the frequency. I’ve opted to use fixed point arithmetic and also rather than store the CV “step” values in the table have pre-calculated the whole 2^CV for each step.

Here is some Arduino code that will output the required look-up table values. My full version will first output the individual voltage steps to 6 decimal places; then for the float version of 2^CV; and finally for the fixed point 16.16 equivalent – that is 16 bits for the integer part and a fixed 16 bits for the binary equivalent of the decimal part.

The code below just does the last part. This is using the FixMath library which was written for use with Mozzi (more here).

#include <FixMath.h>  // Designed for use with Mozzi

int res = 10;        // 10-bit resolution
float maxv = 5.0;    // Max voltage

void setup() {
  Serial.begin(9600);

  int max = (1<<res) - 1;
  float cvstep = maxv / ((float)max+1.0);

  Serial.print("\n\n");
  Serial.print("Resolution=");
  Serial.print(res);
  Serial.print(" bits (0 to ");
  Serial.print(max);
  Serial.print(")\tV/step=");
  Serial.print(cvstep,6);
  Serial.print("\n");

  float cv = 0.0;
  for (int i=0; i<=max; i++) {
    if (i%16 == 0) {
      Serial.print("\n");
    }
    float freqpow = pow(2, cv);
    UFix<16, 16> q16n16fp = freqpow;
    Serial.print("0x");
    Serial.print(q16n16fp.asRaw(), HEX);
    Serial.print(",");
    cv += cvstep;
  }
}

void loop() {}

I’ve used this to create the q16n16 version of the 1024 values required to calculate the frequency for each of the 0..1023 values that the 1V/Oct analog input could provide, covering the full 5V range. This is stored in the header file v2voct.h that is part of the code.

This does mean that any calculation of frequency must be done using the FixMath 16.16 values, for example:

UFix<16,16> q16n16potfreq = mozziAnalogRead(POT1);

This code takes the unsigned integer value (0 to 1023) from mozziAnalogRead and automatically turns it into a 16.16 fixed point format value in variable q16n16potfreq – note that in each case the decimal part will be zero as the starting point is an integer between 0 and 1023.

When reading values in from the look-up table, they have to be pulled in “raw” as they are already in the 16.16 format. But as Arduino doesn’t know anything about this format, they have been declared as uint32_t values in the PROGMEM structure, but then need to be read back out and treated as 16.16 values as show below.

#define CVSTEPS 1024
static const uint32_t q16n16fp [CVSTEPS] PROGMEM = {
0x10000,0x100DE,0x101BD,0x1029C,
...
};

UFix<16,16> fpow = UFix<16,16>::fromRaw(pgm_read_dword(&q16n16fp[voct]));

All calculations related to frequencies are performed using 16.16 values. The Mozzi oscillator setFreq function has a version that takes 16.16 values too, making everything actually quite straight forward once you get your head around what its doing.

Other notes on the code:

• There are two gain values maintained – one for each oscillator. The values used come from another look-up table (that I took from HAGIWO’s original) that allows the CV to pan across from one oscillator to the other. I’m using 7-bit gain values (0..127) so that when the final audio sample is worked out at the end, it should all fit within a 16-bit value give or take.
• The octave selector changes the octave of both oscillators and is determined by POT 4 and can select from 0V = C3 through to 0V = C6.
• Oscillator 2 is set to a frequency between 2 octaves below and 1 or 2 octaves above the frequency of oscillator 1 at all times, as determined by POT 2 – quite how to do this was the subject of a bit of experimentation (see below).
• The frequency of oscillator 1 is given by the setting of POT 1, the V/Oct CV, the mod CV and the octave.

The following code sets up the two frequencies for the oscillators.

UFix<16,16> fpow = UFix<16,16>::fromRaw(pgm_read_dword(&q16n16fp[voct]));

UFix<16,16> q16n16freq1 = q16n16oct * (q16n16c4 + q16n16potfreq + q16n16mod) * fpow;

UFix<16,16> q16n16freq2 = q16n16Mult * q16n16freq1;

aOsc1.setFreq(q16n16freq1);
aOsc2.setFreq(q16n16freq2);

q16n16c4 is the frequency of C4 in fixed point 16.16 format. It is essentially the “BaseFreq” in the original equation. Notice how the base frequency is also affected by POT 1 and the modulation CV. The whole lot is then multiplied by the octave setting, which will be one of 0.5, 1.0, 2.0 or 4.0.

The multiplier used for the second oscillator (q16n16Mult) comes from POT 2. I have included two approaches to using this: discrete values or continuous.

For discrete values, the setting of POT 2 selects one of 8 fixed ratios to use to set the frequency of OSC 2 compared to OSC 1. I’ve chosen the following options (with 0.0 effectively being “off”):

{0.0, 0.25, 0.333333, 0.5, 0.666666, 1.0, 1.333333, 2.0}

For continuous values, I take the raw reading (0..1023) and convert it into a 2.8 fixed point number by shifting left by 8 bits and then treating it as a raw 16.16 value. This works as the number is a 10-bit value, so shifting left 8 bits makes it a 18 bit value – but then when read as a 16.16 bit value, the lowest 16 bits of those 18 are treated as the decimal…

UFix<16,16> q16n16Mult = UFix<16,16>::fromRaw(((uint32_t)mozziAnalogRead(POT2)) << 8);

Note I have to ensure it scales the return value from mozziAnalogRead up to 32-bits first otherwise clipping will occur. This allows me to have fractional octave values for the second oscillator compared to the first.

As the second oscillator starts 2 octaves below the first, this gives a range of multipliers starting from nothing (i.e. “times zero”), to almost two octaves below oscillator 1 (00.01000000 in 2.8 fixed point binary) through to 1 octave below (x0.5 = 00.10000000), to the same as oscillator 1 (x1 = 01.00000000) to 1 octave above (x2 = 0x10.00000000) to almost 2 octaves above (x4 would be 1024, but 1023 is 11.11111111).

The downside of this approach is that the response to the potentiometer setting isn’t linear. Or rather, it is linear, when really I’d like it not to be… I might go back and correct that in software at some point, but it is fine for now.

Note that if POT 2 is set to zero, then oscillator 2 is turned off. One option to always keep it on is to always ensure a minimum POT 2 reading. I’ve included that as an option to have the minimum reading of 64, which when converted to 2.8 format is 00.01000000 or 0.25 in decimal – hence a multiplier that gives “two octaves below”.

The final calculation that is performed for each audio sample is given by:

AudioOutput updateAudio(){
  return MonoOutput::from16Bit(bOsc1Gain*aOsc1.next()+bOsc2Gain*aOsc2.next());
}

This combines the audio samples of each of the oscillators, multiplies them by the 7-bit gain value and then tells Mozzi to take this as a 16-bit value to be turned into a Mono output value.

Right at the start, I’ve told Mozzi to use “HiFi” mode, which should give me 10 bits of PWM output range using D9 and D10. I’ve also used a slightly higher MOZZI_CONTROL_RATE to help with scanning the IO.

Find it on GitHub here.

Closing Thoughts

As can be seen from the video, I don’t really anything much to use this with yet, but I’ve driven it from my “Baby8” CV Step Sequencer and the LFO from my Educational DIY Synth Thing and I think it seems to work ok. The video includes the following:

• Changing basic OSC 1 frequency via POT 1.
• Changing OSC 2 ratio compared to OSC 1 via POT 2.
• Chaning the octave via POT 4.
• Chaning the waveforms via POT 3.
• Generating a V/Oct CV from the Baby 8.
• Setting a low sweep of CV1 to control the relative gain of OSC 1 vs OSC 2.
• Swapping to CV2 to provide additional pitch modulation to the oscillators.

This isn’t quite using the final version of the code, but gives an idea.

Note that the V/Oct input won’t work at true audio frequencies, so it can’t be used for frequency modulation, but otherwise I’m quite pleased with the performance considering it is updating from three CVs and four potentiometers each scan.

It might be possible to up the MOZZI_CONTROL_RATE even more and scan the CVs more frequently than the pots, but for now they are all scanned at the same time using a MOZZI_CONTROL_RATE of 128 (twice the default 64).

The output seems pretty clean to me too, but that is really thanks to HAGIWO’s original PWM output stage.

I’m just waiting for some spray-on adhesive so I can make a simple panel for it now.

Kevin

#arduinoNano #define #HAGIWO #include #mozzi #oscillator #vco

EuroRack 6HP Arduino Mozzi Module

This project uses my EuroRack 6HP MCU Experimenter Module to implement HAGIWO’s Arduino Nano based VCO.

This post describes how to put it together and test the basic functionality. Future posts will look at some code that can run on the module (see the “Sample Applications” section).

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

These are the key tutorials for the main concepts used in this project:

• HAGIWO’s Arduino Mozzi VCO Module
• HAGIWO’s Arduino Mozzi FM VCO
• My EuroRack 6HP MCU Experimenter Module Usage Notes

If you are new to Arduino, see the Getting Started pages.

Parts list

• Arduino Nano
• EuroRack 6HP MCU Experimenter Module Arduino MCU board.
• EuroRack 6HP MCU Experimenter Module IO board built as described below.
• EuroRack 6HP MCU Pots and Jacks PCB built as described below.
• Blank 6HP front panel.
• M2 mounting screws, fixings, nuts.

For the IO board:

• 1x MCP6232 or equivalent OpAmp.
• 8x BAT43 Schottky diodes.
• Normal resistors: 1x 100Ω, 1x 200Ω, 4x 1kΩ, 1x 330kΩ, 2x 100kΩ.
• Higher accuracy resistors (1% or better): 2x 3.9kΩ, 1x499kΩ.
• Ceramic Capacitors: 4x 100pF, 1x 4.7nF, 1x 10nF, 3x 68nF, 1x 100nF.
• Electrolytic Capacitors: 1x 4.7uF.

Note: it is worth measuring a range of 499K and 3.9K resistors and finding the best ones. In my case I only had 500K resistors, so found the closest to 499K I had. I ended up with two 3.88K and one 498K.

For the Pots and Jacks board:

• 4x 10kΩ or 100kΩ PCB mount potentiometers.
• 4x “Thonkiconn” jack sockets.
• Header pins.
• Jumper wires

The IO Board

Here is how the various sub-circuits of the IO board will be used:

Notice that the GATE and OUT circuits are being used in “alternative” modes as additional inputs (see the Usage Notes for more details). In particular the transistors on the GATE circuits are not used.

The following shows which components of the PCB will be populated (yellow), which will be changed for other components (blue), which wire links are required (red) and which connectors will be used for linking to the Pots and Jacks board (green) and MCU (purple).

Here is the list of components required for the above:

Resistors:

• R100: 499K
• R101, R102: 3.9K
• R105: 200Ω
• R300, R350, R400, R450, R600, R650: 1K
• R401, R451: 100K
• R500: 100Ω
• R501: 330K

Capacitors

• C100: 4.7nF
• C101: 10nF
• C102: 4.7uF electrolytic
• R301, R351, C400, C450, C600, C650: 100pF (yes, two resistor slots are capacitors).
• C400, C450, C500: 68nF

Other:

• D100, D101, D400, D401, D450, D451, D500, D501: BAT43 Schottky Diodes
• MCP6243

The mapping between IO connections and MCU IO pins is as follows (all other IO pins are not used):

Note: the order of the Gate/CV is (from top to bottom): CV 2, CV 1, G2, G1. The ordering of the OUT connections is the same for both sets of pin headers: 1 on the left, through to 4 on the right.

Build Order and Photos

This is the suggested build order:

• Diodes.
• Resistors.
• Small capacitors.
• Header sockets (assuming PH5 and PH3.5 sockets).
• Capacitor on the rear of the board.
• OpAmp.
• Larger capacitors.
• MCU board header sockets on rear of the board.
• Jumper wires.

When installing R501, I’ve opted to make the fix described in the EuroRack 6HP MCU Experimenter Module Usage Notes and swap its position to the other side of R500 as shown below.

Otherwise the build proceeding pretty much as suggested.

Note that the OpAmp’s capacitor must be soldered to the rear of the board prior to fixing the OpAmp.

The install the OpAmp, smaller headers and larger capacitors.

Finally the longer headers for the MCU board can be installed on the rear of the board.

Finally the patch links can be installed as described previously (including the links instead of R104 and the transistors).

The Pots and Jacks Board

These functions will map onto the following potentiometers and jacks (and connections) from the EuroRack 6HP MCU Pots and Jacks PCB:

The pots and jacks PCB should be wired up to the interconnecting headers as follows:

Optionally, it might be useful to connect from the GND header pin to the panel once fitted.

It is suggested the Jacks and Pots PCB is built in the following order:

• Small header pins on the underside of the board.
• Long header pins (if used) on the underside of the board.
• Jacks.
• Potentiometers.
• Link wires.

The Panel

This is the panel design required.

The measurements are all detailed in the EuroRack 6HP MCU Pots and Jacks PCB Build Guide, but crucially the pot holes are M7 and the jack holes are M6. I found they needed a 7.5mm and 6.5mm drill respectively to allow for a bit of flex when fitting the panel.

I’ve used M2 mounting posts, screws and nuts between the boards. In particularly, I found that the spacing required a 6mm spacer with an additional nut added as shown below.

I also had to break off the alignment lugs on the potentiometers to allow the panel to fit snugly.

Once all together, you can see it needs around 45 to 50 mm clearance behind the panel for the whole thing.

Testing and Basic Code

I recommend performing the general tests described here: PCBs.

Then it can be connected to an Arduino Nano MCU board an a basic analogRead test can be performed to check the pots and input jacks.

void setup() {
  Serial.begin(9600);
}

void loop() {
  for (int i=0; i<8; i++) {
    int aval = analogRead(A0+i);
    Serial.print(aval);
    Serial.print("\t");
  }
  Serial.print("\n");
  delay(100);
}

An external potentiometer can be connected to a mono patch lead (GND and signal) and VCC to test the CV IN jacks (IN1, IN2, OUT2).

The order should be as follows:

The (dual) PWM output can be tested using the basic Mozzi “Hi-Fi” sinewave test which can be found in the examples here:

• Examples -> Mozzi -> 01.Basics -> Sinewave_HIFI

Sample Applications

Here are other posts describing some sample applications for this module.

• EuroRack 6HP Arduino Mozzi Module – Basic VCO.

Closing Thoughts

I have to be honest – working out which parts of the circuits to use, then referring back to them to populate the PCBs, then soldering on the intra-board links and finally fiddling with the panel was actually quite a lot of work.

I don’t know if I’ve saved anything compared to just building the circuit from scratch on a piece of protoboard.

It is also going to be quite likely that any issues might be hard to trace too.

I might find that as I use more of these boards, (assuming I build some more of course), then I get to know the layout and circuits and won’t be referring back to the designs so much. I’ll have to see how it goes.

But for now, if all you want is a single Arduino Nano HAGIWO circuit, then you’re probably better off just making it up on protoboard…

But I think the whole board “sandwich” once complete does look pretty good!

I’ll have to see if I can get a bit of a “production line” going and make up a few more. And now I have to get on with some code…

Kevin

#arduinoNano #EuroRack #HAGIWO #mozzi

EuroRack 6HP MCU Experimenter Module Usage Notes

Here are some suggestions and usage notes for my EuroRack 6HP MCU Experimenter PCB.

This post walks through the different sections of the schematic and PCB and shows how to tailor the circuits to different applications.

• Part 1: EuroRack 6HP MCU Experimenter Module PCB Design
• Part 2: EuroRack 6HP MCU Experimenter Module PCB Build Guide
• Part 3: EuroRack 6HP MCU Experimenter Module Usage Notes
• EuroRack 6HP MCU Pots and Jacks PCB Design and Build Guide

Here is a list of built modules using these boards:

• EuroRack 6HP Arduino Mozzi Module

Warning! These boards are meant for DIY systems only. They should NOT be used with expensive EuroRack modules, racks, or power supplies. I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Electronics, see the Getting Started pages.

Introduction

As detailed in the design notes, there are a number of different sections for this PCB, each designed to be used to link a microcontroller to a EuroRack synth in a useful, and hopefully electrically useful way. There is also an additional PCB designed to support a range of configurations of Pots and Jacks for use with this MCU and IO board.

At various points, I refer back to a range of HAGIWO’s designs in the discussion (for a complete list see my design notes).

But I have to reiterate right at the start – I strongly state that you DO NOT use these in a rack of expensive or cherished gear!

It is meant for DIY experiments and so it should be expected that:

• Use of this PCB could easily destroy any power supply powering it.
• Use of this PCB could also easily destroy any EuroRack modules in the same rack using the same power bus.

In short, I’m only using this with cheap, second hand, other DIY kit, or equally sacrificial equipment and I strongly state that you should do the same.

The Microcontroller Board

Recall that there are two PCBs to be used: an IO board and a MCU board. The MCU board could support either a Raspberry Pi Pico (or similar) or an Arduino Nano (or similar).

The MCU board has all of the components on the underside, apart from the two rows of headers joining it to the IO board. The IO board has all components on the top-side, apart from the two rows of headers joining it to the MCU board.

Arduino Nano

The following illustrate which components are required to use an Arduino Nano. This shows the rear view of the MCU board.

The Arduino Nano will run directly off the EuroRack +12V line, so no regulator or associated components are required. The following detail shows which components need to be mounted to support the Nano’s power.

The Nano itself should be mounted on the two 15-way header sockets and aligned as shown below. Note that the USB connection is facing “down” towards the EuroRack power connector.

If the regulator and additional circuitry is already fitted it will be ignored if an Arduino Nano is used.

Raspberry Pi Pico

To use a Raspberry Pi Pico, the full power circuit is required, including the regulator, additional capacitors and diode as shown below. Once again this is showing the rear of the MCU board where all of the components (apart from the interconnecting headers) will be mounted.

The Pico will be mounted on the two 20-way header sockets and aligned as shown below, with the USB connector at the “top” facing away from the EuroRack power connector.

The IO Board

MCU Interface

The IO board itself will be connected to the microcontroller board using the interconnecting 14-way headers and all microcontroller IO pins will be broken out to pads as shown below.

The idea is that the main circuit sections terminate at one of the three MCU PWM|OUT|IN headers (also highlighted) and can then be patched across to the MCU IO headers which have the following layout.

The Arduino supports D0-D13 and A0-A7, although for an Arduino Nano A0-A6 can also be referenced as D14-D19 of course.

The Raspberry Pi Pico supports D0-D13, D16-D22 and A0-A2.

External Connections

Potentiometers, switches, jacks, audio or any other external IO can be connected to the IO board in a number of places. The following shows where they are and how they related to the MCU connections (assuming the appropriate circuitry in between has been connected up).

My additional Pots and Jacks PCB has been designed to match up with these headers and just needs a link to VCC and GND adding.

Which headers to use and how to do this is fully described in the Pots and Jacks PCB Build Guide.

Audio PWM Output

There are two PWM output channels, each of which can be driven by one or two PWM outputs from the microcontroller. A great explanation of dual PWM output can be found on Open Music Labs here:

• http://www.openmusiclabs.com/learning/digital/pwm-dac.1.html
• http://www.openmusiclabs.com/learning/digital/pwm-dac/dual-pwm-circuits/index.html

PWM Resolution and Filter

The PCB will support a single PWM output by omitting R100. If dual PWM output is required, then R100 and R101 need to have values that support the required bit-depth of the PWM resolution as described in the Open Music Labs tutorial (see “table 2”).

Some options might be:

Otherwise a single resistor (e.g. R100) could be used for a single, 8-bit resolution PWM, in which case the chosen resistor will form part of the PWM filter consisting of R100 and C100.

As shown, there is a two-stage PWM filter circuit: R100/R101 and C100; R102 and C101. For a simpler application the second stage could be omitted and R102 replaced with a wire link (or short, for 0K).

In HAGIWO’s Nano design, the first stage uses values as per the Mozzi dual PWM default (above) with a 4n7 capacitor. The second stage uses a second 3K9 resistor with a 10nF capacitor. In the XIAO DAC application, HAGIWO uses a single resistor output from the DAC with a two stage filter of twin 10K + 1nF.

From the Open Music Labs tutorial, we have the following relationships for dual PWM and a low-pass filter:

• R2 = R1 . 2^n
• C ~= 1 / ( 2 . pi . R1 . Fc)

So the cutoff frequency Fc = 1 / ( 2 . pi . R1 . C ) where R1 is the smaller of the two resistors, so R101.

But when there are two filter stages, the RC calculation seems to be quite a bit more complicated and beyond my current knowledge of electronics, so I’m just going with some of the suggested values from the existing circuits…

Some options for the PWM filter stage I’ve seen so far can be summarised as follows:

Fundamentally, it depends on the required resolution, single or dual operation, and then the required cut-off frequency of the filter. For the simpler setup, values can be tested using a low-pass filter calculator (more here).

Note: I wasn’t able to easily source 499K resistors, but I was able to find a number of 500K 1% resistors so I used a meter to measure them and picked those closest to 499K.

Also note that the “MOD1” design has a very low cut-off frequency and is stated as being more for LFOs and EGs. More on that later.

OpAmp Gain

R103 and R104 can be used to set the gain of the MCP6232-based OpAmp. For 5V operation, R103 can be omitted and R104 shorted for unity gain. For 3V3 operation, the ration of R103 to R104 can be used to set a gain for 3V3 to 5V amplification. The values below were used by HAGIWO in the XIAO DAC output circuit.

OpAmp Choice

HAWIGO’s circuits often suggest the MCP6232 for rail-to-rail operation, but there are probably many others that would work too. There is a great OpAmp summary of Microchip offerings on their site that lists all of their OpAmps (see here).

I’m pulling out any dual, DIP packaged, rail-to-rail devices, that seem similar to the MCP6232 (I believe these all have the same pinout):

Of course, I’m quoting those figures with very little clue as to their meaning, but in my “hand-wavy” world of electronics knowledge, given the kind of level I’m working at here, I would suggest any of those might be fine for this application.

Most are probably rated more highly than required, and I’d suggest the lower current ones are best for the audio frequencies I want to be working at.

I’ve also seen at least one circuit suggesting the NJM2732, which appears to be another rail-to-rail OpAmp with an operating voltage of 1.8 to 6.0V and GBWP of 1MHz, so I’m going with the idea that again for my Lo-Fi world, that is essentially interchangeable with the above.

Output Coupling

The final stage of the circuit sets the output impedance and removes the DC bias from the audio output. I’ve seen all of the following values used so far:

I’ve not spent any time wondering about how these values will affect the output, so I’m just documenting them for now. This is probably a good area for experimentation to find the most suitable values for any specific application.

The two diodes (D100, D101) that provide clamping are BAT43 Schottky diodes.

Second PWM Output

All of the above can be duplicated for R200-205, C200-202, D200-201 for the second PWM channel, which uses the second OpAmp from the MCP6232.

In the photo below, all components and connections associated with PWM 1 are highlighted in RED and for PWM 2 are highlighted in YELLOW. naturally if only one PWM circuit is required, all components associated with the other can be omitted.

GATE and CV Inputs

There are two GATE and two CV inputs as shown in the following schematic sections – GATE input on the left; CV input on the right.

Gate Input

The GATE input section mirrors that of my Educational DIY Synth Thing, so the values are pretty much fine as being the following:

Note that the actual MCU_GATE_IN signal will be active LOW – so inverted compared to the input signal. The input signal is assumed to be a 0 to 5V signal.

R302 is just a pull-up resistor, and everything should be fine with either a 5V or 3V3 VCC level.

CV Input

The CV input section has several variants. R400 and R401 can be used as a potential divider if the input voltage needs adjusting. Some examples of the components used are as follows:

Note that in most cases D400 and D401 are BAT43 Schottky diodes (in the “MOD1” design, 1N5819WS were chosen).

When the ratio of R400 to R401 is close to 1, then essentially almost the whole voltage range, up to the clamped voltage rails, is used as input.

When the ratio of R400 to R401 is ~2/3 then the output voltage will be approx 3V3 (max) from a 5V input. There are two values that seem to be used: 22K to 33K or 220K to 330K.

I’ve since seen a note that R401 should really be between the external connection and R400 for 5V systems, which would remove the potential divider effect. This is shown below.

Whilst the board doesn’t directly support this, it is possible to patch that in as shown below.

Note: any of the blue spots are GND connections and could be used. In fact, looking at the traces, it would be possible to swap R451 and C450 over, and the same for R401 and C400 – this would leave some spare GND pads where the capacitors were originally placed that could then be easily used for the moved resistors.

Whether this is actually required or not is left as an exercise for the reader – in other words, I’ll get back to it after some experimenting! The “MOD1” design doesn’t worry about this for example.

Potentiometer Input

If a slightly more robust potentiometer input is required, then it is possible to use the CV input circuit without the clamp diodes and omitting R401 as follows:

In this case it would be recommended that R400 = 1K. HAGIWO suggests C400 = 100pF, but I’ve used 10nF for potentiometer smoothing before. Naturally a pot could just be wired directly to the microcontrollers analog inputs of course.

The “MOD1” design uses R400 = 10K and C400 = 10nF with a 100K pot.

Second GATE and CV Input

Components R300-R302, D300 are repeated as R350-R352, D350 to give a second GATE input. Components R400, R401, C400, D400, D401 are repeated as R450, R451, C450, D450, D451 to give a second CV input. The relevant areas are shown below.

• Gate 1 – Yellow
• Gate 2 – Red
• CV 1 – Purple
• CV 2 – Blue

Once again, any unused sections can be omitted completely.

Additional Potentiometer Inputs

It is also possible to use the GATE stage as a potentiometer input too as shown below.

In this case, pull-up resistor R302, diode D300, and the transistor are omitted, but pins 2 and 3 (the two oval pads, left and centre) of the transistor need connecting. then R301 is replaced with a capacitor and the output of R300 connected to the potentiometer “wiper” via the GATE IN link.

Aside: it is also possible to repurpose an OUTPUT stage for a potentiometer INPUT too by omitting the clamp diodes and one of the resistors, as shown below:

But of course, in this case MCU_OUT_1 becomes an MCU_IN connection – a little confusion, but definitely possible. More on the OUTPUT circuits in a moment.

Additional CV Inputs

Whilst on the topic of changing uses, it is also possible to repurpose a GATE input as a CV input as follows.

In this case, R302 and D300 are both replaced with BAT43 clamp diodes and the transistor is omitted, with pins 2 and 3 connected together. To complete the CV in circuit as shown previously a capacitor could also be soldered to the same connections as R301.

GATE and CV OUTPUTS

There are four generic OUTPUT circuits which could be used for either GATE or (PWM generated) CV signals.

The key difference being that for a GATE OUTPUT, R501 and C500 can be omitted. D500 and D501 are BAT43 Schottky diodes once more. Some sample values and applications are shown below.

R501 is not really needed in the above. Truth be told, I can’t remember why I thought I ought to include it! It is there in the “MOD1” design, but it isn’t clear to me why.

It does however leave the possibility that these nominally output circuits could be repurposed as additional inputs if required (this might be why they feature in the “MOD1” design). With all the components fitted, it is essentially mirroring the CV input circuit discussed previously.

Note that for CV generation from PWM, those stated C500 and R500 values give quite a low cut-off frequency:

• 470R + 4u7 ~ 70Hz
• 1K + 1uF ~ 160Hz

These could be adjusted, but I guess the main idea is that these are slower changing control voltages such as from an LFO or envelope generator rather than an oscillator out, which ought to the use more complete PWM “audio” output stage previous mentioned.

Four Output Stages

Each output stage is independent, and the relevant components are shown below. Once again, any unused sections can be omitted.

Key:

• Output 1 – Yellow
• Output 2 – Red
• Output 3 – Purple
• Output 4 – Blue

Closing Thoughts

This was never intended to be a completed board, it was always meant to make it easy to experiment with different options. The downside of that approach of course is that none of the circuits have really been tested yet at all, so it is all theory at this point.

Having seen with hindsight how various sub circuits can be repurposed, it would have been nice to design those options in more officially – via jumpers or silkscreen updates for example. But as the board is pretty packed already, I suspect my options here would be quite limited.

Either way, I think it should support my experiments pretty well so am pretty pleased with how it turned out.

Kevin

#arduinoNano #EuroRack #pcb #raspberryPiPico

EuroRack 6HP MCU Experimenter Module PCB Build Guide

Here are the build notes for my EuroRack 6HP MCU Experimenter Module.

• Part 1: EuroRack 6HP MCU Experimenter Module PCB Design
• Part 2: EuroRack 6HP MCU Experimenter Module PCB Build Guide
• Part 3: EuroRack 6HP MCU Experimenter Module Usage Notes
• EuroRack 6HP MCU Pots and Jacks PCB Design and Build Guide

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Electronics, see the Getting Started pages.

Bill of Materials

• EuroRack Control IO PCB (GitHub link below).
• EuroRack Control MCU PCB (GitHub link below).
• EuroRack 6HP Panel PCB (GitHub link below).
• Arduino Nano or Raspberry Pi Pico.
• Either 2x 15 way headers (Nano) or 2x 20 way headers (Pico) – PH5 headers recommended.
• 2x 14-way header pins and socket – PH5/9.5mm headers recommended (see below).
• Header pins.
• 1x 1N5817 Schottky Diode.
• 1x 10Ω resistor.
• 1x 47uF electrolytic capacitor.
• 1x 2×8 way shrouded pin header socket (EuroRack power).
• M2 mounting posts, screws, nuts as required.
• Jumper/connecting wires.

Power supply circuit (Pico only):

• L7805 regulator.
• 1x 1N5817 Schottky Diode.
• 1x 47uF electrolytic capacitor.
• 1x 100nF ceramic capacitor.

Note the above are the minimal set of components required before actually building in specific circuits.

A note on headers. I’m using “PH5 short profile” headers which don’t stick out as much as normal headers. I’m matching these with 9.5mm long header pins. The difference can hopefully be seen below.

Note: there are “PH3.5” headers too, which need 7.5mm long pins, but I’ve stuck with the PH5.

Some typical components required for the actual circuit modules are as follows. The quantity and values will vary according to the actual circuit built of course.

• BAT43 Schottky diodes.
• MCP6232 OpAmp and (optional) 8-pin DIP socket (for PWM audio output).
• 2N3904 NPN general purpose transistors (for Gate/Trigger IN).
• Resistors – various.
• Ceramic capacitors – various.
• Electrolytic capacitors – various.
• Potentiometers, jacks, switches, etc. – as required.

Build Steps

Taking a typical “low to high” soldering approach, this is the suggested order of assembly for the MCU board:

• Resistor and diode(s).
• Regulator (if used).
• Capacitors.
• Microcontroller headers.
• Eurorack power header.
• PCB connecting headers.

The order of assembly for the IO board will depend on the components and circuit being built, but it is recommended that the connecting headers are soldered on before any connections are made from the rest of the board to the header.

This is the general suggested order of assembly for the IO board.

• All diodes.
• All resistors.
• DIP socket.
  • Note: one of the capacitors has to be fitted within the footprint of the DIP socket. This is probably easier to do on the rear of the board and possibly prior to fixing the DIP socket.
• Disc capacitors.
• Transistors or regulator.
• Pin headers.
• Electrolytic capacitors.
• PCB connecting headers.
• Inter-circuit connecting links (if not using headers).

Be sure to check the components are being soldered to the correct side of the boards. Most of the components (apart from the connecting headers) for the MCU board are on the rear. Most of the components (apart from the connecting headers) for the IO board are on the top side.

Any controls (potentiometers, switches, jacks, and so on) will have to be fixed to the header connections on the IO PCB. It is possible to use header pins and jumper wires, but a better result will probably result from using directly soldered connections. YMMV…

If using my EuroRack panels, then there are GND and VCC rails that can be used to make adding IO controls easier, but these will need to be connected to the power rails of the IO PCB at some point too.

Here are some build photos for the Raspberry Pi MCU board.

Here are some build photos for the Arduino Nano board.

Here is the build photo for the IO board.

Generally, although it might be a little tricky to solder around the header, it is still advisable to solder the headers on before making the final intra-board links.

This is because it is highly likely that some of the patch cables will need to pass over the solder-side of the headers.

Alternatively it might be possible to make the intra-pcb links on the underside of the board, meaning all soldering can be performed “from the top”. In this case, it might be advisable to put the headers on first…

Testing

I recommend performing the general tests described here: PCBs.

It is strongly recommended that all unused EuroRack power connections are checked and verified that they are unconnected to each other, +12V and GND.

Then it is really down to checking the power supply is working and all of the MCU IO is correctly present on the IO board once both boards are connected.

It is strongly recommended that the board is tested on its own, completely independently of any other modules or an expensive EuroRack power supply. In fact, it is NOT recommended that these boards are used with any other modules or an expensive EuroRack power supply at all. They are designed for use with cheap, DIY systems only.

PCB Errata

There are the following issues with this PCB:

•  Nothing at present.

Enhancements:

• With hindsight, I’ve have probably added some GND/VCC connections on the IO board around the edge to make wiring up to panels and controls a bit easier.
• I could probably switch the position of the central mounting hole and shuffle some of C500, C550, C600, or C650 which would then probably allow for a companion mounting hole on the MCU board, where this is currently some spare space on the PCB.
• I thought to add some headers for power on the MCU board, but it might have been useful to include two headers – one on each side of the board – to allow simple jumpering across from one board to another, to save on the cabling requirements of every board being connected back into a EuroRack system and to pass on the 5V connection if required.
• I should have some panels produced with mounting holes in the right place to fit these PCBs directly.
• Alternatively a third PCB could be produced with mounting headers to connect to the audio, INPUT and OUTPUT headers of the IO board to support the mounting of pots, jacks and switches.

Find the IO and MCU PCBs on GitHub here.

Find the blank panel designs on GitHub here.

There are also some templates which can be used alongside the Usage Notes to document and design new circuits in the GitHub too.

Closing Thoughts

My boards power up. There is 12V and 5V largely where I expect it to be and both variants seem to power up their respective microcontrollers ok.

Kevin

#arduinoNano #EuroRack #pcb #raspberryPiPico

Arduino MIDI Master Volume Control

This project uses an Arduino Uno or Nano with a potentiometer to create a MIDI Master Volume Control.

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

These are the key Arduino tutorials for the main concepts used in this project:

• Arduino MIDI Library
• Arduino Read Analog Voltage

If you are new to Arduino, see the Getting Started pages.

Parts list

• Arduino Nano or Uno
• 10K potentiometer
• Ready-Made MIDI or a DIY MIDI Interface
• Breadboard and jumper wires

The Circuit

A potentiometer is connected to A0, 5V and GND. To help smooth out the readings a 100nF ceramic capacitor can be connected between A0 and GND.

A MIDI OUT circuit is required. If full software MIDI THRU is required, then a MIDI IN circuit is also required, but it is not necessary to work. In fact a simple “two resistor” MIDI OUT interface would do the trick too (see DIY MIDI Interfaces).

I’ve used my Arduino Nano Mozzi Experimenter Shield PCB simply because it has a built-in MIDI interface and readily available potentiometers, but most of the additional circuitry is unused in this case.

The Code

This is a variation of the Arduino Serial MIDI Program and Control Messenger in principle, but in practise there are significant differences. Whilst the MIDI Control Change messages include a volume control, it has been long considered that this should be treated as a “channel message volume control” and not meant for “whole device” operation.

Consequently, at some point it was decided that one of the System Exclusive, System Real-time messages would be reserved as a “whole device” master volume control. That is what is required here.

The MIDI specification describes the require message as follows:

The Arduino MIDI library includes a sendSysEx function which has to be given a byte-sequence containing the required message. If the last parameter is “true” then it expects the SysEx start and end bytes to be included in the message.

Note that this MIDI message is using the common MIDI method for higher resolution values – it splits a 14-bit value (0 to 16363) into two “almost bytes” of 7-bits each so this has to be accounted for in the code.

Also, as the control will come from an Arduino analog INPUT port the starting values will be 0 to 1023, so they need to be scaled to the required MIDI range. This all happens in the function below.

void setMasterVolume (int volume) { 
  uint16_t midivol = map(volume, 0, MAX_POT, 0, 16383);
  byte sysex[9] = {0xF0, 0x7F, 0x7F, 0x04, 0x01, 0, 0, 0xF7, 0};
  sysex[5] = midivol & 0x7F; // LSB
  sysex[6] = (midivol >> 7) & 0x7F; // MSB
  MIDI.sendSysEx(8, sysex, true);
}

I’ve also used, and slightly updated, the analog read averaging routine I used in Arduino PSS-680 Synth Editor- Part 2. This code maintains a “running average” reading to smooth out any jitters in the readings.

One thing I was finding though, especially at full-reading (1023), it was still quite jittery even with the smoothing, then I realised that this is because of integer arithmetic always rounding down to the last whole number. This means that no matter how many of the sampled readers were at the full value of 1023 if there was just a single reading of 1022 the rounding down would make the “average” also 1022.

The way around that was to use a single decimal place for each reading and then add 0.5 to the final averaged value to ensure it would also round to the nearest integer rather than round down.

To save having to move into floating point arithmetic I multiply the value by 10 giving me a pseudo single fixed-point decimal.

The complete averaging routine is thus as follows:

#define AVGEREADINGS 32
int avgepotvals[AVGEREADINGS];
int avgepotidx;
long avgepottotal;

int avgeAnalogRead (int pot) {
  int reading = 10*analogRead(pot);
  avgepottotal = avgepottotal - avgepotvals[avgepotidx];
  avgepotvals[avgepotidx] = reading;
  avgepottotal = avgepottotal + reading;
  avgepotidx++;
  if (avgepotidx >= AVGEREADINGS) avgepotidx = 0;
  return (((avgepottotal / AVGEREADINGS) + 5) / 10);
}

Notice how the analogRead() is multiplied by 10 and then once the average is calculated in the last line 5 is added (or 0.5 when we know it is a fixed-single-point decimal) prior to the final divide by 10 to get back into the 0 to 1023 range.

Coupling this with a capacitor across the signal of the potentiometer as shown in the schematic, this gives me a much more stable reading, which is important for a MIDI controller as it means there is no MIDI messages being sent unless something has really changed.

The code is using the MIDI serial transport which has MIDI THRU enabled by default. This means that the board could be used within an existing MIDI link by connecting both MIDI OUT and IN. This would add Master Volume control alongside whatever else is being transmitting and as the MIDI library works on the basis of complete MIDI messages, it should work relatively intelligently while merging the two MIDI streams.

Find it on GitHub here.

Closing Thoughts

There are many directions this code could go next. The obvious ones are:

• Include options for additional MIDI interfaces, especially USB MIDI.
• Support Master Balance in addition to Master Volume.
• Switch to a rotary encoder rather than a potentiometer.

Kevin

#arduinoNano #arduinoUno #masterControl #midi #potentiometer #sysex #systemExclusive

EuroRack 6HP MCU Experimenter Module

I’ve been following the work of HAGIWO for some time and always been really impressed with the breadth and range of modules they produce. I have noticed some patterns in their microcontroller based modules and so wondered if it was possible to build some kind of generic template PCB that would allow me to do some experimenting whilst reducing the number of links and connections required between components compared to using protoboard.

• Note: HAGIWO now has a SMT general purpose 4HP Arduino EuroRack module of their own – the “MOD1” now available via Patreon, and a lot neater than mine – full details here: https://note.com/solder_state/n/nc05d8e8fd311

This is the result.

• Part 1: EuroRack 6HP MCU Experimenter Module PCB Design
• Part 2: EuroRack 6HP MCU Experimenter Module PCB Build Guide
• Part 3: EuroRack 6HP MCU Experimenter Module Usage Notes
• EuroRack 6HP MCU Pots and Jacks PCB Design and Build Guide

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

These are the key materials for the main concepts used in this project:

• HAWIGO’s Repository of DIY EuroRack modules.
• Doepfer EuroRack Construction Details.
• Doepfer EuroRack Technical Details.
• HAGIWO’s own generic PCB used for a dual EG.
• HAGIWO’s “MOD1” generic module design. 

If you are new to electronics, see the Getting Started pages.

The Circuit

I wanted to include the following elements:

• Microcontroller interface – ideally an Arduino Nano or a Raspberry Pi Pico.
• PWM audio output stage.
• Gate/Trigger input and output stage.
• CV input and output stage.
• EuroRack compatible power connector.

I wanted suitable protection on the various stages, so have essentially correlated some of the circuits put up by HAGIWO and pulled out a range of elements into my schematic. I’ve been looking through the designs for the following:

• XIAO RP2040 VCO.
• AD9833 LFO/VCO Re-build.
• Euclidean Rhythm Sequencer.
• 2OSC Mozzi VCO.
• Mozzi FM.
• Additive VCO.
• Chord VCO.
• Overflow folding VCO (XIAO).
• General PCB from the Arduino Dual Envelope Generator.
• “MOD1” generic SMT Arduino module.

Although the basic template for many of HAGIWO’s designs are very similar, often specific component values might be tweaked, so I wanted to ensure there was nothing too prescriptive in the design here to prevent tailoring.

In the end I used some specific component values from certain circuits in the schematic itself, but really they are just an example starting point. The values required will depend on the expected input and output levels and whether converting to/from 5V or 3V3 operation.

For reference, common EuroRack voltages are (from the Doepfer Technical Specification):

• Audio signals: 10Vpp i.e. -5V to +5V.
• Modulating Control Voltages: 5Vpp i.e. -2.5V to +2.5V (LFOs); 8Vpp i.e. 0V to +8V (EGs).
• Trigger/Gate: 0 to 5V, although up to 12V should be accepted.
• Pitch Control Voltages: Typically 1V/octave.

Key design principles for the control board:

• Will allow for a 5V Arduino Nano or a 3V3 Raspberry Pi Pico, with the circuits VCC taken from the power output of the microcontroller (so 5V or 3V3 respectively).
• Powered from the EuroRack +12V either into VIN of the Arduino Nano or via a L7805 generating 5V into VSYS of a Raspberry Pi Pico.
• Anticipating that not everything will fit on a single board, there is a header interface between the microcontroller and everything else.
• The connections to each of the circuit stages is via headers or blank solder pads, allowing patching across to any microcontroller pins as required.
• There is no support for controls, pots or jacks on the board, it is assumed those will be added to a panel and patched across to the control board using headers.
• Some mounting holes will be provided.
• Only the components and circuit blocks required for a specific build will be used. If using an Arduino Nano, this includes being able to omit the L7805 and associated power circuitry as it can be powered from +12V into VIN.

A future post of usage notes will go into the detail of each circuit element a little more.

EuroRack Power

I was pretty keen to include some protection for the EuroRack power side of things, following some of the advice from here: https://www.youtube.com/watch?v=cBGyEBQnIws.

The problem is that although it is possible to protect the 10-pin version of the EuroRack power connector from reverse connection, it is a lot harder to do with the 16-pin version.

Pinout from the Doepfler Technical Specification (note -12V is “pin 1” and usually denoted by the stripe on the cable – but not always!):

For the 10-pin version we essentially just have to cope with +12V and -12V being the wrong way round. With the 16-pin version it isn’t that simple and there are several problems if a cable is plugged in the wrong way round:

• The CV/Gate signals will overlap with -12V and GND.
• The 5V connection will overlap with GND.
• The +12V connection will overlap with GND.
• As there are three sets of GND pins, typically all connected together, the +12V and +5V of the power supply and any other modules in the system will be connected together!

That last one is very likely to cause damage to any module or power supply plugged into the rest of the rack. The worst-case scenario is that it could damage the PSU and ALL other modules in the rack… none are going to like receiving 12V when 5V is expected… err…

As this is a PCB designed for DIY experimentation, I wanted to ensure that the chances of a serious problem with any other kit it might be hooked up to are minimised.

But I should repeat at this point: do NOT use this module alongside any other expensive equipment or rack or power supply. It is meant for DIY experiments only and should only be connected to other DIY or otherwise sacrificial equipment.

Still, I’ve only “wired up” the following of the EuroRack power support connector:

In particular note that I’m only using one of the GND connections – the others are left not connected or linked at all, and especially not to each other. This means that should a cable to plugged in the wrong way round, there is nothing on my PCB that will bridge +5V and +12V via GND; it also means I can include some basic protection against +12V and GND being the wrong way round.

I’m also planning to use shrouded connectors, but of course that won’t guard against incorrectly wired cables or other weirdness.

I was in two minds about attempting to use the +5V rail, but as I couldn’t find any advice online about how to protect that, I just opted for the use of a L7805 and the +12V rail, which I was planning to use anyway as it seemed more “universal” than expecting a 5V too.

The final power related part of the schematic is thus:

PCB Design

I’ve deliberately designed this onto two boards – a MCU board and an IO board, with headers between them. The power circuit is part of the MCU board. The idea is that all of the components on the MCU board are on the underside; all the components on the IO board are on the top side; that they will link together; and that the power connector will be on the underside and all IO connections (jacks, pots, etc) on the top.

I’ve also overlapped the footprints of the Nano and Pico and linked up GND and VCC (5V for the Nano and 3V3 for the Pico), so either could be used.

I’ve deliberately kept the size of the PCBs below 30x100mm, but will get these built as two individual designs. But keeping it within 6HP and 100mm has made for a very packed board!

In terms of silkscreen labels, each section of the schematic has a specific numbering scheme – for example, all components associated with the first PWM circuit are numbered between 100-199. Similarly for all the other sections.

But this is not a PCB that is meant to be populated without referral to the schematic and some bespoke design on a per-board basis.

Closing Thoughts

This is not a board to be soldered up and just used. It is a template, meant to remove the need for some connections, with some commonly used “circuit patterns” allowing easy connection to a microcontroller and EuroRack power supply.

But I’m quite pleased with how I’ve done my best to minimise the chances of this board causing a problem with other DIY modules in a rack.

But for this more than any other boards – the usual warning applies. Do not use with expensive equipment. Test thoroughly, double check cable wiring, and do not use alongside other expensive modules in an expensive rack of kit.

In a future article, I’ll go through some notes on how I expect to be using it.

Kevin

#arduinoNano #EuroRack #HAGIWO #pcb #raspberryPiPico

Here are the build notes for my Nano MIDI Proto PCB.

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

Bill of Materials

• Nano MIDI Proto PCB (GitHub link below)
• 6N138 opto-isolator
• 1x 1N4148 or 1N914 signal diode
• 4x 220Ω resistors
• 1x 4K7 resistor
• 2x 100nF ceramic capacitors
• 1x 100uF electrolytic capacitor
• 2x 15-way jumper header sockets
• 1x 2.1mm barrel jack socket (see photos for footprint)
• Optional: power switch (2.54mm pitch connectors)
• Optional: DPDT slider switch (2.54mm pitch connectors in 2×3 arrangement)
• Optional: 8-pin DIP socket
• Jumpers and header pins
• 2x PCB mount 5-pin 180 degree DIN sockets (see photos for footprint)
• OR 2x 3.5mm stereo TRS jack sockets (see photos for footprint)

Build Steps

Taking a typical “low to high” soldering approach, this is the suggested order of assembly:

• All resistors and diode.
• DIP socket (if used) or opto-isolator.
• TRS sockets (if used).
• Disc capacitors.
• 3-way jumper headers or alternative.
• Arduino 15-way headers.
• Barrel jack.
• Electrolytic capacitor.
• DIN sockets (if used).

Here are some build photos.

I used a DPDT slider switch with 2.54mm pitch leads in place of the MIDI disable jumpers.

If TRS sockets are being used rather than DIN sockets, then they should be placed next.

When soldering the Arduino headers it is useful to have an Arduino Nano to plug them into to ensure they are properly aligned.

If using MIDI DIN sockets, then they are the last things to be fixed.

Testing

I recommend performing the general tests described here: PCBs.

It is worth testing with both USB power and 7-12V barrel jack (but not at the same time of course) and ensuring 5V and GND are correctly broken out to the prototyping area in each case.

The Simple MIDI Monitor can be used to check the MIDI IN and OUT is working successfully. It will indicate MIDI IN activity whilst also performing software THRU functionality back to the OUT port.

PCB Errata

There are the following issues with this PCB:

•  None known at present.

Enhancements:

• It might be possible to mirror the layout of a mini solderless breadboard on the prototyping area to make transferring designs from breadboard to protoboard easier.

Find it on GitHub here.

Closing Thoughts

This is a fairly simple board, and despite the somewhat hacky nature of the PCB design itself, I’m pretty pleased with the result.

Kevin

https://diyelectromusic.com/2024/10/29/nano-midi-proto-pcb-build-guide/

#arduinoNano #midi #pcb

I wanted a simple way to prototype some circuits on an Arduino Nano – and thought I’d built up a prototyping board – but it turns out I haven’t! I have an Arduino shield (more here) and a prototyping board for the XIAO (here) but so far not a Nano. This post fills that gap.

• Find the Nano MIDI Proto PCB Build Guide here.

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

The Circuit

The circuit itself is fairly straight forward. There is a standard, 5V, MIDI IN and OUT circuit, a power barrel jack to power the Arduino via VIN, and a set of headers.

Jumper headers are included to disable the MIDI circuit to allow uploading to the Arduino Nano.

A prototyping area will be added using the footprint editor as the PCB is designed and all the IO pins will be broken out to headers.

PCB Design

First an admission. I’m afraid there is nothing “clean” about this PCB design. There are so many design rules check failures due to overlapping footprints, silkscreen clashes and the cut-and-paste method I used to create the prototyping area.

But this is one of those times when the time to do this cleanly is quite significant compared to the time it took for me to hack this together!

My main aim was to get the IO pins and power off the Nano into close proximity of the prototyping area. I’ve ended up with a design that has 5V and GND across the top, most of the IO down the left hand side, and the remaining across the bottom with more GND connections.

I’ve added a separate header to add VCC, 3V3 and AREF just in case that is useful too.

The power switch and MIDI disable headers all use a 2.54mm pitch footprint and both can be replaced with slider switches if required. Of course both can also be omitted and replaced with direct solder links if required too.

Closing Thoughts

Despite the somewhat hacky nature of this board, I’m actually quite pleased with the result. This should be really useful alongside my other Nano based boards.

Kevin

https://diyelectromusic.com/2024/10/29/nano-midi-proto-pcb-design/

#arduinoNano #midi #pcb

Here are the usage notes for my Proto Pedal PCB Design.

• Part 1 – PCB Design and Introduction.
• Part 2 – PCB Build Guide.
• Part 3 – Proto Pedal Usage and Application Notes.

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to electronics, see the Getting Started pages.

Errata Implementations

These notes are assuming that the jack socket wiring has been corrected.

This is the issue that if the bypass switch is activated with no jack plugged into the OUT socket then the IN signal will be shorted to GND.

Power Supply Jumper Settings

There are two main ways to power the board.

1. 7-12V power via 2.1mm barrel jack and on-PCB regulator.
2. 5V power from a microcontroller.

There are options to support use with or without a microcontroller, and options for either 5V (e.g. Arduino Nano) or 3V3 (e.g. Raspberry Pi Pico) microcontrollers.

Here are the required jumper settings for the various options (yellow box filled = jumper on; yellow box hollow = jumper off):

The “3V3 IO” jumper is there to control the audio levels sent to the microcontroller, not actually related to how either the PCB or microcontroller is powered itself.

The PCB circuit always requires 5V which can come from either the on-PCB regulator or a 5V output from a microcontroller. Any USB powered 3V3 microcontroller usually provides access to the USB’s 5V supply.

The power provided to the microcontroller can come from either the 5V line (from the regulator) or the RAW power input from the barrel jack (typically 7-12V) – labelled VIN on the power jumper.

Some examples:

• Arduino Nano: Use the VIN (RAW) output connected to the Nano’s VIN.
• Raspberry Pi Pico: Use the 5V output connected to the Pico’s VSYS.

Powering the Breadboard from the Regulator

The power rails of the solderless breadboard can be powered from the PCB using the 5V and GND from the PCB-based regulator.

This is useful for prototyping circuits that do not require a microcontroller.

Powering the Breadboard from the Regulator with an MCU

If a 3V3 microcontroller is being used, then the breadboard should be powered from the microcontrollers 3V3 output instead. Otherwise, the 5V line from the regulator can be used as before.

Here is how to use a Raspberry Pi Pico (5V to VSYS, then 3V3 to breadboard) and an Arduino Nano (VIN to VIN then 5V to breadboard).

Powering the Breadboard from the MCU’s USB

It is possible to power the PCB and breadboard from the microcontroller’s 5V USB connection.

IMPORTANT: As previously mentioned, ensure the “REG EN” jumper is removed to prevent any possible “back powering” of the regulator.

The following shows how to do this with a Raspberry Pi Pico (VBUS to 5V, 3V3 to breadboard) and an Arduino Nano (5V to 5V, 5V to breadboard).

Powering the Prototyping Area

If the prototyping area is being used then there are two solder bridges that can be used to connect one or both positive power rails to 5V and one or both negative rails to GND.

By default the prototyping rails are NOT connected to anything else.

Patching into 5V or GND is left as an option to allow for the use of a 5V, 3V3 or no microcontroller as required.

The prototyping area is principally there to allow for easy mapping of a solderless breadboard design over to a soldered design. In that respect, the connections between the prototyping area and the VIN-5V-GND jumper would be the same as when using the breadboard.

The solder bridges are provided as a convenience for when a simple 5V power scheme is in use to avoid the need for longer wires to the power rails.

Audio Connection Options

There is a 4-way header socket to provide links between the PCB-based circuitry and the breadboard. There are two additional jumpers that enable access to the “raw” audio signal too, bypassing the PCB-based circuitry, but still subject to the “stomp” switch bypass action.

The headers are (from left to right):

• RAW INPUT jumper (jumper on = link to ADC input circuit).
• Connection to MCU ADC.
• Connection from MCU PWM: PWM0 then PWM1.
• GND
• RAW OUTPUT jumper (jumper on = link to PWM output filter circuit).

Audio Input

The PCB includes a pre-amp stage to take a guitar signal level and amplify it up to something that is useful for a microcontroller’s analog input. The potentiometer is used to set the gain and some experimentation is likely to be required.

The ADC signal will be DC biased to 2.5V (3V3_IO jumper off) or ~1.7V (3V3_IO jumper on) with the peak to peak amplitude set by the gain potentiometer. If the gain is set too high then clipping will occur at 0V and 5V in either mode.

If a microcontroller isn’t being used and access to the RAW guitar signal is required, then it can be obtained by removing the RAW IN jumper and patching a jumper wire to the RAW pin.

Note that the “stomp” bypass switch will still operate on the RAW signal too.

Audio Output

For output, it is possible to provide a dual PWM signal output which then passes through a filter and buffer before hitting the output jack.

Again, if a microcontroller isn’t being used then a RAW signal can be sent out by removing the RAW OUT jumper and patching a jumper wire directly to the RAW OUT pin. And again the “stomp” bypass switch will still act on the RAW signal.

The PWM output assumes the use of two GPIO pins to provide additional resolution to the digital to analog conversion. The theory is fully described in this tutorial from Open Music Labs.

The short version is that the two outputs are effectively a “most significant byte” and “least significant byte” which are then summed. Key to this working is the ratio of the two resistors used in the mixing, which is why 1% tolerance resistors were used to try to keep this ratio as accurate as (economically) possible.

Referring back to the schematic and comparing it with the notes from Open Music Labs:

We can see that the ratio of resistors is given by 4,700 / 300,000 which is pretty close to 64. This is 2^6 so it is allowing for a 12-bit audio output resolution with the most significant 6-bits on PWM0 and the least significant 6-bits on PWM1.

When used with the 6.8nF capacitor, we end up with a cut-off frequency (again see the OML tutorial) for the filter of:

freq = 1 / (2.PI.R.C) = 1 / (2 x PI x 4,700 x 0.000,000,006,8) ~= 5KHz

This is essentially what Electro-smash did for their PedalPi. Their original PedalShield used a larger resistor for PWM1 (1M2) and aimed for twin 8-bit resolution.

Example Microcontroller Audio Connections

Here are examples using the Raspberry Pi Pico (ADC0, GPIO10, GPIO9) and an Arduino Nano (A0, D9, D10).

RAW Audio Input and Output

Removing the RAW jumpers gives access to the unprocessed, raw audio from the IN jack and direct access back to the OUT jack. As previously mentioned the “stomp” bypass switch will still function on the RAW signals – i.e. it will enable or disable the RAW signals as part of the bypass function.

If the pre-amp is required, then the ADC pin can be used for the amplified input and then the output still sent directly to the OUT jack if required.

Example Arduino Software Pass-through

Using the Arduino Nano audio link up as shown above a simple audio-passthrough test can be performed by configuring PWM access on pins D9 and D10, which both use Timer 1, and then taking the value read from an analog input and writing out over PWM.

To configure PWM for both pins requires the following code:

void initPwm() {
  pinMode(9, OUTPUT);  // OC1A output
  pinMode(10, OUTPUT); // OC1B output
  TCCR1A = _BV(COM1A1) | _BV(COM1B1) | _BV(WGM11);
  TCCR1B = _BV(WGM13) | _BV(WGM12) | _BV(CS10);
  TCCR1C = 0;
  ICR1 = 63; // 6-bit resolution
}

This configures Timer 1 for Fast PWM Mode, running at the MCU system clock speed (no “prescalar”) with outputs enabled for OC1A (D9) and OC1B (D10). The resolution for PWM is set to 6-bits, so the internal counter will count from 0 to 63 and then reset.

This means that software can write a value between 0 and 63 to the OCR1A or OCR1B registers to set the duty cycle for the PWM output between 0 and full. To write out a full 12-bit value requires splitting over these two registers as follows:

void setPwm (uint16_t pwmval) {
  OCR1A = pwmval >> 6;   // Most significant 6-bits
  OCR1B = pwmval & 0x3F; // Least significant 6-bits
}

Then it is simply a case of free-running in a loop a continual read of the analog input and write out to PWM, converting the 10-bit analog value to a 12-bit value on the way.

void setup() {
  initPwm();
}

void loop() {
  uint16_t val = analogRead(A0);
  setPwm (val<<2);
}

In the following trace the blue trace is the signal at the IN jack and the yellow trace is the signal at the OUT jack. The gain has been adjusted to make them essentially the same amplitude.

Find it on GitHub here.

Closing Thoughts

This is a new venture for me, so it remains to be seen if this is actually any good!

But a massive thanks must go to Electro-smash for their PedalShield and PedalPi projects, and for open sourcing the designs, as that information has given quite a leap forward in even starting on my own design – most of the analog circuitry is based on PedalPi.

I might have been tempted to have just bought one of their kits, but they are not currently available (in the UK at least).

But this way, it gives me a chance to learn some new things and make some (more) new mistakes.

Kevin

https://diyelectromusic.com/2024/09/10/proto-pedal-pcb-usage-notes/

#arduinoNano #effects #guitarPedal #pcb #prototyping #raspberryPiPico

One (other) thing I was toying with experimenting with is the whole world of DIY guitar pedals. I don’t know much about them but wanted a platform I could use for experimentation.

• Part 1 – PCB Design and Introduction.
• Part 2 – PCB Build Guide.
• Part 3 – Proto Pedal Usage and Application Notes.

I was intrigued by the Electro-smash DIY pedals based around various Arduino boards or a Raspberry Pi Pico, but they don’t seem to be available anymore and the support forums seem to have dried up.

But as the designs are all open source, I was able to take a look at the design and function and get an idea of what I might want myself. Unfortunately the full open hardware design files are not available on Github (anymore?) but there are quite a few details still on their website about the designs and design process.

So this is my attempt at a prototyping platform for guitar pedals that could support design with either a microcontroller or analog circuits. I’ve found many archives of schematics online and I want a platform that will help me try some of them out.

This might be a one-off – I don’t know yet if this is something I plan to do more of – there is so much to try and learn about (see some of the references below).

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

Here are some references for DIY guitar pedals:

• https://www.diystompboxes.com/ – and a large list of schematics
• https://www.freestompboxes.org/
• https://stompboxschematics.com/

And some suppliers of DIY kits in the UK (I’ve no experience of these, they are just some examples from browsing around):

• Pete’s DIY Guitar Effects Pedals and the Ultimate Beginner’s Guide
• Jed’s Peds
• Fuzz Dog’s Pedal Parts

If you are new to electronics, see the Getting Started pages.

Introduction / Key Requirements

I want something that can achieve the following:

• Includes pre-amp and post-processing circuitry to support use of microcontrollers at 3V3 or 5V levels (I’m basing this on the fact the Electro-smash pedals include them).
• Includes a prototyping area and easy to use with solderless breadboards.
• Includes the IN and OUT standard (1/4″) mono jacks.
• Has a stomp-switch with a “true bypass” function.
• Can fit in a common pedal enclosure (e.g. the Hammond 1590BB).
• PCB within the 100x100mm cheap limit for PCB manufacturing.
• Includes a 2.1mm barrel jack for power.
• Mounting holes, especially to support the stomp-switch.

Things that would be nice:

• Optional smaller variant for use with smaller enclosures (e.g. the Hammond 1590B).
• Optional – pre mounted, ready to use, potentiometers and switches.
• Easy way to make a solderless breadboard circuit permanent.

The idea is to design a PCB that has space for mounting a solderless breadboard but also the holes and prototyping area that matches the solderless breadboard layout to make it easy to turn a design into a soldered version.

The Circuit

The input and output stages are largely taken from the Electro-smash discussion of their own designs. The MCP6002 is a rail-to-rail opamp and will be running at 5V.

Note that the PWM implementation is a twin-PWM output solution. There is a detailed tutorial on how this works at Open Music Labs. Key to this working correctly is an accurate ratio of those two resistors (4K7 and 300K). Consequently I’ll be using 1% tolerance resistors for these. The filter stage is designed to work with a 5KHz cut-off frequency.

I’ve included a “true bypass” stomp switch. There are loads of references out there for how to wire up the 3-pole, double-throw (3PDT) switch to support this, including an LED to show when the effect is active. I can’t remember exactly which site I used in the end, but the variant I wanted to end up with is as follows:

But for some reason (getting interrupted at a crucial moment I expect) I ended up with a slightly simpler version (see schematic). The downside of the simpler version is that the “circuit in” isn’t automatically grounded when inactive. I’ll have to wait and see if that becomes an issue or not…

It appears fixable with a few cut traces and a couple of patch wires though if so.

In terms of power, I wanted to support various options. Ideally:

• The option for power from a 2.1mm barrel jack – so I’ve included a L7805 regulator.
• During prototyping, if using a microcontroller, then the option for power from the microcontroller’s USB port.

I’ve ended up with two jumpers:

• A bias jumper. The input opamp circuit needs a bias voltage that is half of the MCUs expected ADC voltage. There is a jumper to patch in an additional resistor to set the bias voltage to either 2.5V or 1.5V for the case of a 5V or 3.3V MCU, even though the opamp itself is always powered from 5V.
• A MCU/regulator jumper. There is the option to power the whole circuit from either a MCU’s 5V output (even a 3V3 MCU with USB usually has an option for 5V out) or from the regulator on the PCB.

There are additional header points to support connections to the MCU ADC input and PWM outputs, including an extra GND connection.

There are also solder headers to allow for 5V and GND to be patched into the prototyping area if required. These aren’t always enabled as in some circuits these rails might be used for other purposes or a non-5V power rail.

Finally, it is also possible to receive the raw signal input and patch directly to a raw signal output bypassing the opamp circuitry if required.

PCB Design

This board required two custom footprints. There is a 3PDT switch footprint in a library provided by Sparkfun but it didn’t look like the through holes were big enough or the right shape for my switches. Consequently I turned the holes into ovals as can be seen above.

I also couldn’t find anything that approximated a solderless breadboard layout for my prototyping area, so I created a footprint for the entire layout. The issue I had was how to create the tracks between holes. In the end I used elongated SMT pads on the same nets.

One downside of this that I hadn’t considered until the boards came back – SMT pads include a footprint in the solder mask layer, so my copper connections between pads are not covered in mask. That is something I can fix in a future footprint revision.

I did manage to get everything within a 100mmx100mm PCB size though, including mounting holes, so I was pretty pleased about that. I positioned two mounting holes either side of the stomp switch to support it, but really most of the pressure on the switch ought to be taken up by a sturdy case.

It was a challenge to be able to include all the jumpers in useful positions for ease of access to the breadboard area. The one compromise is that the power jumper is part selector and part jumper header. There might be a tendency to assume the jumper part is an “either or” – but if the jumper is swapped from one side to the other, then it will end up shorting 5V to GND.

This isn’t ideal, and leaves the potential for user error relatively high, but I couldn’t fit everything in any other way.

I’ve added a number of notes for the power options especially on the silkscreen on the rear of the board.

The power switch has a three-pin, 2.54mm footprint and there is always the option for mounting some of the connectors, LEDs, and switches directly to a case and connected back to the PCB using wires. I anticipated the LEDs would probably be bent over anyway to appear from the bottom of any box, next to the power socket and on/off switch.

One last thing to note – the two standard 1/4″ jack sockets are stereo sockets as they were more readily available, but the “ring” is not used – just the tip and screen. This means they are essentially mono sockets and will accept a standard guitar mono jack lead.

Closing Thoughts

This is a learning project right from the outset so it’s no wonder there are already a few issues to consider for next time.

If I was more disciplined, I’d do this write-up before sending off a PCB to be made, as it acts as quite a significant “design review” stage. It is almost as if actually designing the thing properly up front has some uses 🙂

But once a PCB seems “done” I’m doing well if I manage to leave it overnight before sending it off! Although I do try to stick to that rule if I can.

And finally a bit thank you to Electro-smash for (at least initially) publishing their open hardware designs for their PedalShield and PedalPi.

Kevin

https://diyelectromusic.com/2024/09/10/proto-pedal-pcb-design/

#arduinoNano #effects #guitarPedal #pcb #prototyping #raspberryPiPico

И снова я сломал атмегу через все ту же #progisp + #usbisp :blobcatjoy: играя настройками фьюзов - Ext.CrystalOsc, но эта "игра" неспроста, после того как я заново оживил контроллер, решил прошить нормально через #usbasp и #avrdudeprog но тут же получил ошибку, даже калибровочные ячейки генератора считать не удалось. Пришлось искать методом тыка ту самую настройку внешнего кристалла в PROGISP :blobcatgrimacing: кажется теперь все серьезно, контроллер не откликается, хотя на выводах #rx_tx есть потенциал... Придется опять отложить контроллер в сторону или уже не суетиться и заказать новую #arduinonano или #arduinoUno или просто закупить #atmega328p и перепаять
#embedded
#troubleshootingfail
#electronics

2024 Tiny Games Contest: Mini Cyclone Tests Reaction Time https://hackaday.com/2024/08/29/2024-tiny-games-contest-mini-cyclone-tests-reaction-time/ #2024TinyGamesChallenge #reactiontime #arduinonano #contests #Games

2024 Tiny Games Contest: Blind Maze Is Fun For All https://hackaday.com/2024/08/29/2024-tiny-games-contest-blind-maze-is-fun-for-all/ #2024TinyGamesChallenge #arduinonano #contests #Games

ШИР - Широтно-импульсный регулятор. Реализован не в #arduino среде, тут только #c #avrgcc #avrdude и #atmega328p Хотел проверить сервопривод, но он кажется мертв... Но, я надеюсь что со специальным устройством проверки он вдруг оживёт :ablobcatnod: AMEN
#embedded
#circuitry
#avr
#atmelstudio6
#servo
#pwm
#sourcecode
#oscilloscope
#testproject
#breadboard
#arduinonano

A Throne for LEGO Baron Harkonnen https://hackaday.com/2024/07/22/a-throne-for-lego-baron-harkonnen/ #ArduinoHacks #steppermotor #arduinonano #ToyHacks #automata #arduino #stepper #dune #lego

Simple Version of Pong Played On a Row of LEDs https://hackaday.com/2024/07/15/simple-version-of-pong-played-on-a-row-of-leds/ #ArduinoHacks #arduinonano #LEDHacks #1DPong #Games #pong

Learning Morse Code with a DIY Trainer https://hackaday.com/2024/06/22/learning-morse-code-with-a-diy-trainer/ #arduinonano #RadioHacks #arduino #display #trainer #morse #radio #cw

The internet can be a really wonderful place. I was looking for an adapter which enables me to use old Joysticks and Gamepads with a #GamePort connector on my #Amiga computers. #eqUInput sounds promising:

"eqUInput is a PCB for Arduino Nano based PS/2 mouse or PC Gameport joysticks to Amiga mouse adapters"

https://github.com/opengiveback/eqUInput

I'm wondering how well this adapter will work specifically for using joysticks and gamepads on the Amiga. I've ordered a handful of PCBs, some #Arduino Nano clones and the connectors and will probably get to it in round about three weeks. I'll report back on my success or failure. ;) I'm not a pro in electronics, just a hobbyist. So everything is possible. Especially since the project is described as experimental.

#ArduinoNano #OpenHiveBack #Gamepads #Joysticks