Tag Archives: esp8266

Wireless classroom conference microphone system – #3

This post is part of a series on designing a wireless microphone system for hybrid online meetings, i.e. with some people present in person and others present online. See also the previous and next post in this series.

I evaluated various small ESP32 and ESP8266 development boards for use in a clip-on microphone. The requirements are that it should be cheap, it should be small, and it should include a charger circuit for a LiPo battery. The most suitable candidates are the WEMOS D1 mini pro and the WEMOS LOLIN32 lite.

LOLIN32 lite versus D1 mini pro

The first is based on an ESP8266 and the advantage is that it is officially available from the WEMOS store. The second is based on the ESP32, has the advantage of a faster MCU, includes Bluetooth (although I don’t have plans for that at the moment) and is even cheaper (about €2.50, whereas the Wemos D1 pro is about €5.00). The disadvantage of the LOLIN32 lite however is that according to the ESP32 page on Wikipedia it is retired and hence not available through an official WEMOS channel. There are many clones of the LOLIN32 lite board available on AliExpress as LOLIN32 lite or as LOLIN32, however, the quality of these clones may vary.

I removed the battery connector from the WEMOS board (that is on the right in the photo) to reduce the height. Furthermore, using a Dremel tool I made a small indentation in the board: this allows passing the wires from the battery cables. Both boards feature a JST-PH-2.0 battery connector that points along the axis of the board in the same direction as the micro-USB. This arrangement of the connectors makes it impossible to plug in a battery, while at the same time having the micro-USB connector flush to the side of an enclosure. To keep the assembly as simple as possible, I want external access to the USB connector for charging, so instead of using the battery connector, I will solder the wires from the battery straight onto the board. The JST-PH-2.0 connector comes off easily with a pair of pliers and a little force.

Note that the LOLIN32 lite should not be confused with the D32 or the D32 pro version. Here is a comparison with the boards side-by-side from left to right the Wemos D1 mini, the Wemos D1 mini pro, the LOLIN32 lite, the LOLIN32 pro, and the LOLIN D32.

comparison of different LOLIN and WEMOS boards

LOLIN board comparison

To evaluate them, I ordered the ESP32-based LOLIN32 and the ESP8266-based D1 mini pro together with some INMP441 I2S microphone modules. Using the Arduino example code, I implemented a simple microphone with both of them. I figured out that there is more online documentation and more examples of the I2S interface with the ESP32; for the ESP8266 there is less documentation (e.g. it is not mentioned here) and it seems from this example that the I2S implementation is limited to 16 bits.

I also experimented with the LOLIN32 and the Adafruit SPH0645 I2S microphone module following this example. Compared to the INMP441, the SPH0645 gave me a harder time with the byte-swapping and scaling of the digital signal. Probably in the end my problems mainly had to do with some I2S timing incompatibility between the ESP32 and the SPH0645. In the best situation, there were still problems with the digital signal randomly jumping up and down, especially at larger input volumes.

For the microphones I therefore decided to continue with the INMP441 modules, which are available for about €1.70.

INMP441 MEMS microphone module with I2S interface

Wireless classroom conference microphone system – #2

This post is part of a series on designing a wireless microphone system for hybrid online meetings, i.e. with some people present in person and others present online. See also the previous and next post in this series.

Pondering about wireless microphones for a classroom or for a larger scale conference/meeting room, I identified some requirements:

  • it has scale to a classroom with 20 or 30 attendees
  • it has to be cheap per microphone, rather in the range of €10 than €100
  • it has to be simple to use, as there is no sound technician to control a mixing console
  • it has to integrate with online meeting software as if it were a regular micophone
  • it has to be portable, so that I can take it to any class or meeting room
  • it has to be DIY and easy to build with already available components

Imagine that you would have a number of rechargeable clip-on microphones that all transmit their audio wirelessly to a single base station. The base station could also act as a charging station, i.e. when not in use the microphones would be docked in it. The base station would be connected to the central laptop/computer as if it is a single external microphone. Bluetooth lapel microphones exist, but Bluetooth does not allow connecting a lot of microphones to the same computer. Proprietary radio systems such as used by audio companies like Sennheiser are not DIY friendly. There are easy to use RF modules, but those are more suited for IoT applications and not streaming audio. This actually sounds like an ideal application for a 5G device-to-device network, but components for those are not easily available yet.

