For the Gonzo exploratory engineering project I’ve been working on the backend receiving data as well as the web interface where said data can be viewed. Compared with the other parts of this project which were replacing the system app on Firefox OS with a camera and 3D printing enclosures for a new kind of device I definitely got the most straightforward one. However, since we didn’t have enough unknowns on this project I’ve jumped on every emerging web fad and gone down every rabbit hole I’ve encountered on my way. It’s been great fun and it’s made me think a lot about where Web UI is heading.

Continue reading »

My idea for Gonzo, from the very moment the idea sparked in my head last September (although that’s another story), was that we should aim for insane battery life. I want people to put up their Gonzo at hard to reach places without them having to worry to charge the device every week. That means that power consumption was our biggest concern when we started doing this project. How do you keep a device alive for at least a month? How much battery do we need to fulfill all our wishes, etc? The first thing we (and by we, I actually mean Thomas) did to achieve this goal was to set up proper power measurement equipment. A nice thing about reusing existing hardware is that a big portion of the work was already done for us by Mozilla engineer Jon Hylands. For power measurement you need a (3D printed) harness, a PCB to connect battery and main board, a power meter, and some software to read the data from the meter. All of that was already written up by Jon in a blog post on Mozilla Hacks.

Although building the harness was easily done by Bjørn (it even fitted the battery for the Geeksphone Keon the very first time), we didn’t have any PCBs until two weeks later, so our first power measurement tool was professionaly soldered together by Thomas.

Continue reading »

Timelapse of the sky. Gonzo can function both horizontal & vertical position. It uses accelerometer data to rotate the picture automatically.

Gonzo generates a lot of data. Our demo models currently make a picture every 30 seconds, mainly so we can see battery drain quickly, totalling at 2,880 photo’s a day. When you have to navigate this many photo’s you want to glaze over them as quickly as possible. To facilitate that we listen to the mousewheel event and change the photos using that which you can then use to quickly ‘fly’ over a stream. Something you learn when you interact with the stream that way is that when a Gonzo is stationary, you can create some pretty amazing timelapses. With that in mind I hacked my Friday morning away on a simple timelapse feature. First thing to do is of course to put one of our prototypes in front of the canals in Amsterdam.

Continue reading »

There is a variety of configuration options on the device that need to be managed, from the interval in which photos are made, to the API URL of the server. When you think over all the configuration options we have we can put them in three categories:

  1. Hard coded in the source code, e.g. the location of the API
  2. Local configuration, e.g. the PIN code of the SIM card in the device
  3. Remote configuration, e.g. the JPEG compression rate on photos

In general you want your basic configuration file to look completely OK so when someone flashes the device everything works out of the box. Sometimes it is required that pre-build time you configure some options, like the PIN code or whether you want to roam on the SIM card. Other options need to be changable from distance, because you would not want to re-flash a device to change the interval it makes photos in.

To accomodate for this we use a couple of techniques. First, we use architect, a dependency injection framework, to abstract away modules and their configuration on the device. We have a base configuration file that lists all the modules we have and we can specify options on a per-module basis. For example:

Continue reading »