AraMDK_0.2

Project Ara

Module Developers Kit (MDK)

Release 0.2 (alpha)

January 8, 2015

Copyright 2015 Google Inc. All rights reserved. Your use of this Ara Module Developers Kit (MDK) is expressly

subject to the terms of the MDK License Agreement found at http://projectara.com/mdk-license.txt.

MDK Release 0.2 (alpha) January 8, 2015 Page 1 of 107

Welcome. What now?

Project Ara is a platform for creating modular smartphones. Users will be able to start with an

Endoskeleton, the structural frame and network backbone of the device, and populate it with

modules, the building blocks that make up the vast majority of the phones functionality and

features. Since modules are interchangeable, a user has the freedom to design exactly the

phone they want and continue to customize the phone over time by replacing modules. Aras

success is predicated on a rich, vibrant, and diverse ecosystem of modules from a myriad of

developers. Users would be able to select modules from an online marketplace using a

con;gurator that facilitates user choice and curates the con;guration process to ensure that

the selection of modules provides the expected system-level functionality.

This document, which serves as the narrative and core of the Module Developers Kit (MDK),

discusses how to develop modules compatible with the Ara platform. Note that while this

document extensively describes the Endoskeleton, or Endo, it does so exclusively for the

bene;t of module developers to ensure compatibility between modules and the Endo. The Ara

platform does not presently support third-party Endo developers.

Chapter 1 provides a brief description of the licensing landscape that governs the Ara

ecosystem. Chapter 2 talks about the industrial design of the Ara platform including the

physical layout of the frame, the Endoskeleton or Endo, and how modules ;t within it.

Chapter 3 talks about the mechanical and electrical assemblies and interfaces of Ara modules.

Chapter 3 also provides reference design templates for each type of module. Chapters 4 and 5

talk about power and networking between the Endo and modules. Chapter 6 discusses the Ara

software platform and how it interacts with various types of hardware devices. Chapter 7 talks

about system-level functions, which require interactions between modules and the Endo.

Chapter 8 discusses compliance criteria to ensure module compatibility with the MDK, such as

environmental speci;cations, thermal loads, electromagnetic compatibility, and corresponding

test protocols. Chapter 9 describe what is provisionally known as the Ara Module Marketplace,

and the process for submitting and selling modules through the Ara Module Marketplace.

Finally, Chapter 10 provides some guidelines for regulatory compliance and carrier certi;cation.

This document provides speci;cation requirements needed to ensure compatibility with the Ara

platform. Heading titles throughout the document mark sections that contain speci;cation

language.

This document also provides reference implementation material to demonstrate exemplars that

comply with the Ara speci;cations. Reference implementation material is in blue text




throughout the document. Heading titles also mark sections that contain reference

implementation material.

Known vendors are provided for various components which are deemed scarce. These

sections are highlighted in purple. Google in no way endorses these vendors.

All MDK releases prior to release 1.0 are considered prototype releases. These are validated

using prototype hardware and software implementations that frequently fall short of the

objective speci;cation. Consequently, some elements of the prototype speci;cations and

reference implementations will diGer from the objective system. Blue boxes like this one

denote distinctions between the current prototype platform and the objective one throughout

the document.




Contributors

The following individuals made signi;cant contributions to the development of the MDK.

Google Elwin Ong (principal author), Paul Eremenko, David Fishman, Jason Chua,

Mark Rich, Greg Kielian, Adam Holman, Roshni Srinivasan, Anil

Rachakonda, Srinivas Nori

NK Labs Seth Newburg, Ara Knaian, Marisa Bober, Dave McCoy, Charles Mycroft

Hannum, Boyan Kurtovich, Shahriar Khushrushahi, Nan-Wei Gong, Chris

Wardman, Nate MacFadden

LeafLabs Marti Bolivar, Perry Hung, Andrew Meyer

New Deal Design Dan Clifton, Gadi Amit, Inbal Etgar, Susan McKinney

Metamorph Software Sandeep Neema, Ted Bapty

X5 Systems Derek Linden

Toshiba Yukio Watanabe, Toshihide Fujiyoshi, Takuma Aoyama, Kaoru Kamata,

Takeshi Oto, Yasuo Ohara, Eugene Chang, Joachim Hausmann

Mixel Ashraf Takla

Quanta Dexter Yeh, Venney Lin, Hans Chang, Barry Tsao, Suya Hou, Rigii Ni,

Sam Kuo, Alens Lin, Sunny Tsai

Opersys Karim Yaghmour

Linux Solutions Greg Kroah-Hartman

Linaro George Grey, Rob Herring, John Stultz, Khasim Mohammed, Vishal Bhoj,

Alex Elder, Glen Valante, Matt Porter, Satish Patel, Viresh Kumar, Bin Chen

BayLibre Fabien Parent, Alexandre Bailon, Benoit Cousson

NewOldBits Jean Pihet

Oxford Systems Olin Sibert

Foxconn Interconnect

Technology (FIT)

Jason Chou, Shan-Ting Hsu, Sutchaya Lertburapa, Pitt Lin, Mickey Ge

IDT Systems Peter Woodd, Kevin Baumber, Sangsoo Yim




SupportThe Project Ara team cannot, as a general matter, provide individualized support to module

developers. If you have a comment on the MDK, have found a bug, or would like to provide

feedback, you can reach the Project Ara team at [email protected].

Developer documentation will be maintained at http://projectara.com/mdk, including a set of

Frequently Asked Questions (FAQs) which will be updated periodically.

Developers are also encouraged to join the Ara Module Developers Google Group at

http://groups.google.com/forum/#!forum/ara-module-developers, which serves as a forum and

mailing list. If your question is not addressed in the latest documentation or FAQ, it may well

have been answered in the Google Group. If not, ask away!

Limited quantities of prototype hardware, including dev boards are available by submitting a

request at http://www.projectara.com/dev-boards/.




Revision HistoryRelease 0.10 (alpha) - April 9, 2014 - Initial public release

Release 0.11 (alpha) - May 28, 2014

Fixed typos in document and reference materials.

Updated power speci;cations; added ;gures to illustrate multiple battery con;gurations

and battery charging events.

Fixed prototype ambient temperature and humidity speci;cations.

Added Prototype Endo Medium Frame CAD ;les to reference materials.

Added Prototype 1x2 and 2x2 Module Shell CAD ;les to reference materials.

Added Prototype EPM build instructions to reference materials.

Added contactless media converter prototype reference implementation.

Separated known vendor sections from reference implementations.

Release 0.2 (alpha) - January 8, 2015

Updated all prototype implementations sections to reQect Spiral 2 design.

Consolidated CMF speci;cations and reference implementation to Section 2.

Updated Layer 1 contactless media converter (CMC) from capacitive to inductive and

included draft CMC speci;cation as a separate document in reference materials.

Updated FPGA UniPro implementation with Toshiba HS and GP Bridge ASICs.

Updated Layer 5+ network, introduced Greybus Application Protocol, and included

Greybus speci;cation in a separate document in the reference materials.

Updated objective software architecture and Spiral 2 prototype reference

implementation.

Updated environmental section to include all MDK compliance speci;cations.

Added initial description of Ara Module Marketplace requirements.




Table of Contents1. Licensing

1.1. The Ara MDK License

1.2. External Licenses

1.2.1. MIPI

1.2.2. Android

1.2.3. Linux

1.2.4. Other IP

1.2.5. Prototype Platform External Licenses

1.2.5.1. I2C

1.2.5.2. I2S

1.2.5.3. SDIO

1.2.5.4. High-Speed Inter-Chip USB

1.2.5.5. DSI, CSI-2

2. Industrial Design

2.1. De;nitions

2.2. Parceling Schemes

2.2.1. Rear Parceling Scheme

2.2.2. Front Parceling Scheme

2.3. Design Language

2.3.1. Geometric Design Language - Speci;cation

2.3.2. Geometric Design Language - Reference Implementation

2.3.3. Color Material Finish - Speci;cation