I think wifi would have enough bandwidth and would be able to support a large number of clip-on microphones: a dedicated wifi access point has no problems dealing with 50 to 100 connected clients. It can be a dedicated/closed network since there is no reason to have the microphones connected to the internet, except perhaps to receive software updates. Also, other devices such as laptops don’t have to connect to this wifi network, except when a web interface is considered for configuration and audio mixing (see below).

For the clip-on microphones, I am considering using an ESP32 connected to an I2S MEMS microphone and a small (e.g 500 mAh) LiPo battery. These can be housed in a custom 3D printed case with a clip to attach it to the clothing, and a hiddeon connector at the bottom for charging in the docking bay. The ESP32 needs firmware that sets up and maintains the wifi connection, processes the I2S audio, does threshold detection and, when loud enough, transmits the audio over wifi.

For the base or docking station and wifi access point, I am considering a Raspberry Pi Zero W combined with a HifiBerry DAC+ Zero. The line-level output of the HifiBerry would be provided on a standard 3.5 mm female jack, such that a standard TRS or TRRS jack-to-jack cable can be used to connect the base station output to the laptop microphone input. The base station requires software that receives the (UDP?) wifi input streams of all ESP32 modules, normalizes them, and mixes them into a single audio output.

Some additional features I was thinking of for the base station are a volume indicator, e.g., a Neopixel that turns green-orange-red). Furthermore there could be a mute button for every microphone, a solo button (muting all but the one that has been selected), and knobs to adjust the volume level for each channel. These could be implemented using physical buttons placed next to the charging bays in the dock, but also through a web interface.

Usability in a classroom or meeting room by people that have no technical understanding of the system is also crucial. If the base station would have physical mute buttons and/or volume knobs for each of the channels, the clip-on microphone modules must be clearly labeled/numbered. Possibly they could all be 3D printed in a different color and the corresponding charging bay (with the knob/button next to it) in the base station would then have the same color. The individual microphones don’t have to be recognizable if audio mixing or muting is not needed.

Considering that this system might be used at the same time in multiple neighboring classrooms, the wifi signal amplitude should be strong enough to have within classroom reception, but as weak as possible to not interfere between classrooms and with the regular internet wifi.

I think that the base station could be made for about 50-100 euro (hardware costs only, and mainly depending on whether it has buttons and knobs for each channel) and that each clip-on microphone can be made for about 10-15 Euro. For a system comprised of 30 clip-on microphones to accommodate a complete classroom that would amount to €350-550. For a smaller meeting room system with 8 clip-on microphones, it would be around €150.

There is quite some development and testing needed for this. For prototyping I have ordered an Adafruit HUZZAH32 and a I2S microphone breakout board from a local and fast (and also more expensive) supplier and some comparable but cheaper components from Aliexpress. Let’s start with a single microphone, similar to this or this baby monitor. If I can get that to work with a Raspberry Pi, the next step would be to check how well that scales to a larger number of ESP32 microphones.

Wireless classroom conference microphone system – #1

This post is part of a series on designing a wireless microphone system for hybrid online meetings, i.e. with some people present in person and others present online. See also the next post in this series.

Update 22 November 2020 – I split the original post into two pieces to make it easier to follow up and added some information about commercial solutions.

I was chatting with my daughter about the challenges of doing hybrid Zoom or Teams meetings. She was not allowed to go to school for a few days and had to follow lessons online, with the teacher and most students in the class. And I was still stuck in my attic, organizing my own university teaching and meetings remotely. Recently I went to work a few times for meetings, but only a few people came to work in person, and most attended online through Zoom. This is similar to the current school situation for my daughter, where most kids attend in person but some attend online on Teams. I expect that we will have these hybrid online/in-person meetings for quite some time to come; perhaps they might even become the new “normal”.

The challenge with hybrid in-person and online meetings is mainly in the physical room where multiple people are attending in person. The online attendees simply connect to the online meeting the same way as if it were a 100% online meeting. The people present in real life also have their laptops in front of them with the webcam on, but with the speakers and microphone muted. This allows online attendees to see everyone, also those people in the physical room. Only one person in the physical room unmutes the speakers and microphone. This allows the noise- and feedback-suppression of the video conferencing system to do its work and not to amplify the voice of the local attendees through the speakers. If you would have multiple laptops with the speakers and microphones on, you will hear echo’s, and the sound will start feeding back, creating lots of noise.

