The internet of things will augment your brain.
– Eric Schmidt
At a very basic level IoT can be described as a network of things (physical devices, vehicles, buildings, and what not), which when augmented with sensors and servers enables these objects or things to collect and exchange data. A major driver behind this growth has been the advent of a comparatively lesser-known technology known as Bluetooth Low Energy (BLE).
In this chapter, we discuss this technology in the light of the following topics:
Bluetooth Low Energy or Bluetooth Smart is a comparatively new wireless communication technology that was introduced by the Bluetooth Special Interest Group in 2010. Although the technology itself was being developed way earlier by Nokia around 2001 to 2006 under the name Wibree, it was not until 2007 that an agreement was reached with the various members of Bluetooth SIG that Wibree should now be included in the Core Bluetooth Specification, a task which was completed in 2010, when Wibree became a part of Bluetooth Core Specification version 4.0 as Bluetooth Smart, commonly known as Bluetooth Low Energy (its original name). The first mobile device to incorporate the 4.0 specification was iPhone 4S. However, as it is almost always with early adopters, the then iPhone 4S operating system did have some bugs regarding Bluetooth connectivity and range sometimes being poor. Bluetooth Smart technology has matured rapidly since then and come a long way. In fact, the dawn of the current IoT revolution is relying significantly on Bluetooth Low Energy for its success. According to an analysis done by IndustryArc.
To read the detailed report from IndustryArc, please visit: http://industryarc.com/PressRelease/43/bluetooth-smart-lowenergy.html.
Bluetooth Low Energy device shipments are forecast to increase to 8.4 billion units by 2020 at a mean annual growth rate of 29% which eventually will also lead to a surge in the number of IoT devices (things, if spoken semantically). We are seeing the early stages of this revolution all around us as a result of which, almost every handheld device and wearable nowadays has BLE capabilities.
So, what is it that makes Bluetooth Low Energy so special? How is Bluetooth Low Energy different from the good old regular Bluetooth? Why is every other wearable device (for example, Fitbit, Nike Fuelband, Apple watch and maybe your own smartphone) on the market using Bluetooth Low Energy (Couldn't they just do away with regular bluetooth and be happy about it)? We will explore the answer to all these questions and many others in this chapter. Furthermore, we will also discuss the architecture and what lies under the hood that makes Bluetooth Low Energy live up to its name.
To know more about bluetooth visit https://www.bluetooth.com/ and for a PDF sample, go to http://www.industryarc.com/pdfdownload.php?id=187https://www.bluetooth.com/
So, coming to the very first question, what makes Bluetooth Low Energy so special? We will have to go back in time a little bit to address this. During the year 2001, the researchers at Nokia had already identified a number of scenarios, which were not being addressed by any of the existing Wireless Personal Area Network (WPAN) communication technologies,
WPAN or a Wireless Personal Area Network is a network centered around a user's personal space. The typical range for a WPAN network is around 10 meters. An example of a WPAN network technology is Bluetooth.
The most common factors that came out as a result of studying these scenarios were:
Hence, what started in 2001 ended up being Bluetooth Low Energy or Bluetooth Smart in 2010. The technology was given a descriptive name, which also describes its real purpose of existence. Bluetooth Low Energy was designed for devices which had:
And guess what? They finally succeeded in achieving all the set goals. If you remember the age of early mobile phones, the ones which had classic Bluetooth only, then you might remember that classic Bluetooth was a battery-expensive feature and continuous usage used to drain the battery on the device pretty quickly. Also, there were not many low-cost Bluetooth accessories available as there are now. However, with the advent of Bluetooth Low Energy (which consumes low power), all these things are bygones. We can now buy a Bluetooth tag, which supports and operates on Bluetooth 4.0, similar to the ones shown next for as low as 1-2 euros (Don't worry too much if you do not yet understand what this tag is used for. In the later chapters, we will build an application around the usage of this tag.):
Figure 1: Low Cost Bluetooth Smart Tag
Fitbit, one of the most common and popular fitness trackers, used for recording the body vitals and daily activity, has a battery life of 7-10 days after a full charge (source: https://www.fitbit.com/charge). Please note that this is a device which is working continuously day and night and even records data when you are sleeping:
Figure 2. Fitbits; source: dev.fitbit.com
Lastly, Bluetooth Low Energy is now being incorporated in each and every smartphone being rolled out. Apple which was one of the early adopters of Bluetooth Low Energy was later joined by Samsung, LG, Motorola, and every other major mobile device manufacturer out there. The popularity and adoption rate of the technology has already seen exponential growth and with the announcement of Bluetooth 5, which promises double the speed and four times the range, we will continue to see an even larger wave of Bluetooth Low Energy and IoT devices hitting the market.
Although Bluetooth Classic and Bluetooth Low Energy share many important things such as architecture, and both operate in 2.4 GHz ISM Band, the fundamental difference between them is that BLE is designed to consume less power. Due to this caveat, BLE is not an ideal candidate for applications such as streaming voice data (talking over the phone); however it makes BLE an excellent choice when it comes to communicating via exchanging small amounts of data over short periods of time. We shall discuss the communication differences between Bluetooth Classic and Bluetooth Low Energy in detail below.
Under Bluetooth Classic, when two or more devices want to talk to each other, then they always need to pair first (although pairing does happen when two devices communicate over Bluetooth Low Energy too, however; it is not mandatory in the case of BLE). Once the pairing has succeeded, an ad hoc network is established also known as the piconet:
Figure 3: A master-slave piconet; source: https://goo.gl/O9tgEB
A piconet can consist of a single master and up to seven slave devices. The devices can switch role by agreement (a slave can become a master at a later stage during the timeline of communication). Although a master can have up to seven slaves, at any point in time the master is addressing a single slave and the slave is supposed to listen when this happens. Also, it is important to note that being a slave to more than one master is certainly possible. This often results in interconnected piconets, also known as a scatternet:
Figure 4: A scatternet; source: https://goo.gl/WXixBp
Whether it is piconet or scatternet, the communication channel between the master and slave remains established even if no data is being exchanged and is only terminated when one (or both) of the parties (master/slave) explicitly decides to terminate the connection.
On the other hand, communication over Bluetooth Low Energy can be abstracted away as interacting with a really intelligent database. During this type of communication, each of the devices involved either plays the role of the database (known as peripheral in Bluetooth Low Energy terminology) or a listener (known as central in Bluetooth Low Energy terminology) of that database updates. Whenever new data is available, the database magically notifies all its listeners that new data is available to use. This magic takes place via something known as Indications and Notifications which we shall elaborate on in an upcoming section:
Figure 5: Bluetooth Low Energy communication; source: learn.adafruit.com
Before moving on to rest of the differences between Bluetooth Low Energy and Bluetooth Classic (also known as Bluetooth BR/EDR), let's first discuss a few terms, the understanding of which is absolutely critical for the discussion ahead:
Both Bluetooth Classic (BR/EDR) and Bluetooth Low Energy operate in the 2400-2483.5 MHz range within the ISM 2.4 GHz frequency band. However, data exchange in Bluetooth Classic happens over one of the 79 designated channels, as opposed to that of Bluetooth Low Energy where the number of designated channels is 40:
Figure 6: RF spectrum for Bluetooth and BLE
The core technical specifications of Bluetooth Classic and Bluetooth Low Energy are tabulated as follows:
Technical specifications | Bluetooth Low Energy | Bluetooth Classic |
Power consumption | Rated power Consumption of 0.01 to 0.5 W |
Rated power consumption of 1 W
|
Data rate and throughput | Physical data rate is 1 MBit/s with an effective application data throughput of 0.3 MBit/s
| Physical data rate is 1-3 MBit/s with an effective application data throughput of 2.1 MBit/s
|
Latency (from a non-connected state)
| 6 ms | 100 ms |
Voice capable
| No | Yes |
Distance/range (theoretical max.)
| >100 m | 100 m |
Pairing mandatory | No | Yes |
Frequency (GHz) | 2.4 | 2.4 |
Active slaves
| Up to 7 | Undefined and implementation dependent |
Security | 128-bit AES and application layer user defined
| 56/128-bit and application layer user defined
|
Network topology | Point-to-point and Star | Piconet, scatternet, and point-to-point |
Frequency channels | 40 | 79 |
Minimum total time to send data (det. battery life)
| 3 ms | 100 ms |
Current consumption | <15 mA | <30 mA |
Logo |
The architecture of Bluetooth Low Energy is divided into three important layers:
Refer to the following figure:
Figure 9: Bluetooth Low Energy architecture
We shall touch on every segment/layer briefly before delving deeper into each of the layers.
We will develop multiple applications for several IoT and Bluetooth Low Energy use cases throughout the course of this book and these applications will be hosted in the application layer of a Bluetooth Low Energy compatible device. This is the layer which will contain the user interface, application logic, and the overall application architecture.
A working knowledge of this layer is necessary to start building Bluetooth Low Energy oriented applications. However, it is always good to know what goes under the hood and how our application talks to the underlying Bluetooth Low Energy hardware/chipset; hence, we will also explore the host and the controller layers.
Lying just the following Application layer is the Host layer, which has the following layers:
Next, the protocol also defines various read and write operations for attributes also known as ATT operations:
All in all, Attribute Protocol is just a set of rules related to accessing data. Don't worry if you don't understand the significance of it at this stage. We will be covering the significance of these characteristics/attributes and related operations in the upcoming sections:
The Host layer defines three very important specifications, that is, characteristics, services, and profiles, which help Bluetooth Low Energy devices to discover, identify, and talk to each other.
It really can't be stressed enough that a thorough understanding of these three specifications is absolutely imperative to design robust Bluetooth Low Energy oriented applications. We will go over each of these in detail, right after we have briefly touched on the controller layer.
Simply speaking, the controller is the actual Bluetooth chip or hardware, which facilitates transmission and receipt of Bluetooth signals:
Figure 10: TI CC2540 Bluetooth Low Energy SoC
It consists of the Link Layer and the Physical Layer. As the name already suggests, the Physical layer consists of all the complex analog circuits, which transmit and receive the digital data over the air. The Link Layer, on the other hand, is responsible for scanning, advertising, creating, and maintaining links (connections) between devices. The link layer can have five states: Standby, Advertising, Scanning, Initiating, and Connection (master- slave):
Figure 11: Link Layer States, source: www.bluetooth.com
Delving deeper into the three main pillars of the Bluetooth Low Energy technology should have already given you an idea of what lies under the hood. Now, as promised, let's discuss the important specifications defined by the Host layer, starting with profiles.
Profile, in a generic sense as a verb, means to describe, and that is what actually Bluetooth Low Energy Profiles are. In a nutshell, A Bluetooth Low Energy Profile is a description of the behavior of a Bluetooth Low Energy device, and it is also an answer to questions like "What is the purpose of this device?" or "What can this device do?"
Perhaps, a conversation between a company executive and the software development team lead revolving around a Bluetooth Low Energy device will give you an idea of the importance of profiles for Bluetooth Low Energy devices:
Healthcare Company Executive: "We want to roll out a new series of health devices for recording and monitoring a user's blood pressure"
Software Development Lead: "Ok, sure. Do you have some specifics in mind about this device?"
Healthcare Company Executive: "Yes, this will be a small handheld device which can diagnose, record user's blood pressure and send the readings to an app installed on the user's smartphone. The app will then upload the data to our servers to be made available to the doctor for diagnosis."
Software Development Lead: "Since this is an on-demand connectivity device; that is, the user only has to connect to the smartphone to transfer the data; hence this can be built into a low power consumption device which uses Bluetooth Low Energy as a mode of communication with the smartphone. Also, the device will support Blood Pressure Profile to be recognized as a healthcare device, which can process blood pressure data."
After the decision committee has reached a conclusion:
Software Development Lead to Developers: "Our company is rolling out a Bluetooth Low Energy based medical device supporting Blood Pressure Profile and we need to write an app for that. More details in tomorrow's meeting. Please come prepared for the meeting."
Our seasoned developer, developing a newer profile, will now head over to the Bluetooth SIG website to read the specification about the Blood Pressure Profile in preparation for the upcoming meeting.
For more information regarding profiles at Bluetooth SIG visit: https://www.bluetooth.com/specifications/adopted-specifications#gattspec and for Blood Pressure Profile visit: https://goo.gl/jVcB0n.
This is a very real example of an ideal IoT+BLE use case and devices like these already exist fulfilling similar use cases.
To know more about a popular blood pressure meter visit: http://www.welltec-usa.com/welltec-idt-products-blood-pressure-BLE.html. Also, a popular blood glucose meter can be found at: https://www.accu-chek.com/meters/aviva-connect-meter.
The preceding discussion might already have given you some vague idea regarding what a profile actually is and how it matters for a Bluetooth Low Energy device. To solidify it to some extent, here is a popular visualization of a profile:
Figure 12: Bluetooth Low Energy Profile
As the diagram shows, the profile dictates what services each profile hosts and, before delving deeper into that, we would request you please go over the Blood Pressure Profile description document available at the link provided previously, since, not only will it give you a better understanding of what we just discussed, but it will also be very helpful in what we are about to discuss. Don't worry if you don't understand everything there (and in the preceding diagram) at once, as we will be delving much deeper into services and other acronyms, which might be puzzling you at this stage.
Going over the Blood Pressure Profile description document, a few things would have jumped out at you right off the bat:
If you recall, this is exactly what we discussed when we went over the Host layer and briefly touched upon the role of the GATT profile. We are now seeing glucose profile building upon GATT and defining individual device roles for a connection to be established between two devices.
The Profile document also dictates what kind of services the sensor will contain by mentioning the following:
That exactly maps up if you look closely at the Profile diagram. The Blood Pressure Profile is already dictating the kind of services it will contain. And this brings us to the question, "What exactly are Services?", which will be our next topic of discussion.
Extending further from the previous section, we saw that the GATT profile imposes a client–server architecture to facilitate the communication between Bluetooth Low Energy devices (the sensor and the collector) and Bluetooth Low Energy technology. Following a service-oriented architecture, the blood pressure sensor (or any other Bluetooth Low Energy device playing a GATT Server role) exposes some services.
Remember, how we compared Bluetooth Low Energy to a very intelligent database in the previous section, and that is exactly what is happening here. The primary reason for the existence of a blood pressure device sensor (or any other Bluetooth Low Energy sensor/device) is extremely simple. It measures the correct data (blood pressure levels in this case), stores it, and then makes the data available when requested by a client. A service is a wrapper on top of this data (this data is also known as characteristics and more on characteristics later). Similar kinds of data or characteristics are bundled together in a single service. This is a key factor in understanding the design of services, which exist to bundle similar kinds of data together. Perhaps an example will provide further clarity to this. The Blood Pressure Profile indicated the existence of two kinds of services:
Figure 13: Services in a Blood Pressure Profile
Did you notice how each service consists of different kinds of data, which is similarly pertaining to itself? If you want to get blood pressure data, you should go and interrogate the blood pressure service and if you need information about the device itself, then you should go and talk to the device service. This is the primary reason for the existence of services. We had already established in the previous section that a profile can have multiple services. Like Bluetooth profiles, the Bluetooth SIG defines a number of official services.
Visit https://www.bluetooth.com/specifications/gatt/services for more insight on service definitions by bluetooth SIG.
Each official service is assigned a unique 16-bit UUID so that it can distinguish itself from others; for example, a blood pressure service has a UUID of 0x1810 and a device information service has a UUID of 0x180A. You can also write your own custom service for a specific purpose, but then it will need to have a 128-bit custom UUID.
Once again, I will strongly advise you to go over the relevant documentation of Blood Pressure Service and Device Information Service. Not only will this be very helpful in the discussion ahead, it will also clarify the information indicated in the preceding diagram.
For further reading on Blood Pressure Service, please visit: https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.blood_pressure.xml. For further reading on Device Information Service, please visit: https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.device_information.xml
The documents outline what characteristics each of the services contain or what information can be found on interrogating relevant services. For example, the blood pressure service contains three distinct characteristics:
The documentation also indicates what kind of data each characteristic holds; for example, the Blood Pressure Feature characteristic is used to describe the supported features of the blood pressure sensor. And by that, we have already started touching base on characteristics which deserve a topic of their own.
Characteristics are the lowest and the most important echelon of the Bluetooth Low Energy technology. Encapsulated by a related service, these are the actual state variables, each of which stores a single piece of relevant measurement and information data:
Figure 14: Relationship of Characteristics, Service, and Profile
Just like services, these have a UUID, which can be 16-bit or 128-bit based, depending on whether a characteristic has a standard or custom definition. For example, the blood glucose measurement characteristic has a UUID of 0x2A35. Also, just like services, a manufacturer is free to define custom characteristics of only his/her software, but to facilitate maximum interoperability between Bluetooth Low Energy devices, it is always better to follow the definition of standard characteristics. Bluetooth SIG defines a list of standard Bluetooth Low Energy characteristics here.
To get a list of standard Bluetooth Low Energy characteristics, visit https://www.bluetooth.com/specifications/gatt/characteristics.
It is worthwhile taking a look at the collection of characteristics exposed by the Blood Pressure Service.
To know more about characteristics and their descriptors in a blood pressure measurement service, visit https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.blood_pressure.xml.
Remember how we previously discussed that we can abstract Bluetooth Low Energy as an intelligent database. To build all that intelligence, characteristics bundle much more than a single value. Although the value is of prime importance, it is important to understand what makes this intelligent database magical.
Each characteristic as a whole comprises the following:
These properties are essentially the guidelines for how clients can interact with this characteristic and also, how they can subscribe (listen) to indications and/or notifications of this characteristic. We will see how the indications and notifications can be enabled in the next section.
To know more about packaging of data in a blood pressure measurement visit https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.blood_pressure_measurement.xml.
For a list of GATT descriptors, you can proceed to visit https://www.bluetooth.com/specifications/gatt/descriptors.
For an insight into descriptors included in a blood pressure measurement visit https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.blood_pressure.xml.
For CCCD specification details included in a blood pressure measurement visit https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.descriptor.gatt.client_characteristic_configuration.xml.
The specification for a characteristic user description descriptor is available at https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.descriptor.gatt.characteristic_user_description.xml.
The specification for a extended properties descriptor is available at https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.descriptor.gatt.characteristic_extended_properties.xml.
Starting with Profiles, we finally covered the lowermost echelon of the Bluetooth Low Energy communication, the characteristic. We saw that it is not just as simple as reading and writing to/from a characteristic. We also touched upon the magic of indications and notifications upon which the whole Bluetooth Low Energy communication relies heavily and, hence, they deserve a topic of their own.
We briefly touched upon indications and notifications in the previous section. Indications and notifications basically are server (GATT) side updates to a client. A client has to configure Indications and Notifications for a characteristic's value through its client characteristic configuration descriptor to get notified every time a characteristic's value gets updated on the server:
Figure 15: Indications versus notifications
As shown in the preceding figure:
Indications and Notifications are a very important mechanism for receiving server-side data probably due to the fact that they are the only and fastest mechanism for receiving asynchronous server-side updates. Since Bluetooth Low Energy was designed to be energy efficient, this asynchronous method of receiving updates prevents continuous polling of the server by the client and, hence, is a huge energy saver too.
The retail market for connected things is projected to have a worth of 53.75 billion by 2022 and Bluetooth Low Energy is forecast to witness a substantial growth with a CAGR of over 25% during the forecast period.
For more extensive reading on the study conducted on the growth of the retail market of connected things, visit https://iotbusinessnews.com/2016/03/16/57411-connected-retail-market-worth-53-75-billion-usd-by-2022/.
In other words, this makes Bluetooth Low Energy a significant driver for this forecast growth and technology to be taken seriously. Bluetooth SIG is leaving no stone unturned to make the existing Bluetooth Low Energy technology a better fit for IoT Applications. The SIG recently finalized and released the specification for Bluetooth 5, which takes the existing technology to the next level by enabling quadrupled range, twice the speed and increasing the data broadcasting capacity by 800%. These new features are specifically focused on Internet of Things technology.
You can find the press release by SIG (Bluetooth Special Interest Group) for Bluetooth 5 at https://www.bluetooth.com/news/pressreleases/2016/06/16/-bluetooth5-quadruples-rangedoubles-speedincreases-data-broadcasting-capacity-by-800.
However, MCUs supporting Bluetooth Low Energy 5 like the one shown here are already available:
Figure 16: CC2640R2F MCU supporting Bluetooth Low Energy 5
Bluetooth 5 is a new standard, which has been rolled out very recently (from the end of 2016 to the beginning of 2017). For the consumers, it may take some time to feel the difference between the older Bluetooth Low Energy 4.2 versus the Bluetooth Low Energy 5 as various device manufacturers will adopt this standard and manufacture Bluetooth Low Energy 5 compatible devices, which will then hit the market and eventually end up in the hands of the consumers. As of the writing of this book, Samsung has already taken the lead and has released Galaxy S8 worldwide during the period towards the end of April and beginning of May 2017, which is the first smartphone to support and an early adopter of Bluetooth Low Energy 5. However, another key update, which is not immediately included in the Bluetooth Low Energy 5 standard is the specification for Mesh Networking. It is still said to be in works and probably will arrive early next year. This update for Bluetooth Low Energy is crucial for the IoT paradigm as it can enable data to be transferred across even greater distances just via Bluetooth Low Energy nodes/hubs. We shall briefly touch upon Mesh Networking to see how this is possible.
Traditional Bluetooth Low Energy network topology looks something similar to the star topology such as shown in the following diagram:
Figure 17: A traditional Bluetooth Low Energy network star topology; source: www.wikipedia.com
Here, one device acts as the server and others access information (characteristics) from the server, if and when required. It goes without saying that this is the traditional way of communication, and it limits the networking capabilities in terms of the following:
The preceding factors mentioned can severely limit an IoT-based solution.
The solution to this is the eagerly awaited mesh networking update, intended to transforming each individual Bluetooth Low Energy node to a hub, where the node/hub can also transfer data to the nearby devices. This will change the network topology from a traditional star network to a Mesh as shown as follows:
Figure 18: A mesh topology; source: www.wikipedia.com
This means each node of the network can accept and forward data to a neighboring node, allowing a network to scale more easily by just adding new nodes. A mesh network exhibits the following characteristics:
Another pre-existing piece of hardware technology, which is greatly going to benefit with Bluetooth Low Energy 5 is Beacons. Beacons are small sized, Bluetooth Low Energy devices which broadcast information:
Figure 19: Beacons from various vendors; source: www.wikipedia.com
Bluetooth Low Energy Beacons are primarily used for proximity broadcasting or advertising. A very popular use case of beacons is to broadcast/advertise contextual information to nearby smartphones and handheld devices, which support Bluetooth Low Energy, in close proximity. The context of the information can be bus updates on a bus stop, new products in a store, or special delicacies available at a restaurant.
The other uses of Beacons include:
There are already various preprogrammed beacons and respective development kits available in the market.
For an insight about Estimote Beacons, please visit https://estimote.com/.
However, later in the course of this book, we will take the road less traveled and create a beacon of our own using a Raspberry Pi. Also, we shall discuss the two primary Beacon protocols namely, Eddystone and iBeacon.
Phew! We covered a lot of ground in this chapter, which although substantial is still just the tip of the iceberg. However, I feel pretty confident in saying that you as a reader should now be familiar with the answers to the following questions, which we asked before starting this chapter:
Apart from delving deeper to answer these questions, we also briefly touched upon the advent of the latest Bluetooth Low Energy 5 specification and how it is going to help IoT to reach new levels of connectivity and data exchange between devices. Furthermore, we also scratched the surface of Mesh Networking and Beacons.
With all this theory under our belt, we are now going to apply it to gain hands-on knowledge over the course of this book. Going ahead, we will be setting up our development environment, sniffing a fit-bit device, brewing our very own homemade beacons, designing a personnel tracking system using iTags, and we'll then bring it all together by building a complete warehouse monitoring system. So put on your seat belts, here we go.
Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.
If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.
Please Note: Packt eBooks are non-returnable and non-refundable.
Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:
If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:
Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.
You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.
Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.
When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.
For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.