Key 2.0 — Bluetooth IoT Door Lock

What is Key 2.0?

Key 2.0 (or Key20 for short) is a Bluetooth IoT Door Lock. It turns a conventional electric door lock into a smart door lock that can be opened using a smartphone without the need for a physical key. Thus, Key20 is the modern version of a physical key, or, as the name suggests, the key version 2.0 for the Internet of Things (IoT) era.

Key20 consists of two parts:

  1. Door lock controller device, which is physically connected to the electric door lock and wirelessly via BLE to the mobile app.
  2. Mobile app implementing the user interface to unlock the door and communicating with the door lock controller through BLE.

You can get a quick impression on how Key20 works by watching the following video:

The following image shows the Key20 door lock controller device and the Key20 app running on a smartphone.

Key 2.0 App and Door Lock Controller Device

Key 2.0 App and Door Lock Controller Device

The main features of Key20 are:

  • Using state-of-the-art security mechanisms (Elliptic Curve Diffie-Hellman Key Exchange (ECDH), HMAC) to protect against attacks.
  • Open-source software and hardware, including an open implementation of the security mechanisms. No security by obscurity! Source code for the app and door lock controller as well as Eagle files (schematic and board layout) are available on GitHub.
  • Maker-friendly: using easily available cheap standard components (nRF51822 BLE chip, standard electronic parts), easy to manufacture circuit board, and open-source software and hardware design.
  • Works with BLE-enabled Android 4.3 mobile devices (and of course newer versions). Porting to other mobile operating systems like iOS should be straightforward.
  • Liberal licensing of software and hardware under the Apache License 2.0 and the CERN Open Hardware License 1.0, respectively.

Security Concepts

A door lock obviously requires security mechanisms to protect from unauthorized requests to open the door. To this end, Key20 implements the following state of the art security mechanisms.

Authorization of Door Open Requests with HMAC

All door open requests are authorized through a Keyed Hash Message Authentication Code (HMAC). A 16 byte nonce (big random number) is generated by the door lock controller for each door open request as soon as a BLE connection is made to the door lock controller. The nonce is sent to the mobile app. Both, the nonce and the shared secret, are used by the mobile app to calculate a 512 bit HMAC using the SHA-2 hashing algorithm, which is then truncated to 256 bits (HMAC512-256), and sent to the door lock controller. The door lock controller also calculates an HMAC based on the nonce and the shared secret, and only if both HMACs match, the door will be opened.

The nonce is only valid for one door open request and effectively prevents replay attacks, i.e., an attacker sniffing on the radio channel and replaying the sniffed HMAC later. Note that the BLE radio communication is not encrypted, and it actually does not need to be encrypted since a captured HMAC is useless when re-played.

Moreover, each nonce is only valid for 15 s to prevent man-in-the-middle attacks where an attacker intercepts the HMAC and does not forward it immediatelly but waits until the (authorized) user walks away after he is not able to open the door. Later the attacker would then send the HMAC to the door lock controller to open the door. With a time window of only 15 s (which could be reduced further), such attacks are futile since the authorized user will still be at the door.

Note that the whole authentication procedure does not include heavy-weight asymmetric crypto functions, but only light-weight hashing algorithms, which can be performed on the door lock device featuring an nRF51822 micro-controller (ARM Cortex M0) very fast in order not to delay door unlocking.

With respect to the random nonce we would like to note the following. First, the nRF51822 chip includes a random number generator for generating random numbers from thermal noise, so nonces should be of high quality, i.e., truly random. An attack by cooling down the Bluetooth chip to reduce randomness due to thermal noise is not relevant here since this requires physical access to the lock controller installed within the building, i.e., the attacker is then already in your house.

Secondly, 128 bit nonces provide reasonable security for our purpose. Assume one door open request per millisecond (very pessimistic assumption!) and 100 years of operation, i.e., less than n = 2^42 requests to be protected. With 128 bit nonces, we have m = 2^128 possible nonce values. Then the birthday paradox can be used to calculate the probability p of at least one pair of requests sharing the same nonce, or, inversely, no nonces shared by any pair of requests. An approximation of p for n << m is p(n,m) = 1 – e^((-n^2)/(2*m)), which practically evaluates to 0 for n = 2^42 and m = 2^128. Even for n = 2^52 (one request per us; actually not possible with BLE), p(2^52,2^128) < 3e-8, which is about the probability to be hit by lightning, which is about 5.5e-8.