Amplifying the audio from the online attendees to the people in the physical room is easy, e.g., using some external speakers connected to the laptop. The problem however is with picking up the voice from the attendees in the physical room. In smaller meeting rooms at the university we use table microphones, like the USB Samson UB1 or the analog Philips LFH 9172 which can be daisy-chained. We also have one room with a Polycom video conferencing setup, and are experimenting with microphone arrays for the larger meeting rooms. However, these microphone systems are still quite expensive, not so portable due to the required cabling, and they work best when placed in the middle of a round table with an equal distance to all speakers. I.e., these systems are OK for traditional conference rooms, but not for classrooms or more ad-hoc meeting setups with multiple people in complex spatial arrangements, or when people have to keep a distance from each other.

What if we could give everyone in the room a wireless clip-on lapel microphone? Companies like Sennheiser and Shure have wireless microphone systems for studios and stage performances, but these don’t scale well to a large number of in-person attendees in a classroom or meeting, at least not financially: imagine equipping all kids in a classroom with a €300 microphone.

Shure microfex

Shure microfex

The Shure Microflex wireless conference system provides a solution for relatively flexible setups for conference calls with multiple people on-site and others online. However, it consists of rather bulky wireless gooseneck microphones that are placed on the table in front of the participants. Although being wireless makes it more portable that regular conference systems that have a fixed installation, I don’t think it can be easily taken from one classroom or meeting room to another.

RØDE wireless go

RØDE wireless go

The system I have in mind is perhaps more comparable to the RØDE Wireless GO, which aims at online content creators and consists of a compact clip-on transmitter and a receiver with an analog output that plugs into a camera. The transmitter is to be worn by the presenter or the person being interviewed and has a microphone built-in. Alternatively, you can connect a separate lapel microphone through a 3.5 mm jack plug. The system operates in the 2.4 GHz range, and according to the specifications you can use up to 8 systems in the same location. However, note that this would then consist of 8 transmitters/microphones and 8 receivers, whereas I am looking for a solution with many microphones connected to a single receiver, without an audio mixing panel.

Shure ULX-D digital wireless system

Shure ULX-D digital wireless system

A more professional system that shares some similarities with what I have in mind is the Shure ULX-D digital wireless system. This comes with a bodypack and handheld microphone for mobile use, and a gooseneck or boundary microphone for use on a table. It also includes various receivers, with up to four channels. Multiple systems can be combined and using a rather fancy assignment/management system for the frequencies at which the devices operate, it can scale to a large number of microphones.

12 Volt trigger for NAD-D3020 amplifier

Update 3 January 2021 – mention that I am now using Tasmota firmware.

The NAD D3020 is a hybrid digital audio amplifier with a combination of analog and digital inputs. I have been using it for quite some years now to play the sound of my Samsung smart TV over the living room speakers and for digital radio, iTunes and Spotify from my Mac mini. The Samsung is connected with an optical Toslink cable, the Mac mini is connected with a USB cable.

In the way the D3020 is placed in our media cabinet, its on/off button is not so easy to access. The D3020 remote control is really crappy and I find it anyway annoying to have to use multiple remotes to switch the power of all devices. Also, the status LEDs of the D3020 are dim and got considerably worse over time, especially for the OPT1 and the USB inputs that are for the TV and the Mac mini, and hence on most of the time. I guess that it uses OLEDs, which have degraded over time. Consequently, it happened quite often that we forgot to switch the amplifier off for the night.

However, the D3020 features a 12V trigger input port which allows the amplifier to be switched automatically on/off along with other gear. Of course, neither TV nor the Mac mini has a 12V output port, but both are connected to my home network; hence it is possible to detect over the network whether these are powered on.

I built an ESP8266-based trigger which allows switching D3020 using the 12V trigger. This is combined with a small Node.js application running on a Raspberry Pi which pings my TV and my Mac mini over the network every 5 seconds. If either one returns the ping – and hence is powered on – an HTTP request is made to the ESP8266 to switch the trigger on. If neither TV nor Mac mini returns the ping, an HTTP request switches the trigger off.

The hardware is implemented using a Wemos D1-mini ESP8266 board. The ESP8266 uses 3.3V logic which is not enough. However, 5V turns out to be sufficient to trigger the amplifier. I tried using a logic level converter, but it did not produce enough output current on the 5V side, causing the voltage to sag and remain below the trigger threshold. Therefore I designed a circuit in which one of the 3.3V GPIO pins is used to switch an opamp. The output side of the opamp is connected to the 5V USB input voltage of the Wemos board. Although the output voltage does not fully reach 5V, it turns out to be enough for the trigger input of the D3020.

