Made in Arcada: An open-access DIY intercom system.

Niclas Hallgren, Technical Operations Manager, Institutionen för Kultur och Media, Arcada UAS

 

An intercom system enables the production team to communicate with each other, it can have many different forms for example studio cameras have built-in intercom systems. At Arcada, we use smaller cameras both for field work and in the studio. The basic parts of an intercom system are a beltpack and a base station. A beltpack is carried in the belt by members of the production team in the studio and usually only have the possibility to talk to one or two places, it can be connected with a wire or wireless. Base stations are used in control rooms, by for example the director and can be used to talk to many different places.

During our multi-camera courses at the university we have been using a 15+ year old wire based Clear-Com intercom system for communication between the different roles in the multi-camera team. A few years ago we began using optical fibers from other parts of the campus as well as mobile ENG teams that stream their AV-feeds over IP back to the studio. The problem was that we could not use the wire based intercom system anymore so we started thinking of alternative solutions. It had to be IP based because of distances and commercial IP based systems were too expensive for us.

 

Mumble to the rescue

I had heard about Mumble, an open source voice chat software with the functionality we needed. It also encrypts all the communications. In Mumble you can have different channels that enable different teams to be separated during production. The video team can have their own discussions, and at the same time the audio team can have their discussions. I decided that Mumble suits our needs very well, but the problem was how to implement and use it. I found clients for mobile phones that could work but there were a few major disadvantages:

• mobile clients only have access to the “Push To Talk” function that only can broadcast to the same channel, to be able to talk across channels we must be able to use a function called “Whisper/Shout”.
• mobile clients must be able to run Mumble for a whole day (8-12h) and most phone batteries will not last that long. And many phones will turn off the wifi and/or Mumble client a while after the screen is locked.
• there are no physical buttons to press, when you need to talk, you must open the phone and press a button on the touch screen.

 

Funding and the process

In order to design and build a new intercom system that would meet our needs, I applied for funds from the university fund for technical education and research, TUF (Fonden för teknisk utbildning och forskning) to cover workhours and component costs. The universities strategy is to encourage open access,  and from the beginning my idea was to be able to share the result on how to replicate the intercom system. During development, I tried my best to keep everything as easy as possible. Most of the connections are done without soldering, using standard Dupont connectors and premade electronics modules, but to be able to finish this project, basic electronics skills are required as well as basic linux knowledge. The project got the funds and the next step was to find a single-board computer that could be carried in the belt. I had been using Raspberry Pi computers but they were not fast enough at that time to run Mumble. The challenge with Mumble is that it cannot be used in text mode from a console, it requires a graphical interface. During the process I tried many single-board computers and actually built beltpacks with a few different single-board computers (Olimex A20.OlinuXino-LIME2, Orange Pi Zero) before choosing the Raspberry Pi 3 just before I started the documentation.

 

Challenges

Without going into too much detail, the reason I settled for the Raspberry Pi 3 is that during the 4 years I have worked on the project there have been all kinds of challenges as things changed. New versions of both hardware and software have been released, components updated and so on. For example, differences between linux legacy kernel (3.x) and mainline (4.x) broke functionality for some hardware, other problems are related to powering the beltpacks. The first beltpack used 6000mAh LiPo batteries because the single-board computer then used supported it, it was nice because then it was possible to remotely check how much power was left in the batteries. The first beltpack was housed in a shelf metal box with hole for the WiFi antenna, later on in the project then I got access to a 3D printer and the limits of the metal box were removed. At the time I googled for inexpensive, high quality power banks and ended up with a 10 Ah from Xiaomi, but during the years Xiaomi have changed their design twice. Resulting in a need for new 3D printed enclosures to fit the new size. To be able to test everything as wanted, I needed the intercom system to be in real use to find the problems and weaknesses. As we only have two multi-camera courses a year it meant that when I found a problem it took about half a year before I had the opportunity to test my fix under real conditions. Many tests were of course conducted between courses but some problems did not appear until a full scale test was done in a production environment with a full studio crew.

 

Hardware to software

Besides audio, there are a few other functions needed that had to be coded as a layer between the hardware and Mumble:

• convert physical buttons on beltpack and base station to emulate keyboard presses for Mumble.
• adjust volume for beltpacks with a potentiometer that controls the soundcard digitally, not after the audio output.
• beltpack with two channels and a display that shows wifi connectivity/strength, IP address, role of beltpack as well as to whom it talks.
• base station with 8 channels and displays to show who is talking and to who it can talk.
• a way to broadcast information between the devices.