2.3.4. Color Material Finish - Prototype Reference Implementation

3. Mechanical and Layout

3.1. Module Geometry and Assemblies

3.1.1. Rear Module Sub-Assemblies

3.1.1.1. Rear Module Sub-Assemblies - Speci;cation

3.1.1.2. Rear Module Sub-assemblies - Prototype Reference

Implementation

3.1.1.2.1. Rear Module Templates - Prototype Reference Implementation

3.1.1.2.2. 1x2 Camera Module - Prototype Reference Implementation

3.1.1.2.3. 1x2 Speaker Module - Prototype Reference Implementation

3.1.1.2.4. 2x2 Marvell AP Module - Prototype Reference Implementation

3.1.1.2.5. 2x2 NVidia AP Module - Prototype Reference Implementation

3.1.1.3. Hiperco-50 - Known Vendors

3.1.2. Front Module Sub-assemblies

3.1.2.1. Front Module Sub-assemblies - Speci;cation




3.1.2.2. Front Module Sub-assemblies - Prototype Reference

Implementation

3.1.2.2.1. Receiver Module - Prototype Reference Implementation

3.1.2.2.2. Display Module - Prototype Reference Implementation

3.1.3. Module Label

3.1.3.1. Module Label - Speci;cation

3.1.3.2. Module Label - Prototype Reference Implementation

3.1.4. Envelope Violation Limitations

3.1.4.1. Envelope Violation - Speci;cation

3.1.4.2. Envelope Violation - Reference Implementation

3.1.4.3. Envelope Violation - Prototype Reference Implementation

3.1.4.4. 1x2 Pollution Sensor Module - Prototype Reference

Implementation

3.2. Connectors

3.2.1. Interface Block

3.2.1.1. Interface Block - Speci;cation

3.2.1.2. Interface Block - Prototype Reference Implementation

3.2.1.3. Front Module Attachment - Speci;cation

3.2.1.4. Front Module Attachment - Prototype Reference Implementation

3.3. Antennas

3.3.1. Antenna in Module - Speci;cation

3.3.2. 1x2 WiFi/BT Module with Antenna - Prototype Reference Implementation

3.3.3. Antenna Interface - Speci;cation

3.3.4. Antenna Interface - Prototype Reference Implementation

3.3.4.1. 1x2 3G Cellular Module - Prototype Reference Implementation

3.3.4.2. 1x1 Antenna Module - Prototype Reference Implementation

4. Power

4.1. Power Consumer Module - Speci;cation

4.2. Power Consumer Module - Prototype Reference Implementation

4.3. Charger Module - Speci;cation

4.4. USB Charger Module - Prototype Reference Implementation

4.5. Power Storage Module - Speci;cation

4.6. Battery Modules - Prototype Reference Implementation

5. Network Stack

5.1. Module Communication Physical View

5.2. Network Stack

5.2.1. Layer 1

5.2.1.1. Layer 1 Contactless Media Converter - Speci;cation

5.2.1.2. Layer 1 Contactless Media Converter - Reference Implementation

5.2.1.3. Layer 1 Contactless Media Converter - Prototype Reference

Implementation




5.2.1.4. Layer 1 MIPI M-PHY - Speci;cation

5.2.1.5. Layer 1 MIPI M-PHY - Reference Implementation

5.2.1.6. Layer 1 MIPI M-PHY - Known Vendor(s)

5.2.1.7. Layer 1 M-PHY - Prototype Reference Implementation

5.2.1.8. Layer 1 D-PHY - Prototype Speci;cation

5.2.1.9. Layer 1 D-PHY - Prototype Reference Implementation

5.2.2. Layers 1.5-4

5.2.2.1. Layers 1.5-4 MIPI UniPro - Speci;cation

5.2.2.2. Layers 1.5-4 UniPro - Reference Implementation

5.2.2.3. Layers 1.5-4 UniPro - Known Vendor(s)

5.2.2.4. Layers 1.5-4 CSI-2 - Prototype Speci;cation

5.2.2.5. Layers 1.5-4 CSI-2 - Prototype Reference Implementation

5.2.2.6. Layers 1.5-4 DSI - Prototype Speci;cation

5.2.2.7. Layers 1.5-4 DSI - Prototype Reference Implementation

5.2.2.8. Layers 1.5-4 Bridged Interfaces

5.2.2.8.1. HSIC Bridge - Prototype Speci;cation

5.2.2.8.2. HSIC Bridge - Prototype Reference Implementation

5.2.2.8.3. I2C Bridge - Prototype Speci;cation

5.2.2.8.4. I2C Bridge - Prototype Reference Implementation

5.2.2.8.5. I2S Bridge - Prototype Speci;cation

5.2.2.8.6. I2S Bridge - Prototype Reference Implementation

5.2.2.8.7. SDIO Bridge - Prototype Speci;cation

5.2.2.8.8. SDIO Bridge - Prototype Reference Implementation

5.2.2.8.9. GPIO Bridge - Prototype Speci;cation

5.2.2.8.10. GPIO Bridge - Prototype Reference Implementation

5.2.2.8.11. UART Bridge - Prototype Speci;cation

5.2.2.8.12. UART Bridge - Prototype Reference Implementation

5.2.2.8.13. PWM Bridge - Prototype Speci;cation

5.2.2.8.14. PWM Bridge - Prototype Reference Implementation

5.2.3. Layers 5+

5.2.3.1. Layers 5+ - Greybus Speci;cation

5.2.3.2. Layers 5+ - Greybus Prototype Reference Implementation

5.2.4. Network Stack Hardware - Known Vendor(s)

5.2.5. Network Stack Prototype Hardware - Known Vendor(s)

6. Software Stack

6.1. Kernel

6.1.1. Kernel - Speci;cation

6.1.2. Kernel - Reference Implementation

6.1.3. Kernel - Prototype Reference Implementation

6.2. Android

6.2.1. Android HALs - Prototype Reference Implementation




6.2.2. Android Application - Speci;cation

6.2.3. Android Application - Reference Implementation

6.2.4. Android Application - Prototype Reference Implementation

6.3. Prototype Development Use cases

6.3.1. CSI-2/DSI Devices

6.3.2. I2C, UART, GPIO, PWM Devices

6.3.3. USB, SDIO, I2S Devices

7. System-Level Functions

7.1. Module Wake/Detect

7.1.1. Module Wake/Detect Electrical - Speci;cation

7.1.2. Module Wake/Detect Electrical - Prototype Reference Implementation

7.2. Module Initialization/Hotplug Event

7.2.1. Module Information - Speci;cation

7.2.2. Module Information - Prototype Reference Implementation

7.3. Active Thermal Management

7.4. Power Management

8. Module Compliance

8.1. Environmental Compliance

8.1.1. Thermal Loads

8.1.1.1. Thermal Loads - Speci;cation

8.1.1.2. Thermal Loads - Prototype Speci;cation

8.1.1.3. Thermal Loads - Prototype Reference Implementation

8.1.2. Ambient Temperature and Humidity

8.1.2.1. Ambient Temperature and Humidity - Speci;cation

8.1.2.2. Ambient Temperature and Humidity - Prototype Reference

Implementation

8.1.3. Electrostatic Discharge (ESD)

8.1.3.1. ESD - Speci;cation

8.1.3.2. ESD - Prototype Reference Implementation

8.1.4. Shock

8.1.4.1. Shock - Speci;cation

8.1.4.2. Shock - Prototype Reference Implementation

8.1.5. Vibration

8.1.5.1. Vibration - Speci;cation

8.1.5.2. Vibration - Prototype Reference Implementation

8.2. Mechanical Compliance

8.2.1. Mechanical Fit

8.2.1.1. Mechanical Fit - Speci;cations

8.2.1.2. Mechanical Fit - Prototype Reference Implementation

8.2.2. EPM Hold

8.2.2.1. EPM Hold - Speci;cations




8.2.2.2. EPM Hold - Prototype Speci;cations

8.2.2.3. EPM Hold - Prototype Reference Implementation

8.3. Power Compliance