Exchanging Keys with Elliptic Curve Diffie Hellman Key Exchange (ECDH)

Obviously, the critical part is the establishment of a shared secret between the door lock controller and the mobile app. Anybody in possession of the shared secret can enter the building, thus, we must ensure that only the lock controller and the Key20 app know the secret. To this end, we use Elliptic Curve Diffie-Hellman (ECDH) key exchange based on Curve 25519. We assume that the door lock controller is installed inside the building that is secured by the lock—if the attacker is already in your home, the door lock is futile anyway. Thus, only the authorized user (owner of the building) has physical access to the door lock controller.

First, the user needs to press a button on the door lock controller device to enter key exchange mode (the red button in the pictures). Then both, the mobile app and the door lock controller calculate different key pairs based on the Elliptic Curve 25519 and exchange their public keys, which anyone can know. Using the public key of the other party and their own private keys, the lock controller and the app can calculate the same shared secret.

Using Curve 25519 and the Curve 25519 assembler implementation optimized for ARM Cortex-M0 from the Micro NaCl project, key pairs and shared secrets can be calculated in sub-seconds on the nRF51822 BLE chip (ARM Cortex M0).

Without further measures, DH is susceptible to man-in-the-middle attacks where an attacker actively manipulates the communication between mobile app and door lock controller. With such attacks, the attacker could exchange his own public key with both, the lock controller and the app to establish two shared secrets between him and the door lock controller, and between him and the mobile app. We prevent such attacks with the following mechanism. After key exchange, the mobile app and the door lock device both display a checksum (hash) of their version of the exchanged shared secret. The user will visually check these checksums to verify that they are the same. If they are the same, no man-in-the-middle attack has happened since the man in the middle cannot calculate the same shared secret as the door lock controller and the mobile app (after all, the private keys of door lock controller and mobile app remain private). Only then the user will confirm the key by pressing buttons on the door lock controller and the mobile app. Remember that only the authorized user has physical access to the door lock controller since it is installed within the building to be secured by the lock.

The following image shows the mobile app and the door lock controller displaying a shared secret checksum after key exchange. The user can confirm this secret by pushing the green button the the lock controller device and the Confirm Key button of the app.

Key 2.0: key checksum verification after key exchange.

Key 2.0: key checksum verification after key exchange.

Why not Standard Bluetooth Security?

Actually, Bluetooth 4.2 implements security concepts similar to the mechanisms described above. So it is a valid question why don’t we just rely on the security concepts implemented by Bluetooth?

A good overview why Bluetooth might not be as secure as we would like it to be is provided by Francisco Corella. So we refer the interested reader to his page for the technical details and a discussion of Bluetooth security. We also would like to add that many mobile devices still do not implement Bluetooth 4.2 but only Bluetooth 4.0, which is even less secure than Bluetooth 4.2.

So we decided not to rely on Bluetooth security mechanisms, but rather implement all security protocols on the application layer using state of the art security mechanisms as described above.

Bluetooth Door Lock Controller Device

The following image shows the door lock controller and its components.

Key 2.0 Door Lock Controller Device

Key 2.0 Door Lock Controller Device

The Door Lock Controller Device needs to be connected to the electric door lock (2 cables). You can simply replace a manual switch by the door lock controller device.

The door lock controller needs to be placed in Bluetooth radio range to the door and inside the building. Typical radio ranges are about 10 m. Depending on the walls, the distance might be shorter or longer. In our experience, one concrete wall is no problem, but two might block the radio signal.

The main part of the hardware is an nRF51822 BLE chip from Nordic Semiconductors. The nRF51822 features an ARM Cortex M0 micro-controller and a so-called softdevice implementing the Bluetooth stack, which runs together with the application logic on the ARM Cortex M0 processor.

An LCD is used to implement the secure key exchange procedure described above (visual key verification to avoid man-in-the-middle attacks).

For more technical details including schematics, board layout, and source code please visit the Key20 GitHub page.

Android App

The app requires a BLE-enabled mobile device running Android version 4.3 “Jelly Bean” (API level 18) or higher.

