Happy New Year!

Many of you guys have been emailing us about the backorder status of our Thundermouse kit. We’re currently experiencing issues obtaining a critical part of the design. As of now, it looks like it may be June of this year before we can acquire all the materials we need in sufficient quantities.

The good news is that we have been using the time to improve the design and add features to the software. 

The bad news, supply chain issues, and inflation are likely going to require an adjustment to the price. All of the parts and materials are more expensive than a year ago. We’re unsure of what that is at the moment. 

In the meantime, we have been selling a small number of complete units to museums and science centers using the parts we’ve already had in stock. This has given us ample testing and feedback for improving the design!

While we are annoyed with the delay in getting this kit out to you guys, rest assured that we are otherwise keeping busy. Performances are starting to pick up somewhat, though not to pre-pandemic levels. We have been doing some contract engineering work on top of Tesla coil production to fill in the gaps.

Sign up for our email list, and we’ll make sure to send out Thundermouse updates as we know more!

Thundermouse Update!

Having a traveling Tesla coil show means having to understand other stage technologies. One often encountered issue is the effect that our machine’s EMI can have on DMX stage lighting. Before we can understand ways of mitigating these problems, we must first become familiar with RS485.

RS485 is so common that you have likely heard the term at least a few times. But what is it even, and what does it have to do with DMX? I’ll go into the details in this article and use what I learned to build a little DMX512 thingy with an Arduino. If you are looking for a complete solution for DMX lighting, check out our open-source MIDI to DMX converter.

What is RS485?

RS485 is a serial communication standard. It outlines what voltage levels and timings data should have when using it. Just like RS232, it uses asynchronous serial communication.

As you can see in the scope trace, there are three distinct phases of a byte:

  1. The “Start bit”: this is always 0 and allows the receiver to synchronize to the timing of the transmitter.
  2. The Data (8 bits): this is the content of the Message. The device reads the data at a fixed frequency, called the baud rate.
  3. The “Stop bit”: this is always 1 and allows the receiver to detect if its timing is wrong. It just checks if the stop bit is “1”. If it isn’t, it will give out an error.
RS485 scope

The stop bit error detection can be unreliable when the receiver’s baud rate is higher than that of the incoming data. In this situation, there is a data bit where the receiver expects a stop bit. If this is “1” by coincidence, the receiver won’t know that it made a mistake as the data looks just like a stop bit. For this reason, some protocols use two stop bits. It is much less likely for two data bits to be “1” after each other, so an error is more likely to be detected.

Balanced signal with RS485

Unlike RS232, RS485 is a symmetrical bus. This means that we have two data lines instead of one. The second one transmits the inverse of the main data line. The receiver detects the difference between the two and ignores absolute voltages. What this means is that it is much more immune to noise.

If some interference produces 2.5V on data lines, an RS232 transceiver would think the signal is always “1”. But with a symmetrical bus, the 2.5V would be induced similarly on both conductors, with the difference remaining the same. The receiver would have no issue decoding the data despite the interference. That’s why it’s used so much in industrial applications.

Another thing the standard outlines is the driver output impedance. At the high baud rates, transmission line effects start to cause problems with signal reflections on cable ends. With a known output impedance, it’s easy to design cables with a matching impedance that negates those effects. Those reflection problems are also why DMX networks are supposed to have a 120 ohm terminator at the end.

What RS485 doesn’t define is what data gets sent over the bus or what format it should have. You can send normal strings over it just as well as some complicated data packets.

So what does DMX512 have to do with this?

DMX512 is one of the protocols using RS485. It’s probably the most common standard for controlling stage lighting in use right now. If you buy any sort of controllable stage light, it probably supports DMX. When it was invented, computer hardware was slow, and ram was small, so it was designed to be as simple as possible. It’s also using RS485 because of its noise immunity, which is why I’m talking about it now 😋

Let’s look at another scope trace to understand how it works:

  1. The Break (or line-break): This is how DMX signals the start of a packet. Its long zero level guarantees that any receiver gets a “Stop bit, not zero” error. 
  2. The Start code: For normal DMX data, this will always be a zero. It’s there as a way to signal package types.
  3. The Data itself: these bytes contain the values for the individual channels.
DMX Protocol on scope

