Asynchronous Serial

Units built with the ASYNC and RS485 options use an asynchronous serial protocol. The parameters are programmed into the unit bootloader at the factory, and special-order units with different parameters are available.

Table 15: Default Asynchronous Serial Parameters

Each word begins with a start bit with space (0) value. Eight data bits follow, with the LSB sent first and the MSB last. Finally, a stop bit is sent with mark (1) value. Once the stop bit has concluded the output transmitter may be disabled if there are no further words to follow.

The actual output baud rate may deviate slightly from the nominal due to inaccuracies in the star tracker master oscillator. Revision 4 and 5a star trackers use a trimmed CMOS oscillator with ±0.5% tolerance. Revision 5b star trackers use a MEMS silicon oscillator with quartz-like accuracy.

Table 16: Actual Asynchronous Serial Baud Rates

CAN

Units built with the CAN option use the ISO 11898 CAN protocol. The baud rate is programmed into the unit bootloader at the factory, and should be negotiated at the time of purchase. Rates of up to 2 Mbps can be achieved. The star tracker’s CAN controller is fed by a 24 MHz clock with ±0.5% tolerance. This information can be used to calculate the actual and permissible CAN baud rates.

Protocol Layer 3 (Network Layer)

NSP is the Nanosatellite Protocol, originally developed at UTIAS/SFL for use on the CanX nanosatellites. This in turn is descended from the Simple Serial Protocol (SSP) used by UTIAS/SFL and Dynacon on the MOST and CHIPSAT spacecraft as well as the Dynacon reaction wheels in the wider market.

The star tracker uses NSP messages for all communication. This includes communication between the host spacecraft and the supervisor processor, as well as communication between the internal supervisor and functional processors. NSP messages sent between the host and the star tracker must be encapsulated in a manner compatible with the data link layer.

Asynchronous Serial NSP Encapsulation

NSP messages are encapsulated for transmission on an asynchronous serial channel using SLIP framing, as described in RFC 1055. This is required in order to indicate the beginning and end of NSP messages.

Table 17: SLIP Framing Special Characters

Each NSP message is transmitted with a FEND character added to the beginning and end. Whenever FEND would occur within the message it is replaced by two bytes: FESC TFEND. Whenever FESC would occur within the message it is replaced by FESC TFESC.

CAN NSP Encapsulation

The mechanism for encapsulating NSP messages into one or more CAN messages is TBD.

Protocol Layer 4 (Transport Layer)

Command and Reply

The star tracker generates telemetry messages in response to command messages received. In the usual case, a single telemetry message will be sent as quickly as possible after reception of the command.

Some commands will take a period of time to execute, and will only generate a telemetry message when they are complete. The star tracker should be considered to own the communications bus while such a command is executed, so do not send additional commands to it or any other unit until the reply is complete.

Some commands may generate more data than can be fit into a single telemetry message. In this case a sequence of telemetry messages will be sent back-to-back to carry the required data. The last message will be indicated using the P/F bit.

Nonwithstanding the above, the star tracker will not generate messages that are not linked to a command. The host spacecraft must poll it to determine its status and to read telemetry.

NSP Message Format

Table 18: NSP Message Fields

Each NSP message has the format shown above. The shortest possible messages are 5 bytes (with zero data, not counting framing).

The supervisor bootloader supports a maximum data length of 516 bytes, giving a total message length of 521 bytes. The supervisor application program and the functional processor software both support a maximum data length of 1028 bytes, giving a total message length of 1033 bytes.

Note that network-layer framing may add additional bytes to the message as it is transmitted.

NSP Address

Each star tracker contains two distinct processors: the supervisor processor and the functional processor. Each has its own NSP address.

The supervisor processor is responsive whenever the star tracker is turned on. Direct communication between the functional processor and the outside is possibly only when the supervisor processor is configured to forward packets, typically during troubleshooting or reconfiguration operations.

The user is free to pick one or more NSP addresses for flight computers and other units that may talk to the star tracker. Avoid choosing the SLIP framing characters FEND (0xC0) and FESC (0xDB), as well as the reserved address 0x00. By convention the flight computer would normally use NSP address 0x11.

Whenever the star tracker generates a reply message, its destination address is equal to the source address of the corresponding command message. Other than this, the star tracker pays no attention to the NSP addresses used by the host spacecraft.

V NSP Addresses

Table 19: 4 V NSP Addresses

Table 19 shows the NSP addresses of both processors, as a function of the Star Tracker A/B designation. The A/B designation is controlled by the Address In pin.

V NSP Addresses

The 28 V (Revision 5) star trackers have a different addressing scheme. In bootloader mode, the supervisor processor has the following address options:

Table 20: 28 V Supervisor NSP Addresses

The supervisor bootloader will accept any of the above addresses, provided the command comes in on the appropriate command port. The associated reply will be sent on the appropriate telemetry port. Thus, addresses 0x0A and 0x08 are half-duplex, while 0x0C and 0x0E are full duplex.

When the supervisor is commanded to transition from bootloader to idle mode, the addressing used in that INIT command is latched. From that point on, the supervisor will only respond to that one address, received on that one command port. Similarly, telemetry will only be sent to the appropriate selected port.

The functional processor address is determined from the supervisor address, as shown.

Table 21: 28 V Functional Processor Address

Multicast Address

The supervisor processor will respond to an additional NSP address, called the multicast address. Multicast commands will never generate replies. Multicast functionality is not available in bootloader mode. The functional processor has no multicast address.

Table 22: Multicast Addresses

Date: 2015-12-17; view: 657