EP1719317A1 - Procedes de localisation par satellite et systemes correspondants installes sur un hote - Google Patents

Procedes de localisation par satellite et systemes correspondants installes sur un hote

Info

Publication number
EP1719317A1
EP1719317A1 EP04709090A EP04709090A EP1719317A1 EP 1719317 A1 EP1719317 A1 EP 1719317A1 EP 04709090 A EP04709090 A EP 04709090A EP 04709090 A EP04709090 A EP 04709090A EP 1719317 A1 EP1719317 A1 EP 1719317A1
Authority
EP
European Patent Office
Prior art keywords
interface
positioning
gps
function
tracker
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP04709090A
Other languages
German (de)
English (en)
Inventor
Clifford Yamamoto
Sebastian Nonis
Ashutosh Pande
Nikola Bulatovic
Stefan Witanis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CSR Technology Inc
Original Assignee
Sirf Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sirf Technology Inc filed Critical Sirf Technology Inc
Publication of EP1719317A1 publication Critical patent/EP1719317A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S19/00—Satellite radio beacon positioning systems; Determining position, velocity or attitude using signals transmitted by such systems
    • G01S19/01—Satellite radio beacon positioning systems transmitting time-stamped messages, e.g. GPS [Global Positioning System], GLONASS [Global Orbiting Navigation Satellite System] or GALILEO
    • G01S19/13—Receivers
    • G01S19/35—Constructional details or hardware or software details of the signal processing chain
    • G01S19/37—Hardware or software details of the signal processing chain
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S19/00—Satellite radio beacon positioning systems; Determining position, velocity or attitude using signals transmitted by such systems
    • G01S19/38—Determining a navigation solution using signals transmitted by a satellite radio beacon positioning system
    • G01S19/39—Determining a navigation solution using signals transmitted by a satellite radio beacon positioning system the satellite radio beacon positioning system transmitting time-stamped messages, e.g. GPS [Global Positioning System], GLONASS [Global Orbiting Navigation Satellite System] or GALILEO
    • G01S19/42—Determining position
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S5/00—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations
    • G01S5/0009—Transmission of position information to remote stations
    • G01S5/0018—Transmission from mobile station to base station
    • G01S5/0036—Transmission from mobile station to base station of measured values, i.e. measurement on mobile and position calculation on base station

