This is a post written for Native Digital documenting an internal project that we wished to share.

---

At Native Digital, we build many campaigns for our clients with one of the main goals to increase the client's "Like Count" on Facebook. The more people that engage with a brand by "liking" it, the larger our client's audience for updates and marketing stories pushed through this social platform. 

As it is Native's responsibility to prove we are boosting the engagement numbers for our clients, we wanted a fun way to show this off to our client. 

Since we build our Facebook campaigns on the web, it would be very easy to hand the client a URL and tell them to check their statistics every so often to see how our campaign is fairing, but we weren't satisfied with the lack of excitement this provides. 

Some ideas few around, all revolving around building something physical to play the numbers game with. We chose to call it the LikeBot.

The LikeBot is a simple-looking portable box which displays text it grabs from the web. It can be battery powered, packs a cellular data radio, large blue LED matrix display, reprogrammable microcontroller and a button.

Doing some research into existing products similar to our concept, we found that many displays required plugging in, configuring, or some other form of setting up. Our ideal scenario would involve the client being sent the LikeBot, taking it out of the box and pushing the button to immediately see their big number. This presented us with some new challenges while working on the concept. 

Firstly, it is simple enough to write a small piece of software that delivers some data it grabs from the web for a hardware device that plugs in to the computer's USB port. This would be a blocker to our clients experience, as they would need to follow instructions, ensure the software runs on their system and plug the device in (https://memearchive.net/memerial.net/3097/plug-in-usb.jpg). 

We've seen several devices that overcome the software/plug-in-to-pc issue, some using WiFi, a physical LAN cable or bluetooth. All of these solutions still depend on either software (for bluetooth or configuring the WiFi password) or just a different type of cable.

The best way we came up with to avoid this was to use a cellular data connection. So long as the LikeBot would be in rage of a cell connection, it can grab data over the air, sans-wires and sans-configuration.

Using a cell chip also opens up other possibilities, such as the ability to SMS the 'Bot or make/receive phone calls with it.

As it turns out, interfacing with a cellular chipset is not an easy task. I will get to that soon.

The second part of the instant-use challenge was power. Most all similar devices plug in to an electrical outlet or are powered over USB. As I've pointed out, this is not the best experience we wanted to deliver. 

The solution sounds simple, but is surprisingly challenging in practicality. Batteries are large, heavy, require replacing or recharging and have a limited amount of juice they can supply. 

We started doing some prototypes and testing, beginning with choosing some hardware kits to build upon. 

Everyone's favourite microcontroller prototyping platform, the Arduino seemed an obvious choice. In hindsight, the limited RAM and difficulty in writing asynchronous programs made developing firmware a tricky task.