8.3.1. Voltage Sweep

8.3.1.1. Voltage Sweep - Speci;cations

8.3.1.2. Power Sweep - Prototype Reference Implementation

8.3.2. Power Input/Output Noise

8.3.2.1. Power Input/Output Noise - Speci;cations

8.3.2.2. Power Input/Output Noise - Prototype Reference Implementation

8.3.3. Power Draw and Discharge

8.3.3.1. Power Draw and Discharge - Speci;cations

8.3.3.2. Power Draw - Prototype Reference Implementation

8.3.4. Power Storage Capacity

8.3.4.1. Power Capacity - Speci;cations

8.3.4.2. Power Storage Capacity - Prototype Reference Implementation

8.4. Network Compliance

8.4.1. M-PHY Compliance

8.4.1.1. M-PHY Compliance - Speci;cations

8.4.1.2. M-PHY Compliance - Prototype Reference Implementation

8.4.2. UniPro Compliance

8.4.2.1. UniPro Compliance - Speci;cations

8.4.2.2. UniPro Compliance - Prototype Reference Implementation

8.4.3. Layer 5+ Greybus Compliance

8.4.3.1. Layer 5+ Greybus Compliance - Speci;cations

8.4.3.2. Layer 5+ Greybus Compliance - Prototype Reference

Implementation

8.5. Software Compliance

8.5.1. Kernel Compliance

8.5.1.1. Kernel Compliance - Speci;cations

8.5.1.2. Kernel Compliance - Prototype Reference Implementation

8.5.2. Android Compliance

8.5.2.1. Android Compliance - Speci;cations

8.5.2.2. Android Compliance - Prototype Reference Implementation

8.6. System-Level Functions Compliance

8.6.1. Wake/Detect Compliance

8.6.1.1. Wake/Detect Compliance - Speci;cations

8.6.1.2. Wake/Detect Compliance - Prototype Reference Implementation

8.6.2. Hotplug Compliance

8.6.2.1. Hotplug Compliance - Speci;cations

8.6.2.2. Hotplug Compliance - Prototype Reference Implementation

9. Ara Module Marketplace




9.1. Ara Developer Console

9.1.1. Signup and Module Submission

9.1.2. Module Merchandising Data

9.1.3. Sales Metrics and Performance Tracking

9.1.4. Payments Disbursement

9.2. Logistics and Distribution

9.3. Module Identi;ers

10. Regulatory Compliance and Carrier Certi;cation

10.1. US Regulatory Compliance and Carrier Certi;cation

10.1.1. US RF Regulatory Authorization

10.1.1.1. FCC Equipment Authorization - Speci;cation

10.1.1.2. FCC Equipment Authorization - Reference Implementation

10.1.1.2.1. FCC Equipment Authorization - Reference Implementation for

Hobbyist/Maker

10.1.1.2.2. FCC Equipment Authorization - Prototype/Experimental License

10.1.2. US Medical Device Regulation

10.1.2.1. FDA Regulation - Speci;cation

10.1.2.2. Pulse Oximeter Module - FDA Regulation - Reference

Implementation

10.1.2.3. FDA Regulation - Prototype Reference Implementation

10.1.3. Carrier Terminal Acceptance

10.2. International Certi;cation




List of FiguresFigure 2.1 - Ara Phone Built Based on Medium Endo

Figure 2.2 - Ara Endo (Medium Variant)

Figure 2.3 - Ara Rear Parceling Scheme for Jumbo, Medium, and Mini Con;gurations

Figure 2.4 - Valid Medium Endo Con;gurations (Rear)

Figure 2.5 - Rear Module s

Figure 2.6 - Valid Endo Con;gurations (Front)

Figure 3.1 - Rear Module Sub-assemblies

Figure 3.2 - Prototype Module Base

Figure 3.3 - Prototype 1x2 PCB

Figure 3.4 - Prototype Shield and Clips

Figure 3.5 - Module Label Speci;cations

Figure 3.6 - Pulse Oximeter Module with Y-Dimension Exceedance

Figure 3.7 - Modules with Z-Dimension Exceedances

Figure 3.8 - Custom Module Shell for Prototype Camera Module

Figure 3.9 - Interface Block with Inductive Pads

Figure 3.10 - Prototype Interface Block Pinout

Figure 3.11 - Closeup View of Front-Module Attachment Assembly

Figure 3.12 - Example of Antenna Pattern on Module Shell

Figure 3.13 - RF Bus in Endo Enables Routing Between Modules on Top and Bottom Halves

Figure 4.1 - Power Architecture

Figure 4.2 - Power Bus Voltage With Multiple Battery Modules

Figure 4.3 - Battery Charging

Figure 5.1 - Module to Module Communication (with Native UniPro and Bridge ASICs)

Figure 5.2 - Prototype Module to Module Communication

Figure 5.3 - Inductive Communication Between PCBs

Figure 5.4 - Contactless Media Converter

Figure 5.5 - Interface Block Unique IDs

Figure 5.6 - Network Stack over Software and Hardware

Figure 5.7 - Prototype Network Stack over Software and Hardware

Figure 6.1 - Software Stack

Figure 6.2 - Prototype Software Stack

Figure 6.3 - Kernel Subsystem Interfaces

Figure 6.4 - Prototype Greybus Subsystem Reference Implementation

Figure 6.5 - Ara Android Stack

Figure 7.1 - Prototype Reference Implementation of Wake/Detect Circuit

Figure 7.2 - Module Initialization Process Sequence Diagram




List of TablesTable 2.1 - Ara De;nitions

Table 2.2 - Design Language Geometric Guidelines

Table 2.3 - Design Language CMF Speci;cations

Table 3.1 - Rear Module Maximum PCB Dimensions

Table 3.2 - Prototype Rear Module Z Dimension Stackup

Table 3.3 - Prototype Rear Module Template s

Table 3.4 - 1x2 Prototype Camera Module Reference Implementation

Table 3.5 - 1x2 Prototype Speaker Module Reference Implementation

Table 3.6 - 2x2 Prototype Marvell AP Module Reference Implementation

Table 3.7 - 2x2 Prototype NVidia AP Module Reference Implementation

Table 3.8 - Hiperco-50 Known Vendors

Table 3.9 - Front Module Outer Dimensions and PCB Dimensions

Table 3.10 - Prototype Front Module Z Dimension Stackup

Table 3.11 - Prototype Receiver Module Reference Implementation

Table 3.12 - Prototype Display Module Reference Implementation

Table 3.13 - Envelope Violation Limits

Table 3.14 - Prototype Pollution Sensor Module Reference Implementation

Table 3.15 - Prototype Interface Block Pinout Descriptions

Table 3.16 - 1x2 Prototype WiFi/BT Module Reference Implementation

Table 3.17 - 1x2 Prototype 3G Cellular Module Reference Implementation

Table 3.18 - 1x1 Prototype Antenna Module Reference Implementation

Table 4.1 - 1x2 Prototype USB Charger Module Reference Implementation

Table 4.2 - 2x2 Prototype Battery Module Reference Implementations

Table 5.1 - Ara Network Stack

Table 5.2 - Prototype Ara Network Stack

Table 5.3 - MIPI M-PHY Known Vendors

Table 5.4 - MIPI UniPro Known Vendors

Table 5.5 - Toshiba UniPro Bridge ASIC Speci;cations

Table 9.1 - Tech Data Package Items (TBD)

Table 9.2 - Module Support Package Items (TBD)

Table 9.3 - Module Merchandising Data

Table 9.4 - Module Identi;cation Numbers




AcronymsThese are some of the acronyms that frequently occur in this document.

ABI Application Binary Interface

AP Application Processor

API Application Programming Interface

ASIC Application Speci;c Integrated Circuit

BOM Bill of Materials

CAD Computer-Aided Design

CMC Contactless Media Converter

CMF Color, Material, Finish

CSI Camera Serial Interface

DSI Display Serial Interface

EDA Electronic Design Automation

EPM Electro-Permanent Magnets

