UPDATE:
Starling is live on Crowd Supply. Back us and help get Starling to life :)
Campaign Video:
Use Cases: These are just a few, you can hack it all the way!
https://www.crowdsupply.com/explore-embedded/starling
Demo Videos
[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.
Features
An 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 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 this stuff. I encourage you to try it out. I am coming to believe that people from hardware background can do it more aptly. Anyways I will be writing more about on the starling wiki page on ExploreEmbedded.com. For now enjoy the screenshots.
The Home tab:
Connect to the MQTT Broker(The server):
I could hide the web server address and the port number. However kept it for now so that it can be changed if required. The other two options are user name and password.
The text message: Custom Patterns: