Recently, my friend Bertrand wrote an interesting article about how he came to realize that we have become a “Society of Many Tribes”. Go ahead and read the article. It will be worth your time  The core concept of the article centers around “Thinking locally first and sharing your ideas with your tribes will eventually result in your impact becoming global”. This is a fascinating idea, begging to be experimented with. But how can one actually measure the breadth, depth and impact of one’s ideas as they travel and evolve through social networks?

Curiously, it turns out that the Klout team has come up with a set of metrics to do just that. If you have a Twitter, Facebook or LinkedIn account, you should try to link them to Klout to understand how this works: in a nutshell, Klout applies a set of algorithms, similar to Google’s page ranking algorithm, to your interactions and relationships within social networks and comes up with a synthetic score on a scale of 1 to 100, representing your overall influence a.k.a your “Klout Score”. A “Klout Score” is itself broken down into multiple data points, described in details here.

Klout’s metrics are interesting from a self-development standpoint because they can be used as a feedback loop: with them, you can evaluate within days or hours the effect of your communications, measuring what works vs. what doesn’t and learn to focus a message in the areas where it will resonate with a target audience. This is a valuable tool for individual bloggers and businesses alike.

Building a Klout Klock

Klout  exposes a web service enabling developers to build mash-up applications around its metrics and all that is required to play is an API key which is easily obtained when registering an application. My application is the “Klout Klock” device and before getting into the details of building it, you can see it how it works in this video:

The clock is built using a Netduino Plus and an AdaFruit ST7735 TFT screen. I have described how to connect them together in a previous post here. In that post, I had indicated that managing such a TFT screen from a Netduino was sub-optimal due to the memory requirements involved. That statement is even more true with a Netduino Plus which has roughly 28KB of RAM available for an application. This means that allocating a 40KB buffer to manage the TFT display as I was doing it previously is out of the question. Also, this time I am using the Netduino Plus’ SD card reader instead of the one built into the AdaFruit ST7735 breakout board. In addition, the screen’s back light is hooked up to a PWN pin to achieve the fade-in / fade-out effect based on the iCuffLink breathing effect 🙂

So, what do you do when you need to fit 10 lbs of crap in a 5 lbs bag? You use a virtual bag, of course! 🙂

Using an SD card as Virtual Memory

The Netduino Plus, in addition to its Ethernet connector, features a handy micro SD card reader for storage which I turned into virtual memory to get around the RAM constraints.

The virtual memory concept is straight forward: instead of reading and writing to/from a RAM buffer matching the size of the AdaFruit TFT display, all reading and writing operations happen against a file whose size matches the size of the display. In this case, that file is exactly 40960 bytes, the size required to hold a 128*160*16 bit/pixel image.

To actually refresh the screen with the image contained in virtual memory, the physical display is updated in ‘segments’, reading the data for each segment into a small RAM buffer, then blasting its content over SPI to the display. For each segment update, a display address window is positioned to cover the proper range of pixels.

The trade-off here is speed since file I/Os are orders of magnitude slower than operations in RAM but speed is not the main concern in this scenario. In addition, the more memory segments are used to chop up a virtual memory block, the slower it gets.

The following diagram shows how the process of updating the display from segmented virtual memory works:

I have added two classes to the Netduino Helpers library, respectively called “VirtualMemory.cs” and “VirtualFrame.cs” which make this process simple. I also refactored the driver that I had previously written for the AdaFruit ST7735 to make use of virtual memory if desired:

In this snippet, a virtual frame the size of the display is created and divided into 16 segments, ensuring that the I/O buffer used to read the image will only require 2560 bytes. The number of segments should be determined by a balance between performance and the overall memory constraints for the rest of the application. The reference to the newly minted VirtualFrame object is then passed to the instance of the display driver. Everything else about the driver works exactly as it did previously when actual RAM was being used.

The VirtualFrame class

This class is the workhorse driving the display and it’s worth explaining its core functions:

• Copy: this method clones a virtual memory object into the current one. The two copies are identical afterwards.
• Merge: this method takes a ‘background’ frame and a ‘sprite’ frame and combines them into the current virtual frame, effectively making this method a ‘BitBlit‘ function. Note that sprite transparency is not yet implemented. This method is used to display arbitrary graphics as well as printing strings on the display.
• GetPathFromCharacter: given a character, this method returns the full path to the file containing the bitmap representing the character. This is heavily used by the Print method to print strings on the display. It relies on the ‘BitmapDirectory’ property to determine the final path.
• Print: prints a character string at an arbitrary location on the display. Font transparency is not yet supported (see Merge). The dimensions of the font bitmaps must be provided as well. Also, the font is strictly limited to what is required by the clock application.

Strategies employed to dodge the dreaded “Out Of Memory” exceptions

In many ways, the “Klout Klock” application really pushes the envelope of what is possible on a Netduino Plus. To put things into perspective, here are the application requirements that needed to fit in 28KB of RAM:

• Use NTP time to update the internal clock of the Netduino Plus
• Use HTTP REST calls to fetch Klout metrics
• Parse JSON responses containing the Klout metrics
• Display the date, the time and the Klout metrics
• Drive the AdaFruit ST7735 TFT screen

Source Code and Configuration

* NTP Server list: http://tf.nist.gov/tf-cgi/servers.cgi
string:name=ntpServers;value=nist1-lv.ustiming.org,nist1.aol-ca.symmetricom.com,nist1.symmetricom.com,nist1-sj.ustiming.org,nist1-la.ustiming.org,utcnist.colorado.edu,utcnist2.colorado.edu,ntp-nist.ldsbc.edu
*
string:name=user;value=<KLOUT user name>
string:name=key;value=<KLOUT API Key>
string:name=host;value=api.klout.com
string:name=port;value=80
string:name=timeZone;value=-8
string:name=dst;value=1