FPGA Field Programmable Gate Array

GP Bridge General Purpose Bridge ASIC

GPIO General Purpose Input Output

GPS Global Positioning System

HAL Hardware Abstraction Libraries

HS Bridge High-Speed Bridge ASIC

HSIC High-Speed Inter Chip (USB)

I2C Inter Integrated Circuit

I2S Integrated Interchip Sound

IMS Internal Master Secret

IP Intellectual Property (generally not Internet Protocol)




LTE Long-Term Evolution

LVDS Low-Voltage DiGerential Signaling

MDK Module Developers Kit

MIPI Refers to mobile industry standards alliance

M-PHY MIPI Physical Layer Speci;cation

MSP Module Support Package

OS Operating System

OSI Open Systems Interconnection

PCB Printed Circuit Board

PWM Pulse Width Modulation

RC Resistor-Capacitor (i.e., RC circuit)

RHC Remote Host Controller

RTOS Real-time Operating System

SDIO Secure Digital Input Output

SLVS Scalable Low-Voltage Signaling

STEP Standard for the Exchange of Product Model data

TDP Tech Data Package

UFS Universal Flash Storage

UniPro MIPI Uni;ed Protocol

USB Universal Serial Bus




1. LicensingThis section discusses certain intellectual property licensing considerations for Ara module

developers. This section is a summary and not a replacement or substitute for the MDK

License Agreement which governs licensing of the MDK. This summary should not be

construed as legal advice.

1.1. The Ara MDK License

The MDK is licensed in accordance with the MDK License Agreement (Jan 7, 2015). The

agreement is meant to provide a permissive license to module developers, while ensuring the

vibrancy and integrity of the Ara developer ecosystem in the long run. One of the more notable

features of the MDK license is that it provides developers, in addition to a development license,

an upfront grant of commercialization rights, conditioned only on developers playing nice

with the rest of the Ara ecosystem. Also noteworthy is that the MDK license does not alter any

of the standard open source software licenses associated with Android or any Ara-speci;c

drivers, apps, etc. that are distributed as part of the MDK. The MDK license does not allow--

nor does the MDK speci;cation facilitate--the development or commercialization of Ara

Endoskeletons by third-party developers.

1.2. External Licenses

Project Ara strives to embrace industry standards where possible. Consequently, the MDK

references numerous external standards and speci;cations. These are available in accordance

with their speci;c license agreements and are neither owned by Google nor part of the MDK.

Below is a brief summary of these external licenses.

1.2.1. MIPIThe MIPI Alliance is an open membership industry consortium that develops interface

speci;cations for mobile devices. Ara modules implement several MIPI speci;cations. At

minimum, modules communicate with the Endo and with other modules using the MIPI M-PHY

and UniPro speci;cations. Depending on the application, some modules may implement

additional MIPI speci;cations such as CSI and DSI. In order to get a hold of the detailed MIPI

speci;cation, you need to join the MIPI Alliance. This gives you a royalty-free license to

implement your own version of the MIPI interfaces. Alternatively, developers may procure from

third-party vendors IP blocks (for use in FPGAs or in creating ASICs) or complete bridge chips

implementing the MIPI standard interfaces.

1.2.2. AndroidThe software stack for the Ara platform is built on the open source Android OS. The majority of

Android software including Android software modi;ed/developed for Ara is provided under the

Apache 2.0 license. Except for the preservation of the copyright notice and disclaimer, this

license allows the user of the software the freedom to use the software for any purpose, to




distribute it, to modify it, and to distribute modi;ed versions of the software, under the terms of

the license, without concern for royalties.

1.2.3. LinuxThe Android OS is built on the Linux kernel. The Linux kernel and its derived works, including

kernel drivers, are distributed under the terms of the GNU General Public License, version 2.

1.2.4. Other IPTo the extent that you utilize intellectual property from other sources, you are responsible for

obtaining approved licenses to implement and market their modules.

1.2.5. Prototype Platform External Licenses

1.2.5.1. I2C

The current prototype platform uses the I2C bus standard implemented as a bridged

protocol between modules and the Application Processor. The I2C bus standard is

copyrighted by NXP Semiconductors, and is provided free of charge on their website.

1.2.5.2. I2S

The current prototype platform uses the I2S bus standard implemented as a bridged protocol

between modules and the Application Processor. The I2S standard is available online here

and here.

1.2.5.3. SDIO

The current prototype platform uses the SDIO bus standard implemented as a bridged

protocol between modules and the Application Processor. The standard is copyrighted by

the SD Card Association and provided free on their website.

1.2.5.4. High-Speed Inter-Chip USB

The current prototype platform uses HSIC USB in several modules. The standard is

copyrighted but provided free of charge on the USB Implementers Forum website.

1.2.5.5. DSI, CSI-2

In the current prototype platform, the DSI and CSI-2 standards are implemented in the

prototype Display Module, Camera Module, and the Application Processor Modules. These

standards are copyrighted by the MIPI Alliance and require an approved license to implement

or provided through a third-party with an approved license.




2. Industrial Design

2.1. De$nitionsThe Ara architecture requires the introduction of several new concepts to the traditional mobile

device lexicon. These terms are de;ned in Table 2.1 below and illustrated in Figures 2.1 and

2.2.

Table 2.1 - Ara De$nitions

Term De$nition

Module Modules are the building blocks of an Ara phone. They are the hardware

analogue to software apps. These are physical components that

implement various phone functions. There are currently two major

classes of modules: Front modules, which make up the front of the

phone and generally provide user interaction or interface the display,

receiver, microphone, etc., and rear modules, which provide the bulk of

the phones back-end (non-user facing) functionality. Front modules

reach across the entire width of a particular Endoskeleton frame, while

rear modules come in three standard sizes (1x1, 1x2, and 2x2) and can

;t into multiple frame sizes. (See Figure 2.3)

Endoskeleton (Endo) The Ara Endoskeleton (or Endo) is the frame and backplane of the

device, determining the size and layout of the phone. Ara modules slide

in and attach to the Endos slots, which has a backplane to electrically

and logically connect modules together. There are currently three Endo

size variants: Mini, Medium, and Jumbo, with varying rib con;gurations

for each. Note that the MDK only details the speci;cation of the Endo to

the extent that it is necessary for module developers to develop

modules. In the interest of maintaining the integrity of the Ara platform

speci;cation, third-party Endo development is not permitted.

Spine (Endo Spine) A singular vertical feature that bisects the rear of the Endo and forms

part of the module slots. (See Figures 2.1 and 2.2)

Rib (Endo Rib) Horizontal features located either in the front or the rear of the Endo and

forms part of the module slots. Note that the rib con;guration shown in

Figures 2.1 and 2.2 is an instance of a rib arrangement and not the only

possible arrangement. (See Figure 2.4)

Top The orientation of the primary display module determines the top of

the phone. The top of the phone is de;ned as the direction in which the

volume buttons aTxed to the display module are biased. (See Figure

2.1, volume buttons are required on all primary display modules)

Phone Coordinate Axes

(X, Y, Z)

The Ara platform uses the Android de;ned coordinate system. The

Side-to-Side direction de;nes the X axis. The Top-Bottom direction

de;nes the Y axis. The thickness direction de;nes the Z axis. (See

Figure 2.1)




Interface Block The interface block is the area on the Endo and the modules where the

electrical power pins and contactless data pads are located.

Electro-Permanent

Magnets (EPM)

The Endo contains electro-permanent magnets (EPMs) to attach and

secure each module. The EPMs are activated upon module insertion

and deactivated by the user with an Android application.

Module Shell The module shell is a user-replaceable cover for Ara modules that can

be aesthetically customized as part of the Ara ful;llment process. With a

few exceptions as noted in the MDK, Ara modules should nominally

support user serviceable module shells.

Figure 2.1 - Ara Phone Built Based on Medium Endo




Figure 2.2 - Ara Endo (Medium Variant)

2.2. Parceling Schemes

Parceling schemes are rules that determine how and where modules can be placed in the Endo