The following images show the two major tabs of the app: one for opening the door, and the second for exchanging keys between the app and the door lock controller.

Key 2.0 App: door unlock tab

Key 2.0 App: door unlock tab


Key 2.0 App: key exchange tab

Key 2.0 App: key exchange tab

The source code is available from the Key20 GitHub page.

BLE-V-Monitor: How car batteries join the Internet of Things

The Internet of Things (IoT) envisions a world where virtually everything is connected and able to communicate. Today, I want to present one such IoT application, namely, the BLE-V-Monitor: a battery voltage monitor for vehicels (cars, motorbikes).

BLE-V-Monitor consists of an Arduino-based monitoring device and an Android app. The BLE-V-Monitor device is connected to the car battery to monitor the battery voltage and record voltage histories. The app queries the current voltage and voltage history via Bluetooth Low Energy (BLE) and displays them to the user. Below you can see an image of the circuit board of the BLE-V-Monitor device and two sceenshots of the app showing the current voltage, charge status, and voltage history.

BLE-V-Monitor Board

BLE-V-Monitor board.


BLE-V-Monitor app: voltage and charge status

BLE-V-Monitor app: voltage and charge status

BLE-V-Monitor app: minutely history

BLE-V-Monitor app: minutely voltage history

The main features of BLE-V-Monitor are:

  • Voltage and battery charge status monitoring
  • Recording of minutely, hourly, and daily voltage histories
  • Bluetooth Low Energy (BLE) to transmit voltage samples to smartphones, tablets, Internet gateways, etc.
  • Very low energy consumption
  • Android app for displaying current voltage and voltage histories
  • Open source hardware (CERN Open Hardware Licence v1.2) and software (Apache License 2.0)


According to a recent study of ADAC (the largest automobile club in Europe), 46 % of car breakdowns are due to electrical problems, mostly empty or broken batteries. Personally, I know several incidents, where a broken or empty battery was the reason for breakdowns of cars or motorbikes. So no question: there is a real problem to be solved.

The major problem with an empty battery is that you might not realize it until you turn the key, or for those of you with a more modern car, push the engine start button. And then it is already too late! So wouldn’t it be nice if the battery could tell you in advance, when it needs to be recharged and let you know its status (weakly charge, fully charged, discharged, etc.)?

That’s where the Internet of Things comes into play: the “thing” is your car battery, which is able to communicate its voltage and charge status using wireless communication technologies.

Let me present you some technical details of BLE-V-Monitor, to show you how to implement this specific IoT use case. More details including Android and Arduino source code and hardware design (PCB layout) can be found on Github:


The technical design of BLE-V-Monitor was driven by two key requirements:

  1. Keep it as simple as possible: Simple and commonly available hardware; through-hole PCB design to allow for simple etching and soldering.
  2. Very low energy consumption. What is the use of a battery monitor consuming substantial energy? Just to give you an idea that this is not trivial even considering the fact that a car battery stores a lot of energy (usually more than 40 Ah even for smaller cars): Consider the current of one standard LED, which is about 15 mA connected through a resistor to your 12 V car battery. After two hours, this LED and the resistor consumed 2 h * 15 mA * 12 V = 30 mAh * 12 V energy. Now, assume starting your motor with a starter motor drawing 50 A on average over a 2 s starting period. In this scenario, starting your motor once consumes 2 s * 50 A * 12 V = 28 mAh * 12 V. Thus, in less than two hours, the LED and its resistor consumed about the same energy as starting your car once. I know, this scenario is highly simplified, but it might serve to show that even a small consumer (in our case the BLE-Monitor device) is significant if it is running for a long time. Consequently, as a goal we want to bring down the average energy consumption of the monitoring device far below 1 mA.


Technically, BLE-V-Monitor consists of the BLE-V-Monitor device already shown above and a smartphone app for Android.

The BLE-V-Monitor device periodically samples the voltage of the battery, and the app uses Bluetooth Low Energy (BLE) to query the battery voltage when the smartphone is close to the car. Instead of using a smartphone, you could also install some dedicated (fixed) hardware (e.g., a Raspberry Pi with a Bluetooth USB stick in your garage), but since I walk by my car every day and the range of BLE was sufficient to receive the signal even one floor above the garage, I did not consider this option so far.

