14 575

1
A seminar report on
PROJECT ARA
(Modular Phones)
BY
K.V.G.SATISH
14A81A0575
(Under the guidance of MR.J.VIJITHANAND, M.TECH)
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
SRI VASAVI ENGINEERING COLLEGE
Pedatadepalli, Tadepalligudem-534101,
W.G.Dist, AndhraPradesh,
2016 - 17

2
INDEX
Content Name Page No.
1. Introduction 1
2. Project ara an overview 3
3. General Hardware Architecture 4
4. Design Language 6
4.1 Design Language – Specification 6
5. Module Geometry and Assemblies 8
6. Electro-Permanent Magnets (Epm) 10
7. Parceling Schemes 12
7.1 Rear Parceling Scheme 12
7.2 Front Parceling Scheme 12
8. Power Architecture 14
8.1 Power Consumer Module 15
8.2 Charger Module 16
8.3 Power Storage Module 16
9. Extended Architecture 17
10. Software Architecture 20
10.1 Kernel Drivers 21
10.2 Android Hals 21
10.3 Android Application 21
11. System-Level Functions 22
11.1 Module Detect 22
11.2 Enumeration 22
11.3 Epm Control 23
11.4 Active Thermal Management 23
12. Advantages 24
13. Disadvantages 25
14. Conclusion 26
15. Bibliography 27

3
LIST OF FIGURES
Figure Name Page No.
Figure 1.1 Project Ara 2
Figure 3.1: Ara Endo (Medium Variant) 4
Figure 5.1 -Rear Modules 8
Figure 5.2 Rear Module Sub-assemblies(1x2 module) 9
Figure 6.1 - Rear Module EPM Exploded View 10
Figure 7.2.1 front parceling schemes 13
Figure 8.1 -Power Architecture 15
Figure 9.1 - Pulse Oximeter Module with Y-Dimension Exceedance 18
Figure 9.2 -Thermal Imager Module with Z-Dimension Exceedance 19
Figure 10.1 - Software Architecture 20

4
ABSTRACT
Project Ara is the codename for an unnamed modular smartphone that is essentially a
computer board with compatible modules. The platform will include a endoskeletal frame
with modules of the owner's choice, such as a display, camera or an extra battery. The phone
itself can be swapped from malfunctioning modules or upgrades as innovations emerge,
providing longer handset cycle lifetime, and potentially reducing electronic waste. ProjectAra
smartphone is scheduled to release a developer version in the United States in the fourth
quarter of 2016 with a target bill of materials cost of $50 for a basic grey phone.A consumer
version is not expected until at least 2017.
The project was originally headed by the Advanced Technology and Projects team
within Motorola Mobility while it was a Google subsidiary. Although Google has since
divested Motorola to Lenovo, it retained the ATAP group, now a division under Android.The
project separated from ATAP and is now an independent division.

5
1.INTRODUCTION
Project Ara is the codename for an initiative by Google that aims to develop an open
hardware platform for creating highly modular smartphones. The platform will include a
structural frame that holds smartphone modules of the owner's choice, such as a display,
keyboard or an extra battery. It would allow users to swap out malfunctioning modules or
upgrade individual modules as innovations emerge, providing longer lifetime cycles for the
handset, and potentially reducing electronic waste. The first model of the modular phone is
scheduled to be released in January 2015. The project was originally headed by the Advanced
Technologies and Projects team within Motorola Mobility while it was a subsidiary of
Google. Although Google had sold Motorola to Lenovo, it is retaining the project team who
will work under the direction of the Android division.
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. Ara’ssuccess
is predicated on a rich, vibrant, and diverse ecosystem of modules from developers. Users
would be able to select modules from an online marketplace using a configurator that
facilitates user choice and curates the configuration process to ensure that the selection of
modules provides the expected system-level functionality.
Project Ara is a platform for creating modular smartphones. Users will be able to populate
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 phone’s 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.
Ara’ssuccess 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 configurator that facilitates user choice and curates the configuration process to
ensure that the selection of modules provides the expected system-level functionality.