The design follows that of a MIDI input, see here on Sparkfun and here on the Teensy forum. The difference is that the optocoupler input comes from the microcontroller GPOI pin at 3.3V, and the output is pulled up to 5V from the Vin pin. I also added a diode to protect the electronics from reverse voltage spikes that might come from the amplifier.

schematic

The list of components is:

The PC900v datasheet specifies a maximum forward current of 50 mA, which would require a 66 Ohm resistor at 3.3V. However, the maximum current that can be drawn from a single GPIO pin is 12mA, hence I decided to use a 270 Ohm resistor.

Here you can see the design on a breadboard for testing:

And the final implementation just prior to fixing it with hot glue:

The firmware for the ESP8266 that I wrote myself can be found here on Github. However, around 2019 I switched to Tasmota, which is a generic open-source firmware for ESP8266 devices like these.

I am using this ESP8266-based 12V trigger in combination with a small node.js script running on a Raspberry Pi that constantly monitors whether either my TV or Mac mini are powered on. The code for this is found in on here on Github.

Timing and jitter in DMX512 signals

My previous post on building an Art-Net to DMX interface using an ESP8266 seems to be getting a lot of attention. However, from the comments it is clear that a lot of people that build it themselves have difficulties to get it to work, or don’t get it to work at all. This post investigates this in more detail.

We have not been using these interfaces in our performances for quite some time, and started wondering whether there is something wrong my firmware. My implementation goes back to April 2017. Over the course of time there have been some updates to my code. Furthermore, the Arduino IDE has been updated, as well as the ESP8266 core for Arduino.

Recently I received all three interfaces back that I had built for my 1+1=3 collaborators and decided to update the firmware and to test them. One of them did not work at all due to a broken connection between the power supply and the Wemos D1 mini; two of them started just fine. After fixing the broken wire and updating the firmware on all three of them; they started up just fine, showing the green light (indicating a connection to the WiFi network) and on the monitor page of the web interface I cold see that Art-Net packets were being received. However, with my DMX controlled light it did not work at all.

Testing and initial diagnosis

Using an Enttec Open DMX interface and the very nice JV Lightning DmxControl software (which supports both Art-Net and the Enttec Open DMX), I set out to debug the issue. Since DMX is all about timing, I connected my DS203 mini oscilloscope to pin 2 and 3 of the DMX connector.

I found detailed schematic information about the timing of the DMX protocol on this page. Searching for oscilloscope images of DMX signals, I also found this page with information.

Comparing the output voltage with the DMX512 schematics, it became clear that something was wrong in the signal. To make it easier to see the full signal on the oscilloscope, I configured only three DMX output channels, all set to zero. The oscilloscope shows 5 similar blocks; changing the value for DMX channel 1, I see that the 3rd block changes – that is apparently the first channel. Prior to that should be a “start code” with value 0, so the last 4 blocks make sense. But the first block is too short; there is also a very short pulse all the way at the start which does not match the specification.

Output voltage with the initial firmware:

By connecting the Enttec Open DMX to my DMX controlled light, I could confirm that the combination works and that the DMX interface to my light is not broken. Connecting the Enttec Open DMX to the oscilloscope, I see that it has a much longer 1st block which is the “space for break” (labeled 1 according to this), and slightly different 2nd block which is the slot with the “start code”. Following is a whole series of blocks/slots corresponding to the DMX channels. In this case I cannot limit the number of DMX channels, so the series contains a full universe of 512 channels, each of them set to zero. Changing the values of the first few channels in Lighting DmxControl, I can see the corresponding change in the signal on the oscilloscope.

Since a static photo of the oscilloscope screen does not show that there is quite some jitter, especially in the first part of the signal, I uploaded a short video recording of the Enttec Open DXM signal.

Output voltage of the Enttec Open DMX:

As the initial “break” signal was apparently not correctly implemented in my firmware, I changed the code to use the low-level implementation of the break that was contributed here. Using 3 DMX channels again, this results in a good DMX signal.

Output voltage with the firmware, using the low-level break:

