Upload
carlos-david-chanchi
View
12
Download
2
Tags:
Embed Size (px)
DESCRIPTION
ara
Citation preview
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
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 2 of 107
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.
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 3 of 107
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
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 4 of 107
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/.
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 5 of 107
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.
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 6 of 107
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
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 7 of 107
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
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 8 of 107
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
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 9 of 107
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
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 10 of 107
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
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 11 of 107
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
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 12 of 107
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
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 13 of 107
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
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 14 of 107
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)
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 15 of 107
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
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 16 of 107
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
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 17 of 107
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.
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 18 of 107
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)
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 19 of 107
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
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 20 of 107
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.
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 21 of 107
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
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 22 of 107
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.
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 23 of 107
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:
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 24 of 107
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.
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 25 of 107
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.
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 26 of 107
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.
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 27 of 107
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
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 28 of 107
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.
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 29 of 107
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).
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 30 of 107
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.
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 31 of 107
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.
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 32 of 107
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.
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 33 of 107
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.
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 34 of 107
Figure 3.4 - Prototype Shield and Clips
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 35 of 107
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.
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 36 of 107
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
Prototype 1x2 Module 3D Models and Drawings:
ReferenceMaterials\1x2\Prototype1x2ModuleTemplate\CADFiles
EDA File and Outputs:
ReferenceMaterials\1x2\Prototype1x2ModuleTemplate\EDAFiles
Prototype 2x2 Module 3D Models and Drawings:
ReferenceMaterials\2x2\Prototype2x2ModuleTemplate\CADFiles
EDA File and Outputs:
ReferenceMaterials\2x2\Prototype2x2ModuleTemplate\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
EDA File and Outputs:
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
Module Design Artifacts
Prototype Speaker
Module
3D Models and Drawings:
ReferenceMaterials\1x2\PrototypeSpeakerModule\CADFiles
EDA File and Outputs:
ReferenceMaterials\1x2\PrototypeSpeakerModule\EDAFiles
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 37 of 107
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
Module Design Artifacts
Prototype Marvell AP
Module
3D Models and Drawings:
ReferenceMaterials\2x2\PrototypeMarvellAPModule\CADFiles
EDA File and Outputs:
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
Module Design Artifacts
Prototype NVidia AP
Module
3D Models and Drawings:
ReferenceMaterials\2x2\PrototypeNVidiaAPModule\CADFiles
EDA File and Outputs:
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.
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 38 of 107
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.
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 39 of 107
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
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 40 of 107
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
3D Models and Drawings:
ReferenceMaterials\ClassH(Medium)\PrototypeReceiverModule\CADFiles
EDA File and Outputs:
ReferenceMaterials\ClassH(Medium)\PrototypeReceiverModule\EDAFiles
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 41 of 107
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
Component Design Artifacts
Display
Module
3D Models and Drawings:
ReferenceMaterials\ClassI(Medium)\PrototypeDisplayModule\CADFiles
EDA File and Outputs:
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.
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 42 of 107
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
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 43 of 107
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.
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 44 of 107
Figure 3.6 - Pulse Oximeter Module with Y-Dimension Exceedance
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 45 of 107
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.
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 46 of 107
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
Component Design Artifacts
Pollution
Sensor
Module
3D Models and Drawings:
ReferenceMaterials\1x2\PrototypePollutionSensorModule\CADFiles
EDA File and Outputs:
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
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 47 of 107
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.
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 48 of 107
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
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 49 of 107
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.
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 50 of 107
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
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 51 of 107
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
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 52 of 107
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
Module Design Artifacts
Prototype WiFi/Bluetooth
Module
3D Models and Drawings:
ReferenceMaterials\1x2\PrototypeWiFiModule\CADFiles
EDA File and Outputs:
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.
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 53 of 107
3.3.4. Antenna Interface - Prototype Reference ImplementationThe RF bus can currently route signals