7
5. PROJECTARAANOVERVIEW
Project Ara an overview
Developer Google
Manufacturer User
Type Smartphone
Release date 2015
Introductory price minimal cost ~US$50
Operating system Android
Power Variable
System-on-chip used Variable, Toshiba-supplied for the first year
CPU Variable
Memory Variable
Storage Variable
Display Variable
Graphics Variable
Sound Variable
Input Variable
Camera Optional
Connectivity Variable
Dimensions Variable
Weight Variable
Table 2.1- Project Ara overview.

8
6. GENERAL HARDWARE ARCHITECTURE
Figure 3.1: Ara Endo (Medium Variant)
The Ara architecture requires the introduction of several new concepts to the
traditional mobile device lexicon. These terms are defined in the following table.
Term Definition
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
affordance such as thedisplay, speaker, microphone, etc., and rear
modules, which provide the bulk of the phone’s back-end
functionality. Front modules reach across the entire width of a
particular endoskeleton frame, while rear modules come in three

9
standard sizes (1x1, 1x2, and 2x2) and can fit into multiple frame
sizes.
Endoskeleton (Endo) The Ara endoskeleton (“endo”) is the frame of the device,
determining the size and layout of the phone. Ara modules slide in
and attach to the endosslots, which hasa backplane to electrically and
logically connect modules together. There are currently three endo
size variants: Mini, Medium, and Large, with varying rib
configurations for each.
Spine (Endo Spine) A singular vertical feature that bisects the rear of the endo and forms
part of the module slots.
Rib (Endo Rib) Horizontal features located either in the front or the rear of the endo
and forms part of the module slots.
Top The orientation of the primary display module determines the “top”
of the Phone.
Phone Coordinate
Axes (X, Y, Z)
The Ara platform uses the Android defined coordinate system. The
Side-to-Side direction defines the X axis. The Top-Bottom direction
defines the Y axis. The thickness direction defines the Z axis.
Interface Block The interface block is the area on theendo and the modules where the
electrical power pins and capacitive data pads are located.
Electro-Permanent
Magnets (EPM)
Rear modules attach and secure themselves to the endo with electro
permanent magnets (EPM) directly, whereas front modules utilize
pins for attachment to the endo.
Module Shell The module shell is a user-replaceable cover for Ara modules that
can be aesthetically customized and is 3D printed as part of the
Arafulfillment Process.
Table 3.1– Terms and definitions.32

10
4. DESIGN LANGUAGE
The design language is a set of design elements used to visually communicate a
specificaesthetic. Implementing a consistent design language ensures that every Ara phone
has a set of aesthetically cohesive modules, even though each phone may include modules
fromdifferent sources.
4.1 DESIGN LANGUGE – SPECIFICATION:
The overall goal of the module aesthetic is to create a smooth, fat, 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
tounderstand
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, finish
(CMF) guidelines. Table 4.1.1 summarizes the geometric guidelines. CMF guidelines will be
provided ina future release.
Guideline Illustration
Module side profle must conform to
the shape of the endo. This is not
onlynecessary to follow the design
language, but is also critical to allow
the modules to slide into module
slots in the endoandlock into place.
Modules taller in Z should continue
the trapezoid form while expanding
in Z.

11
The side profle 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
exemplified by 1.5 mm rounded
corners connected by straight lines.
Planar surfaces (meeting at angles)
do not need to be parallel or
perpendicular to the module’s bottom
surface

12
5. MODULE GEOMETRY AND ASSEMBLIES
Figure 5.1 -Rear Modules
All rear modules should nominally support user-replaceable module shells. Module
shells attach to rear modules via mechanical snap-fit features built into the module base and
shell itself. Replaceable module shells are a unique feature of the Ara architecture. They
allow users to leverage consumer-grade, full-color 3D printing to aesthetically customize
their Ara phone before purchase, and if desired, to replace each module shell any time
thereafter. The 2x2 modules may support an optional second interfaces block for increased
power and data utilization. All three rear module types are composed of three sub-assemblies:
the module base, printed circuit board (PCB), and safety shield.