In order not to lose data while the smartphone is not within BLE range, the BLE-V-Monitor device records minutely, daily, and hourly histories in RAM, which can then be queried by the smartphone.

This approach based on BLE has several advantages: It is cheap. It is energy efficient. Clients can be implemented with many existing devices since BLE is commonly available in most consumer devices, in particular, mobile devices and cheap single-board computers like the Raspberry Pi (using a Bluetooth USB stick).

BLE-V-Monitor Device

The BLE-V-Monitor device is based on the Arduino platform. It uses an ATmega 328P microcontroller and the BLE module MOD-nRF8001 from Olimex with the Nordic Semiconductors BLE chip nRF8001. The ATmega is programmed via an in-system programmer (ISP) and interfaces with the BLE module through SPI. Overall, if you build this device yourself, the hardware might cost you less than 20$.  And since we rely on a simple and energy efficient microcontroller and BLE together with small duty cycles, the current consumption can be below 100 microampere (including everything like the 3.3 V voltage regulator to power the microcontroller and BLE module from the car battery).

To measure voltage, we use the 10 bit analog/digital converter (ADC) of the ATmega (no extra ADC component required). The voltage range that can be measured ranges from 0 to 18 V, thus, the resolution is 18 V / 1024 = 17.6 mV, which is fine-grained enough to derive the charge status of the battery (see voltage thresholds below). Note that while the car is running, the car’s alternator provides more than 12 V to charge the battery (about 15 V for my car as can be seen from the voltage history screenshot). A voltage divider with large resistor values (to save energy) is used to divide the battery voltage. Since we use a 2.5 V reference voltage, 18 V is mapped to 2.5 V by the voltage divider. The 2.5 V reference voltage is provided by the very precise micropower voltage reference diode LM285-2.5, which is only powered on demand through a GPIO pin of the ATmega during sampling to minimize energy consumption as much as possible. Since the resistors of the voltage divider have large values to save energy, a 100 nF capacitor in parallel to the second resistor of the voltage divider provides a low impedance source to the ADC (this 100 nF capacitor is much larger than the 14 pF sampling capacitor of the ATmega).

A 18 V varistor (not shown on the image; it’s an SMD on the backside of the PCB since I only had an SMD version available) protects from transient voltage spikes above 18 V. Since varistors typically age whenever they shunt excessive voltage, a fuse limits the current to protect against a short circuit of the varistor.

A micropower voltage regulator (LP295x) provides 3.3 V to the ATmega and BLE module. The 100 mA that can be provided by this regulator are more than sufficient to power the ATmega and BLE module while being active, and a very low quiescent current of only 75 microampere ensures efficient operation with small duty cycles.

BLE-V-Monitor App

The BLE-V-Monitor App is implemented for Android (version 4.3 or higher since we need the BLE features of Android). It consists of a tab view with a fragment to display the current voltage, and three more fragments to display minutely, hourly, and daily voltage histories, respectively.

The charge status of a lead–acid car battery can be quite easily derived from its voltage. We use the following voltage levels to estimate the charge status on the client side:

  • 100 % charged (fully charged): about 12.66 V
  • 75 % charged (charged): about 12.35 V
  • 50 % charged (weakly charged): about 12.10 V
  • 25 % charged (discharged): about 11.95 V
  • 0 % charged (over discharged): about 11.7 V

The screenshots above show some examples of the current voltage, charge status, and voltage histories. In the history screenshot you can also identify two periods when the car was running where the charging voltage reached about 15 V.

Final Prototype

The following photos show how the BLE-V-monitor PCB is mounted inside a case and the placement of the monitoring device right in front of the battery of my car (in this photo, the device is already connected to the battery but not yet fixed). Fortunately, older cars have plenty of space and not a lot of useless plastic hiding every part of the motor.

BLE-V-Monitor device

BLE-V-Monitor device with case


BLE-V-Monitor device in car

BLE-V-Monitor device mounted in car and connected to car battery

The pull relief (knot) might not look very elegant but it is highly effective.

Obviously, plastic is the better choice for the case since the Bluetooth module is inside. Still, I had some concerns that all the metal of the car would shield Bluetooth signals too much, but it works suprisingly well. Even one floor above the garage with the metal engine hood and a concrete ceiling between device and client I can still receive a weak signal and I can still query the battery status.

