Spree Hackathon Mars 2018


Spree is looking for new talents and wants to challenge you at a mini hackaton where we share knowledge and push each other towards new solutions in programming and problem solving.

Together in one evening we take a classic problem. The goal is to find the optimal solution and all funds are allowed. The task is given in Java, and a jar file will be provided on site. Bring your computer, and make sure you have an IDE for Java programming installed.

We offer light snacks and drinks. OSA for participation by Tuesday 20th of March.

Where: Spree AB, Dalagatan 100, 8tr
When: Thursday 22 of Mars, Time 17.00-20.00

Sign up with your name, where you study or work
and if you have any allergies / food preferences.

We have a limited number of places, so first come first served
and bring your own computer to hack!


About Spree

Spree has three focus areas that together complement us both in terms of competence and business. We develop tailored comprehensive solutions focusing on interactive installations and customized IT systems. With mission-specific teams in our own office, we drive projects from ax to limpa to ensure we deliver solutions based on our vision.

In parallel with our “inhouse” projects, we also strengthen our customers IT projects with competence rental. Our developers and UX designers become part of the customer’s team on both longer assignments, but also shorter projects. With our third focus area, we are always looking forward to technology, hardware like software. We have a constantly updated lab environment where we experiment and explore what new technologies can offer our customers.

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.