GPS

Global Positioning System (GPS) is a satellite-based navigation system that sends and receives radio signals. A GPS receiver acquires these signals and provides you with information. Using GPS technology, you can determine location, velocity, and time, 24 hours a day, in any weather conditions anywhere in the world—for free.
GPS technology requires the following three segments:

• Space segment
• Control segment
• User segment

Space Segment
At least 24 GPS satellites orbit the earth twice a day in a specific pattern. They travel at approximately 7,000 miles per hour about 12,000 miles above the earth’s surface. These satellites are spaced so that a GPS receiver anywhere in the world can receive signals from at least four of them.
Each GPS satellite constantly sends coded radio signals (known as pseudorandom code) to the earth.
Control Segment
The control segment is responsible for constantly monitoring satellite health, signal integrity, and orbital configuration from the ground. The control segment includes the following sections:

• Master control station
• Monitor stations
• Ground antennas

User Segment
The GPS user segment consists of your GPS receiver. Your receiver collects and processes signals from the GPS satellites that are in view and then uses that information to determine and display your location, speed, time, and so forth. Your GPS receiver does not transmit any information back to the satellites.
The Global Positioning System (GPS), formally known as the NAVSTAR (Navigation Satellite Timing and Ranging), originally was made up of a network of 24 satellites placed into orbit by the U.S. Department of Defense. GPS was originally intended for military applications, but in the 1980s, because of its popular navigation capabilities and because you can access GPS technology using small, inexpensive equipment, the government made the system available for civilian use.
For example, Now there are a several of car that using GPS tracking. It have a function to monitoring of car location or car movement. Many parents was installed GPS tracking on their car or their child car. They installed it to monitor their child driving habits and know where they’ve been going. Another application of GPS tracking was used in car company who have a large number of vehicles. GPS Vehicle tracking systems prove beneficial in supplying current and historical data on routes taken by all their drivers whenever they are in motion. Company who distribute a lot of car from manufacturing plant into showroom will be install this tools to monitoring about their cars. They not want that in someday will lost their cars. This will give a greater loss than if they install this equipment in transportation unit.

What’s Brew ………?

First of all, BREW™ is an acronym that stands for Binary Runtime Environment for Wireless. From a software developer's perspective, Qualcomm®'s BREW can be viewed as:

1. A set of APIs that enable developers to create software applications for wireless devices (wireless phones for now), and
2. A means of selling and delivering applications to end-users.

On the phone itself, BREW is a thin client (about 150K) that sits between a software application and the Application Specific Integrated Circuit (ASIC) level software. Thus developers can write to BREW without knowing or caring about the device's chipset or air interface. While it's true that CDMA is Qualcomm's specialty, BREW is equally capable of running on devices that employ other air interface standards. Figure 1 shows the conceptual layering of software on a wireless device.

The BREW Shop lets users browse the carrier's Application Download Server to see what applications are available for purchase or trial. The entire transaction is completed over the air. The carrier generates a billing record for each purchase and a corresponding charge appears on the subscriber's monthly phone bill.

The carrier retains any retail markup and shares 20% of the application's wholesale price with Qualcomm. The remaining 80% of the wholesale price flows to the developer.

Developing BREW Applications

BREW applications can be written using Java™, C, or C++. At the 2002 BREW Developers Conference, held in early June in San Diego, IBM® and Insignia® demonstrated Java Virtual Machines for BREW. Hewlett Packard® (HP) has also ported its MicrochaiVM™ to BREW. IBM will offer a BREW development plug-in with its WebSphere Studio Device Developer™ product.

This series of articles will focus on C and C++ development for BREW, as supported by the freely available BREW SDK. Note that there are presently 3 versions of the SDK available: 1.0, 1.1, and 2.0. Each SDK version is paired with a corresponding Application Execution Environment (AEE) on the phone. Applications written using the 1.0 SDK will run on phones equipped with later versions of the AEE. The converse is not necessarily true since each successive version incorporates new capabilities.