I investigated the problem with the original code, which consists of switching to a slower baud rate, sending a single byte as the break signal, and switching back to the original baud rate of 250000. Given that the “break” appears just as long as the other bytes, the switching of the serial port speed apparently fails. On the Arduino forum I found a post that suggested to flush the serial port prior to and after changing the speed; I implemented this and now the break signal looks fine again.

I think that the reason that it broke is due to updates in the Arduino version that I am using, and/or updates to the ESP8266 Arduino core. I guess I must have been lucky with my buggy initial implementation; this may explain why it failed for some people and worked for others.

Output voltage with the firmware, using the slow serial break:

DMX512 universe size

Connecting my Art-Net to DMX512 adapter with updated firmware to the DMX controlled light initially did not work; increasing the size of the DMX universe that is is passed on by my Art-Net to DMX512 adapter solved this. After some trial and error it turned out that – although I had configured the DMX light for three channels (R, G, B) – it would not work if it would receive less than 8 channels. I suppose this is because the light has a 3, 4, and 8-channel DMX mode, and that 8 channels is apparently the minimum for DMX input to be properly handled.

Comparing the timing of the three systems

Looking back at the videos, I see that the timing of the Enttec Open DXM controller is the worst, especially in the space for break and the mark after break (MAB). This is actually a known characteristic of the Open DMX, since timing is controlled by the serial (USB) port of the computer rather than by a dedicated microprocessor; that is also the reason why it is not recommended for serious applications.

My own EXP8266 firmware with the low-level code for the break shows less jitter for the break. Using the “slow serial byte” the jitter is totally gone for the break itself, but there is still some jitter in the duration of the MAB.

Regardless of the jitter, all three are working fine with my DMX controlled light! Having seen the timing of the signals in detail, I am also more confident that they should work with other DMX equipment. One thing I noticed however and don’t have a solution for right now, is that the differential voltage of the Max485 modules that I am using is considerably lower at ~3.5V than that of the Enttec at nearly 8V.

Summary

To summarize, I was glad to have the Enttec Open DMX USB adapter for testing, and especially for having the DS203. If you are doing electronics like this, I can really recommend to get an oscilloscope!

Besides testing with the Lightning DmxController software, I was also able to confirm that it all works smoothly again with our EEGsynth, using a patch consisting of the redis, inputcontrol and outputartnet modules.

Restoring the AT firmware on the ESP8266

Most of the time I am using Wemos D1 mini development boards in combination with the Arduino IDE to make my own firmware to run directly on the ESP8266 chip. But I also have some bare ESP-01 and ESP-12 modules lying around, and recently I came up with the plan to use one of them.

The specific project requires very well controlled timing of an ADC, for which I will use a regular ATmega328P-based Arduino board. In this project the ESP8266 will only be used to transmit the data over WiFi. Neither my ESP-01, not my ESP-12 still have the original AT firmware, since I have been experimenting with various other firmwares.

This is where the challenge starts, since my plan required restoring my ESP-12 to the AT firmware and use a library like ESP8266wifi or WiFiEsp. I realize that I have been struggling with different firmwares before, hence this post to give a short review and to keep some notes for my own future reference.

Module form factor

The ESP8266 microchip comes on various development boards that include an USB interface, such as the Wemos D1 Mini and the NodeMCU board, but also as bare modules such as the ESP-01, 02, etc. This page on the ESP8266 wiki has an overview of all modules and this page has comparison of some of the raw modules with some of the development boards.

ESP-01 module:

ESP-12 module:

Flash memory capacity

Besides the number of GPIO pins that is exposed by each of the modules, another important feature is their flash memory capacity. The AI-Thinker website has a module list table that includes this. The ESP-01 module comes with 512kB flash (old modules) or 1MB (now more common). The ESP-12 module comes with 4MB. Note that there are development boards such as the Wemos D1 mini pro that even have more.

Firmware

As the ESP8266 is nowadays fully supported in the Arduino IDE, I prefer to develop my own custom firmware for the ESP8266 using C/C++ and the Arduino IDE and libraries. So the most confusing aspect of the ESP8266 for me is that there are multiple “standard” firmwares available for it, which I often accidentally confuse. These include

  • The AT firmware, comparable to the Hayes command set on old modems.
  • The NodeMCU firmware, which includes a LUA interpreter.
  • The MicroPython firmware, which includes a Python interpreter.
  • The Espruino firmware, which includes a JavaScript interpreter.

For the firmware options that include a Python or a JavaScript interpreter it should be mentioned that there are other versions from other companies/projects.

