Use Cases: These are just a few, you can hack it all the way!
[update: IFTTT support for Starling using maker channel]: Now display messages that matter to you without code. Looking forward to have a dedicated channel for starling.
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.
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.
- 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 phone Apps:
Ionic is beautiful to work with. You can build professional apps with just web technologies. It was first time I was doing a phone app. It is turning out to be an incredible experience. After shuffling embedded bits, where there is lot of uncertainty of what is working and what is not, web development and phone apps in a higher language comes as a breeze. It takes a little time to get you head around the programming languages, the framework and the architecture. However once that is done; you type, it simply works. If it does not you can simply check the log and figure out what is happening. If you're from electrical/electronics/embedded background and wanting to do...Read more »