ROC - dual frequency GPS receivers for occultation.DOC

PURDUE UNIVERSITY Jonathan W. Amy Facility for Chemical Instrumentation May 13, 2009 Professor: Dr Jennifer Haase Engineer: James R Zimmerman Project 17292 ROC ­ dual frequency GPS receivers for occultation PURDUE UNIVERSITY Facility   Jonathan   W   Amy Chemical Instrumentation for May 13, 2009 Professor: Haase Project: 17292 Description: ROC – dual frequency GPS receivers for occultation BACKGROUND   This project describes the Jonathan Amy Instrumentation Facility’s (JAFCI) participation in a joint  effort with several collaborators to produce a GPS guided Radio Occultation system used in the  Concordiasi Stratospheric Balloon Campaign The responsibility of the Instrumentation Facility for this project entails the fabrication of two Radio  Occultation system enclosures, each to be deployed in a long duration unmanned aerial vehicle.  Each  ROC enclosure will be mounted in a gondola containing a payload module.  Each ROC enclosure  contains a Single Board Computer (SBC) module and two Trimble BD950 GPS receivers.  JAFCI has  fabricated both ROC enclosures and generated custom software, integrating the two Trimble GPS  receivers’ data streams via the internal single board computer system.  The SBC module communicates via an RS­485 connection to the Payload Supervisory Board, provided by the Centre National d’Etudes  Spatiales (CNES), also contained in the gondola payload module An additional device was also built, a test fixture which routes three of the four serial ports on each  GPS receiver to external connectors.  (The remaining serial port on each receiver is dedicated to the  SBC module.)  The test fixture can be connected to either ROC enclosure using a ribbon cable.  HARDWARE CIRCUIT DESCRIPTIONS The ROC box contains four main components.  Each ROC enclosure consists of:  • • • Technologic Systems TS­7260 Single Board Computer Two Trimble BD950 GPS Receiver module boards JAFCI designed custom interface board, interfacing all I/O and power between SBC and GPS  receivers The Trimble BD950 receiver boards are interfaced to the Single Board Computer (SBC) via the JAFCI  designed interface board.  The JAFCI board directly interfaces serial ports from both BD950 receivers,  routes power connections, and digital I/O connections to the SBC.  The SBC utilizes digital I/O lines  on both BD950 boards (Power ON/OFF, Master RESET, Power status indicator, Tracking SV, and CMR received) The aluminum ROC enclosure contains external connectors for power input and RS­485  communication to the Payload Supervisory Board.  LEMO part number ERN1S302.CLL is used for the  power input connector, LEMO p/n ERN1S306.CLL for the RS­485 connection.  An additional  connector, LEMO p/n ERN2S310.CLL, is externally available for software downloading to the SBC’s  RS­232 console port.  A 37 pin DSUB connector provides connectability to the test fixture for external  testing and programming Technologic Systems TS7260 Single Board Computer The SBC is based on the Cirrus EP9302 processor, running on the Linux platform.  It provides on­ board peripheral support via a PC/104 bus as well as several individually configurable serial ports and  digital I/O ports.  For this project, the SBC was ordered as a TS7260­64­128F containing 64MB RAM  and 128MB flash memory.  The options selected were the TS­XDIO Port, Half Duplex RS­485  communication, a battery backed up real­time clock, and an on­board temperature sensor.  A PC/104  based serial port daughter board p/n TS­SER1 was also added to provide enough serial connections for the project Serial Port Assignments are as follows: COM1 COM2 COM3 COM4 Console RS­232 connection for external programming and debugging RS­485 to Payload Supervisory Board Serial connection to GPS1 serial port 1 Serial connection to GPS2 serial port 1 Two eight­bit digital I/O ports receive status indication from each BD950 GPS module as well as  provide power control using the BD950 On/Off Switch inputs.  Hard Reset can also be issued to each  GPS module via digital I/O Digital I/O Port assignments are as follows: GPS 1: DIO_0 DIO_1 DIO_2 DIO_3 DIO_4 Tracking SV CMR Received Power On/Off SW RESET INPUT INPUT INPUT OUTPUT OUTPUT Logic High = True Logic High = True Logic High = True Logic Low = True  (BD950 is ON) Logic Low = True (RESET is asserted) Tracking SV CMR Received Power On/Off SW RESET INPUT INPUT INPUT OUTPUT OUTPUT Logic High = True Logic High = True Logic High = True Logic Low = True  (BD950 is ON) Logic Low = True (RESET is asserted) GPS 2: XDIO_0 XDIO_1 XDIO_2 XDIO_3 XDIO_4 Trimble BD950 GPS Receiver modules The Trimble BD950 receivers are designed for high­precision navigation.  The receivers use Real­Time  Kinematic (RTK) techniques, achieving centimeter accuracy when used as a base and rover receiver  pair.  In this application, data communication occurs between the SBC and each receiver’s COM1 port Each receiver provides status outputs for Tracking SV, CMR Received, and Power on/off status.  The  On/Off SW input is pulled Low during normal navigational mode and during data transmission.  A  High level can place the receiver into Standby mode to reduce power consumption.  A hard RESET  input is also provided on each board.  I/O assignments to the SBC are noted above The BD950 boards are mounted in a stack and plugged into the interface board via 64­pin DIN  connectors.  A ground plane board is mounted between the GPS receivers to reduce the chances of  crosstalk or EMI/RFI issues.  All components are permanently mounted in an aluminum enclosure  with all screws secured with Loctite thread lock solution to prevent accidental disassembly during  deployment GPS­Computer Interface Board The JAFCI­built GPS­Computer Interface Board provides the means for both BD950 receivers to  connect to the SBC and to be supplied power.  Each receiver plugs into a 64­pin DIN connector,  routing power, serial port connections, and digital I/O connections to an array of connectors.  I/O  connections are hard­wired from the interface board’s connectors to the corresponding Digital I/O port  on the SBC.  Connectors also provided for each of the four BD950 serial ports.  COM1 from each  receiver is dedicated to communication with the SBC.  COM2, COM3, and COM4 from each receiver are connected to an external programming and test connector, to be connected to the Test Fixture to  facilitate external de­bugging and programming.  All three digital status outputs (Power, CMR Received, and Tracking SV) are also brought out to the programming and test connector.  Since the SBC digital  I/O ports are limited to 3.3 volt logic, MOSFET switches are used on status inputs to provide level  translation from the BD950’s status outputs.  See the schematic diagrams for more detail TS7260 SBC BD950 GPS  Stack GPS Computer Interface Board Hardware Block Diagram Payload Power TTYAM1 to Payload Module (RS-485) Power Distribution TTYAM0 To Console Connector (RS-232) Trimble GPS ONOFFSW (A32) Tracking SV (A5) CMR Received (A6) Power (B5) Trimble GPS DIO TS-7260 ONOFFSW (A32) Tracking SV (A5) CMR Received (A6) Power (B5) PC 104 Trimble Serial Port TXD (A9) / RXD (A10) To TTYS0 TS-SER4 Trimble Serial Port TXD (A9) / RXD (A10) To TTYS1 Weight and Dimensions: Weight:  950 grams (approx.) Dimensions:  260mm Length (including mounting brackets),  160mm Width,  85mm Height Test Fixture The test fixture is a simple interface which allows an external direct connection to the COM2, COM3,  and COM4 serial ports on both GPS receivers.  (COM1 serial ports are dedicated to the SBC.)  All 6  serial ports (3 from each receiver) are available at the external test and programming connector.  The  test fixture simply routes the serial port connections to standard 9­pin “D” connectors to be interfaced  to an external computer.  Each receiver’s three digital status outputs (Power, CMR Received, and  Tracking SV) are brought into the test fixture and are connected through MOSFET switches to LED  indicators.  See the schematic diagrams for more detail Software The CNES protocol service handles all frame acknowledgements, acknowledgement timeouts and CRC  computation and checks.  It discovers flight ID by examination of sync packets.  The service is  responsible for buffering data for transmission.  The service will also buffer commands to be passed to  the coordinator.  The service may interpret and execute some command packets as long as the  commands only affect transmission and reception of data.  Other processes may request text of  commands sent and the last synchronization data received from the Power Supervisory Unit (PSU)  along with the time difference between system and sync time at the time of reception.  Only the data  section of a command is passed to the requester.  The service uses the Unix socket datagram protocol  for communication with all other processes.  No other process should make decisions based on the  external transmission protocol used. All modules run in their own process/processes The coordinator is responsible for executing all commands emitted by the protocol service, maintain  configuration data, accept configuration changes generated from command packets and serve  configuration data to the GPS handlers.  The GPS handlers request configuration parameters on start  up or when signaled with a hangup (HUP) signal (a basic convention in the unix/linux world).   Configuration request and receipt are done via Unix socket datagram protocol.  The external  reconfigure command should be separate from specifying new configuration parameters so that the  GPS handler need only deal with one reconfiguration when reconfiguration has multiple changes in  parameters.  The coordinator will also signal the GPS handlers to terminate gracefully if a shutdown  GPS type of command is defined and sent Only the GPS handler has knowledge of GPS devices, GPS data formats, data processing requirements  and other experiment­specific information.  All other processes will treat data as just some known­ length block of bytes.  The GPS handler program controls a single GPS card.  Multiple processes  running different configurations are used to handle multiple GPS devices Coordinator starts on system startup and starts other processes.  This allows the coordinator to track  if other processes sporadically die and so can recover.  The system initialization process will restart the coordinator program if it fails Communication between the CNES protocol service and other processes is via Unix socket datagram  protocol.  This allows the GPS handlers to just send the data off and forget about it not having to  consider whether it is really talking to the CNES protocol service or just a test stub.  The CNES service  can be tested with a coordinator stub that acts as an echo service CNESserver API The CNES server provides the data connection between processes (instances of running programs) in  the ROC and the PSB. All data and status blocks are transmitted to the PSB via the CNES protocol.  The main purpose of this document is to describe what is transmitted in the data frame, i.e., data  portion of the CNES TM packet, and how other ROC processes instruct the server to transmit data and  status Transmission of data across CNES system Since we want compress data for transmission, we need to have some unit of compression. Typically  the unit of compression is the file, so we will save the data stream in chunks to files which are  compressed. In the following, these compress files are called segments. We need then to indicate the  beginning and ending of those segments in the CNES packet stream. To accomplish that the service  would define several different data frames, that is the data portion of the CNES protocol TM packets.  This scheme will work independently of the compression style chosen including no compression  whatsoever Since there probably will be a need for some status information as well as data, there are several other  frames types defined which may be intermixed with file frames and must be broken out of the stream.  The different frame types have different headers. The header bytes would not be compressed.  The architecture of the data frames will be the following (the named data structures and header type  definitions mentioned are contained in the header file commandLoop.h): Byte 0: the data frame type 0 – start of segments 1 – segment continuation 2 – reply to command (Not all commands may have a reply, but may result in a change  of status. This is just an anticipatory type) 3 – status update (unsure what would be, not implemented as the CNES protocol doesn’t provide timely transmission of special packets) 4 – shutdown message – this has no content – it is three bytes long. It indicates that the  next messages will begin at the beginning of a segment that was being transmitted at shutdown (if any) Bytes 1 & 2:  the data frame size. This is required as the data stream as delivered to the ground  station may not keep the individual packet sizes and in general the files will not fit  exactly into a set of full frames. The size includes header bytes For type 0 (start of segment): Byte 3 and  4 File sequence number – all data frames with this identifier will refer to the same file until all possible sequence numbers are seen and then will be re­used. This provides for  65538 files before reuse Byte 5 ­ ? File meta data:  all the data that determined why this logical block of data was packaged into a file. The size of this portion should be fixed at some point. Currently, the only  metadata is the size of the entire file. This will aid in the reconstruction of the file at the  base station. The size of this may change during development but will be a fixed number of bytes in production. Responsibility for the meta data and compression has moved to  the arbitrator. The CNESserver now simply transmit the segments byte by byte although it is true that the metadata lies at the start of the segment Remaining bytes: stream of initial bytes of the compressed file This is represented in the code API as type start_of_file_header with type code  CMD_START_HEADER_TYPE For type 1 (segment continuation): Bytes 3 & 4: file sequence number. This identifies the data frame as part of the file  initially identified by a type 0 data frame Bytes 5 & 6: file frame sequence number. This tells us what frame of the file is being  transmitted so we know how to put all the frames back together. This starts at 1 after  the transmission of a type 0 frame. No file would be as big to reuse frame sequence  numbers in the same file This header is represented in the code API as type data_frame_header with type code  CMD_DATA_FRAME_TYPE Remaining bytes: continuation of the stream of bytes of the compressed file For type 2: The remaining bytes will have to be defined according to what information pertinent to  command sent expects. No current command (see “TEXT Command Types” below)  generates a response of this type This header is represented in the code API as type generic_frame_header with type code CMD_COMMAND_FRAME_TYPE Note the CNES protocol simply does not have a method for handling this frame  adequately For type 3: Status blocks will be transmitted on unexpected changes of state or on request. The  structure of a status block is yet TBD. The status block contains device configurations  as they actually are (power is off rather power should be off in this configuration).  Currently the code expects the status block to be able to be contained within one data  frame. Binary coding of the information should easily allow for this. (This still isn’t  implemented wholely.) This header is represented in the code API as type generic_frame_header with type code CMD_STATUS_FRAME_TYPE No real need has arisen to implement this and would not be handled well by the CNES  protocol TEXT Command Types These are the TC commands containing “TEXT” as the first four bytes of the TC data frame. For this  section “command” refers to the string of bytes after “TEXT” There are two types of commands: device  dependent configuration commands and device independent commands.  The difference between the  two is that device independent commands need no knowledge of the structure of the configuration  data. Most of the CNES server code treats the status and configuration information as just a block of  bytes of a given size. Only one section (config.c) has any knowledge of the structure. That section reads  and writes configuration files and updates configurations given device dependent commands. The  section receives the block of bytes along with its size from the rest of the CNESserver modules. This is  a compromise between passing device dependent commands to a separate process and ensuring a  quick response back to the PSB on all TC commands. Passing commands to another process would  allow the CNESserver to not have to be re­tested at all when configuration commands are added. The  additional overhead of using a separate process may take more time than allowed to respond to TC  TEXT commands. The compromise allows unit testing of the config.c section without retesting the  remaining sections Device independent commands, and only those commands, begin with an @ character @FINISH – write the configuration to a file with a standard path name and signal all requesting  processes that the configuration update has completed. If the system should shut down  or fail between the another TC TEXT command before this command is sent, the  updated configuration will be lost. This simply calls a routine in the config.c section to  write it however it need to be @HARD ­ do a hard reset. The system writes the file /reset and a reboot of the system is forced  with no acknowledgement of the command nor notification to any other system module.  The reboot process detects this file causing it to clean datasets and segments from the  system. The default configuration will be copied to the normal configuration file @SOFT ­ do a soft reset. This is the same as a hard reset except that it will not do an immediate  reboot. The actions to be taken on reboot will be done on the next normal  shutdown/startup cycle   In the current coding of config.c, commands are a single character followed by up to three parameters  (though not all three may be of the numeric type)1. Each parameter may be either a four digit decimal  number, a single decimal digit representing a device number or a true/false indicator (T/F or 0/1). To  make adding additional commands easier, each defined command is described in a table which a  parser uses to decode the parameters. The only addition to the code needed is to use the parsed  parameters to change the configuration. Numeric data (indicated by dddd) are up to four digits (or an  initial sign and three digits) that are left justified and space padded The power on/off command Powers a GPS receiver on or off and if on, begins the current application PDS  ­ where D is a device number and S is the true/false state of the power being on Example: P1T P2F ­ set power on for device 1 ­ set power off for device 2 Set Elevation Sets the elevation at which occultation recording is started or position recording is started and  stopped EDdddd – where D is the device number and dddd is the elevation in degrees. This may be signed Maximum Gap The time in seconds since the last transmission of a single satellite before it is assumed that the  satellite has set GDdddd – where D is the device number and dddd is an unsigned decimal number Resample Rate Adding parameter types would not be a difficult chore Rate at which data is recorded when satellite is not in occultation or rate at which data is resampled  for position application RDdddd ­ where D is the device number and dddd is an unsigned decimal number. This will be coerced to a multiple of the occultation rate in seconds per record Occultation Rate Rate at which data is recorded during a satellite’s occultation period. This is the rate that the receiver  outputs data and therefore must be a rate supported by the receiver. The rate is in seconds per record ODdddd ­ where D is the device number and dddd is an unsigned decimal integer in seconds per  record Occultation Selection This is the number of occultations to be acquired before considering which is to be transmitted Sdddd – where dddd is an unsigned number. The maximum is 32. Note that this is not device  dependent, but it is listed here because it is implemented in config.c to keep the high level of  modularity for the CNESserver. The server code knows nothing of the actual data or devices it serves  except in the config.c module Application Mode Sets the application mode to position or occultation for a device MDA – where D is the device number and A is either P or O Dataset Size This sets the amount of data that the position application will acquire before attempting to send it off.  This is done by closing the current dataset causing the arbitrator to transmit up to the  CLOSE_DATASET event. The size is given in units of 1K bytes KDdddd – where D is the device number and dddd is the unsigned size Local Client Requests The requests to the server and responses are sent and received by the datagram routines send_dgram  and recv_dgram (this API is yet to be documented beyond code comments). The requests codes and  data structures are defined in the header file commandLoop.h There is a requirement that none of these data structures be larger than the generic clientRequest  structure. Each structure has their own typedef given below along with the request code. Those listed  with typedef of clientRequest only use the command code portion of the packet, so only the command  code of type/size client_command need be sent Unless otherwise documented, the response to the client process will either be  CMD_OPERATION_SUCCEEDED or CMD_OPERATION_FAILED. The response contains the request  code that generated the response and the response in a structure name response_block tries to enforce this). In that track collection, it is recorded which satellites have been using it as a  calibrator When a satellite sets, all the satellites that were calibrated by this one is marked as a candidate track if the state of the track is marked as complete2, othewise they are marked as invalid. When all the  receivers for a given satellite are marked as something other than TRACK_FORMING or  TRACK_COMPLETE, arbitration between devices are done. One track among all devices in the  collection is marked selected and the others not selected3. The track collection is placed in a list.  When enough occultations (programmable parameter) are listed, one is chosen among and marked chosen  and the others are mark not chosen When the OCCULTATION_START event gets to the head of the queue of a given device the backpointer  in the event is used to get the state of that device's track. If it is chosen, then the device's data  structures are modified to indicate that satellite's information from occultation records are to be  written. When the chosen track is detected, the corresponding calibration satellite has its calibration  count incremented. (END_SATELLITE will decrement it). Satellites with non­zero counts are also to be  written At the beginning of processing of a device queue, the first and last record written are set equal.  Processing events appropriately set the last record to be at the record which occured just before the top event that cannot yet be processed. At the end of queue processing, if the last record now is greater  than the first, records from first to last are written (with a filtering of occultation records) to a segment  to be transmitted. The location of the file is controlled by the environment variable  BASE_TRANSMISSION_DIRECTORY. See Arbitrator Behavior – Dataset and Segments power point  presentation for a diagrammatic view of queue processing The arbitrator is built as one monolithic source module except for some data compression routines in  compress.c shared by the standalone archive program Done initially at its END_SATELLITE event There are currently only two devices, but the program is built to accommodate an arbitrary number defined by parameter MAX_DEVICES Architecture of the Collect Program Main Routine The main routine of the collect program does initialization of the GPS packet protocol, creates and  loads the application file created from the configuration file and then simply loops to wait for a gps  packet, process it and wait again. As it stands now, only one type of packet is received, the type 57H  raw data packet. Type 57H records come as paged packets so a routine is called to gather additional  GPS packets and bind them together in one record. This record is then process by the routine  process_all_satellites located in source module filter_raw_data.c Workhorse Routines The filter_raw_data.c source module is the workhorse module for the program. The  process_all_satellites subroutine walks through the type 57H record processing each satellite with  process_one_satellite. That routine, if the data is valid, calls the change_state routine. This routine  looks at the current state of satellite track (such as satellite has not been seen recently), looks at the  current elevation and determines whether a state change is appropriate. Upon state changes, the  arbitrator is notified as to the particulars of the event that caused the state change (such as satellite  reaching the occultation elevation Other modules of importance GPSpacket.c – does the low­level serial I/O for communicating with the receiver paged_packet.c – sends and receives receiver messages that span more than one GPS packet dataset.c – creates, read and writes GPS records. It generates the NEW DATASET and CLOSE  DATASET events that are sent to the arbitrator getConfiguration.c – opens and reads the configuration file The collection program communicates with the arbitrator using the datagram.c source module Program event_recorder can be used to record the events output by the collection program (they are  stored in standard output of the event_recorder). These events can be played back to the arbitrator  with event_player which reads events from standard input.  The collect programs only useful command line argument is the receiver to use in collection. The  receiver is indicated by a number (1 or 2). All other information is obtained by reading the first or  second configuration block or environment variables (see the CNES protocol architecture document for  information on environment variables) Arbitrator Behavior Datasets and Segments PURDUE UNIVERSITY Jonathan W. Amy Facility for Chemical Instrumentation May 13, 2009 Professor: Haase Project: 17292 Description: ROC – dual frequency GPS receivers for occultation SCHEMATIC DIAGRAMS GPS­Computer Interface Schematic Diagram Test Fixture Schematic Diagram ROC Enclosure  Bill of Materials  Qty Designator Description Part Number Custom Aluminum Enclosure 160 X 220 X 85mm GPS1, GPS2 Trimble BD950 GPS Receiver Technologic Systems Single Board Computer TS7260­64­128F with options: TS­XDIO Port OP­XDIO Half duplex RS­485 OP­485­HD­12 Battery Backed Real­Time Clock OP­BBRTC On­board Temperature Sensor OP­TMPSENSE 1GB Flash Drive with Debian PC/104 Serial Port with ext. temp USB­FLASH­1GB TS­SER1 Rt. Angle USB Extender Cable –USB Firewire RR­AAR04T­04G J1 external LEMO 2 pin connector ERA1S302CLL J2 external LEMO 6 pin connector ERA1S306CLL J3 external LEMO 10 pin connector ERA2S310CLL J4 external DSUB 37R Bulkhead Receptacle Cinch DCUH­37S­FO ANT1, ANT2 SMA feedthrough Bulkhead Adapter connectors Amphenol 901­9209A Antenna Cable connectors SMA Rt. Angle Amphenol 901­9531­3 Antenna Cable connectors SMC Rt. Angle Amphenol 903­288P­52A DIO1,DIO2 16 Pin Header Socket Connector AMP/TYCO 87456­2 COM2,COM3 10 Pin Header Socket Connector AMP/TYCO 87456­6 Header Connector Female Contacts AMP/TYCO 87667­5 J1,J2 64 Pin DIN 41612 Female Connector AMP 5650860­5 J3,J4 2 Pin PC Mt. Mini Header Connector AMP 1445084­2 P3,P4 2 Pin Male Mini Connector Shell AMP 1445022­2 Connector Female Contacts AMP 1­794610­2 J5,J6 6 Pin PC Mt. Mini Header Molex 22­23­2061 P5,P6 6 Pin Female Connector Shell Molex 22­01­3067 J7­J14 5 Pin PC Mt. Mini Header Molex 22­23­2051 P7­P14 5 Pin Female Connector Shell Molex 22­01­3057 J17 10 Pin PC Mt. Mini Header Molex 22­23­2101 P17 10 Pin Connector Shell Molex 22­01­3107 Q1­Q8 MOSFET Transistor BSS123LTIG ROC Enclosure  Bill of Materials (cont.) Qty Designator Description Part Number C1 10uF @35V Tantalum Capacitor AVX 106K035SCS C2 0.1uF @50V Monolithic Ceramic Capacitor Vishay K104K15X7RF5TL2 D1 Transient Voltage Suppressor 1.5KE30CA D2 Diode 1N4004 D3­D6 10V Zener Diode BZD27C10P R1­R4 150 ohm Resistor CRCW0805150RJNEA R5­R8 100K ohm Resistor CRCW0805100KJNEA 37 Pin DSUB Ribbon Cable Assembly AMP Tyco NE2537­06­ROHS Printed Circuit Board JAFCI designed IS­521 Miscellaneous Hardware, Spacers, & Screws Test Fixture Enclosure  Bill of Materials (cont.) Qty Designator Description Part Number Enclosure BUD Style A BUD CU3284 J1 DSUB 37­P PC Mount Connector AMP Tyco 5747375­8 J2­J7 DSUB 9­S PC Mount  Connector AMP Tyco 5747150­8 U1 5V 3­terminal Voltage Regulator LM7805C C1,C2 10uF @35V Tantalum Capacitor AVX106K035SCS C3,C4 0.1uF @50V Monolithic Ceramic Capacitor Vishay K104K15X7RF5TL2 D1,D2 Red LED Avago HLMP­3390 D3­D6 Green LED Avago HLMP­3590 R1,R2,R5,R6,R9,R10 330 ohm Resistor CRCW0805330RJNEA R3,R4,R7,R8,R11,R12 150 ohm Resistor CRCW0805150RJNEA R13­R18 4.7 Megohm Resistor CRCW08054M70JNEA Printed Circuit Board Miscellaneous Hardware, Spacers, & Screws JAFCI designed IS­522 PURDUE UNIVERSITY Jonathan W. Amy Facility for Chemical Instrumentation Professor: Haase Project: 17292 Description: ROC – dual frequency GPS receivers for occultation MANUFACTURER DATA SHEETS  ... Jonathan W. Amy Facility? ?for? ?Chemical Instrumentation May 13, 2009 Professor: Haase Project: 17292 Description: ROC? ?–? ?dual? ?frequency? ?GPS? ?receivers? ?for? ?occultation SCHEMATIC DIAGRAMS GPS? ?Computer Interface Schematic Diagram... parameters.  The coordinator will also signal the? ?GPS? ?handlers to terminate gracefully if a shutdown  GPS? ?type of command is defined and sent Only the? ?GPS? ?handler has knowledge of? ?GPS? ?devices,? ?GPS? ?data formats, data processing requirements  and other experiment­specific information.  All other processes will treat data as just some known­... PURDUE UNIVERSITY Jonathan W. Amy Facility? ?for? ?Chemical Instrumentation Professor: Haase Project: 17292 Description: ROC? ?–? ?dual? ?frequency? ?GPS? ?receivers? ?for? ?occultation MANUFACTURER DATA SHEETS