The NodeMCU project is more centrally managed/organized and includes a website where you can compile customized firmwares with support for specific hardware add-ons.

Restoring the AT firmware

To flash the firmware to an ESP8266, you will need to wire it up and get it in the right boot loader mode. There are many online tutorials for this and I won’t elaborate here. You will also need software to write the new firmware, I am exclusively using esptool.py.

I tried various options to flash my ESP-12 with the original firmware, most of which failed. The challenge is to figure out which firmware is compatible with my specific module, and to which flash memory locations to write the different pieces of the firmware. In the next section I will describe three things that worked, going from the oldest to most recent firmware versions.

Following the instructions here and using a rather obscure version of the firmware contained in a single binary file from here, I had success with:

esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x00000 v0.9.2.2\ AT\ Firmware.bin

Subsequently I was able to connect in a terminal program with 9600 bps and got

[System Ready, Vendor:www.ai-thinker.com]
AT+GMR

0018000902

OK

Using the old AT firmware from Espressif itself with the “Offical ESP8266 AT+ Commands” from their old GitHub repository I was also able to get it to work with:

esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x00000 boot_v1.1.bin
esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x01000 newest/user1.bin
esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x7C000 esp_init_data_default.bin
esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x7E000 blank.bin

Subsequently I was able to connect in a terminal program with 115200 bps and got

ready
AT+GMR

00200.9.4

OK

The Espressif ESP8266 SDK Getting Started Guide contains the most recent information about the layout of the flash memory. Using the 2.2.1 release from the Espressif NONOS_SDK repository and

esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x00000 boot_v1.2.bin
esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x01000 at/512+512/user1.1024.new.2.bin
esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x7C000 esp_init_data_default_v05.bin
esptool.py --port /dev/tty.usbserial-FTG54BPS --baud 115200 write_flash --flash_mode dio 0x7E000 blank.bin

I also had success and was able to connect in a terminal program with 115200 bps. This resulted in the following response

ready
AT+GMR
AT version:1.6.2.0(Apr 13 2018 11:10:59)
SDK version:2.2.1(6ab97e9)
compile time:Jun 7 2018 19:34:26
Bin version(Wroom 02):1.6.2

I did not have success with the 3.0 release from the Espressif NONOS_SDK repository. That one does not have the “512+512” directory, only the “1024+1024” directory, which I could not get to work on my ESP-12. Suggestions to make this work are welcome.

Motion capture system

For the EEGsynth project I have developed a full-body 8-channel motion capture system. It is based on the MPU9250 9-DOF inertial motion unit, which contains a three-axis accelerometer, gyroscope and magnetometer. I have combined this with the Madgwick AHRS algorithm, which takes the raw sensor data and computes the yaw, pitch and roll.

The design is based on one battery operated main unit that is worn for example in a Fanny pack around the waist, and up to 8 sensors that are attached to the arms, legs, etc.

The main unit contains a Wemos D1 mini, which is based on the ESP8266 module. It uses the TCA9548 I2C multiplexer to connect a maximum of 8 MPU9250 sensors.

The data from the IMU sensors is streamed using the Open Sound Control (OSC) format. The sampling rate that can be achieved with one sensor is around 200 Hz, the sampling rate for 8 sensors is around 60 Hz.

For initial configuration of the WiFi network it uses WiFiManager. After connecting to my local WiFi network, it has a web-server through which the configuration can be set, which includes the number of sensors and the destination host and port for the OSC UDP packets.

For the IMUs I am using MPU9250 modules that I purchased on Ebay for about 3 USD each.The MPU9250 units fit very nicely in a Hammond 1551MINI enclosure.

I designed the enclosure for the main unit in Fusion360 and printed it on my Prusa I3 MK3 3-D printer. I made two motion capture systems so far, one with black and one with white PLA filament.

The Arduino sketch and more technical documentation can be found here on GitHub.

Art-Net to DMX512 with ESP8266

Update 1 August 2019 – added the connectors to the list of components.

Update 4 July 2019 – You may also want to check out this instructable, which describes a more sophisticated ESP8266-based solution.

Update 6 April 2019 – I wrote a follow up post on the timing and jitter in DMX512 signals and fixed a bug in the firmware.

Update 26 May 2017 – added photo’s of second exemplar and screen shots of web interface for OTA.

