Spree Spring Party 2017 - The technology

Spree Spring Party 2017

The technology behind the event

On May 17, 2017, Spree organized a party. To the party, a lot of software and hardware had been developed to make the experience as interactive and unique as possible. Here I was focusing about how the hardware worked and was designed. Hardware-wise is  it actually about two different solutions. All our RFID readers, both those used to start and sign up, as well as the wireless boxes, look the same on the inside. The robot bishop, on the other hand uses a completely different solution. The small RFID readers use a microcontroller called NodeMCU, which is a development board based on the wifi module ESP8266. If you are familiar with Arduino and its development environment, NodeMCU is very easy to use, as it can be programmed directly through the Arduino IDE. Although NodeMCU is limited in its GPIO, for example, there is only one ADC, it has at least the usual protocols SPI and I2C, which means it can communicate with a multitude of components. Among these there is the RFID reader we chose to use to read a tagging from users, MFRC522, which communicates via SPI.

In addition to the RFID reader, a single LED was also plugged in, flashing for certain patterns to show both an RFID tag was detected and to show that the server communication had gone as intended the server had accepted and responded to the incoming message. The communication between NodeMCU and server was via TCP. Each time a user tagged the RFID reader, a new connection to the server was opened, which was then closed again after the message was sent and response received. However, the WIFI connection itself was never broken. This was mainly because a WIFI connection takes a while to establish while a TCP connection is fast. An argument for not keeping the WIFI connection constant could be that this is taking a lot of power. Our solution estimates somewhere around 300mA, which is quite a lot in the IoT context. However, because we chose to run many of the solutions through standard mobile chargers, where even the simpler models managed to deliver 1A, we saw no problem in this. The wireless variants, our “hidden tags”, operated by so-called powerbanks to mobile phones. The model we chose had a capacity of 2600 mAh, which means we could drive each solution for about 8-9 hours. If it should be interesting to run the solutions for a long time, there are a number of options for accomplishing this.

Secondly, one could use the sleep functions available in ESP8266, which would reduce power consumption somewhat. Should the need be fined for significantly longer operating times, the voltage rating can be changed from 5V to 3.3V, which is the logic voltage used on both ESP8266 and MFRC522. This would mean that the voltage regulator on the NodeMCUn can be removed, which would save a couple of mA. Even the USB to UART circuit mounted on the NodeMCUn draws relatively much power. Because this circuit Only needed during the development phase, it can actually be removed completely, or redistributed in such a way that it can be manually switched on and off if necessary. In the end, these interventions should be able to extend battery life to days or weeks.


The little robot Bishop was built in Lego, mainly because Lego is really fun to build with and is very suitable for prototyping. Against all the rules that apply to Lego, it was then glued to a 3D-printed shell that designed for the purpose. Because the theme of the party was “Time Trip”, we chose to give a little wink to the TV series “Doctor Who”, and let Bishop’s shape be a scaled-down version of a Dalek.

Bishop had a little more electronics under the hood than the RFID readers. Bishop was based on an Arduino M0 Pro, a development board made by Arduino, based on a Cortex M0 microcontroller. M0 pro looks very much like the popular Arduino UNO board, but is much more advanced. It’s faster and has more memory, and a number of features that are not available at UNO. For example, M0 Pro has a DAC, multiple serial ports, and almost all GPIOs can act as PWM. However, it does not have a WIFI module, which meant we could use an external one. Here too, we chose to use the ESP8266 module, in this case as a stand-alone module, not placed on the NodeMCU development board. Because the ESP8266 itself contains a microprocessor, it is easy to communicate with it serially, with only one TX and RX cable. Here comes the fact that M0 Pro has access to several serial ports for utility. ESP8266 can be controlled by AT commands on a serial port, while serial communication via USB can be held as usual to communicate with a computer. As with the other solutions, an MFRC522 was used to read the guest’s RFID tags, and communicated via SPI.