13
Figure 5.2 Rear Module Sub-assemblies(1x2 module)
The PCB contains the circuitry for the module, including the endo interface
functionality, as well as the custom functionality of the module. Any non-electronic
components that are part of the Module (e.g., batteries, sensors) must either mount to or in
place of the PCB. Table 5.1 provides maximum dimensions available for rear module PCBs.
PCBs smaller than these dimensions are allowed. Note that interface block(s) and EPM(s)
(and driver circuits) will take up some of the available PCB areas. The PCB must mount to
the module base.
Rear Module PCB Maximum Dimensions (X, Y)
1x1 18 mm x 18 mm
1x2 18 mm x 40.5 mm
2x2 39.5 mm x 41 mm
Table 5.1 - Rear Module Maximum PCB Dimensions

14
6. ELECTRO-PERMANET MAGNETS (EPM)
The EPMs provide a low-power and user-controllable method to securely attach
modules to Slots in the endoskeleton. The EPM has two selectable states: the attach state and
release State, corresponding to high and low levels of magnetic force. Electrical power is
needed to Switch between the two states only; the EPMs require no sustained electrical power
to maintain Either state. EPMs in the attach state provide sufficient magnetic force to secure
modules into their slots on the endo throughout all nominal usage scenarios. EPMs in the
release state provide a residual magnetic force to prevent modules from falling out unless the
user deliberately removes the Module from the endo. Users should be able to remove
modules with minimal effort when the EPM is in the release state.
The 1x1 and 2x2 modules each use a single EPM. 1x2 modules use two EPMs, one
for each Valid module insertion direction. Each EPM must provide a minimum holding force
of 30 N in the attached state, and 3 N in the release state. This force must be applied in the
insertion Direction of the module, i.e., in the X direction. The EPM attachment surfaces on
the endo are made from Hiperco-50 alloy to provide enhanced magnetic holding force.
Figure 6.1 - Rear Module EPM Exploded View

15
Figure 6.1 shows an EPM used in the prototype. The front curved face mates with
theHiperco-50 attachment surface on the endo spine. The EPM is made from three parallel
Sections. The N42SH magnets at the front are magnetized parallel to the long axis of the
device, alternating magnetization direction from section to section. The Alnicomagnetsin the
back can have their magnetization direction reversed by passing a current through the coils.
When the Alnicomagnets are magnetized opposite to the N42SH magnets, the holding forceis
low; this is the release state. When the Alnico and N42SH magnets are magnetized together,
the holding force is larger; this is the attach state.

16
7. 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
parcelingscheme can have many different configurations depending on the location of the ribs
and spine.
7.1 REAR PARCELING SCHEME
The rear of the endo is parceled into 1x1 unit squares. Each 1x1 square is approximately
20mm. Note, however, that 1x2 and 2x2 modules are not exactly 20x40mm and 40x40mm
due tothe fact 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.
1. Endos must have exactly one vertical spine.
 The Medium variant spine must be at a 1:2 horizontal offset from the centerline of
thedevice as viewed from the rear.
 The Mini and Large (TBD) 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
endoconfgurationsfor each size variant.
7.2 FRONT PARCELING SCHEME
The following design rules govern the front parceling scheme:
 Vertical spines are not allowed - all modules must fll 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 foreach endo size variant. Figure shows the valid set of front endo configurations for

17
each sizevariant, labeled A through L. Front modules for the Largeendo variant will be
formalized in afuture MDK release.
Figure 7.2.1 front parceling schemes

18
8. POWER ARCHITECTURE
The Ara power architecture is designed to accommodate the unique and flexible
nature of the platform. Users of an Ara phone will be able to power their device with one or
multiple batteries; they will be able to swap a depleted battery with a fresh one, without
powering of their phone; they will be able to charge one or more batteries in their phone from
one or multiple charging devices. The design of the power architecture enables all of these
use cases and provides a flexible power platform for new applications.
Figure 8.1 shows a high-level view of the Ara power architecture. A common power
bus is Central to the architecture. The power bus is held between 3.0 and 5.5 V. The power
bus is distributed through the endo frame to each interface block. A power manager in the
endooptimizes power consumption, reduces current leakages, and provides protection against
overcurrent. The endo also has a small battery or capacitor bank, and associated charge
controller. The power stored in the endo provides power to the phone during brief periods
when the battery and/or charger modules are being hot-swapped or reconfigured and no other
power source is available to keep the device on.
Ara modules fall into three categories in relation to the power architecture: power
consumers, charging modules, and power storage modules (batteries, fuel cells, etc.).
Modules can change categories throughout their usage life. For instance, a battery module
may have a built-in charging port. Such a module would serve as a power consumer when
being charged from the bus (e.g., if another module’s charging port is active), a charging
module when powered throughits charging port, and a power storage device when
functioning as a regular battery. Figure 8.1 also illustrates a simplified view of these three
module types.