I decided to go with the MQTT (Message Queuing Telemetry Transport) protocol for communication between the devices. MQTT has a central server called a broker that devices can subscribe and publish to. Every message has a topic and based on the topic the broker knows who have subscribed and can relay that message to the right recipients.

Python was chosen as the main programming language for both the beltpack and base station as I had played around with it before and knew that it had many pre-made libraries for the functions I needed. The web interface for setup of the display and role system is made with Node.js.

 

Using the intercom system

In the code, I have chosen to use the keyboard combination of CTRL+ a number (1-8) when a switch or button is pressed. So when the switch on the beltpack is pushed to the left it sends “CTRL+1” and when pushed to the right “CTRL+2”. The base station has 8 buttons with the same logic.

Before first use and if changes are needed, the system needs to be setup. This is done in two parts because the web interface cannot make changes to Mumbles configuration. This is all covered in the published documentation which allows anyone interested to build a similar system for their own use (see links below).

At the moment our intercom system tree looks like this, channels are in bold

ANNOUNCEMENT

Studio speaker (a Raspberry Pi connected to the studio monitor)

AUDIO

AUDIO (base station)

AUDIOBP1 (beltpack)

AUDIOBP2 (beltpack)

IN-EAR

INEAR1 (possibility to talk to host, beltpack)

LIGHT

LIGHTBP1 (beltpack)

TECH

TOM (Technical Operations Manager, desktop computer)

VIDEO

                           DIR/SCRIPT (Director basestsation)

VISION (Vision control base station)

 CAMS

CAM1 (beltpack)

CAM2 (beltpack)

CAM3 (beltpack)

CAM4 (beltpack)

CAM5 (beltpack)

CAM6 (beltpack)

FM

FM (Floomanager, beltpack)

We have used the system with 12 beltpacks and 4 base stations but it should be possible to connect many more. The audio latency between a WiFi beltpack and a base station is around 100ms. It is also possible to use a 4G mobile as a WiFi access point and connect the beltpack to the phone. This enables communications with teams off campus.

 

Conclusions

The project ended in December 2018. We will continue to use the intercom system for our multi-camera productions. The beltpack batteries are good for 18+ hours so even very long studio days are possible. Everything works as it should but there is always room for improvement. The python and node.js code is unlicensed without any warranties or support and only released here to be able to follow up the interest of projects like this. IP addresses, usernames and passwords used in the guides are for demonstration purposes only, and as stated in the guides you should use your own. Use the code as a starting point and feel free to make it better. I have learned a lot during this project and if I would start over I would re-think the battery solution and go for a standardized NP-F750 type battery that most likely will be around for many years to come. Regarding the 3D enclosures, I had no experience designing/printing 3D enclosures prior to this. When it comes to the electronics I would take a look at the new Raspberry Pi 3A+ which has a smaller footprint and also supports 5GHz WiFi. The way the current beltpack enclosure is designed the soundcard would not fit when attached to the new 3A+, but with some small adjustments to the design in Fusion 360 it will. If you need a truly headless client take a look at talkiepi (https://github.com/dchote/talkiepi (External link)) written in Go by Daniel Chote but it only supported the “Push To Talk” function last time I checked.

 

The DIY Intercom Package includes instructions for: 

Server

Setup instructions for server (pdf 12 pages)

Node.js code

Beltpack

Beltpack hardware installation guide (pdf 16 pages)

Beltpack software setup instuctions (pdf 22 pages)

Beltpack enclosure in Fusion 360 format

Fritzing breadboard view of beltpack

Python code

Gerber file for optional breakout pcb

Base station

Base station hardware installation guide (pdf 16 pages)

Base station software setup instuctions (pdf 23 pages)

Base station enclosure in Fusion 360 format

Fritzing breadboard view of base station

Python code

Gerber file for optional breakout pcb

 

Links

http://crabbofix.arcada.fi/intercom_blog_files/basestation_setup.zip (External link)

http://crabbofix.arcada.fi/intercom_blog_files/beltpack_setup.zip (External link)

http://crabbofix.arcada.fi/intercom_blog_files/server_setup.zip (External link)

 

niclas.hallgren@arcada.fi