Starling: A simple internet connected modular led display.
Sandeep (talk) 15:46, 19 November 2015 (IST)
Starling, aims to be a modular Wifi connected hackable LED Display board. It can be used out of the box to display text messages and custom characters. It can be used from anywhere you're. It should also be able to expand and display messages from web; sports, schedules, social network notifications, whether data, news and anything else you want. The display should be able to expand without changes in the software. The display blocks can be added or removed on the fly
Features:
- Modular: Individuals modules can be added on the fly without changing the firmware or the software.
- MCU driven: Individual LED modules are driven by Atmega8 instead of ASIC. It allows flexibility addressing, programming and interface support.
- Cloud Connected: The modules are are driven by ESP8266 which also connects to a WiFi Router and though it the the Internet.
- MQTT: reliable and fast. The Starling is connected to the MQTT broker hosted on a scalable clould
- Smart-Phone Apps: Apps for Android and iOS to display text or custom messages.
- Hackable with APIs: The APIs provide a way to easily display anything on the internet from twitter feed to scores, for the programmer in you.
Contents
Design Overview
The Hardware Design Choices
Atmega8 based Display Driver.
Since there the software needs to be adaptive the display driver board cannot have a ASIC like MAX7219. Here are reasons for choosing a controller over an ASIC:
- It can store ASCII tables and character patterns in lookup tables, this will make programming extremely easy.
- The display modules can communicate among-st each other and share data. In fact the master display module receives data. It check how many slave modules are connected, enumerates them and sends the data to be displayed. It can make smart decisions and make the hardware modular. I will speak more about this aspect later.
- It can be cheaper in large volumes.
- Firmware allows us to add features as we go along.
ESP8266 Wifi:
This choice was obvious. For the price and features it is a no brainier.
The Software Design Choices
The Master Firmware:
The master display module which handles the Wifi, device enumeration, communication etc will be written in Arduino. I am pondering over this this choice as of now. One reason to do this is, it will be easier for people to hack. On the other hand if do it in 'C'. It can be more efficient. If you want to suggest a choice do comment below with a reason.
The Slave Firmware:
This will be written in C for sure. It will make the code efficient, run fast and probably people would not want to fork around with it.
Smartphone Apps
I will be using a combination of JavaScript (AngularJS), node, Ionic and HTML 5 in order to write cross platform apps for Android and IOS. Since the apps will be simple it should work. However I might latter attempt to write native android and IOS apps; depending on the scope and interest in the project.
The Protocol (MQTT):
I wanted to make the display real time. Using HTTP for initial tests showed that it was slow and had lot of overhead. The request response structure isn't simply enough especially on slow networks. Hence I tried MQTT. It works beautifully even on slow networks and where bandwidth is a concern. The MQTT works on publish, subscribe model. The complexity is in the broker (the server), the apps, the display hardware are all the clients. The clients can simply subscribe to a Topic and receive messages. The broker does all the hard work of authentication and authorization. I will speak more about this later.
The Broker (Mosca or Mosquitoo)
Both of these work pretty well. Have tried hosting them on a local network as well as on the clould. They work reliably well as you will see in some of the tests.
The Web APIs:
There are lot things that I believe people would like to display depending on their interests. Hence giving out web APIs is a good option for all the hackers out their. I am comfortable with PHP and laravel and this what I am thinking of using. Even direct MQTT device access should be a good option. If you've any suggestions on this, please do comment below.
The Hardware