Professional stage and theatre lighting fixtures are mainly controlled over DMX512. To allow a convenient interface between the EEGsynth and this type of professional lighting systems, I built an Artnet-to-DMX512 converter. It quite closely follows the design of my Artnet-to-Neopixel LED strip module.

Let me first show the finished product. It has a 5 pin XLR connector, a 2.1 mm power connector, and a multi-color status LED:

Continue reading

ESP-8266 Art-Net NeoPixel module

As explained in a previous post, for the EEGsynth we want to use a neopixel array that can be controlled wirelessly using the DMX512 protocol. I purchased a number of Adafruit neopixel rings with 12, 16 and 24 elements respectively. Each RGBW pixel contains a red, green, blue and white LED. For the 24-pixel ring that means that there are in total 4*24=96 LEDs of which the intensity can be set.

The ESP-8266 module is a versatile WiFi module that comes in many versions. During development I especially like the NodeMCU version, which mounts the ESP-12 module on a development board with USB connection, and the even smaller Wemos D1 mini board. The Wemos D1 mini is hardly more expensive on Ebay than the simpler bare-bone ESP-8266 modules.

The hardware connection is simple: I connected Vcc and GND directly to the Wemos D1 mini board, and connected pin D2 to the data-in of the first pixel. Although the Neopixels are specified for 5V, in my experience the Adafruit rings also work fine at 3.3V, both for power and for the serial control signal. Each LED can take up to 20 mA when fully bright, which means that all LEDs of the 24-pixel RGBW ring can take up to 24*4*20 = 1920 mA, or close to 2 A. However, not all LEDs will be at full intensity at the same time, and driving them with 3.3V rather than 5V further reduces the current. I encountered no issues powering them over the USB port of my MacBook.

For the EEGsynth we want to map a small number of control signals to aesthetically pleasing light effects. E.g. it can control the hue, the frequency with which the array flashes, or the speed with which a bright bar rotates along the ring.

Continue reading

Scalable lighting systems

The X-mass holiday is always a nice time of the year to spend studying and tinkering on electronics projects. In the EEGsynth project we have identified that it would be cool to control light with brain and body signals, besides controlling modular synthesizers which we have focussed on so far. As it is not yet clear what kind of light and what kind of control will conceptually and aesthetically work well on the EEGsynth control signals, I have been studying both small and large lighting systems. We might for example want to use small and wearable lights on a performer, or control the stage light, or use a LED strip as indicator of the EEG-extracted control signals.

In theatrical and stage performance lighting there is a clearly dominant standard: DMX512. For lighting setups there are many fixtures (i.e. lamps rigged on ceiling mounted truss) that can be remotely controlled over DMX512, not only on-off, but they can be dimmed, the color can be changed, spotlights can be moved, etc. If you look on for example on Thomann, you’ll see that many light fixtures support DMX.

The Disco Biscuits – City Bisco – 10/5/12 – The Mann Center for the Performing Arts – Philadelphia, PA – Photo © Dave Vann 2012

Going to the smallest systems, I considered individual LEDs. Neopixels are a very interesting type of RGB LEDs, which combine a red, green and blue (and sometimes white) LED in a single few-mm small housing together with a controller chip. The controller chip allows the individual LED intensities of the neopixels to be addressed over a serial controller by a microcontroller such as an Arduino. Furthermore, multiple Neopixels can be daisy-chained, where each pixel in the array can be addressed. LED strips consisting of 30, 60 or even 144 pixels per meter can be purchased per meter, for example on Ebay.

Adafruit NeoPixel Ring with 16 x 5050 RGB LEDs with integrated drivers

For the the EEGsynth it is desirable to have a single control module that provides a uniform interface between ExG control signals and light control. An individual neopixel can be considered as an RGB lamp, just like a theatrical stage light. The intensity of the red, green and blue can be controlled, just like the DMX channels of a stage light. Controlling a small LED jewel worn by the performer should not be different than controlling the light of the stage on which the performer acts.

An important difference in the requirements for fixed stage lighting and a small wearable LED jewel is that the first must hook up to existing DMX512 cabling systems, whereas the second should be wireless. This is where Art-Net and the ESP-8266 come in. Art-Net is a protocol for sending the DMX control protocol over a network. The ESP-8266 is a small and low-cost microcontroller combined with a WiFi chip that is compatible with Arduino.

Further details on the hardware and firmware design for the actual light controller modules will come in a series of follow-up posts.