The amount of bytes sent differs between lighting desks/interfaces. The cheap Chinese ones, for example, may only send out 192 channels because their CPUs can’t keep up with anything more. The official spec puts a limit on the time between one break and the next. This limits the number of bytes to 513 slots (1 Start code and 512 Channels), hence DMX512. This is also sent with two stop bits for added fault tolerance.

Another thing to keep in mind is that many cheap DMX interfaces won’t adhere closely to the spec. Especially the length of the break if often shortened or not accurate in cheap lighting desks. Other controllers might have a lot of variance in the timing of the data. Most cheap lights also don’t check the second stop bit because it works and only reduces fault tolerance. But since all of those just impact the resilience to faults, it’s not that big a deal for hobby use. 😄

DMX Packet

One other thing to talk about is the connector. The DMX standard specifies a 5pin XLR connector but only uses three pins. And since 3pin XLR is cheaper and more common, many cheap lights use them instead.
This brings some problems with it, though. Audio cables don’t have a controlled impedance and are thus not matched to RS485 drivers. But since they are sometimes cheaper, people tend to use them for lights that have 3pin sockets too. This can cause signal reflections and make the entire DMX network go haywire. Some 3pin cables can also have some nasty voltages on them from certain audio equipment. Keep this in mind when you choose what connector to use. Even though I have never had any of those issues with the three-pin variant myself 😀

Using an Arduino to receive DMX

Now that we are experts in RS485 communications, we can get to the fun part:
making some LEDs blink over DMX with an Arduino 😎

First, we’ll need the hardware. To receive RS485 properly, the Arduino needs some help from a transceiver chip. I used an sn75176 differential bus transceiver, probably the most common one you’ll find anywhere. Since it can be a transmitter too, we need to tell it to receive. We’d risk damaging the transmitter on the other side if we tried to transmit 😉 We do this by pulling the two config pins !RE and WE to ground. We’ll also need a connector for the DMX data. I had a three-pin one lying around, so I soldered a pin header to it and plugged it into the breadboard.

Arduino DMX RGB example
RS485 to Serial pin diagram

You’ll need to connect the output of the SN75176 to pin0 of the Arduino if you’re using an UNO. This is because the data rate is too high for a software serial port. The library uses the hardware UART module. That means that you won’t be able to upload code with the transceiver connected as well.

Oh, and don’t forget to put a couple of LEDs onto the breadboard to control 😁 Then all we need is the software that receives the data. I just used the Conceptinetics DMX library. I used the following code to output three channels of PWM data depending on DMX addresses.
				
					#include <Conceptinetics.h>

DMX_Slave dmx_slave (3);

void setup() {  
  dmx_slave.enable();  
  dmx_slave.setStartAddress(1);
  
  pinMode(9, OUTPUT);
  pinMode(10, OUTPUT);
  pinMode(11, OUTPUT);
}

void loop() 
  analogWrite(9, dmx_slave.getChannelValue(0));
  analogWrite(10, dmx_slave.getChannelValue(1));
  analogWrite(11, dmx_slave.getChannelValue(2));
}
				
			

And that’s it! 

I hope this helped you understand RS485 and DMX a little better. If you have any feedback, we’d love to hear it 😀

DMX over RS485 with an Arduino

Some time ago, I saw an article on an old german website that talked about building a field mill to measure atmospheric electricity and other electric fields. I have always wanted to build one since, and I decided it was finally time this month. But since that article is almost as old as I am, I thought there must be some areas in which we can improve the design. Instead of just a box with a voltage output, I turned it into an ESP32-IOT Sensor node. I also published all of the files and an assembly guide on our GitHubso you can make one yourself if you want to.

Why Would Anyone Even Want to Make This?

I decided to make it because it can measure the static field generated by the weather. Thunderstorms are probably the most obvious ones, but the weather always generates static even if it does not result in lightning strikes. In theory, a grid of them would allow accurate tracking of storm cells and give more accurate warnings about lightning strikes or tell if a thunderstorm is beginning to form. (Though there are some problems with that, as you’ll read later).

It can also do contactless voltage measurements and detect a buildup of static charges, but that has fewer practical uses besides just being cool… at least for what I do in my lab. One thing it can’t detect, is the changing field of a Tesla coil

How the Field Mill Works

Operating Principle