19
Figure 8.1 -Power Architecture
8.1 POWER CONSUMER MODULE
At the top of Figure 8.1 is a power consumer module, which is the simplest in its
operation. The power consumer module draws power directly from the power bus, or more
commonly, voltage regulator(s) steps down and regulates the voltage from the bus for various
circuits within the module.

20
8.2 CHARGER MODULE
Charging modules can supply externally derived power to the power bus. Charging
modules May draw a small amount of current from the power bus during EPM activation and
the module enumeration process, but current flows nominally in one direction, from the
module to the bus. A traditional DC charger module is shown in Figure 8.1
8.3 POWER STORAGE MODULE
Power storage modules primarily include battery modules, but other power storage
devices are envisioned. Power storage modules can supply power to the rest of the system or
draw power from the bus for recharging. Battery modules supply power to the power bus by
default. Ideal diode circuits prevent current flow into a battery, and, therefore the power bus
voltage is equal to the highest voltage presented by any of the batteries connected to the
power bus. When a charger module is connected to the system and ready to deliver charging
current to the batteries, it signals the supervisory controller in the endo (central power
management system) via UniPro messaging. The supervisory controller then signals battery
modules to cut of power delivery to the power bus and activate their charging circuits to draw
power from the bus. The supervisory controller periodically polls battery modules to report
self-diagnostics such as state of charge and uses this information in its power management
routines.

21
9. EXTENDED ARCHITECTURE
The envelope for a module comprises the standard dimensions for the module to
conform to the Araendos. While a module will ideally fit within these very specific
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 9.1 provides the absolute maximum exceedence limits, driven by the
capability of 3D printers (to print the associated module shells); however, module developers
should also use good engineering judgment 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 user’s pocket. Modules
with dimensional exceedances must have a custom safety shield and ensure all electrically
active components are encapsulated within.
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 figure.
Z 2.5 cm
Overall module thickness must not
exceed this figure.
Table 9.1 - Envelope Violation Limits

22
Exceedances may be appropriate and necessary for some applications as demonstrated
in figures 9.2 and 9.1 Figure 9.2 is a reflective Pulse Oximeter Module, which measures
blood oxygen saturation. The exceedance in the Y dimension provides a convenient
affordance and sensor location for a user’s finger. Figure 9.1 is an example of a Prototype
Thermal Imager Module. The exceedance in the Z dimension enables modules to
accommodate components with high thickness requirements such as a camera lens unit.
Figure 9.1 - Pulse Oximeter Module with Y-Dimension Exceedance

23
Figure 9.2 -Thermal Imager Module with Z-Dimension Exceedance

24
10. SOFTEARE ARCHITECTURE
The Ara software stack is predicated on the attachment of a single Application
Processor (AP) Module running Android(Support for multiple AP modules may be included
in a future). From the perspective of an Ara phone’s Linux kernel, there are two types of
modules: those which conform to a particular device class (device classes such as cameras,
displays, human interface devices, etc.), and novel, unique, or otherwise special-purpose
modules, which do not belong to any device class. Devices without in-kernel device class
drivers are unlikely to have native UniPro interfaces. These devices will communicate with
Android through a UniPro Bridge chip driver in the kernel and a developer-supplied
Userspace driver. Figure 10.1 shows the software interfaces and interactions for modules with
and without existing in-kernel device class drivers.
Figure 10.1 - Software Architecture

