Category Archives: Personal

Wireless classroom conference microphone system – #4

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 want to design a wireless clip-on “Lapel” microphone based on the LOLIN32 lite board and the INMP441 I2S microphone module (not to be confused with the INMP 411, which has analog output). Given the size of the board (about 25 by 50 mm), an 802040 or possibly an 802540 Lithium Polymer battery would be a nice match. These LiPo cells are 8 mm thick, 20 (or 25) mm wide, and 40 mm long. In a few iterations, I designed a simple enclosure in Fusion360 and 3D printed them.

ESP32 wifi microphone enclosure

ESP32 wifi microphone enclosure

The box has a port in the top for the microphone; on the inside are two rails to keep the ESP32 board in place. The microphone is mounted in a small holder that clips perpendicular onto the antenna-side of the ESP32 board. The micro-USB connector is exposed at the bottom, this allows charging the LiPo battery. I expect that this design will also allow making a docking station for charging multiple microphones at once, for example, using these male micro-USB connectors. The first versions (red and blue) did not have an on-off switch; I added these in the later versions of the design (green, yellow).

The ESP32 wifi microphone enclosure is about 57x28x18 mm in size. For mounting the microphone on a lapel or in the neck of a shirt, I considered 3D printing a clip. However, I know from experience that 3D printing a clip with exactly the right flexibility is not so simple, since that depends on the properties of the filament. The clip would also make the 3D printing and assembly more complex. I think that a magnetic name badge holder will be a good alternative to a clip for mounting the microphone to your clothing; it has the advantage that the microphone can be positioned more flexible, especially for informal clothing such as t-shirts. Using double-sided adhesive tape the magnetic name badge holder can be attached to the recesses at the back of the 3D printed microphone enclosure.

magnetic name badge holder

magnetic name badge holder

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.

KlikAanKlikUit “Blender Defender”

Some 2 year ago I came across the “Blender Defender“, a nifty DIY solution to train cats to stay off the counter. You should have a look at the original site, the video’s there are great!

We have cats, so you can imagine that we also have need for one… I started implementing my own version quite some time ago, but shortly after finishing it, it broke down somehow and I never came to diagnose the problem and fix it. Today I did: it turned out that rather than a fried RM module (what I was afraid for), it was simply a wire that came loose.

The design I followed for the Blender Defender is based on a Passive Infrared (PIR) sensor, linked to an Arduino that subsequently controls a KlikAanKlikUit RF switch.

Blender Defender

Blender Defender

In the end it is of course simply a movement sensor that can switch anything connected to the KAKU switch. But since we have a blender, I also added that to the photo.

The components I used are:
Arduino Mini, about 20 Euro (see below)
PIR sensor, about 1 Euro
SparkFun 5V Step-Up Breakout – NCP1402, about 5 euro
RFM12b module, about 4 Euro
– KlikAanKlikUit switch, about 10 euro
– 2 NiMH rechargeable batteries
– dual AA battery holder
– ABS project box

The reason for using the Arduino Mini is that I had it lying around 2 years ago and had no other use for it. Nowadays I would not use a Mini, but rather an Arduino Pro Mini. The Pro Mini is cheaper (especially if you get a clone of Ebay or DX.com) and easier to hook up to an FTDI cable. Also the choice of the RFM12B was based on me having it lying around and not having any other use for it. For my other RF projects I am using 868 MHz radio modules. A simpler (non SPI) 433 MHz radio transmitter module would also work, although the code (see below) would have to be modified.

2016-06-12 15.30.22

2016-06-12 15.30.52

Wiring it all up is quite easy. Besides 5V (VDD) and ground (GND), these connections need to be made between the radio module and the Arduino:

  RFM12b         Arduino 
    3      SDI     11
    4      SCK     13
    5      SS      10
    6      SDO     12
    7      IRQ      2

The output of the PIR sensor is connected to pin 9 of the Arduino, the button to pin 4, a green LED (placed under the button) to pin 3 and a red LED (also under the button) to pin 5.

Arduino Mini

Arduino Mini

RFM12b DIP

RFM12b DIP

The combination of the green and red LED allows to monitor the state of the sensor and to toggle between disarmed/armed:
– at startup the sensor is disarmed and the button is green
– click button -> blinking red for 5 seconds (about to be armed)
– after 5 seconds -> constant red (armed)
– upon movement -> yellow (both LEDs on) and the Blender switches on
– click button -> green (disarmed)

