Pierre Auger Project Surface Detector Electronics

Tank Power Controller (TPC) Board

June 14, 2001

Power Controller Functionality:

The Tank Power Controller (TPC) Board has as its main function the
responsibility of turning on and shutting off the power to the station
electronics. The TPC has the capability to power down the station
electronics at any time. However, to protect against mid-operation
shutdowns, often the TPC will notify the local station CPU (host) when a
shutdown is required. The TPC will notify the host when it detects a
questionable battery or system electronics status. The host will then
immediately reply with a shutdown or remain-on command. Although the
host will usually be notified, certain critical incidents will cause
immediate shutdown.

In order to simplify the explanation of the power controller program, it
has been divided into two sections: the main program and the
transmission protocol. The main program procedure flows very linearly
from top to bottom with very few branch points. As a result, the main
program flow may be understood equally well by looking at a flowchart or
a numbered sequence. The host protocol, on the other hand, does not flow
simply from top to bottom. The host protocol has several wide branch
points and is best explained in paragraph form although a simplified
flowchart is included.

# Main Program

The main program provides a framework for following a set sequence of
states. The main program at its highest hierarchy level has only three
modes and various states associated with these modes. The three modes of
the main program are as follows: initialize mode, run mode, and shutdown
mode. The procedure for traversing the modes is shown below.

1)  IDLE state is exited upon power up.

> ***Initialize Mode:*** Initialize Mode is where power is turned on
> from being off and the TPC is preparing to communicate with the host

2)  READ BOARD STATUS state reads the board status following power up to
    make sure that the power controller board is functional.

3)  If the board status is not valid (overheated or digital voltage too
    low) then the power controller board remains off

4)  READ BATTERY VOLTAGE state reads the battery voltages (ADC 5 and
    ADC 6) to determine whether or not to turn the system electronics on
    .

5)  If the battery voltage is greater than 16V, then the system
    electronic power is turned on.

6)  POWER UP ELECTRONICS is the state where the system electronics
    switch is turned on if the status is okay and there is enough power
    in the batteries.

7)  WAIT 1-2 MINUTES state is necessary to give the system electronics
    enough time to initialize and stabilize.

8)  CHECK TURN ON/OFF BIT state reads a single bit on the J4 connector
    which should be externally driven high to indicate that power to
    station electronics should remain on.

9)  If the status is still okay, the TPC keeps power on and sends the
    board status back to the local station controller.

. ![](media/image1.wmf)

# Figure 1: Main Program Flowchart

## *Run Mode:* Run Mode is a continuous loop where communication between the PCB and the host is established and the system electronics are on. Run mode is only exited on a bad PCB board status or by a command from the host.

10) Convert next ADC channel

11) The next step in Run Mode is WAIT FOR COMMAND

12) If a command is received from the host then the TPC will PROCESS THE
    COMMAND: reply and set parameters associated with the command.

13) After processing the command, the TPC will CHECK BOARD STATUS again

14) If the board status is okay then the TPC will go to the next step.
    If not, the TPC will notify the host and then shutdown the power to
    the station electronics

15) If the board status is valid, then the TPC must CHECK BATTERY
    VOLTAGES again.

16) If the voltages are \> 16V, then the TPC will wait for another
    command and return to step 10. If voltages are between 14 and 16V,
    then the TPC will send a warning message depending upon which
    battery is low. If the battery voltage is below 14V then the TPC
    immediately turns off the switch and cuts station power.

> ***Shutdown Mode:*** The purpose of shutdown mode is to keep the
> system electronics powered down long enough for the batteries to
> recharge. Shutdown mode is exited every 3-4 hours to check and see if
> enough battery power is available to run the electronics.

17) WAIT 3-4 HOURS self explanatory

18) After shutdown mode is exited, Initialize mode is re-entered at step
    2.

# Communications Protocol

The TPC communicates with the host via a UART port using an RS-232
standard interface. The communications system operates in half-duplex
system mode, where only one device is transmitting at a time. The TPC
software uses the following RS-232 mode parameters:

-   Baud rate: 9600 baud

-   Data bits: 8 bits

-   Parity: None

-   Stop Bits: 1

-   Flow Ctrl: None

The host has a quad UART chip which handles the RS-232 transfers at the
byte level so the CPU doesn't have to worry about it. This UART has a
data buffer several bytes deep so that the CPU may access data at its
leisure. To take full advantage of the use of this chip while also
preserving the command structure, two (2) bytes are used to frame each
transaction: the preamble ('\<') and the postscript ('\>').

Any byte that is received between the two framing bytes is assumed to be
a real command and not just serial port noise. If the received command
is one of the commands supported by the TPC board, then this command is
executed and a correctly framed reply message is sent.

