BiTonal Tesla coil MIDI controller

The issue with my current tesla coil, and most of the Musical tesla coils we seem to see online, is that for the most part they only seem to be able to do a single frequency at a time. So if you wish to have more than one frequency at a time, to produce more complex music you need more coils. (See FranzoliElectronics for some amazing musical Telsa coil demonstrations).

I say this, not because I know for sure, but because I suspect it from noting what other coils sound like. I believe this issue comes from the way that these tesla coils are operated. More specifically how the controller is designed. Again, I have limited information on what every Tesla coil operator uses, but I base my analysis (and my initial design) on this design sold by LoneOceans. While he has some outstanding Tesla coils, this MIDI controller was a bit lacking (to me). The interface was purely through the use of potentiometers (which I do not like for noisy environments, and the lack of repeatability). He relies on the use of a USB to MIDI converter, which I did not want to buy. Further the channels are fixed, and cannot be changed, unless you edit the MIDI files, which was too painful. Lastly, when I asked for the source code of his controllers, he would not give up the secrete source (code).

Old Design.

When looking at the midi controllers I could find online, there was one common element, an ATMEL microcontroller (Arduino). This makes sense, for most people these are the easiest to learn and program with. However this ease of use, makes them particularly difficult to work with.

Personally I have never truly been a fan of the ATMEL series of processors, while they are easy to use, I find the development environment outside of the Arduino environment painful. Given how the Lone Oceans controller uses two Atmega328s, I have a suspicion that the code base is similar to my initial attempts. I however did not want to rely on an external USB to MIDI device, being suspicious of driver support and noise susceptibility) and preferred a direct connection to a computer. I, for one, would not be too keen to use my keyboard, near a Tesla coil!

My initial attempt using an Arduino Uno, used the timer as a base for the Enable signal and then a second timer to set the frequency. This worked ok and allowed me to get an initial prototype up and running. But I wanted more (of course).

The design of my first prototype used the USB-Serial of the Arduino Uno through LoopMidi (Used to loop the midi signals back into the computer) and Hairless Midi (used to take the midi signals to a Serial port) to get the midi commands into the Microcontroller. All setpoints, for fixed frequency operation and for MIDI operation were editable from the LCD on the box. Delay could be (somewhat) accurately set from the display in steps of 10us. Which for my DRSSTC was good enough. Emphasis on was…

This design used an LCD screed for display, a rotatory encoder as an input and a “Deadman’s switch” to enable or break the Fibre optic connection (So that we don’t rely purely on the software). Also included , for dramatic effect was a large switch with a cover. When closed, it holds the microcontroller in reset, just as an additional measure.

These were connected to the Arduino via a custom shield made from proto Veroboard and ribbon cables. This was done to give me a rapid initial prototype, with the knowledge I would be later revisiting the microcontroller.

Current design

Ever since the STM32F407 discovery board came out I was hooked. A cheaper more powerful microcontroller available for cheaper than the Arduino environment. A device family I have become more and more acquainted with. So when I discovered the STM32F411 Blackpill with a USB-C connection. I knew this would be perfect (as I privately detest the other common USB connectors, USB mini and micro USB). Combine into the microcontroller are 8 timers, Floating Point processing Unit etc.

Since I had an existing set of ribbon cables to the original components, I would need a new adapter from the microcontroller development board to the ribbon cables. This was fairly simple. A new enclosure was 3D printed for the base. This means that the final design would connect simply to a computer with USB-C cable and then be connected simply to the fibre optic connector.

The code was written, using the STM32Cube IDE software. This simplified the creation of the Virtual COM port using the USB port of the development board, which from experience… can be difficult.

The code includes a MIDI interpreter, which converts the Serial commands from the PC into the required frequency and “velocity” (volume). If the channel of the note, matches the channels selected by the user. The volume is scaled from 0 to max (127) of the MIDI standard, and then multiplied by the current nominal Pulse duration, set by the user. For example with a nominal pulse duration of 40us, a velocity command of 96, would result in a pulse duration of 30us). This was then passed through to the pulse generator.

Pulse generator

The pulse generator has three tasks.

  • Generate a fixed pulse of a fixed duration as determined by the code, with minimal jitter.
  • Repeat this pulse at a required frequency, or frequencies.
  • Ensure sufficient deadtime between two pulses, such that the Tesla does not stay on for longer than the pulse duration, with sufficient downtime to let the plasma generated by the arc dissipate. This also gives the IGBTs time to cool down.

This was achieved using a heavy reliance on interrupt driven code. A timer was responsible, in Single Pulse mode, of generating a pulse with a well defined on time and then a following off time. During firing the timer would not allow itself to be triggered again. This is the keypoint, again.

Dual/Multi Frequencies

When trying to figure out how to best drive one or more frequencies, I considered a range of techniques, however, I eventually decided on the easiest. I simply use a timer per frequency. Each timer runs, independantly at its requested frequency. When the timer resets, it throws an interrupt. This then attempts to fire the Pulse Generator. If the pulse generator is already busy, then the request is discarded. Naturally later work can be implemented to improve this. However, I have had great success with this for the time being.

Code/Schematics?

I have chosen not to document this particular version, as for other, more exciting reasons, I had the need to drive 2 Tesla coils at once.

I have been busy with that project and will be publishing everything used to get that running.

Till then!

Leave a comment