frame. The front parceling scheme only has a few possible layouts, while the rear parceling

scheme can have many diGerent con;gurations depending on the location of the ribs.

2.2.1. Rear Parceling SchemeThe rear of the Endo is parceled into 1x1 unit squares. Each 1x1 square is approximately 22

mm. 1x2 and 2x2 modules are approximately 22x44mm and 44x44mm respectively. Note that

the thickness of the missing rib must be accounted for to conform to the overall grid scheme.

Refer to the computer-aided design (CAD) models and drawings for exact dimensions. All three

Endo sizes use the same rear parceling scheme so modules can be shared between Endo size

variants.




Figure 2.3 - Ara Rear Parceling Scheme for Jumbo, Medium, and Mini Con$gurations

As shown in Figure 2.3, a Medium Endo variant is composed of a 3x6 parceled grid while the

Mini and Jumbo variants are 2x5 and 4x7 respectively. Furthermore, the following design rules

govern the placement of the spine and ribs on the rear of the Endo:

Endos must have exactly one vertical spine.

The Medium variant spine must be at a 1:2 horizontal oGset from the centerline of the device as

viewed from the rear.

The Mini and Jumbo variant spine must be in the middle.

For the horizontal ribs, there must be at least 1 rib per 2 units (since modules cannot be larger

than 2x2).

Only a single cross is allowed in an Endo (that is, only one rib can go straight across the spine

on both sides).

The application of these design rules results in a discrete set of possible Endo con;gurations

for each size variant. Figure 2.4 shows the valid set of rear Endo con;gurations for the Medium




variant. While Google may or may not make every possible Endo variant available, developers

should be mindful that modules should support every variant.

Figure 2.4 - Valid Medium Endo Con$gurations (Rear)

The Ara parceling scheme and Endo design rules enable the three rear modules to be used

across multiple Endo sizes. A 1x2 module can be used on all three Endo size variants, while a

2x2 module can be used on the Jumbo and Medium Endo variants, and a 1x1 module can be

used on the Medium and Mini Endo variants. Note also that a 1x2 module can be inserted into

an Endo either in the vertical or horizontal orientation.




Figure 2.5 shows the front and rear views of rear modules with standard module shells

installed. Note that all rear modules should nominally support user-replaceable module shells.

Module shells attach to rear modules via mechanical snap-;t features built into the module

base and shell itself.

Replaceable module shells are a unique feature of the Ara architecture. They allow users to

aesthetically customize their Ara phone by leveraging injection-molded polycarbonate plastic

and dye sublimation process to create full-color and high-resolution shell designs, and if

desired, to replace module shells any time thereafter.

Figure 2.5 also shows the locations of the interface blocks for each module. Note that 2x2

modules may support an optional second interfaces block for increased power and data

utilization.

Figure 2.5 - Rear Modules

2.2.2. Front Parceling SchemeThe following design rules govern the front parceling scheme:




Vertical spines are not allowed - all modules must ;ll the complete horizontal width

A maximum of 2 ribs are allowed

Only a single rib is allowed in each of the upper or lower halves

The parceling scheme for the front Endo results in modules that are proportionally sized for

each Endo size variant. Figure 2.6 shows the valid set of front Endo con;gurations for each

size variant, labeled A through R.

Figure 2.6 - Valid Endo Con$gurations (Front)

2.3. Design Language

The design language is a set of design elements used to visually communicate a speci;c

aesthetic. Implementing a consistent design language ensures that every Ara phone has a set

of aesthetically cohesive modules, even though each phone may include modules from

diGerent sources.




2.3.1. Geometric Design Language - Speci$cationThe overall goal of the module aesthetic is to create a smooth, Qat, pebble form. The reasons

for this aesthetic are as follows:

1. A softer form without sharp lines and edges is simple, iconic, and visually easy to

understand

2. The shape enables modules to easily slide into a module slot

3. The form of the module is one that is friendly to hold and enjoyable to handle

The design language can be articulated as a set of geometric and color, material, ;nish (CMF)

guidelines. Table 2.2 summarizes these geometric guidelines.

Table 2.2 - Design Language Geometric Guidelines

Guideline Illustration

Module side pro;le must conform to the

shape of the Endo. This is not only

necessary to follow the design language,

but is also critical to allow the modules to

slide into module slots in the Endo and

lock into place.

Modules with components taller in Z which

occupy most of the X and Y dimensions

should continue the trapezoid form while

expanding in Z.




Modules with localized components taller

in Z should have localized Z growths with

soft transitions to reflect the notion of a

smooth pebble form.

The side pro;le sections should be

symmetric across X and Y axes.

Corners should have 1.5 mm curvature

radii.




Modules should keep rectilinear footprints

when possible; these are exempli;ed by

1.5 mm rounded corners connected by

straight lines.

2.3.2. Geometric Design Language - Reference ImplementationSection 3 provides example applications of the Ara design language including references to

CAD models for module templates and custom enclosures that meet the Ara design language

speci;cations.

2.3.3. Color Material Finish - Speci$cationColor, material, and ;nish (CMF) speci;cations ensure a uniform and consistent look and feel

across all Ara modules. CMF speci;cations generally focus on externally visible components

as those components have the most impact on the end-users experience.

Modules are composed from three main sub-assemblies as detailed in the Mechanical and

Layout section: the module base, printed circuit board (PCB), and shield. The module base

(includes main Aluminum piece and Hiperco-50 inserts), the interface block PCB, and module

shells are externally visible to the end-user and must adhere to the CMF guidelines as de;ned

in Table 2.3




Table 2.3 - Design Language CMF Speci$cations

Module Component

(Exposed Sections)

CMF Speci$cations

Aluminum Base Color: Natural Silver (clear anodize)

Material: Anodized Aluminum

Finish: Satin (Mold Tech 11005)

Hiperco-50 Inserts Color: Bright Satin Nickel plate

Material: Hiperco

Finish: Satin (Mold Tech 11005)

Interface Block PCB Color: Pantone Matching System (PMS) Black C

Material: FR-4 PCB

Finish: Matte Black, Liquid Photo Imageable Solder Mask

Shells and Buttons Color: Base White clear topcoat (for dye sublimation printing)

Material: Injection-molded polycarbonate plastic

Finish: Satin (Mold Tech 11005) or high gloss

2.3.4. Color Material Finish - Prototype Reference ImplementationThe prototype system design artifacts in the Mechanical and Layout section provide

examples of compliant reference implementations of module bases and PCBs. The prototype

interface block design is diGerent than the objective system. Instead of inductive pads as

shown in Figure 2.5, the prototype interface block uses electrical contacts for data

connections. These contacts are made from copper traces with 30 microns gold plating. See

the drawings in the reference materials for exact dimensions.




3. Mechanical and LayoutThis section de;nes mechanical speci;cations and general layout for Ara modules.

3.1. Module Geometry and Assemblies

3.1.1. Rear Module Sub-Assemblies

3.1.1.1. Rear Module Sub-Assemblies - Speci;cation

All three rear module types are composed of three sub-assemblies: the module base, printed

circuit board (PCB), and shield. Figure 3.1 shows an exploded view of these sub-assemblies for

a 1x2 module.

Figure 3.1 - Rear Module Sub-assemblies

As described in Section 2, the module shell is not considered part of the module assembly. To

the extent that it may deviate from a standard shell geometry, it will be created in accordance

with a module developers geometric speci;cations, but will include a consumers aesthetic

customizations and is presently envisaged to be manufactured as part of the ful;llment

process (i.e., not by the module developer).




The module base must be composed of a piece of machined anodized Aluminum and one or

two pieces of Hiperco-50 inserts (1x1 modules have a single Hiperco-50 insert). Hiperco-50 is

an alloy with enhanced magnetic properties and thus enhanced holding force between

modules and the Endo. The inserts must mount to the sections of the module base that

correspond to the locations of electro-permanent magnets (EPMs) on the Endo. When

activated, EPMs in tandem with the Hiperco-50 inserts should provide suTcient magnetic force

