BINARY ANALYTICS Version II

Binary Analytics is

A physical terminal and control dashboards that allow any company to become its own consultant. Learn more

This project was the second collaboration with Binary Analytics Team check Versions Ifor details.

In 2019, my hardware partner and I were contacted by the CEO of Binary Analytics in order to discuss phase two of the product.

In a nutshell, the project was to design and develop an arcade-like terminal device that consists of a screen and four large buttons.

Note: I won’t go into hardware related details as my role was solely to design and implement the software system that runs on the device

Changes

• Binary Analytics hired a new backend developer and they went through some serious technical changes one of which was to use a different tech stack (move from .NET to NodeJS). This change breaks the version I of the app. We could just fix the broken API communication logic, but we thought it would be better to improve on what we had learnt from version I and implement the system from scratch.

• We decided to go with a more powerful raspberry pi (Raspberry Pi 3B), as we wanted to be able do some cool animations.

Requirements:

• Implement a Kiosk application that runs on the device.
• The device needs to communicate with Binary Analytics server through their new REST API.
• The device downloads configuration info from the server frequently.
• The device’s UI as well as other functionalities such as how frequently to check for WiFi can be configured from the server.
• Users can authenticate using RFID Tags.
• Control some LED s to indicate the state of WiFi status as well as power status.
• Ability to configure WiFi and other options on the Pi through a USB stick.
• Read Battery Status from an arduino chip and send it to the raspberry pi over I2C.

Process:

This time, in version 2, using Electron JS became a valid option after moving to Pi 3B. So, I decided to go with it as my main tech infrastructure.

Challenges:

• Electron Js is a single threaded framework, so running concurrent tasks wasn’t available out-of-the-box. to overcome this, web workers as well as other techniques have been implemented.
• To reduce costs, we wanted to use a small SD card to store the raspbian OS image.
• To save power when running on battery, we need to disable all unnecessary power intensive resources, such as Bluetooth, USB ports,etc. However, we needed at least one USB port to be able to configure the terminal device like WiFi etc..
• The API was being developed in parallel with the terminal device that consumes it. This resulted in a lot of changes that had to be communicated back and forth between the team, as well as introduced regression bugs whenever some major changes happened in the API implementation.

Outcome:

The project is in the final handover phase, the client likes the device and asked for 30 more devices to send out to potential customers and gather feedback.