Looking at the unit of the electric field (Voltage per distance, V/m) might give you the idea that it would be enough to just connect a multimeter to two plates at a fixed distance. But unfortunately, physics says no.

The reason for this becomes obvious when thinking of the sensor as a capacitor and the meter as a load. In a normal capacitor, the act of charging it up creates an electric field between the electrodes, so those two plates are like a pre-charged capacitor. And just like in a normal capacitor, the input impedance of the meter would allow charges to move from one electrode to the other until the voltage between them is zero, discharging it and canceling out any field that we might want to measure. All that means is that a sensor using two plates would always drift to an output of 0V regardless of the field applied and can only be used to measure changes in an electric field.

Satic Fields to Dynamic Fields

So, if the sensor can only measure changes, how do we manage to measure the static field generated by the atmosphere? Simple: we turn the static field into a changing one 😀 This is done with the grounded rotor, which acts as a faraday cage and shields the electric field underneath it. As it turns, it continuously covers and uncovers the electrodes, which results in a constantly changing electric field. Changing field can then sense this with the two plates described above.

As the rotor rotates, it moves charges onto and off the plates, and since the movement of charges is current, we can measure that. That current depends entirely on the external field and the rotor speed, so we can use it to calculate the field the sensor is in.

That current needs to be amplified, turned into a voltage, and read by an ADC, bringing more issues with it.

Field Mill Front End

The first issue is that the electrode current is very, very tiny… Sub-microamp at the highest expected field tiny. We will have to convert that current to a voltage to measure it with our ADC, and just using a resistor in front of the ADC like one usually would not really work. The input bias currents and leakages in the system would probably generate more signal than the sensor itself.

To solve this, we use a high gain transimpedance amplifier. It converts the current from the electrodes to a voltage, while having a near-zero input impedance so we don’t get wrong readings from the voltage drop across the resistor (as even just 100mV across the 1.6mm FR4 would result in a 60V/m offset).

Transimpendance Amplifier Considerations

One thing to keep in mind here is that the OpAmp for the transimpedance amplifier needs to have a low input bias current, as it gets amplified as much as the electrode current. The OpAmp in my plans is a CMOS one with less than 100pA below 70°C.

There is also a low pass filter with a cutoff frequency of around 3kHz in the signal path, limiting the bandwidth of the system to reduce noise. The frequency spectrum of the signal shows how there is pretty much no signal above 1kHz, and in cutting off the signal above that, we are only removing noise.

Sensing the Rotor Position

The last component here is the optical rotor position sensor (IC2) which is required if we want to measure the direction of the field and the strength. When a positive field is applied, the current is >0 when the rotor uncovers the electrodes, but when the field is negative, that happens as the rotor covers them instead. The sensor gives the ESP32 the ability to see where the rotor is and consider it when calculating the sensor reading.

One thing you might have noticed is the use of a 2.5V virtual ground for the entire system. This allows us to use a single 5V supply, as the output from the transimpedance is not mirrored around the 0V rail. That means it will not need to output any negative voltages up to an input current of 250nA.

The ESP32 Board

This contains all the digital stuff needed, which is really just a differential ADC, the ESP32 dev board, and some miscellaneous power stuff. The ADC is a differential one to give the system common-mode noise immunity. This will remove both the 2.5V offset and any other signals received by the electrodes caused by the rotor. Mains interference from a cable next to the field mill would, for example, be eliminated by this.

Since the ESP32 does all the signal processing in software, we don’t need any analog switches and logic gates used in some of the older schematics for field mill amplifiers on the web. The signal from the front end goes straight into the ADC, and the ESP does the rest. The one issue that we have is that the performance of the ESP32s ADC is pretty miserable and not suitable for this application. That is why I chose to use a dedicated differential ADC chip instead.

To give the measurements a stable reference, we use a voltage reference IC that is more stable and lower noise than either the 5V or 3.3V rails. The 2.5V from this is divided down by a factor of 5 to give the ADC a reference of 500mV.

Field Mill Code

I won’t be going into any detail about the user interface or its back-end because it isn’t really relevant to this project. All it is is a web server that serves either the webpage or the data from the sensor in the form of a .json file. No idea if that is the best or even a good way to do it since I have little experience doing web dev stuff, but it works 😛

The two other tasks the code has are controlling the motor and calculating the field from the ADC reading.