Where to go from here?

Obviously, there is some potential to further improve the functionality. Beyond just monitoring the raw voltage and mapping it to a charge status, we could analyse the voltage data to find out whether the battery is still in a healthy condition. For instance, we could look at voltage peaks and analyse the voltage histories to find out how quickly the battery discharges, and how these values change over the lifetime of the battery. To this end, you could send the data to the cloud. Although I think, you could implement such simple “small data” analytics also on the smartphone or even on the microcontroller of the monitoring device.

However, the battery or car vendor might want to collect the status of all of their batteries in the cloud for other reasons, for instance, to improve maintenance and product quality, or to offer advanced services. With the cloud, everything becomes a service, so why not offering “battery as a service”? Instead of buying the battery, you buy the service of always having enough energy to operate your car. When the performance of your battery is degrading over time, the vendor already knows and sends you a new battery well before the old one is completely broken or invites you to visit a garage where they exchange the battery for you (this service would be include in the “battery as a service” fees).

I hope you found this little journey to the IoT interesting. Have a good trip, wherever you go!

Faros BLE Beacon with Google Eddystone Support

Today I want to introduce Faros, an open-source Bluetooth Low Energy (BLE) beacon supporting Google’s open beacon format Eddystone implemented for the popular Arduino platform.

With the invention of Apple’s iBeacon, BLE beacons became very popular as a positioning technology. Now Google has released a new open beacon format called Eddystone (named after a famous lighthouse), which is more versatile. Eddystone supports three frame types for broadcasting data:

  • UID frames broadcasting identifiers, namely a namespace identifier to group a set of beacons, and an instance identifier to identify an individual beacon.
  • URL frames broadcasting a short URL, so you can think of this as a radio-based QR code replacement.
  • Telemetry (TLM) frames to check the health status of beacons. These frames contain the beacon temperature, battery level, uptime, and counters for broadcasted frames to facilitate the management of beacons.

The complete protocol specification is online, so I do not go into much technical detail here.

Faros (named after the Faros of Alexandria, which was one of the seven wonders of the ancient world) is an implementation of the Eddystone protocol targeting the popular Arduino platform and using the nRF8001 chip of Nordic Semiconductors. The main features of Faros are:

  • Full support for all Eddystone frame types (UID, URL, TLM)
  • Energy efficiency allowing for runtimes of several years
  • Using popular and powerful hardware platforms: Arduino and nRF8001 BLE chip
  • Simplicity of hardware: easy to build using a commodity Arduino or our Faros board together with the BLE module MOD-nRF8001 from Olimex
  • Liberal licensing: Apache License 2.0 for software, CERN Open Hardware Licence v1.2 for hardware

Faros is hosted at GitHub and includes:

  • Source code for Arduino
  • Faros board schematics and board layouts

Below you see several versions of Faros beacons:

  • Faros software running on a commodity Arduino Pro Micro, powered and programmed through the USB connector. This could also be easily setup on a breadboard.
  • Self-made Faros printed circuit board (50 mm x 70 mm) with an ATmega328P powered by two AA-size batteries. A PDF with the PCB mask is included in the Git repository.
  • Faros printed circuit board (50 mm x 50 mm) manufactured by Seeed Studio using an ATmega328P. 10 PCBs cost about 15 $ including shipping. Gerber files are included in the Git repository.
Faros on Arduino Pro Micro

Faros running on Arduino Pro Micro

Faros board with ATMega 326P

Self-made Faros board with ATmega328P

Faros Board

Faros board manufactured by Seeed Studio with ATmega328P

The Faros board further lowers cost and energy consumption—two very important requirements for field deployments. The Faros board just needs the BLE module and an ATmega328P (where the “P” stands for pico-power). It is programmed via ISP so you do not need USB. The ATmega is put into power-down mode whenever possible, and then consumes only few micro-ampere. The nRF8001 will wake up the ATmega whenever it has an event to transmit. Moreover, the watch dog timer wakes up the ATmega periodically to switch the Eddystone frame types. Thus, the beacon can send all three frame types sequentially in a round robin fashion.