Looking through our choices for big, bright displays, we settled on the LotsOfLedsShield designed by Jimmy P Rodgers (https://jimmieprodgers.com/kits/lolshield/), which we ordered in blue, to match Facebook's branding.

I thought the kit would come pre-assembled, but when a packet of over 100 LEDs arrived, I discovered the construction guide and settled down to a long soldering session. Once the excitement of a big glowing array of LEDs, running a test program, had settled I poured over the schematics to figure out how many pins were left to play with. The LOLShield is an essentially simple circuit which uses a matrix arrangement to control all 126 LEDs using charliplexing on the 14 digital IO pins on the Arduino. 

The analogue bus was still available, however the hardware UART pins (0 and 1) were taken. 

Once the GPRS shield arrived from Cooking Hacks (https://www.cooking-hacks.com/index.php/shop/arduino/arduino-gprs-module.html), I discovered those UART pins were required in conflict with the LOLShield.

The GPRS shield is another, essentially simple circuit, relying mostly on the SAGEM GPRS chip, while providing the necessary niceties like a 3.3V power rail, antenna connector and an easy-to-prototype shield size package. 

Prototyping, using just the GPRS shield interfaced with the computer over a serial connection, was surprisingly difficult to get going.  

Finally after hours of trying different combinations of settings and tiny wires going back and forth to different points, I got the two letters I was looking for in my serial console 

OK

For anyone attempting this in the future, the serial settings I found to work using the Arduino serial monitor are thus:

• Turn on both new line and carriage return characters for the end of commands (Both NL & CR)
•  Use a baud rate of 38400 baud

The examples online and documentation don't make the process of establishing a data connection using the GPRS Shield very clear. My process went as follows: (All commands must be terminated by NL [ASCII 10] character and a CR [ASCII 13] character unless otherwise indicated) 

1. Ensure the modem is responding by sending the command AT and receive OK back 
2. Switch the modem into hardware flow control mode AT&k3
3. Set GPRS connection options. You will require your cellular providers APN for this step. Replace "internet" with your APN AT+KCNXCFG=0,"GPRS","internet"
4. Set timing options (check the cellular chip's datasheet for more information) AT+KCNXTIMER=0,60,2,70
5. Tell the modem which profile to use (unless a complex application is being built, stick with 0) AT+KCNXPROFILE=0
6. Bring the GPRS connection to attention (when the modem is powered on, it takes some time to establish a connection with the network, just like a mobile phone does) AT+CGATT=1 and receive OK back if the network connection is ready
7. Create a HTTP connection instance.This command takes a URL and port number. The modem allows for a number of simultaneous connections AT+KTCPCFG=0,0,"example.com",80 this will return a KTCPCFG acknowledgement followed by a connection number. Each time this command is run until the modem is reset, this number will increase (up to a small limit)
8. Using the connection number that was returned by the previous command, replace 1 AT+KTCPCNX=1 after a short delay OK will be received to say that the modem has successfully opened a connection 
9. Tell the modem to buffer data it will send over the air to the server it is connected to AT+KTCPSND=1,20 it is necessary to specify how many bytes are to be sent by replacing 20 with your own total. This includes new line characters and all the HTTP headers
10. Write the HTTP request. It is important to note, do not terminate the EOF Pattern indicator with either NL or CR otherwise the connection will be held open
    • GET / HTTP/1.0
    • --EOF--Pattern--
    • Once the request has ended (indicated with EOF Pattern), two acknowledgements will be received +KTCP_NOTIF: 1,8 and after a short time, followed by +KTCP_DATA: 1,477 the last number indicating how many byes will be received 
11. The data may now be retrieved using AT+KTCPRCV=1,477 the last number, a request to receive that many bytes. The requested data will at last be displayed! 
12. Finally, remember to close the connection with AT+KTCPCLOSE=1,1

It should be pretty obvious how low-level this hardware is, when it is necessary to write so many commands just to connect to a server. Writing software to do this using the limited RAM on the Arduino was certainly challenging. The beta code can be found on our GitHub.

As mentioned earlier, the GPRS shield uses the hardware serial (UART) pins on the Arduino, but the LOLShield already had taken these. After much brainstorming and experimentation I finally managed to get the modem to talk over a software serial library using the spare analogue pins. This makes the connection to the modem more unstable and a lower baud rate must be used to prevent corruption. A better solution would be to use a different microcontroller, such as the Arduino Mega, which has several hardware serial pins, or develop a custom display circuit and edit the libraries appropriately. 

I found the software serial solution the easiest to implement, however and it allowed the board to be stripped of extra components and mounted on the back of the Arduino using a few solder blobs to the data and power pins, while the LOLShield had an unimpeded  display on the front.

Attempting to battery power this three-board stack of circuitry provided another challenge, as outlined earlier. The GPRS chip frequently reset while establishing a connection to the network due to the rush of current required. I found it necessary to add some large capacitors to the 5v and 3.3v rails on the GPRS shield to provide enough current while connecting. Along with the display, wireless chip, an inability to put the Arduino to sleep (as the hardware interrupt pins were taken by the LOLShield), the LikeBot draws a lot of power and drains batteries fairly quickly.

The best way I could get around this limitation in the first prototype was to program the 'Bot to only display when the button was pushed, turn the modem off after downloading the latest text and when idle, run a loop waiting for the button state to change. 

Currently there are two 4xAA battery packs wired in parallel to provide the regulator with 6V. The circuitry could be optimised to eliminate the inefficient regulators and other battery-draining fluff, like the power LED

Powering on the modem, establishing a network connection, sending the request and reading the response over GPRS is incredibly slow, taking around 30 seconds! This defeats the original goal of taking the 'Bot out of the box and instantly seeing a number. 

Instead of waiting for new data to be retrieved, the current version of our firmware stores the last request in the Arduino's EEPROM space and makes a request to refresh this cache after the number or text has been displayed.

To drive our big number to clients, a basic Node.js server is running on Heroku. This provides a simple URL that the LikeBot can hit, polls Facebook's API to gather the Like count and Engagement stats and returns a very basic string, which is fed into the text library for the LOLShield.

There are many possibilities for reprogramming the 'Bot, as the display can produce graphics and animation and the cell routine could surely be optimised so updates are faster. Also, because it makes a request to our server every time the button is pushed, it would be possible to turn this into a web-connected counter or trigger for anything.

We finished the prototype with a slick white perspex case, modelled on the infamous Like button, including a vinyl cut "thumbs up" icon. The LED display is mounted behind the perspex where the work "like" appears on the virtual button. 

Pushing the physical button on top of the 'Bot first lights up the work "like" from inside the front perspex panel, followed by scrolling text including our big number.

Building this 'Bot provided many challenges, and many lessons were learnt. The final product looks fantastic, durable and friendly. We hope to keep working on this idea and produce a more cost effective, lower power, easier to build model which one day (if we work for you) may appear on your desk, ready to be taken out wherever you go to show off live statistics.