To interact with their environment, three ultrasonic sensors were also used, with which measuring distances can be measured. By sending out an audio pulse and measuring the time it takes for an echo to return, one can decide the distance to objects in the surroundings. One sensor pointed straight ahead, and the other two pointed to the sides. Using these, the robot could determine if it was about to crash something, and then back up and rotate either to the right or left, depending on which sensor responded. These ultrasonic sensors do not communicate via any protocol, but only need two regular GPIOs, one to send away an audio pulse, and one stick to listen to the answer. The engines that gave Bishop life were common DC engines, of the Lego brand. Because DC motors are pulling too much power to make an Arduino manage to drive them directly through their studs, a separate drive circuit was required for this. We previously had a model MC33926 drive, of the brand Pololu laying around. It can handle two engines and can deliver up to 3A per engine. It also has some more advanced features, such as reading power consumption per engine. However, we chose these features to not use. MC33926 can be controlled by two studs per engine, one for direction of the engine, and one for the speed. The speed is determined by setting a PWM, where the duty cycle determines the speed of the engine. By cause of us having a few GPIO sticks left to use, we chose to also install five LEDs, which could indicate that a user had tagged the robot.

The engines are preferably powered with a voltage greater than 5V, because of this we chose to connect two power banks to power up the 10V power. The Arduinon voltage regulator is capable of managing voltages up to 12V, so this could be used to drive the rest of the system. If you were at the party, you might´ve noticed that Bishop got a little sad after a while and lost speed. This was due to a number of reasons, an accident commission has been put in place and is in the process of analyzing problem, but most likely it is a combination of a couple of things. The reason is that a lot of dirt and hair came into the machinery, which made the engines harder to spin. Another thing that happened was that a couple of cables jumped out at one time, which where possibly inserted incorrectly. It may also be because of the powerbanks we chose. To ensure that the batteries would not end, we chose to use two powerbanks for each 20000mAh. However, it seems that these were unnecessary advanced models, which included some type of surge protector that was activated when we connected the two packages to 10V.

Spree at ISE 2017

Spree was on the ISE in Amsterdam to capture the latest in screen technology, touch enabled screens, augmented reality and virtual reality. Everything that could be used for our projects and customers was of interest.

ISE 2017

The ISE (Integrated Systems Europe) fair took place on February 7th in Amsterdam at RAI, which is an area for trade fairs. We were at the fair on 7th and 8th of February for a total of 4 days. The ISE fair is, according to themselves, the largest Audio / Video exhibition in the world. The fair had 1200 exhibitors and 73000 visitors. The fair is aimed primarily at companies even though there were parts of the fair that are interesting to individuals. Much at the fair was aimed at “digital signage”, ie digital signage for advertising / concerts and other areas that need digital signs / displays.

There were also other areas that focused on integration between audio and video systems and end users. There was wide spread on which exhibitors were in place. For example, there were exhibitors targeting the education sector where products were available that would facilitate education. There were areas at the fair as only processed sound systems. There was also a smart home department where exhibitors showed different integrated home automation systems.

There were even A dronning area where several drones were demonstrated indoors. There was a large area dedicated to the latest projectors. To name a few of all the areas covered under this big roof. To name a few names, there were Samsung, LG, AOTO and others.

Module screens

Many exhibitors demonstrated screens that were made up of modules. Each module had a certain number of pixels and could be built into a larger screen. We were impressed with the built in modules did not show any joints.

The modules could be put together using simple means via contacts on each module. The modules were sliced until one had the desired size and width / height ratio. Each module could either be replaced completely or serviced both front and rear if only one side was available. Some models failed to replace damaged pixels.

One might imagine that the modules are not as good as a non modular screen solution, but these screens had high pixel density. You did not see the pixels if you stood 2-3 m from a 127 inch screen that had 1.4 mm between each pixel. We did not see a difference in the picture from different viewing angles, and the joints did not seem to. The heat generation was basically non existent unlike a consumer LED TV. It would not surprise me if this technology comes to ordinary consumers.

Transparent screens and display mirrors

We also saw transparent screens we used for our projects before. But this variant seemed to be significantly improved against those we used.

The screen works so that colored pixels can not be seen through while a white pixel makes it look straight through the screen. When the screen shows black color, you did not see the screen wherever you stood. It was just the viewing angle that was improved, enabling easier placement of the screen because the user could stand anywhere and interact.

Samsung demonstrated screens with mirrors so the mirror image collapsed with the image from the screen.