25
10.1 KERNEL DRIVERS
Linux device drivers provide low-level hardware support on Android devices. On a
standardSmartphone, the available hardware is fixed, allowing device manufacturers to pre-
select a set ofdevice drivers. On an Ara phone, however, almost all of the hardware which is
normally an immutable part of a smartphone’s design is designed to be user replaceable and
hot pluggable.
To enable hot-plug support and provide a framework that enables arbitrary future
extensions, two driver classes will be developed, as previously shown in Figure 10.1 native
UniPro-based class drivers and UniPro Bridge ASIC-based user mode drivers. UniPro class
drivers will support a range of module devices with in-kernel device drivers that will be part
of the base Ara software release. The UniPro Bridge ASIC drivers will allow a module device
without native UniPro interface or in-kernel device driver to communicate with Android
through the Linux driver core and a developer-supplied userspace driver. The design of this
interface is influenced by the file system in Userspace (FUSE) project.
10.2 ANDROID HALS
Hardware Abstraction Libraries (HAL) are implemented as shared libraries; their code
runs within Android’s system services. Unlike device drivers, HAL APIs are specified by
Google andare updated with each release. Device manufacturers provide library binaries
which implement these interfaces in their devices’ system images. These libraries are then
subsequently loaded by the relevant system services as part of their initialization. Among
other things, HALs provide an abstraction barrier between Android system services and the
various device driver interfaces exposed by the kernel for different hardware peripherals
those services must control.
10.3 ANDROID APPLICATION
In general Android applications for the Ara platform are not in any significant respect
different than traditional Android apps. Consequently, Ara devices are anticipated to be
compatible with most standard apps.

26
11. SYSTEM-LEVEL FUNCTIONS
The following are the system-level functions performed by Ara modules. Modules
will utilize the network and software stacks to exercise these functions. Modules interface
with the supervisory controller in the endo to carry out these functions.
11.1 MODULE DETECT
A feature of the Ara platform is that batteries and power buttons can be distributed
among the modules. The platform uses out-of-band wake and detect signals to allow modules
and the endo to power themselves of when appropriate. The detect signals are used to
communicate to a module and the endo when a module is inserted or removed. Power
consuming modules naturally lose power when removed from the endo, so they automatically
shut off. Modules with batteries must place themselves in a powered-down standby state
when they lose the detect signal from the endo.
An Ara phone can power itself on and offby pressing buttons on a module. The wake
signalsare used to bring the phone out of a low-power standby state. The WAKE_TX signal
is sent from a module to the supervisory controller when the power button is pressed. This
brings the supervisory controller out of standby state, and the supervisory controller, in turn,
sends WAKE_RX signals to each of the installed modules to turn them on.
11.2 ENUMERATION
Enumeration allows the phone to identify and determine the capability of a module
when it is plugged into the endo. For example, a Display Module will provide its
vendor/manufacturer name, device class indicating the type of device driver it needs, screen
resolution, and other performance identifier needed to operate the module. When a module
insertion event occurs, the UniPro switch on the endo signals an interrupt to the supervisory
controller. The supervisory controller then establishes a low-speed link with the module and
initializes the device identification. The supervisory controller then sends a UniPro message
to the other modules, including the Application Processor to announce the insertion event so
appropriate drivers can be loaded.

27
11.3 EPM CONTROL
EPM control addresses how EPM(s) in the module are switched between attach and
release states. These actions are triggered by the user with an application interface. The
application will graphically show the current state of modules and module slots in the phone
including whether a module is present in the slot, the name identifier of a module, and the
state of the module’s EPM(s) (attach/detach). The user may then toggle the state of the EPM
by touching on a specific module.
Once triggered by the user, the supervisory controller issues EPM control messages to
activate the EPM driver circuits
11.4 ACTIVE THERMAL MANAGEMENT
Active thermal management features protect the user and the phone from excessive
heat buildup. Excessive heat generated from a module can cause injury to user and cause
neighboring modules to fail. Temperature sensors in the endo and the modules provide
measurements to the supervisory controller. If temperatures exceed predefined limits,
modules may receive warnings, and in the worst case, power will be removed. Active thermal
management is not implemented in the prototype platform.

