Here is what you will find on this page :
Enjoy !
In a word, Activelook is a piece of hardware technology, the ‘optical module’ integrable in cool-looking eyewear. It also is an open protocol, aimed at addressing remote notification displays. It together delivers key information right in the field of vision of the user.
Can you think of an activity that requires real time and “mission critical” information ? Gives not much space for the user to check a smartphone screen while in action ? A need to push some key information without impacting a movement or activity ? Give visual feedback on a physical activity?
Then you are in the right place.
And.. one more thing :
All Activelook glasses share the same open API interface: your application will be able to connect and display its content on all Activelook certified devices (sport glasses, safety glasses, sports helmets, head-up display modules, goggles, …)
Check here the list of glasses featuring ActiveLook technology.
Walk through the below onboarding guide and get the whole idea about ActiveLook.
ActiveLook is minimal. That is the target, that is the challenge.
Minimal in terms of footprint, size, power consumption. This means:
ActiveLook optical module is everything but smart: *you* will be smart.
It is not a video screen, it is a notification display.
An image displayed in ActiveLook is a combination of :
It is not a display with a refresh rate (like regular video displays), it is a ‘memory’ display: you can update any pixel or fraction of the display as you would write a byte or page in a memory. What is not modified or erased remains displayed. It therefore is energy efficient for displaying content with little variation.
Addressing an ActiveLook device is done in 2 phases :
Phase 1- Setup: Pre-load your graphical resources on the glasses flash memory (icons, fonts etc.). This is done once for all, the first time your application connects to a given pair of ActiveLook glasses.
Phase 2- Play ! : Send display commands to the glasses to combine text and precharged icons. Note that you are not sending full images ‘live’ to the display, only graphical commands over bluetooth, such as :
You therefore have to be smart in:
We also have ‘layout’ and ‘pages’ commands for you in order to club your updates into minimal commands.
Next thing for you: have a look at the ActiveLook Application certification plan: this program will grant the license to advertise your ActiveLook compatibility and guarantees your app will fit the ecosystem, and get promoted !
If you get this all, you get most of the idea.
First thing first: make sure you register as a developer on ActiveLook website, developper section.
ActiveLook is young and our firmware will further evolve in the months to come.
Registering will allow you to access the upcoming glass firmwares a few months before they are deployed in the field. That is a must have to ensure you can update and test your application prior to new FW deployment and align the release of your new application with the one of the latest firmware.
Information on new FW availability as well as access rights to the ‘developing FW’ repository will be provided to all ActiveLook registered developers.
You are lucky, we have some pre-cooked ressources for you.
Get the Android SDK :
Get the IOs SDK :
Check out the demo application here :
You can operate an ActiveLook pair of glasses from any BTLE enabled master device.
The API documentation is here. It leverages on the BTLE communication protocol. Find here the exhaustive list of services, characteristics and commands to operate an ActiveLook pair of glasses
https://github.com/ActiveLook/Activelook-API-Documentation
While your first app is compiling, take 5min to order your development kit. Despite having a Wysiwyg somewhere in our development roadmap, we will always recommend you check your development by connecting to a real pair of glasses. Readability of your AR content needs to be confirmed with a real background.
The Development kit is a real, fully functional pair of ActiveLook glasses. The exact model & design of glass we will send to you will depend on stock & availability.
You will be able to upload on this development kit the Beta release of each FW in order to develop/test your application a few months before each new FW is released in the field.
Targeting ActiveLook certification is a great way to ensure that your application or services is successful within the ActiveLook ecosystem.
Follow this link and get all information you need on our certification program.
Having your app ActiveLook certified will guarantee to gain in visibility, ensure its robustness and a smooth integration in ActiveLook ecosystem.
Here are the key requirements regarding application and service development, this ensures your application will deliver an exciting experience.
In augmented reality (virtual image projected on top of the user's environment) what is ‘black’ in your image will appear totally transparent. What is brighter will be the most visible. Think of watching the reflection of a television screen into a glass window.
ActiveLook display is monochrome Yellow. Focussing all the light energy on one single color / wavelength allows a far higher light efficiency and brightness than we would have with a color display. That allows also optimizing the whole optical design (filters, coatings etc) to maximize readability and contrast in daylight, still maintaining a radically low power consumption.
The display offers 16 greyscales values (16 yellow scales in fact).
As stated above ActiveLook features a memory display that won’t change if you do not ‘write’ any new content. You need to leverage on this.
As you design it, visualise your interface as a combination of both fixed and ‘changing’ areas.
ActiveLook® features a micro-projector. Its compact form factor and integration implies optical trade-offs. To limit visible flare or parasitic reflections it is recommended to:
ActiveLook has been designed as a minimal (or, say, ‘optimal’) system in order to be light, non-intrusive and long lasting. It uses a low throughput BTLE link and small battery (90mAh for 12 to 15hours autonomy)
Both technical constraints make it not the right candidate for displaying video. Loading a single image over BTLE would take several seconds so your video will not be super fluid.
Addressing an ActiveLook device implies *preloading* your graphical icons and images on the memory glasses. That is done once for all the first time your app connects to a new pair of glasses. Then you will send commands to display the icon you like. Doing this, you may manage to build some stylish ‘animated gif’ but consider this as a maximum.
ActiveLook gives 12 to 15h autonomy in continuous display mode.
If you want your application to reach this kind of performance, consider reducing the frequency of graphical updates and leave the system sleep in between your refreshes.
Targeting ~1 update per second, and using pages & layout commands to group your updates will ensure maximization of battery life time.
Also, note that the gesture sensor is consuming half the device power. Disabling the gesture sensor
The bluetooth link is a tiny link. In order to keep the graphical latency low and smoothen the display updates, ensure you maximize your use of ‘layout’ commands and ‘pages’, rather than sending individual commands for placement of each graphical item (image, text etc.)
Always club your display update commands between a 'Hold' and a 'Flush' command. In doing so, there will be one single copy of the display buffer to the physical display, once all your updates are executed. Hence saving power consumption, maximizing refresh rae and limiting 'blinking effect'.
ActiveLook® is a memory display: previous content will remain displayed unless you explicitly overlay new opaque content.
To clear content, you can:
In order to accommodate the different personal face features to the optical eye box, it is recommended not to use the whole display area and keep "margins" on all sides.
As done by the ActiveLook application, consider creating a "reserved" area of 30 pixels on either horizontal side and 25 pixels on either vertical sides. This makes an effective useful area of 244 x 206 pixels (See "Adjust screen offset" in the "settings" section and image below)
The shift command (see above) is useful to manage the visual margins.
To simplify the use of graphical elements, it is possible to save a list of graphical commands as “layouts”. These layouts are identified by a simple number and allow displaying a value (passed as function's argument) as text or another graphical element (image, circle…).
Pages are defined as a set of layouts to be displayed together on the screen. Usually, a layout is used to display a certain type of information, for instance, the speed or the time. Depending on the application and on user settings different layouts can be displayed with a page.
ActiveLook aims at being one unified ecosystem of cross-compatible applications (sources) and devices (displays).
This is ensured by deploying on all ActiveLook compatible devices (glasses) one unified firmware that ensures a consistent behavior whatever the device brand. ActiveLook firmware will continuously evolve and improve. New firmwares are deployed in the field from 1 to ~4 times per year (see next section for firmware check/update process description).
In order to remain available to the community, your ActiveLook application needs to be maintained aligned to the latest firmware functionality as they deploy.
It is required to set up a mechanism checking that your application is compatible with the latest FW deployed in the field (using first 2 digits of FW version number). and prompt your user of the need to upgrade their application if a mismatch is detected.
Ideally, your application can then leverage on latest and new functionalities, and, at minimum, it will ensure your application remains functional in case of FW behavior discontinuity.
Most firmware upgrades will be neutral for API but some upgrades may deprecate or modify some pre-existing functions or behavior. This will induce release of a “major” version. Obviously, we will try to minimise the occurrence of these major releases (you may budget a maximum frequency of once per year).
Such major releases will be announced 6 months before deployment. Corresponding new FW and SDK will be made available as ‘development’ versions 3 months before firmware field deployment.
Corresponding communication will be circulated to the developer mailing list and will allow all developers to plan for an application adjustment ahead of new FW deployment.
Exact FW deployment date will be circulated upfront so that you can synchronize your new application deployment.
Ensuring that all glasses run the same firmware, is a shared responsibility of all ActiveLook applications. That ensures that the ecosystem will not ‘fragment’, with users facing bugs with app & firmware misaligned versions.
As of now, the glass firmware upgrade itself is solely performed by ‘ActiveLook sports application’, the native ActiveLook companion application developed by Microoled.
ActiveLook applications are requested to systematically check the firmware version when pairing to any glasses. If an old FW is detected, the application should prompt the user for a FW upgrade.
Here is general process:
As described above, on a first connection to a given pair of glasses, an application needs to pre-load the graphical ressources it will later require in order to operate.
This set of bitmaps and layouts loading commands is here called the initial ‘configuration’ for your application.
A given pair of glasses can then host configurations (set of graphical ressources) coming from several applications.
That implies some simple yet clean process to manage resources and memory on board.
From FW rel.4.0 onwards (avail. June 2021) the flash memory is organized using a filesystem: each application is allocated a private configuration directory in which all its resources will be stored.
At first connection to a given pair of glasses, and after the FW version checking (as described in previous section), your application will:
Detailed processes and commands are described in SDK & API documentations.
Note that the default ‘system’ configuration (used by ActiveLook sports application) is ~40kB. The embedded flash offers ~3MB free space. So configuration cleaning is not expected to happen very frequently.
We missed something here ? Anything unclear. Please let us know by filling the contact form (click here).
