Blog - Sketching with Hardware

Team 5 – Optogram

Published on: | Author: Ronja Brettschneider | Categories: 2015b, Projects

The Optogram – see more. A new way of displaying images.

The Concept:

       The Concept started out with the idea of display images in a private setting. Since people can always look at your phones screen while your scaling over your “personal” news feed, we wanted to develop a program and hardware that would enable the user to view images in a private setting, no matter where they are.

The idea was inspired by an old school View-Master. Since we really wanted to focus on displaying images, we quickly decided to use once personal Instagram feed.

Getting started:

The original plan was to create an app, which would log on to your Instagram account and stream the feed to a server, create the server and parse the incoming stream of pictures, let the server serve those pictures via a GET request and let the Arduino stream the incoming pictures on a 3.2” TFT Display.

Baby steps:

On our first day we were able to experiment with the Arduino (we were able to get to know it on a deeper level) 😉

Our first little Project consisted of a GameCube-Controller, which we developed by hacking a keyboard and building a cube with sensors that were able to detect the direction in which the cube was tilted. A simple jump and run game was easily found and very interesting to play with the cube, since tilting a bulky cube fast enough to play a jump and run game is not the easies task (which was totally intended to spice up the game).



Getting real:

 Once the TFT display was delivered the real work began. After connecting everything mirrored due to the wrong data sheet, Alex was about to burn the entire thing. Instead we ordered the corresponding shield.


Viewing the first images on the TFT Display

Some more problems came up once we figured out that the UTFT library is not able to decode any common image formats. To work around this issue we created our own decoder, which was added to the server. Now it was possible to create a .txt file including the RGB values from any .jpg file.

Moving on we got started on the WiFi shield and tried to send a GET request to the server. It turned out to be a bit more problematic than expected. We didn’t fully comprehend the incoming data and how it was displayed. At the end, the parser was written, but we had about 50% packet loss. The example images (size 32x32px) were almost not visible.

We implemented an easy error correction algorithm. It restored the picture to ~ 60% completion. It also turned out that our TCP connection reset after ~ 200 sent pixels. We decided to save the Images to the SD-Card and parse them from there.

After we got the 2GB SD card up and running, the library for saving something to the SD card was not really sufficient. There was no “append”-mode and there were several other limitations that didn’t allow us to save the files as we intended. After a while it turned out that this was because we didn’t quite understand the way the data was coming in.

We uploaded the raw data on the SD card by hand and tried to display the picture via the parser. It terminated early, probably because of the unoptimized data consumption by the parser (we used the String objects provided by the Arduino library).

Then came an insight on how the data was really presented by the WiFi shield library – it was saved in fragmented chunks by the TCP. All we had to do was to update the parser to have a stateful design where it could handle a not ended pixel definition! But some of those fragments (and needed operations) were too big for our Arduino, which only had 8 KB RAM. With the help of several people in the Haskell & Python IRC channels and stackoverflow, we set up a proxy server based on Python, that splitted the data via a custom made delimiter and slowed the transfer rate just as much as needed by the Arduino to parse the incoming data and display it on the screen!

And it worked! Displaying a 32x32px picture took 2 minutes (and 45 min for a 140x160px)

We attached a rotary encoder to move between the pictures and a simple GUI that shows the current status of the WiFi. It automatically restarts if there is no connection to the WiFi and it also restarts after a failed connection setup between the servers and itself.


Rotary Encoder

 We eventually had some ideas to speed things up (e.g. rewrite the parser with custom accumulated memory in pure C), but there was just no time for it.

 We decided to use some pre-rendered pictures and some streamed 32x32px icons for the presentation. But again, luck was not on our side – if the capacity of the Flash Memory was more than 50% it wouldn’t load any pictures. So we displayed a start screen, the WiFi on/off symbol plus the pre-rendered and streamed images.


Start screen with WiFi symbol

Finally we tried to get the best alignment for the lenses and the corresponding pictures on the display.

We even fit a power bank in there, so our finished product was cordless!

DYI that thing:

After deciding on the over all idea, we unexpectedly found an old View-Master in a thrift shop around the corner of the university. We decided to rebuild something similar.

The basic design concept was to build a box that displayed the images inside of it. Once we researched different possibilities for our project we found the Goolge Cardboard.

Since we were not using a cell phone the decision to build a custom made version of it was inevitable.

After factoring in the space we would need for the Arduino, screen, power and cables the design started to come together.


The pieces were designed in Illustrator and cut out of wood by a laser cutter. In order to adjust and adapt the Optogram we decided to use screws, iron angles and fastener.


Laser cutting the pieces

The logo displays the old View-Master combined with a modern twist and the handwritten words “see more” to display the character of being inspired by an old thing, adding something modern and maybe unexpected and the fact that it is all build, designed and programmed by us.


Logo Design

The geers on the side of the Optogram are build to control the rotaty encoder.




We underestimated the extent of this project by far and we didn’t have any time left for the corresponding app. Altogether it was an interesting experience to work on such a low level where every byte is needed.

On the side note: The connection with the WiFi was somewhat unreliable and sometimes it took ~ 30 tries to get it up and running. The problems listed here were the most crucifying, but there were also others, which had not a big magnitude, so we excluded them. If somebody wants to implement this again or has in depth questions about this, message me at:


linked categories 2015b, Projects


Write a comment