http://ion.le.ac.uk/~jth/kallisto/programming.htmProgrammingThe following sections give information on how to program the Kallisto card. Some utility programs are supplied with the unit, but most applications will require some programming given the specialised nature of accurate timing. The Rockwell Jupiter programming manual is also supplied, but some concepts will be outlined here to familarise the programmer with the card.
The block diagram above shows the main sections of the Kallisto card. The Jupiter receiver tracks the satellites and provides position and time information over the serial link. The UART converts the serial data and makes it available to the PC's bus. The receiver also generates a 1 pulse per second (1pps) signal, whose rising edge is synchronised to the second boundary. The control logic turns this signal into a hardware interrupt generated every second. The 1 pps signal is also buffered to two hardware outputs - as a raw signal, and qualified with a software register within the control logic. The qualified signal is only active when the appropriate control bit is set. There are three other hardware outputs: two uncommitted signals whose state is determined by two bits of the control register and a 10kHz signal locked to GPS time. (There are exactly 10,000 pulses per GPS defined second) Serial LinkThe Jupiter receiver can provide quite complex information about position, time, speed, satellite location etc and full details are given in the accompanying Rockwell Jupiter programming manual. Obtaining the time, however, is quite simple. The serial link can be set to either provide data in Rockwell binary format or ASCII NMEA format. (See Jumper settings in the installation guide) NMEA mode sets the link to 4800 baud, binary mode sets it 9600 baud. NMEA is a GPS industry standard and is useful if you have existing GPS software. It can also be useful as part of a simple board confidence test by using a terminal emulator program to read the data stream. A set of ASCII parameters, all starting with a $ symbol, should be printed every second. Binary mode provides more information from the receiver and is probably easier to program since string handling is avoided. The following discussion assumes binary mode. Note: there is no provision for either hardware or software flow control over the serial link. Your application must be able to receive the data at the rate it is transmitted. The modem control lines DCS, DSR and DTR are physically connected to each other, as are CTS and RTS. Unless the receiver is otherwise programmed, it generates a 55 word (110 bytes) packet every second. This packet, called message 1000, is one of 13 output messages. The remaining 12 messages are only transmitted upon request (except for message 1011 which is sent once at power up/reset). To determine UTC time and position simply set your serial software to capture message 1000 into a buffer and then decode the contents of the buffer. The Rockwell manual fully describes the contents of the message. The UTC time recorded in the message is the time of the next 1 pps edge. Your software should check that the Number of Measurements Used in Solution field returns a value of 4 or more and that the Solution Invalid field returns 0 before the time and position are assumed to be accurate. If your application only requires time resolution to one second you only need to decode the message packet. If, however, you require greater accuracy you should activate the 1 pps hardware interrupt. The interrupt will occur within one microsecond of the UTC second boundary, the exact time of this interrupt being denoted by the time given in the last received message 1000 packet. Your 1 pps interrupt service routine will then perform its task at a precisely determined time (within the constraints of other system interrupts/tasks). For example, an accurate system clock can be created by reading in the time once from message 1000 into a variable, and then incrementing this variable within the 1 pps interrupt service routine. Most multitasking and or real time operating systems already provide interrupt driven drivers to read serial ports, so reading the serial data stream is simply a question of making calls to the correct driver. Windows 3.1 and Windows 95 also provide serial drivers whose parameters are set up in the appropriate control panel. The relevant Windows programming documentation should be consulted for further information. MS-DOS programmers have a harder task in so far as they have to provide their own software to read the serial port. If your application is reasonably simple BIOS calls can be made to read the port. (Usually called _bios_serialcom() by most C compilers) More demanding applications will need an interrupt driven driver. The book "C Programmer's Guide to Serial Communications" by Joe Campbell, published by SAMS, ISBN0-672-22584-0, gives a useful introduction to the subject. The source code provided with Rockwell's Labmon software also give an example of how to communicate with the UART. |