The motor rpm is regulated with a simple PID loop (but without the P). It needs to be well regulated as the electrode current is linearly proportional to the speed of the motor, which means that any inaccuracy here will directly impact the reading. The PID also corrects for slight variations in the motors and the mechanical assembly of the sensor.

ADC Operation

The ADC is set to sample at a fixed 10KHz, and the task automatically ignores all values within a specified dead time around the zero-crossing point. This is because the rotor does not perfectly shield only the area it covers because the field lines aren’t straight at the edges. This results in the soft-ish edges you see, which we ignore.

The value then gets digitally rectified by inverting it when the optical interrupter outputs a 1 (which is every time the A electrodes get uncovered) and averaged to eliminate the last bit of noise and leave us with the DC content of the signal. We then use the calibration data to calculate the applied field from the measured value.

And because I can, I added a task that periodically sends the data to an MQTT server if desired so that it can be processed further and logged in a database like InfluxDB.

Problems You May Have Building This Field Mill

The biggest thing to keep in mind is how crazy sensitive this thing is. I had issues with it not working the first time I assembled it because there was some flux residue with caused enough leakage to overpower the signal completely. Make sure to clean the board with some IPA or ethanol and an old toothbrush to prevent this.

Another problem you might run into is a high reading even without any field applied. If this happens, you should make sure that there is absolutely no exposed plastic near the sensor anywhere, that all of the top part is covered in copper tape and that the tape is electrically connected to the tape on the middle piece.

What To Improve

As it stands, the performance of the sensor is acceptable but not stellar. The signal we are trying to measure is tiny, even after the high gain transimpedance amp, so the signal-to-noise ratio is quite poor. To improve this, I could add a lock-in amplifier, which is extremely narrow band and would eliminate almost all noise from the system. I could also increase the gain from the Transimpedance amplifier and decrease the effect of the noise caused by the ADC, but since the ADC is pretty low noise, it would really only increase the effective number of bits we get from it (right now, the reading is not full range).

The one other issue is that the field mill does not have a lid. The rotor and circuitry are completely exposed, so it couldn’t really be used in the rain, which greatly limits its potential as a meteorological instrument.

Conclusion

My plan initially was to make a bunch of them and spread them all over the place to gather data but without a lid, they’d last maybe a week if I’m lucky. The problem with a lid is that it must not impact the measurement. A plastic one would get charged up and create a field of its own (I tested it and got a reading 10x larger than the external field), and a wood one is conductive enough to shield the field that we want to measure completely. The only option I could think of would be something ceramic, but that might get conductive enough to cause issues once it gets dirty. That is all to say that I could not think of a way to cover it properly. If you have any good ideas, I’d love to hear them 🙂

Make a Field Mill to Detect Static Electricity

We just finished up our winter educational tour of 2020 and it was a blast!  This tour mainly focused on engineering and explaining the methodology engineers use to build everything from medicine to electronics mixed in with our Tesla coil performance. What better way to do this than a little bit of Tesla coil music!  For us, it’s fun to play some Tesla coil music but what’s more fun is being able to answer the question “How does a Tesla coil work?”, and the kids seem to enjoy it just as much as we did. (If you’re asking yourself “How does a Tesla coil work” you should click here!)

It was also fun to show off what else we have made besides our Tesla coil performance, Like our robot drummer King Beat.  Not only did he rock the drums, but he also dropped some knowledge going over the basics of engineering. Unfortunately, though he dropped more than some knowledge as some of the back roads we took shook him a little bit too much and he dropped a couple of bolts.  Thankfully we had enough time before our shows to get him right as rain. 

This tour was even more exciting with our new crew member Destiny.  One of the best stagehands we’ve had and she also offered to teach me how to weld when we get back. She was definitely a welcome addition and I hope she comes out for many more shows and productions in the future.

Joe and I grew up in Michigan but now live in Texas so it was awesome to see snow again albeit a little scary since we haven’t driven through that kind of weather in a while. As much fun as this tour was, we are pretty excited to get back to Austin to continue working on our DIY Tesla coil kit, The Thundermouse. Hopefully, soon you can build your own ArcAttack DIY tesla coil!  The worst part of this tour though was having to leave our new puppy Riker at home. Maybe one day we’ll figure out a way to take her with us.   

Winter 2020 tour wrap up!