Previous versions of the host-to-TPC communications software did not
utilize the UART interrupt. The previous code iterations polled UART
flags at a given rate. This made all processes deterministic and easy to
model and simulate, but it did not minimize the time required to acquire
UART data. This was not a problem because the previous protocol required
software handshaking after every byte. The current version of the code,
however, utilizes the UART interrupts and as a result, significantly
higher data rates may be achieved. The tradeoff for this faster data
rate is increased susceptibility to noise on the transceiver lines. This
is not a major issue as there is a fixed length structure to all data
packets and any packets with the wrong structure are thrown out. The
host may simply request a re-transmission on these events without
adverse effects.

All UART data falls into one of 3 categories: command byte, data byte,
or framing byte. The command bytes are listed below.

### Command Bytes

There are only four command bytes necessary to operate the PCB:

Command Byte Description

  ------------- ---------------------------------------------------------
  'a'           System electronics power

  'b'           PCB board status

  'c'           Upload PCB ADC data
  ------------- ---------------------------------------------------------

Table 1a: Local Station controller command Bytes and their meanings

These command bytes are always transmitted by the local station
controller and received by the TPC board. After completing the
corresponding command, the TPC board replies with a correctly framed
command except that the lowercase character is replaced with an
uppercase one. As a result, the TPC may respond with one of the
following commands.

Command Byte Description

  ------------- ---------------------------------------------------------
  'A'           System electronics power

  'B'           PCB board status

  'C'           Upload PCB ADC data
  ------------- ---------------------------------------------------------

Table 1b: TPC Command Bytes and their meanings

### Paramter/Data Bytes

Within this document, the term *parameter* refers to a byte sent
downstream to the TPC from the local station controller. Conversely, the
term *data* refers to the bytes sent upstream from the TPC to the local
station controller. Currently there are only three commands implemented
in the TPC code. Of these three commands, only one has parameters
associated with it. However, the framework is present to easily add more
commands and these additional commands could easily be defined to
contain parameters. The following table displays the possible data and
parameter bytes that may follow each command byte:

Command Byte Data Byte Meaning

  ----------------------- ---------- ------------------------------------
  'a'                     '0'        Do nothing

                          '1'        Turn ON system electronics

                          '2'        Turn OFF system electronics
  ----------------------- ---------- ------------------------------------

Table 2a. Parameters and their meanings

  ----------------------- ---------- ------------------------------------
  'A'                     '1'        Switch turned ON

                          '2'        Switch turned OFF

  'B'                     '0'        Digital supply failure, switch
                                     overheat (never see)

                          '1'        Digital supply failure (never see)

                          '2'        Switch overheat

                          '3'        Status OK

  'C'                     Any number ADC data channels 0-14, every 4^th^
                                     byte starts a new ADC channel

  'D'                     N/A        Status error

  'E'                     N/A        Battery failure

  'F'                     N/A        Turn-OFF bit LOW

  'S'                     N/A        Shutdown
  ----------------------- ---------- ------------------------------------

**Table** **2b**: **Data** **bytes** **and** **their** **meanings**

# Framing Bytes

The framing bytes are the bytes that are used to pick out the beginning
and end of commands in the current communications protocol. The preamble
character '\<' signifies the beginning of a new command. The postscript
character, '\>', signifies the end of a command. The use of both of
these characters in conjunction with the known command lengths enables
transfer errors on the byte level to be easily detected. The addition of
these framing bytes is essential to enabling commands to be issued in
atomic units. By framing the commands, using fixed length commands, and
utilizing the TPC interrupts, commands may be sent as multiple bytes
without handshaking. Multiple commands may even be sent without
handshaking.

# Communications Subroutine

Utilizing the UART interrupt splits the Run mode into 2
semi-concurrently running processes. The processes are not entirely
concurrent as the UART interrupt is handled by the MCU when an interrupt
is received, but the processes become relatively independent of one
another. The flow charts in figure 2 show the program flows of the 2
processes controlling the communications protocol. The main
communications loop flowchart illustrates the portion of the
communications software that resides within the main program loop. This
portion of the code is running as long as the TPC is in RUN mode. The
interrupt service routine (ISR) is entered upon receiving a UART
interrupt. The ISR code must determine the type of interrupt, store any
received data, and reset the interrupt within this ISR to prepare for
the next interrupt. This code must be very short and quick to ensure
that the UART is able to receive more bytes as quickly as possible.

![](media/image1.wmf)

**Sample commands:**

I\) Transmitting status: command byte = 'a', server = PCB, client = host

A)  TPC sends transaction: "\<B3\>"

II\) Receiving power down: command byte = 'b', server = Host, client =
PCB

A)  Host sends command: "\<a2\>"

B)  TPC replies with "\<A2\>"

C)  TPC shuts down