28
12. ADVANTAGES
PRICE
The basic Project ARA phone is going to cost less than $50 to manufacture making it
accessible to almost everyone.
CHEAPER REPAIRS
If a screen breaks, you just replace that. The same will be true with any module.
Hopefully there will be some sort of diagnostic built in so whatever breaks, you can just swap
the part out.
CUSTOMIZATION
You only need to add in what you need.so you need to pay only for what you want.
INCREASED LIFE
You just upgrade as you require or as parts break so you never need to buy a whole
new phone. This will also result in less waste.
BATTERY LIFE
By having 2 or more battery’s, phone will last longer and being able to how swap
modules should mean that you can keep your phone going as long as you need.
SUPPORT SPECIALISATION
You may have specialized modules that you onlyswap in when you need them.

29
13. DISADVANTAGES
SIZE OF THE PHONE
In the early days Project ARA phone is not going to be as slim as a traditional phone.
Height and width will not be an issue, because people want big phones but thickness could be
a problem.
TESTING ISSUE
Expect more bugs with an ARA phone. Even with only a handful of modules, there
will be a huge number of combinations and it will be almost impossible to test them all. With
the open module development environment, there will be ARA modules from a huge number
of suppliers which can’t all be tested together.
DESIGN
Due to the modular architecture, project ara is can’t offer attractive designs which is
offered by todays smart phones.

30
14. CONCLUSION
 One field that is benefitting from this project is 3Dprinting
 Specialized technology (UniPro and M-PHY) has made the development of this
device efficient
 Technology used in Project ARA can be re-used in other items
 Modular market might not settle so quickly
 With the prototype’s receive in the market, new companies or individuals might get
interested in the development of modules
 The success is tightly connected to the variety ofmodules and brands that the user
might be able to acquire
 The platform that allows the user to manage all its modules should be intuitive enough
for new smartphone users

31
15. BIBILIOGRAPHY
1. PHONEBLOKS. Phonebloks, a phone worth keeping.2014.
https://phonebloks.com/en
2. REISINGER, Don. Report: Google acquires Modu'smobile patents. 20/05/2011.
http://www.cnet.com/news/report-google-acquires-modus-mobilepatents/
3. THUNDERCLAP.INC. Thundeclap. 2012 https://www.thunderclap.it/en
4. MCCRACKEN, Harry. Project Ara: Inside Google’sBold Gambit to Make
Smartphones Modular. 26/02/2014. http://time.com/10115/google-project-
aramodular-smartphone/
5. YUE, Yu. Two Futuristic ZTE Phones. 29/10/2013
http://wwwen.zte.com.cn/endata/magazine/mobileworld/2013/5/articles/2013
10/t20131029_411072.html
6. PÉREZ, Alex. Smartphone modular Xiaomi MagicCube. 10/10/2013.
http://www.movileschinos.eu/noticias/xiaomi-magic-cube/
7. BLOCKS. Choosebloks. 2014. http://www.chooseblocks.com/
8. CHAN, Norman. Tested Explains: How Google's ProjectAra Smartphone Works.
15/04/2014 http://www.tested.com/tech/smartphones/460765-tested-explains-
howgoogles- project-ara-smartphone-works/
9. GOOGLE ATAP. Project Ara Developers Conference Day1. 15/04/2014.
https://www.youtube.com/watch?v=v2OEKL1w__4
10. GOOGLE ATAP. Project Ara Developers Conference Day2. 15/04/2014.
https://www.youtube.com/watch?v=cP8yzJhe-BA
11. MIPI ALLIANCE. UniPro(SM) Specifications. 2014.
http://mipi.org/specifications/unipro-specifications
12. MIPI ALLIANCE. Physical Layer Specifications. 2014.
http://mipi.org/specifications/physical-layer
13. DEYLE, Travis. Electropermanent Magnets. 7/12/2010
14. http://www.hizook.com/blog/2010/12/07/electropermanentmagnets-programmable-
magnets-zero-static-powerconsumption-enable-s

14 575

More Related Content

Similar to 14 575

More from Chaitanya Ram

Recently uploaded

14 575