In the simplest case GLCT is run by a single call to the function GpsRun(). This is a blocking call which returns only upon exit of the GLCT. After initialization the GLCT enters an execution loop in which it repeatedly calls GpsHalWaitForEvent(). This is a platform dependent function which the customer must implement. The function is expected to suspend (using whatever mechanism exists in the platform) and return when there is an event for the GLCT to process. The function populates a structure of type GPSCTRL_EVENT containing details of the event. When GLCT is finished processing the event it will again call GpsHalWaitForEvent(), unless the event itself caused the GLCT to exit.
This execution model for the GLCT is intended for a software architecture where a dedicated task exists for calling GLCT. The blocking nature of GpsRun() is acceptable because no other software functions share the task. The task will suspend each time GpsHalWaitForEvent() is called, using the platform specific mechanism implemented by the customer. If a dedicated task implementation is not suitable the application can utilize an alternative interfaces to the GLCT that does not involve any blocking calls. This is described next.
If there is not a dedicated task for the GLCT the function GpsRun() should not be used and the application does not need to include an implementation of GpsHalWaitForEvent(). Instead the application should make use three separate function calls to the GLCT. The first is CreateGpsController() which the application calls once to initialize the GLCT. The second is DisposeController() which is called at the end of execution to clean up the GLCT. The third function is GlctProcessHallEvent(). This function should be called each time an event occurs which requires processing by the GLCT. All three function calls are non-blocking, that is they perform whatever calculations are needed, invoke necessary callbacks, and then immediately return.
The call to GlctProcessHallEvent() passes event information to the GLCT within a structure of type GPSCTRL_EVENT. This is the same structure returned by GpsHalWaitForEvent() in the case when GpsRun() is used.
The rest of the discussion belows focuses on the basic operation of the GLCT using GpsRun().
The GLCT is configured by means of an XML-formatted string that is passed to either GpsRun() (or, alternatively, to CreateGpsController()). The string contains configurations related to core GPS positioning as well as configurations related to the platform. These platform specific settings are passed onto the HAL layer via GpsHalSetCfgValue().
The definition of the XML strings is provided in gpsconfig.xml. In addition, existing configuration files can conveniently be viewed and edited with a standard text editor.
The GLCT can be controlled in two ways. The first method is for an application to send ASCII commands to start and stop the GPS positioning function. These major commands include IRM Commands.
Alternatively, the GLCT can be controlled by job files, which are included in the XML configuration string. The following configuration file is an example of the simplest and most commonly used job file:
<job id="normal"> <task> <req_pos /> </task> </job>
This string instructs the library to run continuous GPS positioning upon startup. The positioning runs forever, until the GLCT is terminated by the $pglirm,stop command.
More complex files can be created. Their main purpose is facilitate engineering test of the GPS. For example, a job can be defined to perform a sequence of "cold starts" to determine gather statistics on time to first fix. Broadcom can provides configuration files defining jobs that allow the application to exercise a basic set of GPS performance tests.
For more information on how to define job files please see GL XML Config file description.
When the GLCT is commanded by the interactive command or job files, positioning output is delivered as ASCII strings, compliant to the National Marine Electronics Association (NMEA) format. The sentences containing position, velocity and satellite information outputs. Definitions of these sentences are provided in NMEA messages supported by GLL.
The NMEA sentences are delivered to the application via the function GpsHalNmeaWrite(). The customer creates an implementation of this function suitable for receiving data in their software architecture. The functions GpsHalNmeaOpen() is called by the library before the first NMEA sentence associated with a request is provided and the function GpsHalNmeaClose()is called when the request ends.
The GLCT interfaces with applications by means of an Application Request Processor (ARP). For example, the interactive commands described above are processed by the Interactive Application Request Processor. The interface between an ARP and the GLCT is quite straightforward and can easily be used to interface any sort of application.
As described, the GLCT receives events through GpsHalWaitForEvent(). Specific events are reserved for additional applications, for example the event type GLCTEV_PAL_APP1_DATA indicates an event destined for the first additional application.
The GLCT receives the event and then passes it to an event handler which is written for the application. The event handler makes use of the GLCT APIs to interact with the GLCT. Since the event handler is called by the GLCT, it runs as part of the GPS task, allowing it to make API calls. All interprocess communication between an application running in an different task occurs via the customer-implemented interprocess communication within GpsHalWaitForEvent().
The GLCT API calls available to the event handler allow it to begin position fixes and receive results. In addition, APIs calls exist to provide assistance data and to query assistance data status. Broadcom supplies an example of an assisted GPS application that uses RRC formatted messages communicating to a Spirent ULTS/ADS system.