The sensitivity of the PIR sensor and the duration that it remains on can be adjusted with two small screws under the sensor.

2016-06-12 15.28.35 2016-06-12 15.28.45 2016-06-12 15.28.51

The source code is available from my GitHub repository.

Raspberry Pi – getting the RFM12b to work

Now that I know how to blink a LED, it is time to move to slightly more interesting applications of the GPIO interface on the Raspberry Pi. I have a few Arduino modules in and around the house monitoring the climate and various other measures. They are all battery operated and send their information to a relay that forwards all data to Thingsspeak.

My current relay module consists of an Arduino Uno with an Ethershield, connected over i2c to another Arduino pro mini. The second Arduino is connected to a RFM12b module and uses JeeLib to receive data from the sensing modules. Would it not be nice to receive that data on a slightly more powerful platform and be able to do more with it than just forwarding it elsewhere…

Raspberry Pi with RFM12b

Raspberry Pi with RFM12b

I decided to give the rfm12b-linux kernel driver a try, as it explicitly supports the JeeLib format. I followed the instructions from rbi-source without problems. After changing the board type (RFM12B_BOARD) and group (RFM12B_DEFAULT_GROUP_ID) in rfm12b_config.h, the module compiled without problems. However, it would initially not load, showing errors in the dmesg output.

Following some suggestions here and here, I used rasps-config to disable the SPI, I2C and the Device Tree. After that, it did load and dmesg showed

[ 478.278166] rfm12b: added RFM12(B) transceiver rfm12b.0.1
[ 478.278391] rfm12b : driver loaded.

I compiled the example applications and used this

pi@hackpi:~/rfm12b-linux/examples/bin $ sudo ./rfm12b_read 

successfully opened /dev/rfm12b.0.1 as fd 3, entering read loop...

Fri Apr 29 20:07:50 2016
	32 bytes read
		4 0 0 0 115 24 0 0 87 14 109 64 102 230 11 65 41 44 124 68 
		0 0 192 127 0 0 192 127 115 162 189 253 
Fri Apr 29 20:08:14 2016
	32 bytes read
		2 0 0 0 59 77 2 0 122 233 110 64 210 225 148 65 0 0 192 127
		0 0 192 127 0 0 192 127 93 112 175 32 

showing two messages from two modules. I recognise the pattern as

typedef struct payload_t {
  unsigned long id;
  unsigned long counter;
  float value1;
  float value2;
  float value3;
  float value4;
  float value5;
  unsigned long crc;
};

belonging to the lm35 and bpm085 modules that are sending their data approximately every minute.

lm35

bmp085

Raspberry Pi – first steps to blink a LED with Python

I already purchased my first Raspberry Pi in 2011, but have been postponing connecting any electronics to its GPIO interface. Instead, I have been using it for more general computing applications (media center, web server, remote ssh access and tunnel, etc.). Rather than using the Raspberry Pi for in refacing with hardware and IOT, I have been using a bunch of Arduino’s to implement sensors and actuators for home automation.

Since I recently have been brushing off my Python programming skills for the EEGsynth project and been teaching myself Node JS, I was triggered to revisit the Raspberry Pi for GPIO electronics. With the Raspberry Pi it will be easier to implement my own web server and to use webhooks to integrate my home automation hardware projects with online platforms such as IFTTT.

I decided to try Python first and after browsing the web decided to use the WiringPi interface, as it supports C programming in the same style as on the Arduino, but also has wrappers for more high-level languages (Python, PHP, Ruby and Perl).

I started with installing the WiringPi library as per instructions

git clone git://git.drogon.net/wiringPi
cd wiringPi/
./build 

and tested it with a LED in series with a 680 Ohm resistor attached to the first GPIO pin, aka pin 17 on the Pi cobbler. I still have to wrap my head around the pin numbering, but understand that there are different numbering schemes.

Subsequently I ran the test from

cd examples/
make blink
sudo ./blink

and also tried out this on the Linux command line

gpio write 0 1
gpio write 0 0
gpio write 0 1
gpio write 0 0

This all worked as expected and the LED would nicely blink. I subsequently moved on with Python. Instead of following the detailed installation instructions, I simply tried