The Faros board is kept as simple as possible (through-hole design, no SMD
components). It comes in two versions: (1) a single-sided 50 mm x 70 mm layout
that is well-suited for self-etching; (2) a double-sided 50 mm x 50 mm layout that can be sent to a PCB manufacturer.

The Faros board also has a 3 mm low-current LED, which can be switched on by a digital pin of the Arduino. It draws 10 mA at 3 V, which is a lot if one targets runtimes of several years! So if you aim at maximum battery lifetime, only send short pulses in long intervals (e.g., one 100 ms pulse every 30 s amounts to about 33 uA average current), or even better: rely on TLM frames (management is their job anyway).

Of course, the Faros board can be run from batteries. The nRF8001 can run down to 1.9 V; the ATmega down to 1.8 V at frequencies <= 4 MHz. The maximum voltage for the nRF8001 is 3.6 V. Thus, one good option is to use two AA- or two AAA-size alkaline batteries. They are cheap. They provide > 1800 mAh, which should suffice for several years of runtime. Two batteries are discharged at about 2.0 V (then the voltage drops rapidly), which fits nicely our desired voltage range of 1.9 – 3.0 V. And at runtimes of several years, no re-charging is required (you rather replace the device than changing the batteries). Of course, you can also try out other options like coin cells (e.g., one CR 2450 @ 3.0 V, 560 mAh), or one battery (1.5 V) plus a step-up converter (which wastes maybe more than 20 % energy for conversion and is probably more expensive than a second AA or AAA battery).

Finally, here are some screenshots from Google’s Eddystone Validator and Nordic’s nRF Master Control Panel showing the content of the Eddystone frames broadcasted by a Faros beacon.

Eddystone data sent by Faros beacon

Eddystone data sent by Faros beacon

UID Eddystone frame sent by Faros beacon

UID Eddystone frame sent by Faros beacon

URL Eddystone frame sent by Faros beacon

URL Eddystone frame sent by Faros beacon

TLM Eddystone frame sent by Faros beacon

TLM Eddystone frame sent by Faros beacon

All further technical details can be found in the Faros GIT repository at GitHub.

Have fun building your own Eddystone beacon with Faros!


What is Panodroid?

Since I enjoy taking panorama photos and wanted to watch them on my Android phone, I developed Panodroid: an interactive panorama image viewer for Google’s Android platform targeted at smart phones and tablets. It displays equirectangular panorama images (360 deg x 180 deg spherical panoramas) hosted at Flickr, local images stored on the device, or from any user-defined URL. The user can rotate the view by 360 degrees horizontally and 180 degrees vertically. Panodroid supports kinetic rotation and tag-based image queries. It can also act as generic panorama image viewer for other third-party apps (see developer information below).

If you want to get an impression of Panodroid, I recommend to watch this short video:


After a while I realized that I do not have enough time to add further features to Panodroid. Therefore, I decided to make Panodroid open source. This open version is called OpenPanodroid. I hope the community will give OpenPanodroid a hand, and add some more features or bug fixes — if there are any ;) I also hope that the source code is helpful for other projects that require a fast high-quality panorama image viewer, or just to learn how OpenPanodroid converts and renders panoramas (e.g., using OpenGL and native code). I am looking forward to any feedback how you modified or used Panodroid!

The full source code can be downloaded from github:

git clone git://

Getting Panodroid

You can download Panodroid from Google Play using one of the following links, or simply by scanning the QR code below:

panodroid QR code

Supported Image Formats

To display your panorama image with Panodroid, it must fulfill some properties. It must be a full-spherical panorama covering 360 degrees horizontally and 180 degrees vertically. It must be stored as single JPG or PNG image using the equirectangular projection. Such images have an image resolution where the image width is two times the image height. This is a common format for panorama images and should be supported by most applications for creating panorama images.

Developer Information