to secure modules into their slots on the Endo throughout all nominal usage scenarios. When

released, EPMs provide a residual magnetic force suTcient to prevent modules from falling out

unless the user deliberately removes a module from the Endo. Users should be able to remove

modules with minimal eGort when the EPM is in the release state. EPMs require no sustained

electrical power in either attach or release states and only a short electrical pulse to transition

between states.

Except for cutouts needed for external interfaces (e.g., USB connector), the external

dimensions of the module base must conform to the shape de;ned by the CAD model and

drawings provided in the reference materials. This requirement ensures the module is

compatible with third-party provided module shells and ;ts snugly into the Endo frame.

Custom milled cavities are allowed in the inside of the module base as long as the structural

integrity of the module base is maintained and can survive module compliance speci;cations,

provided in a later section.

Figure 3.2 shows renders of the prototype 1x2 module base. Due to machining constraints,

prototype module bases include additional thin Aluminum pieces (GM 145 wrought aluminum

alloy) that are laser-welded to the inside of the main Aluminum base. These mounting inserts

provide additional surface area to adhere to the Hiperco-50 inserts.




Figure 3.2 - Prototype Module Base

The PCBs (interface block PCB and main PCB) contain the circuitry for the module, including

circuits to enable interfaces to the Endo, as well as custom circuitry of the module. Any non-

electronic components that are part of the module (e.g., batteries, sensors) must either mount

to or be in place of the PCB. Table 3.1 provides maximum dimensions available for rear module

PCBs. PCBs smaller than these dimensions are allowed. The main PCB must be securely

mounted to the module base suTciently to survive vibration and shock speci;cations de;ned

in the Module Compliance section. A smaller PCB for the interface block should be soldered to

bottom of the main PCB and must conform to the shape and dimensions in the reference

implementation to ;t Qush with the corresponding cutout in the module base.




Table 3.1 - Rear Module Maximum PCB Dimensions

Rear Module PCB Maximum Dimensions (X, Y)

1x1 16.2 mm x 16.5 mm

1x2 16.5 mm x 39.15 mm

2x2 39.5 mm x 39.5 mm

Figure 3.3 shows renders of the 1x2 WiFi/BT Module main PCB and interface block PCB. The

main PCB should include the set of circuits and components needed by a generic prototype

module including a Bridge ASIC or equivalent. The module templates section provides

reference materials including a detailed Bill-of-Materials for the minimal set of components

needed for a module.

The prototype interface block PCB should implement the prototype interface block design

de;ned in a later section. The interface block PCB should be soldered to the main PCB and

adhere to the dimensions de;ned in the CAD models and 2D line drawings in the module

templates section. The interface block PCB should have the same thickness as the module

base to mount completely Qush in the opening of the module base. A 30 m gold plating

must be applied to all 12 interface block contacts.




Figure 3.3 - Prototype 1x2 PCB

A shield is necessary to prevent users from making unintentional contact with sensitive

components on the PCB while changing module shells. The shield also acts as a Faraday cage

to protect modules from potential interference and ensure a uniform RF environment for

modules which are intentional RF emitters. The shield must be made of nickel-plated steel or a

functionally and aesthetically similar metal. Cutouts for components that exceed the standard

envelope are allowed (e.g., camera lens). The shield must securely mount to the module base.

Figure 3.4 shows a render of the prototype 1x2 WiFi/BT Module shield and PCB. The shield

is mounted to the PCB with 3 (minimum of 2) SMT-mounted clips (EMI STOP Corp SUL-

1320A1M). While the clips are not strictly required, they enable developers to remove and

reinstall the shield in order to access PCB components for debugging purposes. The shield

should nominally be installed during module operation and otherwise adhere to the

speci;cations de;ned in the objective system.




Figure 3.4 - Prototype Shield and Clips




3.1.1.2. Rear Module Sub-assemblies - Prototype Reference Implementation

Table 3.2 provides a vertical stack up of various layers in prototype rear modules including

dimensions available for PCB components.

Table 3.2 - Prototype Rear Module Z Dimension Stack Up

Layer Thickness Notes:

Module Shell 0.65 mm Not part of module, provided by module shell developer

Air Gap 0.1 mm Thermal insulation

Shield 0.2 mm

Clearance 1.55 mm Available for PCB component

PCB 0.6 mm FR-4 PCB

Insulation/Adhesive 0.05 mm E.g., Glue. Area is not available where interface block

mounts to PCB.

Module Base/Interface

Block PCB

0.85 mm Interface block PCB should mount Qush to the module

base opening

Total Module Thickness 4.0 mm

The following subsections provide reference implementations of several prototype rear

modules.

3.1.1.2.1. Rear Module Templates - Prototype Reference Implementation

Table 3.3 provides relative ;le paths to design artifacts to create a minimal instantiation of

prototype rear modules. The module templates include both mechanical and electrical

models. The mechanical model includes 3D CAD models in STEP format and additional 2D

line drawings. Hiperco-50 inserts on the prototype modules are attached to the module base

with 3M Scotch-WeldTM Epoxy Adhesive DP100 Plus Clear, while the PCB is attached to the

module base with Hitachi Kasei Polymer Hi-PURSHOT 9753 adhesive.

Electronic design automation (EDA) ;les are in Allegro format (DSN for schematics and BRD

for layout). The template also includes EDA output packages, which contain schematics in

pdf format and bill-of-materials (BOM).

The module template EDA and output ;les include the Toshiba GP Bridge ASICs that handles

module communications and other system-level functions. The ASICs provide bridging of

several interface protocols that module developers can use to communicate with an

Application Processor (AP) in the AP module or on the AP development board. The Network

Stack section of this document details these protocols.




Table 3.3 - Prototype Rear Module Templates

Prototype Rear Module Design Artifacts

Prototype 1x1 Module 3D Models and Drawings:

ReferenceMaterials\1x1\Prototype1x1ModuleTemplate\CADFiles

EDA File and Outputs:

ReferenceMaterials\1x1\Prototype1x1ModuleTemplate\EDAFiles









3.1.1.2.2. 1x2 Camera Module - Prototype Reference Implementation

Table 3.4 provides relative ;le paths to design artifacts to create the prototype Camera

Module in a 1x2 module template.

Table 3.4 - 1x2 Prototype Camera Module Reference Implementation

Module Design Artifacts

Prototype Camera

Module

3D Models and Drawings:

ReferenceMaterials\1x2\PrototypeCameraModule\CADFiles


ReferenceMaterials\1x2\PrototypeCameraModule\EDAFiles

3.1.1.2.3. 1x2 Speaker Module - Prototype Reference Implementation

Table 3.5 provides relative ;le paths to design artifacts to create the prototype Speaker

Module in a 1x2 module template.

Table 3.5 - 1x2 Prototype Speaker Module Reference Implementation


Prototype Speaker

Module


ReferenceMaterials\1x2\PrototypeSpeakerModule\CADFiles


ReferenceMaterials\1x2\PrototypeSpeakerModule\EDAFiles




3.1.1.2.4. 2x2 Marvell AP Module - Prototype Reference Implementation

Table 3.6 provides relative ;le paths to design artifacts to create the prototype Marvell AP

Module with GPS in a 2x2 module template. The AP Module incorporates a GPS antenna in

the module shell. See the Antenna section below for details on antenna and antenna

interface speci;cations and reference implementations. The AP module includes a USB

connector to facilitate direct access to the AP for diagnostics and debugging purposes.1 The

USB connector does not provide power.

Table 3.6 - 2x2 Prototype Marvell AP Module Reference Implementation


Prototype Marvell AP

Module


ReferenceMaterials\2x2\PrototypeMarvellAPModule\CADFiles


ReferenceMaterials\2x2\PrototypeMarvellAPModule\EDAFiles

3.1.1.2.5. 2x2 NVidia AP Module - Prototype Reference Implementation

Table 3.7 provides relative ;le paths to design artifacts to create the prototype NVidia AP

Module in a 2x2 module template. The AP Module incorporates a GPS antenna in the module