sudo pip install wiringpi

which worked like a charm. The following Python code

#### this is blink1.py #### 

import wiringpi
import time

wiringpi.wiringPiSetup()

wiringpi.pinMode(0,1)

while True:
    time.sleep(0.5)
    wiringpi.digitalWrite(0,1)
    time.sleep(0.5)
    wiringpi.digitalWrite(0,0)

works with sudo, i.e.

sudo python blink1.py

As with the pin numbering, it is still a bit of a puzzle to me when super user rights are needed and when not. But the following worked for me without sudo

#### this is blink2.py #### 

import wiringpi
import time
import os

wiringpi.wiringPiSetupSys()

os.system('gpio export 17 out')

wiringpi.pinMode(17,1)

while True:
    time.sleep(0.5)
    wiringpi.digitalWrite(17,1)
    time.sleep(0.5)
    wiringpi.digitalWrite(17,0)

and then on the Linux command line

python blink2.py

It is already rewarding to see a simple LED blink. Next challenges will include combining it with a RFM12B or RFM69CW module to have the Rasperry Pi receive the messages from the (battery operated) Arduino’s for which I use the RFM12B for communication.

Furthermore, Adafruit has a nice tutorial showing how to use Node JS with a Raspberry Pi. That is also something to explore…

Raspberry Pi as Eurorack synthesizer module

Processing realtime EEG data from the OpenBCI system requires software running on a computer. For the EEGSynth project we do the rapid application development using the platforms that we are most familiar with, i.e. standard laptops and the FieldTrip toolbox, which is based on MATLAB. However, in the end we want to implement as much as possible using affordable and open hardware and software. Hence we opted for the Raspberry Pi, a credit card–sized single-board computer. It runs Linux, which makes it easy to use standard programming platforms and interfaces such as Python and Redis to implement the software stack.

In the first EEGSynth studio performance you can see Stephen in the middle, operating the MATLAB-based GUI for the EMG/EEG processing, and Jean-Louis at the back operating the synthesizer. The goal of the technological development is to put Jean-Louis completely in control and to make the interface of the EEG synthesizer as similar as his other modular synthesizer modules. Hence the need for fitting the Raspberry Pi into a Eurorack synthesizer case.

Here you can see some photo’s from the construction of the front panel.

2015-11-14 15.32.52 2015-11-14 16.30.57

The front plate has holes for the various interface ports to interface with the Raspberry Pi. For a sturdy mount I glued a section of L-profile rails to the front plate.

2015-11-14 21.36.36

After mounting the Raspberry Pi, I connected the HDMI and audio port with a short cable to the front panel.

DSC_0061

Here you can see the Raspberry Pi in the Eurorack case, next to the power supply.

DSC_0084

Eurorack power supply

I am working on fitting a Raspberry Pi as a Eurorack module in the EEGSynth. A previous post shows the completed case. Besides the Raspberry Pi which needs 5V, it will also hold a CV/Gate controller and some other modules for interfacing between the digital and analog parts of the synthesizer. The operational amplifiers and some other ICs on those modules require a symmetric positive and negative rails.

As I am not planing any critical parts that require an very stable voltage (such as a VCO) in my enclosure, I decided not to go for an expensive linear power supply, but rather construct one myself on the basis of two 12V switching power supply that I salvaged from some old wall-warts that once served some external 3.5 inch USB hard disks. The AC-DC converters have the 220V side isolated from the 12V side. This allows to connect the positive DC rails of one to the negative DC rails of the other, resulting in +12V and -12V from either converter relative to the common ground.

The Raspberry Pi requires quite a bit of current compared to most synthesizer modules, hence converting the 12V into 5V with a voltage regulator such as the L7805 would not be very efficient. Therefore I also added a 5V 2A AC-DC converter.

DSC_0071

DSC_0069

For safety I made a small plexiglass enclosure using the laser cutter at the Techlab Nijmegen. All electronics, except for the connector, switch and three LEDs are completely enclosed behind the aluminum front panel.

DSC_0072

The connector with the synthesizer modules consists of a flat cable, wired according to the A-100 system bus.

The LEDs show the status for each of the three voltage levels. Surprising is to see that it takes a good 10 seconds for the capacitors of the +12V and -12V to completely drain when switching the power off.