Panodroid can be used by other applications to display panorama images. To call the panorama viewer activity, you have to supply an URI pointing at the panorama image (remote file URL (http://), local file path (file://), content URI (content://)). The following code example shows how to invoke Panodroid:

Uri panoUri = Uri.parse("");

ComponentName panoViewerComponent = 
    new ComponentName("de.frank_durr.panodroid", 

Intent intent = new Intent(Intent.ACTION_VIEW);


Frequently Asked Questions

  • Question: Why are some panoramas only displayed in poor quality?
    • Answer: On the one hand, display quality depends on the resolution of the input panorama image. In general, images with a resolution of 3000 pixel x 1500 pixel and higher will give good quality on devices with a screen resolution of 800 pixel x 480 pixel (WVGA smart phones). About 6000 pixel x 3000 pixel will give optimal quality for WVGA screens. If you display images from Flickrs, please note that many Flickr users do not have a pro account and therefore can only offer images of 1024 pixel x 512 pixel. These images can only be displayed with low quality. You can exclude such low resolution images in the panorama search dialog. Moreover, high resolution images are tagged with a star in the panorama list view. On the other hand, display quality depends on the texture size used for the 3D visualization. The default (1024 pixel x 1024 pixel) should be sufficient for smart phones with WVGA screens. To further increase the display quality, e.g., on tablets with larger screens, you can select a texture size of 2048 pixel x 2048 pixel in the preferences menu. However, this requires more memory and leads to longer image conversion times.
  • Question: What does the star in the panorama list view mean?
    • Answer: The star marks high resolution images that can be displayed with higher quality.
  • Question: Why is image conversion slow on my device?
    • Answer: Images are stored at Flickr as equirectangular images. This format cannot be display directly as 3D image and, therefore, has to be converted into another format (cubic panorama). This step is complex for mobile devices with (compared to desktop and server CPUs) slow CPUs. We have optimized this step as much as possible using a native implementation for the conversion routine which reduces the conversion time from several minutes to about 30 seconds on a current mobile phone. Unfortunately, users of older devices might experience longer delays.
  • Question: Why does Panodroid require a network connection?
    • Answer: Because it has to download panorama images from Flickr.
  • Question: Why does Panodroid require a lot of memory (RAM)?
    • Answer: Panodroid was carefully designed, to keep memory usage to a minimum. However, as described above, Panodroid has to convert panorama images from the equirectangular format to cubic format in order to display it as 3D image. In this step, Panodroid has to store the original (downloaded) image in memory. Depending on the size of the original image, this can take a lot of RAM. To give you an impression of the required memory. An image of resolution 3000 pixel x 1500 pixel requires 18 MByte. An image of size 6000 pixel x 3000 pixel requires 72 MByte. For a current PC with gigabytes of memory, this does not sound too much. However, note that your mobile phone might only have about 500 MByte RAM or less, and other applications and the operating system also need some memory.
  • Question: Why can’t I load large panorama images?
    • Android restricts the amount of RAM for each app. For instance, for second generation Android devices (~ Android v2.x), the limit is often 24 MB. A panorama image of size 3000 pixel x 1500 pixel consumes about 18 MB. Therefore, with a limit of 24 MB you could not load much larger images than this. Fortunately, there are possibilities to increase the amount of memory available for images. For instance, we were able to load images of size 6000 pixel x 3000 pixel (~ 72 MB) on smart phones running Android 2.x. However, some Android 3.x devices seem to be more restrictive. Some suppport per app memory sizes up to 256 MB, some only allow for 48 MB. Since this is a restriction imposed by Android, we cannot get around this. (We won’t downsample images since this degrades quality too much.)
  • Question: I have stored a panorama image at Flickr. How can it be displayed with Panodroid? It seems that currently it is not found by Panodroid.
    • Answer: In order to be considered by Panodroid, your images must fulfill a few properties. It must be an equirectangular panorama image covering the full sphere, i.e., 360 degrees horizontally and 180 degrees vertically. Such images have an image resolution where the image width is two times the image height. If your image does not fulfill this requirement, it will be ignored. Moreover, you must tag your image with the tag “equirectangular”.
  • Question: How can I create panorame images with Panodroid?
    • Answer: You can’t. Panodroid is a panorama image viewer, not a creator.

Legal Notice

Panodroid is a free non-commercial application.

Panodroid uses the Flickr API but is not endorsed or certified by Flickr. The API is used according to Flickr’s terms of use. In particular, every photo is displayed together with the name of the author and the required link to the original photo page at Flickr. However, if you as an author of photos stored at Flickr want your photos to be excluded from Panodroid, you can opt-out from being considered by requests through the Flickr API. Please read the official discussion at Flickr for more details on this issue.