shell. See the Antenna section below for details on antenna and antenna interface

speci;cations and reference implementations. The AP module includes a USB connector to

facilitate direct access to the AP for diagnostics and debugging purposes. The USB

connector does not provide power.

Table 3.7 - 2x2 Prototype NVidia AP Module Reference Implementation


Prototype NVidia AP

Module


ReferenceMaterials\2x2\PrototypeNVidiaAPModule\CADFiles


ReferenceMaterials\2x2\PrototypeNVidiaAPModule\EDAFiles

1In future MDK releases, AP modules may be required to have a USB or another external connection for certain debug scenarios. This is not a requirement of the current MDK release.




3.1.1.3. Hiperco-50 - Known Vendors

Hiperco-50 inserts are available from Foxconn Interconnect Technology (FIT) or in raw form

from vendors listed in Table 3.8.

Table 3.8 - Hiperco-50 Known Vendors

Vendor Product

Foxconn Interconnect Ara Module Hiperco-50 inserts

Ed Fagan & Associate Hiperco-50 alloy in strip/coil or sheets

Carpenter Steel Hiperco-50 in large quantities

3.1.2. Front Module Sub-assemblies

3.1.2.1. Front Module Sub-assemblies - Speci;cation

Figure 2.6 shows the possible distinct front module (A-R). While all front modules require a

module base and PCB for mounting the interface block(s), the other sub-assemblies are

speci;c to the module. As an example, a Display Module may have a display, touch sensor,

and glass cover. Table 3.6 provides outer dimensions and dimensions available for a PCB in

the two front modules in the current prototype. Maximum PCB dimensions for the other

modules will be provided in a future MDK release.




Table 3.9 - Front Module Outer Dimensions and PCB Dimensions

Front Module (Endo Size) Module Outer Dimensions (X, Y) Maximum PCB Dimensions (X, Y)

A (Mini) 45 mm x 114 mm TBD

B (Mini) 45 mm x 20 mm TBD

C (Mini) 45 mm x 91 mm TBD

D (Mini) 45 mm x 68 mm TBD

E (Mini) 45 mm x 68 mm TBD

F (Mini) 45 mm x 46 mm TBD

G (Medium) 67.74 mm x 136.87 mm TBD

H (Medium) 67.74 mm x 14.74 mm 62.2 mm x 9.5 mm

I (Medium) 67.74 mm x 120.74 mm 52.2 mm x 90 mm

J (Medium) 67.74 mm x 104.25 mm TBD

K (Medium) 67.74 mm x 75.02 mm TBD

L (Medium) 67.74 mm x 44.81 mm TBD

M (Jumbo) 90.74 mm x 169.74 mm (TBD) TBD

N (Jumbo) 90.74 mm x 14.74 mm (TBD) TBD

O (Jumbo) 90.74 mm x 143.74 mm (TBD) TBD

P (Jumbo) 90.74 mm x 127.74 mm (TBD) TBD

Q (Jumbo) 90.74 mm x 111.74 mm (TBD) TBD

R (Jumbo) 90.74 mm x 30.74 mm (TBD) TBD




3.1.2.2. Front Module Sub-assemblies - Prototype Reference Implementation

Table 3.10 provides a vertical stack up of various layers in a front module including

dimensions available for PCB components, displays, glass, and other components that are

typically found on the front of a phone.

Table 3.10 - Prototype Front Module Z Dimension Stack Up

Layer Thickness Notes:

Module Shell 0.65 mm

Air Gap 0.1 mm Thermal insulation

Clearance 0.1 mm E.g., Mesh for receiver speaker

Shield 0.15 mm

Clearance 1.7 mm Available for module component

PCB 0.4 mm FR-4 PCB

Insulation/Adhesive 0.05 mm E.g., Glue

Module Base/Interface

Block PCB

0.85 mm Interface block PCB should mount Qush to the module

base opening

Total Module Thickness 4.0 mm

3.1.2.2.1. Receiver Module - Prototype Reference Implementation

The current prototype implementation includes two front modules, both for the Medium Endo

variant. There is a Receiver Module (Class H) and a Display Module (Class I). Table 3.11

provides relative ;le paths to design artifacts to create a prototype Receiver Module. In

addition to the receiver speaker, the Receiver module includes a proximity sensor and light

sensor.

Table 3.11 - Prototype Receiver Module Reference Implementation

Component Design Artifacts

Receiver

Module


ReferenceMaterials\ClassH(Medium)\PrototypeReceiverModule\CADFiles


ReferenceMaterials\ClassH(Medium)\PrototypeReceiverModule\EDAFiles




3.1.2.2.2. Display Module - Prototype Reference Implementation

Table 3.12 provides relative ;le paths to design artifacts to create a prototype Display Module

with touch interface, microphone, power, and volume buttons.

Table 3.12 - Prototype Display Module Reference Implementation


Display

Module


ReferenceMaterials\ClassI(Medium)\PrototypeDisplayModule\CADFiles


ReferenceMaterials\ClassI(Medium)\PrototypeDisplayModule\EDAFiles

3.1.3. Module Label

3.1.3.1. Module Label - Speci;cation

The back of every module must have a clearly marked module label. This label must include

the Ara emblem, the name of the module developer, the name of the module, and a module

icon signifying the module function. The Ara emblem, module icons, and application

instructions will be provided in a future MDK release. If applicable, module labels should

include regulatory markings such as the module FCC ID and CE markings.

Figure 3.5 de;nes the speci;cations for positioning text and icons in the module label in

relation to the interface block. If a module has multiple interface blocks, the module label must

be positioned in relation to the leftmost interface block as viewed from the direction in Figure

3.5. Module labels should be applied with a laser-etched process.




Figure 3.5 - Module Label Speci$cations

3.1.3.2. Module Label - Prototype Reference Implementation

Module labels are not required for prototypes.

3.1.4. Envelope Violation Limitations

3.1.4.1. Envelope Violation - Speci;cation

The envelope for a module comprises the standard dimensions for the module to conform to

the Ara Endos. While a module will ideally ;t within these very speci;c dimensions, modules

are allowed to exceed the standard envelope in the Y (top-bottom) and Z (thickness) directions.

Modules are NOT allowed to exceed the envelope in the X (side-side) direction. Table 3.13

provides the absolute maximum exceedance limits; however, module developers should also




use good engineering judgement to determine the stress levels from user levied forces and

torques and ensure exceedances are structured to accommodate common usage scenarios

including scenarios where the module and phone are in the users pocket. Future releases of

the MDK may be more restrictive in exceedance limits based on results of handling and

accelerated lifecycle testing. Modules with dimensional exceedances must have a custom

shield and ensure all electrically active components except antennas and batteries are

encapsulated within.

Table 3.13 - Envelope Violation Limits

Direction Max Dimension Notes

X 45 mm (Mini), 67.02 mm

(Medium), 21.82 mm (1x1,

1x2), 44.82 mm (1x2, 2x2)

Modules are NOT allowed to exceed the standard

envelope in the X direction.

Y 20 cm Overall module height must not exceed this ;gure.

Z 2.6 cm Overall module thickness must not exceed this ;gure.

Whenever modules exceed the standard envelope, the exceedance should conform to the Ara

design language speci;cation (in Section 2).

3.1.4.2. Envelope Violation - Reference Implementation

Exceedances may be appropriate and necessary for some applications as demonstrated in

Figure 3.6. Figure 3.6 shows a reQective Pulse Oximeter Module, which measures blood

oxygen saturation. The exceedance in the Y dimension provides a convenient aGordance and

sensor location for a users ;nger.




Figure 3.6 - Pulse Oximeter Module with Y-Dimension Exceedance




3.1.4.3. Envelope Violation - Prototype Reference Implementation

Figure 3.7 shows several examples of modules that exceed the standard envelope. The

exceedances in the Z dimension for the Camera, USB Charger, and Extended Battery

Modules enable each to accommodate components (camera lens unit, charge port, and

battery respectively) with higher thickness requirements than is aGorded in the standard