Definitions

  • This invention relates to satellite positioning systems.
  • this invention relates to satellite positioning systems implemented utilizing the processing power of a host in communication with a hardware tracker.
  • a host based SPS system may include a host processing system that connects through a tracker hardware interface to a dedicated hardware space vehicle tracker.
  • the host processing system may also include a memory that includes a SPS library having a user interface, positioning engine, a tracker interface and an operating system interface.
  • a processor in the host processing system runs the positioning engine and the functions provided by the interfaces.
  • the tracker hardware interface receives positioning information from the space vehicle tracker. Through functions in the tracker interface, the positioning information is communicated to the positioning engine. In turn, the positioning engine may determine a position and communicate the position to a user application through functions provided in the user interface.
  • Figure 1 illustrates a detailed block diagram of one example of a positioning systems implemented as a host based SPS solution.
  • Figure 2 illustrates a hardware tracker that communicates with the positioning system shown in Figure 1.
  • Figure 3 depicts a hardware and software diagram of a positioning system that includes a GPS library with a user interface, a tracker interface, and an operating system interface.
  • Figure 4 illustrates a flow diagram of a user program running in the positioning system.
  • Figure 5 illustrates a block diagram of the cooperation between threads, tasks and hardware in one implementation of a host based SPS solution.
  • Figure 6 illustrates an execution schedule for a receive manager thread and a periodic navigation task.
  • Figure 7 illustrates a synchronization diagram for the timing and interaction between the threads and tasks shown in Figure 5.
  • a typical satellite positioning system (“SPS”) system has approximately 12 satellites that may be visible at any one time to a wireless device.
  • SPS means any system utilizing satellites and/or land-based communications devices for providing or enabling the determination of a location of the wireless device on the earth, for example but not limited to: the global positioning system (“GPS”) known as NAVSTAR, GLONASS, LORAN, Shoran, Decca, or TACAN.
  • GPS global positioning system
  • FIG. 1 depicts a block diagram of a positioning system 100 suitable for practicing methods and implementing systems consistent with the present invention.
  • the positioning system 100 includes a host 102 and tracker hardware 104.
  • the host 102 includes a central processing unit (“CPU") 106, a hardware tracker interface 110, and a memory 112.
  • the host 102 also includes a secondary storage device 114 (e.g., generally non- volatile memory such as a magnetic disk, flash memory, optical storage, and the like), and a display 116, and an input interface 118 (e.g., a mouse, keyboard, and the like).
  • a secondary storage device 114 e.g., generally non- volatile memory such as a magnetic disk, flash memory, optical storage, and the like
  • an input interface 118 e.g., a mouse, keyboard, and the like.
  • An operating system 120 (e.g., Windows CE, QNX, Palm OS, UNIX, Linux, Windows 2000, NT, XP, or the like) runs in the memory 112.
  • a user program 122 communicates with a SPS library 124 and the operating system 120.
  • the user program 122 thereby receives position information from the GPS library, and may also communicate commands to the SPS library.
  • the user program 122 may be any program that utilizes positioning information, including, as examples, a mapping program, course charter, location aid, and the like.
  • the host 102 connects through the hardware tracker interface 110 and the interface connection 126 to the tracker hardware 104.
  • the hardware tracker interface 110 may be virtually any type of data transfer interface (as examples, a serial, parallel, compact flash, PC Card, or network interface).
  • the interface connection 126 may then be, as examples, a serial cable, parallel cable, or network cable, and may optionally be wireless.
  • the hardware tracker interface 110 is an RS232 port running at 38,400 bps, N-8-1 that communicates up to 2KB of data per second between the host 102 and the tracker hardware 104.
  • the tracker hardware (as illustrated by the reference numeral 128) is more closely incorporated into the host 102.
  • the tracker hardware 128 may be directly coupled to the host 102 address, data, and control buses.
  • the host 102 receives and processes navigation information from the hardware tracker 104, 128 in order to provide the user programs 122 with position information.
  • the CPU 106 may be a microprocessor, microcontroller, application specific integrated circuit ("ASIC"), discrete or a combination of other types of circuits acting as a central processing unit.
  • the memory 112 may be RAM, DRAM, SDRAM, or any other type of read/writeable memory.
  • the tracker hardware 1O4 acquires and tracks SPS satellites and sends raw measurement data to the host 102 for position calculation.
  • the tracker hardware 104 includes an antenna 202 for receiving SPS satellite signals and a radio frequency ("RF") filter 204 for passing the signals to the RF interface circuit 206.
  • the RF interface circuit 206 processes the signals, produces 2-bit Inphase and Quadrature ("I/Q") signals and recovers SPS clocks.
  • the RF interface circuit 206 provides the I/Q signals and SPS clocks to the location processing circuit 208 for digital processing.
  • a reference frequency source 210 e.g., a crystal oscillator
  • RTC real time clock
  • the tracker hardware 104 may be implemented with components available from SiRF Technology, Inc. of San Jose California.
  • the RF interface circuit 206 may be implemented as a GRF2i/LP integrated circuit.
  • the location processing circuit may be implemented, as examples, as a GSP2t integrated circuit or GSP2e integrated circuit.
  • the tracker hardware 104 minimizes the overhead on the host 102 and operating system 120 by keeping low the maximum transmission rate of raw measurements to the host 102 (e.g., one measurement per second).
  • the memory 112 in the host 102 includes a SPS library 124, user programs 122 (e.g., map displaying, map matching, dead reckoning and route calculation programs), and the operating system 120 (which may be a multi-threaded operating system).
  • the SPS library 124 includes a positioning engine 302, a user interface 304, a tracker interface 306, and an operating system interface 308.
  • the user tasks 310 implement device drivers or link directly to the user programs 122, as examples.
  • persistent storage 312 and a real time clock 314 may optionally be provided.
  • the persistent storage 312 may be, as examples, 2 KB of Flash memory, battery backed up RAM or a disk drive.
  • the SPS library 124 may use the RTC in the host 102, the RTC 314, or may operate without an RTC.
  • the user interface 304 is called by the user programs 122 to start and configure the positioning system.
  • the positioning engine 302 calls a function provide by the user program 122 (e.g., GPS_Output) to deliver positioning messages (e.g., position updates and other synchronous and asynchronous data) to the user program 122.
  • the tracker interface 306 provides for communication between the tracker hardware 104 and the host 102 and, to that end, may load and call the operating system 120 serial communication drivers.
  • the operating system interface 308 calls operating syste functions for task scheduling and synchronization, RTC access, and storage access.
  • Figure 4 shows a flow diagram of a user program 122.
  • the user program 122 calls GPS_Start to start the positioning engine 302 (step 402).
  • the user program 122 determines whether to configure the positioning engine 302 (step 404).
  • the program 122 configures the positioning engine 302 by sending a message to the positioning engine 302 using the GPS_Input function, for example (step 406).
  • the program 122 waits for a new position fix (or other information) from the positioning engine 302 (step 408).
  • the positioning engine processes the information, for example, to display or update a map (step 410). If the program 122 continues to run (step 412), processing returns to step 404. Otherwise, the program 122 stops the positioning engine (step 414) and terminates.
  • the positioning engine runs separately and, when new positioning information is available, creates a message for the program 122 (step 416) and sends the message to the program 122 (step 418). Tables 1-5 below show exemplary function calls.
  • Table 6 shows which functions and messages are associated with each interface, while Tables 7-10 set forth files and data types used or referred to in the follow description. Table 6 - Interface Functions and Messages
  • GPS_COMM TRK_Create() GPS_COMM ⁇ TRK_Delete()
  • GPS_COMM " TRK_Read() GPS COMM- TRK_Write()
  • the user or GPS interface includes a GPS control interface and a GPS communication interface.
  • the GPS control Interface functions allow a user program to start and stop the GPS engine using the functions shown in Table 11.
  • the GPS communication interface functions allow a user program to send and receive messages to and from the GPS engine using the functions shown in Table 12.
  • GPS_Start() initializes and starts positioning engine threads and communication interface. This function should be called by user programs to start GPS activity.
  • the GPS_Stop function stops the positioning engine threads and communication interface. This function should be called by the user program to stop GPS activity.
  • the GPS_Output function retrieves a message from positiomng engine. There are no return values. The function is called by the positioning engine whenever any message is sent out. This function is implemented by the v ser program and statically linked with the GPS library.
  • the GPS_Input function sends a command to the GPS engine.
  • Tlxe function may be called by the client program to send a command to the GPS receiver.
  • the GPS communication interface messages are exchanged between the GPS client (e.g., a user program) and positioning or GPS engine via the user interface input and output functions.
  • the GPS client e.g., a user program
  • positioning or GPS engine via the user interface input and output functions.
  • the GPS_NAV_MEASURED_NAVIGATION output message provides ECEF position, velocity, GPS time and position status information.
  • the message is outputted periodically at 1Hz rate.
  • the GPS_NAV_MEASURED_TRACKER output message provides satellite status, azimuth, elevation and C/No information.
  • the message is outputted periodically at 1Hz rate.
  • Table 43 - tGPS_SV_INFO sub-structure Note: To get a real value of the parameter a value from the structure should be multiplied by the scale factor.
  • the GPS_NAV_SW_VERSION output message provides a positioning engine software version string. Message is sent as a reply to the GPS_NAV_POLL_SW_NERSION input message.
  • the GPS_NAV_CLOCK_STATUS output message provides current GPS clock status information. Message is outputted periodically at 1Hz rate or on demand as a reply to GPS_NAV_POLL_CLOCK_STATUS input message.
  • the GPS_NAV_ERROR output message outputs notification, warning, and alert messages.
  • GPS_ADC_ODOMETER_DATA output message provides ADC, odometer and GPIO lines state from tracker. Message is outputted periodically at 1 or 10Hz rate depending on setting used in GPS_Start() function.
  • the analog to digital converter may, for example, take measurements at 50Hz rate and the reported value adcX_avg may be an average of the last 5 samples.
  • the GPS_NAV_COMPLETE output message is sent at the end of the navigation cycle to confirm that the GPS engine has finished a position computation cycle (with or without success). In one implementation, this message is outputted at 1Hz rate.
  • the GPS_NAV_TEXT output message outputs debug and development messages in text format.
  • GPS_NAV_iNITIALIZE input message performs GPS engine re-initialization. Message should be used to perform factory, cold, warm or hot restart.
  • the navigation engine will initiate restart within one second and a default clock offset value is 96250 Hz.
  • a default clock offset value is 96250 Hz.
  • a value of 96250 Hz should be used.
  • TTFF TTFF
  • GPS_NAV_POLL_SW_VERSION input message asks for the software version of the position / GPS library.
  • the software version string may be returned, for example, in a GPS_NAV_S W_VERSION output message via GPS_Output() function.
  • the GPS_NAV_SET_DGPS_SOURCE input message selects a data source for differential (DGPS) corrections.
  • GPS_NAV_POLL_CLOCK_STATUS input message asks for the cunent GPS clock status of the GPS library.
  • the clock status data may be returned in GPS_NAV_CLOCK_STATUS output message via GPS_Output() function.
  • the GPS_NAV_SET_SBAS_PRN input message manually forces PRN for use in SBAS corrections.
  • the Operating System Interface functions are operating system dependent and are implemented in the open source format available from SiRF Technology, Inc.
  • the functions include Thread, mutex and semaphore functions. Permanent storage and RTC functions may be available depending on hardware availability.
  • the OS_Thread_Create() function uses an appropriate operating system service to create a thread.
  • the function is called by the GPS engine at the startup to create all desired threads.
  • a maximum number of desired threads may be specified by a GPS_RTOS_THREAD_MAX define.
  • the OS_Thread_Delete() function uses appropriate OS service to stop a thread and/or to wait for thread to gracefully stop. Function is called by the GPS engine from GPS_Stop() to stop all SiRFNav threads.
  • Thread identifiers and functions may be specified, for example, in the gpsjrtos.h header file.
  • the OS_Thread_Sleep() function uses appropriate OS service to suspend a thread for a given number of milliseconds. Function is called by the GPS engine to suspend current thread temporarily.
  • the OS_Mutex_Create() function uses an operating system service to create a Mutex (mutually exclusive) object, or OS-specific equivalent such as a software critical section. This function is called by the GPS engine at the startup to create all desired mutexes.
  • the maximum number of desired mutexes may be specified by a GPS_RTOS_MUTEX_MAX define.
  • the OS_Mutex_Delete() function uses an operating system service to delete a Mutex object. The function is called by the GPS engine at the stopping procedure to delete all used mutexes.
  • the OS_Mutex_Enter() function uses an operating system service to obtain a Mutex object. This function is called by the GPS engine just before entering into a critical section.
  • the OS_Mutex_Exit() function uses appropriate OS service to release a Mutex object. Function is called by the GPS engine just after leaving from a critical section.
  • the OS_Semaphore_Create() function uses an operating system service to create a Semaphore object.
  • the function is called by the GPS engine at the startup to create all desired semaphores.
  • the maximum number of desired semaphores may specified by a GPS_RTOS_SEM_MAX define.
  • the OS_Semaphore_Delete() function uses an operating system service to delete a Semaphore object. The function is called by the GPS engine at the stopping procedure to delete all used semaphores.
  • the OS_Semaphore_Wait() function uses an operating system service to wait for Semaphore object. Function is called by the GPS threads to wait for events.
  • the OS_Semaphore_Release() function uses appropriate OS service to release a Semaphore object.
  • the function is called by the GPS engine to schedule other thread.
  • the OS_Storage_Open() function uses an operating system or BIOS service to open a non volatile storage system.
  • the function is called by the GPS engine at the startup to open a storage.
  • function may return GPS_RTOS_ERROR.
  • OS_Storage_Close() function uses appropriate OS or BIOS service to close a non volatile storage system. The function is called by the GPS engine at the shut down procedure to close a storage.
  • function may return GPS_RTOS_ERROR.
  • the OS Storage_Write() function uses appropriate OS or BIOS service to write given words to a non volatile storage system (battery backed RAM, file system, etc.).
  • the function is called by the GPS engine periodically, for example every 30 seconds, to save time, position and ephemeris information. That information is used later to speed up the GPS start procedure (e.g., for hot or warm starts).
  • the OS_Storage_WriteAll() function uses an operating system or BIOS service to write a GPS data structure to a nonvolatile storage system.
  • Tbe function is called by the GPS engine periodically, for example every 30 seconds, to save time, position and ephemeris information. That information is used later to speed up the GPS start procedure (hot or warm starts)
  • the OS_Storage_Read() function uses an operating system or BIOS service to read GPS data structure from a nonvolatile storage system.
  • Trie function is called by the GPS engine at the startup to retrieve time, position and ephemeris information. This information is used to speed up the GPS start procedure (e.g., for hot or warm starts).
  • the OS_RTC__Read() function uses an operating system or BIOS service to read a real time clock information from the host's RTC.
  • the function is called periodically by the GPS engine.
  • the tracker communication interface functions allow messages to be sent and received between the tracker hardware and the user programs and position library.
  • the GPS_COMM_TRK_Create() function uses an OS or BIOS service to create a tracker communication handle.
  • the function is called by the GPS engine at the startup to create a communication handle.
  • the GPS_COMM_TRK_Delete() fixnction uses an OS or BIOS service to delete a tracker communication handle.
  • the function is called by the GPS engine at the stopping procedure to delete a communication handler.
  • the GPS_COMM_TRK_Open() function uses an OS or BIOS service to open and configure a tracker communication port. The function is called by the GPS engine at the startup.
  • the GPS_COMM_TRK_Reo ⁇ en() function uses an OS or BIOS service to re-open a tracker communication port.
  • the function is called by the GPS engine after coming back from a power suspend mode. When power suspend mode is not required then the function may return GPS_SUCCESS only.
  • the GPS_COMM_TRK_Close() function uses an OS or BIOS service to close a tracker communication port.
  • the function is called by the GPS engine at the stopping procedure to close the port.
  • the GPS_COMM_TRK_Wait() function uses an OS or BIOS services to wait for data from a tracker communication port.
  • the function is called by tlxe GPS engine to wait for the tracker data.
  • the GPS_COMM_TRK_Read() function uses appropriate OS or BIOS services to read data from a tracker communication port. The function is called by the GPS engine to read tracker data.
  • the GPS_COMM_TRK_Write() function uses appropriate OS or BIOS services to write data to the tracker communication port.
  • the function is called by the GPS engine to send commands to the tracker hardware.
  • FIG. 5 that figure shows a block diagram 500 of the cooperation between threads, tasks and hardware in one implementation of a host b ased GPS solution.
  • the tracker hardware 104 communicates through a serial driver 502 (for example, the Windows CE serial driver).
  • the serial driver 502 communicates and coope-rates with a file system 504 (for example, the Windows CE file system), which includes input buffers and output buffers for the communications that will occur.
  • Figure 5 shows a pass through data flow path to the tracker hardware 10-4.
  • the path includes the SendPassThroughDataToTracker thread 506 that forwards data directly from a client program, tlirough a pass through control function 508 to a tracker interface send function 510.
  • the tracker interface receive function 5 2 forwards data from the tracker hardware 104 to the navigation / positioning engine queue; 514 (if the message is destined for the positioning engine), or to the user interface queue 516 (if the message is destined directly for the user program).
  • the DataForwarder thread 5 18 removes messages from the user interface queue 516 and sends them via the user callback function 520 to the user program.
  • the host 102 includes the Component Obj ect Module interface (available from Microsoft), the user callback function 520 may be thte IcallBack function.
  • the receive manager and navigation thread 522 removes messages destined for the GPS library from the positioning engine queue 514, and also places messages destined for the user programs on the user interface queue 516.
  • the messages for the GPS library are processed by the tasks including the NavPeriodicTask 524.
  • a set of shared buffers, control flags, completion flags, and the like 526 are maintained by the GPS library.
  • the COM interface provides a set of control functions 528.
  • FIG. 6 that figure illustrates one execution schedule 600 for the receive manager thread 522 and the NavPeriodicTask 524.
  • the schedule 600 the NavPeriodicTask 524 runs as a low-priority (background) thread, while the receiver manager and navigation thread 522 run in one normal-priority thread.
  • Figure 7 that figure shows a synchronization diagram 700.
  • the synchronization diagram 700 illustrates the timing and interaction between the threads and tasks shown in Figure 5.
  • receive manager (RxM) and navigation (Nav) run sequentially in one loop that waits for new data from Tracker Interface (TRK_IF) Receiver before each iteration.
  • Either RxM or Nav may signals NavPeriodicTask 524 to proceed with one iteration of its loop (unless NavPeriodicTask 524 already performing its task:, in which case it will finish the task and skip one loop).
  • the RxM and Nav thread 522 may wait on a Critical Section when writing data to the UI Queue 516, or when sending data to Tracker 104. There will typically be a thread running while RxM&Nav are waiting.
  • NavPeriodicTasks .524 runs at smaller priority than the other tasks and it will not run as long as any other thread is running.
  • NavPeriodicTasks 524 runs at normal priority, b»ut does not present a conflict as long as RxM&Nav have sufficient priority to consume data generated by NavPeriodicTasks 524.
  • the RxM and Nav thread 522 runs the RxM control task that maintains a state machine for the Rx and manages the state machine transitions based on cunent state.
  • the RxM communicates with the tracker hardware 104 through the tracker interface. It both sends data and commands to the tracker hardware 104 to pace it through initial acquisition and tracking of SPS satellites, and receives data and status messages from the receiver with raw SPS satellite tracking data.
  • the primary purpose of the RxM task is to manage and control the operation of the tracker hardware 104. It also preprocesses the raw tracker data and submits the processed data to the Navigation Processing Task.
  • the RxM gets scheduled or called by the Nav Task once the tracker hardware 104 starts tracking.
  • the NavPeriodicTasks thread 524 is a pseudo task that peforms miscellaneous support operations for the RxM and Nav tasks. Its functions include determining and performing updates to the satellite state tables, and generating new visible SPS satellite list when new ephemeris data is collected, or whenever it is requested.
  • the Nav Processor Thread performs position, velocity and time computations based on the RxM generated individual SPS satellite data. This makes use of the functionality offered through the navigation library in optimally computing the navigation position data.
  • the computed navigation data is made available to the Data Forwarding thread.
  • the Nav Processor calls or schedules the RxM task to run, and then it performs navigation computations and generates the user position, velocity, and time data. Based on the computation results, if pre-selected enor thresholds are exceeded, the Nav Processor may send commands to the receiver, either directly or through the RxM, to force the receiver to reset.
  • the I/O Reader thread and Tracker Interface Receiver 512 sends data to queues as shown in Figure 5.
  • data length enor checks may be performed with enor counts logged in a global variable. Enoneous message bytes will be reported to the user program through debug messages.
  • the I/O Writer thread 510 is not used. Instead, its role may been taken by TRK_IF, whose methods are invoked from the RxM+Nav thread 522 and SendPassThruDataToTracker 504. TRK F writes directly to the serial port. (All I/O functions will be grouped into one class). In WinCE, buffering is performed on the File System level, which allows TRK_IF to return quickly upon sending data. On Nucleus, additional buffering may be provided. [00106] The DataForwarderThread 518 reads from the UI Queue 516 and calls the user program's ICallBack interface for each binary message to be sent.
  • the DataForwarderThread 518 may continue piping data until the UI queue 516 is empty.
  • the UI Queue 516 is not locked while Callback is being executed, which allows other threads to run while waiting for Callback to return. Client Callback typically puts data in internal storage for another thread to use. Generally, one Callback is called at a time.
  • the UI Queue 516 is prioritized and it will put pass-thru messages before all others in the queue.
  • the SendPassThruDataToTracker function 506 is an API call for sending pass- thru messages from the user program to the fracker hardware 104.
  • the pass through control function 504 may be implemented as a filter to enable or disable pass-thru iraessages.
  • a Shutdown may be performed by purging all queues and I/O. For example, 300ms (enough for RxM&Nav to complete) may then be given for threads to complete. Although some threads may not complete in that time, such as the DataForwarderTTiread 518 (that may be waiting for Callback to return), and NavPeriodicTask 524, for which there may or may not be a provision to interrupt long-term calculations. Regardless, threads which do not complete on time are terminated.
  • the following synchronization objects may be used: a Semaphore and Critical Seciton in UI Queue 516 for triggering UI output, a Semaphore and Critical Section in Trk2Nav Queue 514 for triggering Nav update, a Positioning / Navigation Library sync flag (from NavPeriodTasks to RxM and Nav), and a shutdown semaphore and flag. No»te that the Critical Section(s) in the Tracker Interface are for protecting access to the serial port.
  • Queues may have the following API and features: Constructor/destru-ctor, void *GetBuffer(int priority, long size) to obtain a pre-allocated buffer for Put(), voi ⁇ l Put() to queues the buffer with specified priority, void *BeginGet() to waits until data ready or shutdown, void EndGet(), void Remove(), void Purge() to cancel all BeginGet calls, an internal Semaphore for notifying BeginGet() when data is ready, and an internal Critical Section.
  • enor checking all queue overruns, I/O enors, timeouts and COM enors may optionally be reported to client, packaged in debug messages, UI queue 516 overruns will be reported as an enor to user program, Tracker message time-outs may be handled by Nav, and Trk2Nav Queue 514 overruns may be signaled to RxM and Nav.
  • the Windows registry may provide a mechanism for configuring thread priorities (that may, for example, be set once at startup and remain unchanged during execution), I/O buffer sizes, and queue sizes.
  • the SetupComm() function may be used to increase the size of existing WinCE I/O buffers. Doing so prevents input data loss under stress conditions. This may also be configurable through registry, and default values may be chosen to accommodate several seconds of I/O (e.g., 4kb for input and lkb for output).

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Position Fixing By Use Of Radio Waves (AREA)
  • Navigation (AREA)

Abstract

Les procédés et les systèmes selon la présente invention concernent un système de localisation installé sur un hôte (102). Le système de localisation installé sur un hôte comprend une interface matérielle de poursuite (110) qui se connecte à un suiveur (104) de véhicule spatial matériel spécifique. L'interface matérielle de suiveur reçoit des informations de localisation du suiveur (104) de véhicule spatial. Le système de localisation installé sur un hôte comprend également une mémoire qui contient une bibliothèque GPS (124) dotée d'une interface utilisateur, d'une interface suiveur et d'une interface système d'exploitation. Un processeur (106) exécute les fonctions fournies par les interfaces.
EP04709090A 2004-02-06 2004-02-06 Procedes de localisation par satellite et systemes correspondants installes sur un hote Withdrawn EP1719317A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2004/003535 WO2005086459A1 (fr) 2004-02-06 2004-02-06 Procedes de localisation par satellite et systemes correspondants installes sur un hote

Publications (1)

Publication Number Publication Date
EP1719317A1 true EP1719317A1 (fr) 2006-11-08

Family

ID=34920915

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04709090A Withdrawn EP1719317A1 (fr) 2004-02-06 2004-02-06 Procedes de localisation par satellite et systemes correspondants installes sur un hote

Country Status (2)

Country Link
EP (1) EP1719317A1 (fr)
WO (1) WO2005086459A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005044497B4 (de) * 2005-09-16 2007-07-12 Bury Sp.Z.O.O Navigationsgerät
RU2456630C1 (ru) * 2010-12-30 2012-07-20 Общество с ограниченной ответственностью "СПИРИТ-Телеком" Спутниковый навигационный глонасс/gps/galileo-приемник с корреляторами, асинхронно управляемыми внешним процессором
RU2616970C1 (ru) * 2016-01-27 2017-04-19 Федеральное государственное казенное военное образовательное учреждение высшего образования "Военно-космическая академия имени А.Ф. Можайского" Министерства обороны Российской Федерации Способ обработки сигнала системы ГЛОНАСС с частотным разделением

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5528248A (en) 1994-08-19 1996-06-18 Trimble Navigation, Ltd. Personal digital location assistant including a memory cartridge, a GPS smart antenna and a personal computing device
US5589835A (en) 1994-12-20 1996-12-31 Trimble Navigation Limited Differential GPS receiver system linked by infrared signals
US5832247A (en) 1995-12-28 1998-11-03 Trimble Navigation Limited PCI card for receiving a GPS signal
US6078290A (en) 1998-01-06 2000-06-20 Trimble Navigation Limited User-controlled GPS receiver
US6377891B1 (en) * 1999-02-12 2002-04-23 Trimble Navigation Limited User interface for global positioning system receiver
US6401037B1 (en) 2000-04-10 2002-06-04 Trimble Navigation Limited Integrated position and direction system for determining position of offset feature
US6593878B2 (en) 2001-06-25 2003-07-15 Intel Corporation Integrated network interface card and global positioning system receiver

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005086459A1 *

Also Published As

Publication number Publication date
WO2005086459A1 (fr) 2005-09-15

Similar Documents

Publication Publication Date Title
US8954269B2 (en) Host based satellite positioning systems
US7151489B2 (en) Method and system for multi-function satellite positioning system receivers
EP1425604B1 (fr) Gestion d'energie avancée pour un systeme de localisation par satellite
US5448773A (en) Long life portable global position system receiver
US8094066B2 (en) Method and system for calculating position
US9323314B1 (en) System and method for reducing energy usage in a mobile communications device
US20120021767A1 (en) Updating position assist data on a mobile computing device
JP2011520131A (ja) 低電力センサを使用するｇｐｓ省電力
US20040252049A1 (en) Tracker architecture for GPS systems
JPH11258327A (ja) 分散型ｇｐｓナビゲ―ション・システム
JPH11258326A (ja) ユ―ザ制御のｇｐｓ受信機
BRPI0610377A2 (pt) método para operar um dispositivo eletrÈnico portátil, dispositivo eletrÈnico portátil, e, produto de programa de computador
WO2018052722A9 (fr) Récupération rapide d'un verrouillage entier de phase de porteuse incorrecte
US20070008218A1 (en) Tracker architecture for GPS systems
EP2478390B1 (fr) Procédés et appareils permettant d'affecter l'application d'un modèle de filtrage à l'aide d'une phase de porteuse
JP2023011006A (ja) 衛星電波受信装置、電子時計、測位情報取得制御方法及びプログラム
WO2005086459A1 (fr) Procedes de localisation par satellite et systemes correspondants installes sur un hote
JP3259723B2 (ja) 情報端末および測位方法
JP7032970B2 (ja) 通信システム、通信モジュール、サーバ、制御方法、及び制御プログラム
KR20070015378A (ko) 호스트 기반 위성 위치 확인 방법 및 시스템
EP2881758A1 (fr) Procédé de calcul de position et calculateur de position
US7546395B2 (en) Navagation processing between a tracker hardware device and a computer host based on a satellite positioning solution system
JP2003035763A (ja) 位置算出装置
JP2019158357A (ja) 衛星電波受信装置、電子時計及び測位制御方法
US20230266482A1 (en) Satellite signal receiving device, satellite signal processing device, control method of satellite signal receiving device, and electronic apparatus

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060816

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE IT

RIN1 Information on inventor provided before grant (corrected)

Inventor name: YAMAMOTO, CLIFFORD

Inventor name: PANDE, ASHUTOSH

Inventor name: WITANIS, STEFAN

Inventor name: NONIS, SEBASTIAN

Inventor name: BULATOVIC, NIKOLA

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE IT

17Q First examination report despatched

Effective date: 20071023

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIRF TECHNOLOGY, INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110901