Since the provision of BREW updates for existing phones is unlikely, maintaining compatibility with version 1.0 is advisable if you want to maximize the size of your target market. Nonetheless, versions 1.1 and, particularly, 2.0 do offer significant incremental functionality. To learn more about the differences, download the 1.0 SDK and flip through the API Reference (754 pages). Then follow the 1.1 and 2.0 "What's new" links from the download page.

While it's true that the SDK is free of charge, the developer must have at least version 6.0 of Microsoft Visual C++™ in order to develop and test applications using the BREW Emulator™ supplied with the SDK. The emulator is a Windows™ program that simulates the AEE on a phone. An application runs on the emulator as a Windows .dll. The emulator is a good tool for learning the APIs and testing an application throughout the development process. Be forewarned that there are significant differences between the emulator environment and the phone itself. Developers should incorporate actual hardware and frequent native builds early in the development process, in order to avoid convoluted debugging issues down the line.

When a developer decides to take the leap and commence commercial development, several additional costs must be incurred at various stages of the project. First of all, in order to gain access to tools fundamental to development on actual hardware, the developer must be authenticated. In essence, developer authentication involves an outlay of $400 for a Verisign Authentic Document Digital ID™, good for one year from date of purchase or the digital notarization of 100 applications, whichever comes first.

Authentication gives the developer access to the BREW Developer Extranet™ where several important tools can be accessed and/or downloaded. For example, the BREW ClassID Generator™ assures the provision of a unique, 32 bit ID for each application. The BREW TestSig Generator™ provides a digital signature that allows a developer to test an application on actual hardware. Additionally, the BREW AppLoader™ downloads applications onto phones.

Beyond authentication, there are other costs. The CPU used in BREW phones is currently an ARM7TDMI®. Since C and C++ applications run natively on the device, an ARM® compiler is required. Qualcomm presently supports ARM BREW Builder™ ($1,500), ARM Developer Suite (ADS) 1.0.1™, ADS1.1™, and possibly ADS1.2™. Given that ADS1.2 costs $5,500 for a node-locked license and $6,500 for a floating license, the $1,500 price tag for BREW Builder looks like a steal of a deal! A free, 45-day, evaluation version of ADS1.2 is available.

The developer will also need a BREW phone for testing applications. Presently only 2 models are commercially available: the Sharp® Z800™ ($399.99 from Verizon Wireless®) and the Kyocera® QCP3035e (price unavailable, though certainly less than the Z800). Note that both of these phones have version 1.0 of the AEE, thus applications targeting these devices must be developed using version 1.0 of the SDK. Three new phones, equipped with version 1.1 of the AEE and a CDMA 1x air interface, are due to hit the market as early as September 2002. Pricing information is currently unavailable. Phones with version 2.0 of the AEE are expected late in 2002 or early in 2003.

As shown by Figure 2, TRUE BREW™ certification testing, conducted by NSTL™, represents another potentially significant cost for the developer. An application must pass TRUE BREW certification before a carrier will make it available on their network. Certification aims to ensure that carriers' networks remain free of viruses and malicious or unstable applications.

 

Getting to Profit

Once the developer has cleared TRUE BREW certification, a pricing plan must be negotiated with the carrier via a virtual marketplace maintained by Qualcomm. The plan involves several decisions, including the wholesale price per download as well as the type of license to grant to the end user.

Developers can choose to sell the application to end-users, charge a monthly subscription fee, or provide a free demo. When the sell option is chosen, the developer must further decide if the license is based upon a specified number of uses (an unlimited number is an option), an expiration date, a specified number of days of availability, or a fixed number of minutes of actual use. Demo options include 1-5 uses, 1-10 minutes of use, and 1-24 hours of elapsed time on the handset.

Once the developer and a carrier have agreed on a pricing plan, the carrier can make the application available to consumers by adding it to the BREW Shop catalog accessible from the handset.

Conclusion

Chipset independence, integrated distribution and billing features, and direct carrier involvement differentiate BREW from other wireless development contenders. BREW picks up where most APIs leave off - it provides a path to profit without requiring the developer to independently penetrate the "carrier barrier".