envelope.

Figure 3.7 - Modules with Z-Dimension Exceedances

Figure 3.8 demonstrates a compliant custom module shell for the prototype Camera Module.

The shell has a raised opening for the lens. CAD ;les and line drawings of the custom

Camera Module Shell is provided in the reference materials.




Figure 3.8 - Custom Module Shell for Prototype Camera Module

3.1.4.4. 1x2 Pollution Sensor Module - Prototype Reference Implementation

Table 3.14 provides relative ;le paths to design artifacts to create the prototype Pollution

Sensor Module in a 1x2 module template. The Pollution Sensor Module exceeds the

standard envelope but remains within the envelope limits.

Table 3.14 - Prototype Pollution Sensor Module Reference Implementation


Pollution

Sensor

Module


ReferenceMaterials\1x2\PrototypePollutionSensorModule\CADFiles


ReferenceMaterials\1x2\PrototypePollutionSensorModule\EDAFiles

3.2. Connectors

The following subsections de;ne the connectors on Ara modules. All modules require at least

one interface block to exchange power, data, and detect/wake signal between modules and

the Endo. Some modules may also send RF signals through the interface block to another

module on the device. Modules require Hiperco-50 insert(s) on the module base to provide

enhanced magnetic coupling with the EPMs in the Endo. Front modules also require an

additional spring loaded mechanism attached to the Hiperco-50 insert that work in tandem




with EPMs in the Endo to secure the module in place when activated. Finally, ;nger-nail slots in

the module base allow users to remove and replace module shells.

3.2.1. Interface BlockThe interface block hosts electrical, data, and RF connections between modules and the Endo.

The Ara platform utilizes a contactless inductive interface for high-speed data transfer between

modules and the Endo. The Network Stack section details the contactless data transfer

mechanism.

3.2.1.1. Interface Block - Speci;cation

Each interface block is composed of 4 electrical connections (2 for power, 1 detect/wake, and

1 RF) and 8 data interfaces transferred by means of 4 contactless inductive pads as shown in

Figure 3.9 (1x2 modules have 2 sets of electrical connections to enable module insertion in

both orientations). Details of the contactless inductive interface is provided in the Network

section. Additional details of the objective interface block design will also be provided in a

future MDK release.

Figure 3.9 - Interface Block with Inductive Pads

The interface block is itself mounted and printed on a separate PCB. The interface block PCB

is then soldered to the main PCB. When installed into the module, the interface block PCB

should be completely Qush with the corresponding opening in the module base. The interface

block PCB must follow the geometry speci;ed in the module template CAD and EDA ;les

provided in the reference implementation.




3.2.1.2. Interface Block - Prototype Reference Implementation

The interface block in the current prototype platform diGers from the objective speci;cation.

Instead of contactless data transfer with inductive pads, the prototype uses electrical

signaling between the gold-plated copper pads on the module interface block and spring

pins on the Endo for data transfer (i.e., the same method used for power transfer). The shape

of the prototype interface block pad is round to match the spring pins on the Endo. The

module template section provides design artifacts for the prototype interface block reference

implementation.

The prototype interface block provides 8 data pads: two bidirectional M-PHY data lanes with

8 diGerential pairs (2 TX pairs and 2 RX pairs), a power pad, a ground pad, a detect/wake

pad, and an RF pad. Figure 3.10 and Table 3.15 detail the pinouts of the prototype interface

block.

Figure 3.10 - Prototype Interface Block Pinout




Table 3.15 - Prototype Interface Block Pinout Descriptions

# Pin/Pad Label Description

1 RF RF Signal

2 DET/WAKE Detect/Wake Signal

3 VCONN Positive Voltage Connector

4 MTX_D0N M-PHY Transmit Lane 0 Negative

5 MTX_D0P M-PHY Transmit Lane 0 Positive

6 MRX_D0N M-PHY Receive Lane 0 Negative

7 MRX_D0P M-PHY Receive Lane 0 Positive

8 MTX_D1P M-PHY Transmit Lane 1 Positive

9 MTX_D1N M-PHY Transmit Lane 1 Negative

10 MRX_D1P M-PHY Receive Lane 1 Positive

11 MRX_D1N M-PHY Receive Lane 1 Negative

12 GND Ground

3.2.1.3. Front Module Attachment - Speci;cation

Front modules attach to the Endo with a spring-loaded Hiperco-50 insert and are secured with

an EPM on the Endo. The ribs in the Endo secure front modules in the Y direction (top-bottom).

When a user slides the module into the Endo and aligns the module in the X direction (side-to-

side), the EPM in the Endo activates and pulls the Hiperco-50 insert into the Endo to lock the

module in place. To release and unlock a module, the user commands the EPM to release and

springs the Hiperco insert back into the module.

The front module attachment spring should have a spring force constant in the order of 1

N/mm to provide optimum release force when the EPM is deactivated, while not exceeding the

ability of the EPM to pull the insert into the Endo when activated. The dimensions of the

Hiperco-50 insert should conform to the shape de;ned by the CAD model and drawings

provided in the reference materials. In the release state, the Hiperco insert must be Qush with

the module base.




3.2.1.4. Front Module Attachment - Prototype Reference Implementation

Front module attachment prototype reference implementations are provided in the reference

materials for the Prototype Display and Receiver Modules. Figure 3.11 shows a closeup view

of the front module attachment mechanism in the Prototype Receiver Module.

Figure 3.11 - Closeup View of Front-Module Attachment Assembly




3.3. Antennas

Antennas can be installed inside a module, outside the shield (i.e. on top of the shield), or as

part of the module shell. Modules may also route RF signals to a diGerent module on the phone

using the RF connector on the interface block and the RF bus in the Endo. The following sub-

sections provide speci;cations and reference implementations for each scenario.

3.3.1. Antenna in Module - Speci$cationModule developers may design an antenna within a module, outside of the shield. Antennas

may be connected to components in the module PCB through any suitable means as long as

all electrically active components on the PCB are still covered by the shield. Slots in the shield

are allowed for antenna connectors.

Module developers may also design antennas directly into the module shell as shown in Figure

3.12. In this scenario, developers should design an antenna pattern that leverages laser direct

structuring (LDS) method to create antennas directly on the polycarbonate plastic module shell.

Several prototype modules provided in the subsequent reference implementation sections

include LDS antenna patterns as examples. All custom shells, including those with LDS

antennas should be ful;lled as part of the user aesthetic customization process, independent

of the module developer.

Figure 3.12 - Example of Antenna Pattern on Module Shell




3.3.2. 1x2 WiFi/BT Module with Antenna - Prototype Reference ImplementationTable 3.15 provides relative ;le paths to design artifacts to create the prototype WiFi/BT

Module in a 1x2 module template. The WiFi/BT Module incorporates an antenna in the

module shell manufactured with an LDS method. The antenna was designed and optimized

using automated methods including the use of a genetic algorithm, which used RF and

geometric speci;cations to generate suitable designs. The antenna is connected to the main

PCB using one ground and one RF signal spring contact. Details of the assembly are

provided in the reference materials in Table 3.16.

Table 3.16 - 1x2 Prototype WiFi/BT Module Reference Implementation


Prototype WiFi/Bluetooth

Module


ReferenceMaterials\1x2\PrototypeWiFiModule\CADFiles


ReferenceMaterials\1x2\PrototypeWiFiModule\EDAFiles

3.3.3. Antenna Interface - Speci$cationThe Endo enables modules to route RF signals to other modules on the device. This feature

allows diversi;cation of antenna placement and specialized antenna modules (e.g., antenna

modules that combine multiple frequency bands). RF signals can be routed through the RF

connector in the interface block to an RF bus in the Endo. Modules should treat the RF signal

through the Endo as a 50 transmission line.




3.3.4. Antenna Interface - Prototype Reference ImplementationThe RF bus can currently route signals

AraMDK_0.2

Documents

interfaces of ara modules

ara platform

ara module marketplace

ara ecosystem

ara specications

selection of modules

modules compatible

modules t