1

P09141 Satellite Thermal Heater Controller Detailed Design Review Package Industrial Engineering Section

Document Revision: 01

Document Date: 02/08/2009

2

Table of Contents Industrial Engineering Section ............................................................................................................. 1

Table of Contents .................................................................................................................................. 2

1 Specifications ................................................................................................................................. 3

1.1 Purpose ....................................................................................................................................... 3

1.2 Requirements .............................................................................................................................. 3

1.3 Interfacing .................................................................................................................................... 3

2 Front Panel ...................................................................................................................................... 3

2.1 Layout .......................................................................................................................................... 3

3 Code ................................................................................................................................................ 4

3.1 Introduction .................................................................................................................................. 4

3.2 Specifics ...................................................................................................................................... 4

4 Appendix ......................................................................................................................................... 5

4.1 GUI .............................................................................................................................................. 5

4.2 LabView Serial Communications Help .......................................................................................... 6

4.3 Performing a Loopback test in LabVIEW .................................................................................... 11

4.4 Texas Instruments 2808 DSP Serial Port Specifications ............................................................. 14

3

1 Specifications

1.1 Purpose LabView is needed in our project because of the requirements of demonstrating the use of our communications via power lines. Using the LabView software, the group needs to show that we can control and send data over power lines using the program as the GUI interface for the DSP. LabView was chosen for the purpose of the project because of previous user experience and also its ease of use.

1.2 Requirements A requirement that is needed is the ability to communicate over the power lines to the DSP using a serial communications port. The DSP must be able to pull data from the HHC’s to relay the temperature set points and also some system checks to make sure the proper voltages are being relayed.

• RS232 port using SCI protocol

• Front panel visually describing transmissions

• Boolean controls to monitor system status

• Input variables ranging from 0 to 30 degrees Celsius.

• On/Off/Auto controls for the temperature regulation

• Easily update system information on front panel

1.3 Interfacing The program within the DSP will have to convert the integer value that is inputted into LabView into a voltage value that is corresponding to the temperature set point we want. This will be achieved with a lookup table using a constant that will convert a temperature to voltage to the regulators within the masters and slaves.

The Baud rate on the TI 2808 DSP is programmable with a 16bit baud-select register. This allows the DSP to have over 65000 different baud rate speeds that we can select based upon needs.

The amount of data bits the DSP requires are as follows: One start bit, eight bits of data, an option parity bit, and two stop bits. This is a total of 12 maximum bits and our protocol is set up for 12.

Included on the DSP are two methods in which to wake it up, or “handshake”, these are idle-line and address bit. “Handshaking” between the master and slaves is not something that will be done using the GUI interface. This will be achieved through the protocol and programming within the DSP’s themselves.

2 Front Panel

2.1 Layout The Front Panel is laid out in a very simple user friendly way to optimize ease of use. Each item of importance is clearly labeled, along with the addition of visual indicators for the temperature and status of the important system variables. The slave control panel has an input field which allows the user to type in the number of the slave they would like to set the temperature point on. Each slave will have a specific set point and

4

corresponding system status lights and temperature gauge. The thermister control is built into each channel with three parameters that can be changed, on/off/auto. These allow the user to select if the heaters should be on or off, and also auto so the heaters can regulate themselves according to the user defined set point. The telemetry buttons allow the user to perform the system checks to make sure all the voltages are correct within the system itself. The front panel also includes a Bus voltage monitor and also slave and master control buttons. These allow the user to control the sleep/awake status of the slave, and also gives them the ability to reset it if there is a problem. The bus voltage is there so the user can monitor what the current voltage is going into the system.

3 Code

3.1 Introduction The code will be programmed and worked on as soon as our specific parts we ordered arrive. Looking at the specifics and metrics that are needed, the program will consist of loops to check for the system functions. The communications will be initialized with the program example that NI supplies on its website.

3.2 Specifics The program logic will directly relate to the front panel diagram which is included. Each light is a system check to check for specific voltages and to make sure all connections are solid within the HHC module.

The on/off/auto buttons are there for the user to select which mode you want the HHC to be in. On will keep the heating units on, while off minimizes power consumption by making sure no power is going to the module. The auto selection will rely on the user input in the text field to make sure the temperature is set so the module can regulate itself. The transfer of data will only occur when changes are made to the front panel, or when the user asks to retrieve all the telemetry and temperature. This part will be done using a case selection structure which takes a true value from the Boolean and initiates the communication sequence.

An input field is provided so the user can select what slave to monitor/adjust. This field is limited and will not let a user input a value other than 0-255. This is to prevent system failures or errors from occurring.

The temperature gauge will be linked to the Boolean “Get Temp” button. This will initiate the transfer of data of the serial port to update the scale to clearly show what temperature it is currently in the heaters.

Reset buttons are provided on the main panel so the user can reset the slave or master in the event of an issue. Also provided is the bit error rate percentage. This will compare the amount of messages sent to the amount of messages received. This will provide a percentage of successful transmissions.

The communications protocol specs are laid out earlier, and these will be used with the help of NI technical help site to complete the SCI interface to the DSP boards. Experimentation of this will start as soon as the DSP’s arrive.

5

3.3 Appendix

3.4 GUI

6

3.5 LabView Serial Communications Help

Serial Communication General Concepts

Primary Software: Driver Software>>NI-Serial Primary Software Version: 3.0 Primary Software Fixed Version: N/A Secondary Software: N/A Hardware: Serial

Problem: Where can I learn more about serial communication basics? Solution:

1.

Serial Communication General Concepts

What is Serial? 2. What is RS-232? 3. What is RS-422? 4. What is RS-485? 5. What is handshaking?

1. What is Serial? Back to Top Serial is a very common protocol (not to be confused with Universal Serial Bus or USB) for device communication that comes standard on just about every PC. Most computers include two RS-232 based serial ports. Serial is also a common communication protocol that is used by many devices for instrumentation; numerous GPIB-compatible devices also come with an RS-232 port. Furthermore, serial communication can be used for data acquisition in conjunction with a remote sampling device. The concept of serial communication is simple. The serial port sends and receives bytes of information one bit at a time. Although this is slower than parallel communication, which allows the transmission of an entire byte at once, it is simpler and can be used over longer distances. For example, the IEEE 488 specifications for parallel communication state that the cabling between equipment can be no more than 20 meters total, with no more than 2 meters between any two devices; serial, however, can extend as much as 1200 meters. Typically, serial is used to transmit ASCII data. Communication is completed using 3 transmission lines: (1) Ground, (2) Transmit, and (3) Receive. Since serial is asynchronous, the port is able to transmit data on one line while receiving data on another. Other lines are available for handshaking, but are not required. The important serial characteristics are baud rate, data bits, stop bits, and parity. For two ports to communicate, these parameters must match:

a. Baud rate: a speed measurement for communication. It indicates the number of bit transfers per second. For example, 300 baud is 300 bits per second. When we refer to a clock cycle we mean the baud rate. For example, if the protocol calls for a 4800 baud rate, then the clock is running at 4800Hz. This means that the serial port is sampling the data line at 4800Hz. Common baud rates for telephone lines are 14400, 28800, and 33600. Baud rates greater than these are possible, but these rates reduce the distance by which devices can be separated. These high baud rates are used for device

7

communication where the devices are located together, as is typically the case with GPIB devices.

b. Data bits:

c.

a measurement of the actual data bits in a transmission. When the computer sends a packet of information, the amount of actual data may not be a full 8 bits. Standard values for the data packets are 5, 7, and 8 bits. Which setting you choose depends on what information you are transferring. For example, standard ASCII has values from 0 to 127 (7 bits). Extended ASCII uses 0 to 255 (8 bits). If the data being transferred is simple text (standard ASCII), then sending 7 bits of data per packet is sufficient for communication. A packet refers to a single byte transfer, including start/stop bits, data bits, and parity. Since the number of actual bits depend on the protocol selected, the term packet is used to cover all instances.

Stop bits:

d.

used to signal the end of communication for a single packet. Typical values are 1, 1.5, and 2 bits. Since the data is clocked across the lines and each device has its own clock, it is possible for the two devices to become slightly out of sync. Therefore, the stop bits not only indicate the end of transmission but also give the computers some room for error in the clock speeds. The more bits that are used for stop bits, the greater the lenience in synchronizing the different clocks, but the slower the data transmission rate.

Parity:

a simple form of error checking that is used in serial communication. There are four types of parity: even, odd, marked, and spaced. Of course, the option of using no parity is also available. For even and odd parity, the serial port will set the parity bit (the last bit after the data bits) to a value to ensure that the transmission has an even or odd number of logic high bits. For example, if the data was 011, then for even parity, the parity bit would be 0 to keep the number of logic high bits even. If the parity was odd, then the parity bit would be 1, resulting in 3 logic high bits. Marked and spaced parity does not actually check the data bits, but simply sets the parity bit high for marked parity or low for spaced parity. This allows the receiving device to know the state of a bit so as to enable the device to determine if noise is corrupting the data or if the transmitting and receiving devices' clocks are out of sync.

2. What is RS-232? Back to Top RS-232 (ANSI/EIA-232 Standard) is the serial connection found on IBM-compatible PCs. It is used for many purposes, such as connecting a mouse, printer, or modem, as well as industrial instrumentation. Because of improvements in line drivers and cables, applications often increase the performance of RS-232 beyond the distance and speed listed in the standard. RS-232 is limited to point-to-point connections between PC serial ports and devices. RS-232 hardware can be used for serial communication up to distances of 50 feet.

Pin Functions for RS-232

Data

TXD (pin 3) Serial Data Output

8

RXD (pin 2) Serial Data Input

Handshake

RTS (pin 7) Request to Send

CTS (pin 8) Clear to Send

DSR (pin 6) Data Set Ready

DCD (pin 1) Data Carrier Detect

DTR (pin 4) Data Terminal Ready

Ground

GND (pin 5) Ground

Other

RI (pin 9) Ring Indicator

3. What is RS-422? Back to Top RS-422 (EIA RS-422-A Standard) is the serial connection used on Apple Macintosh computers. RS-422 uses a differential electrical signal, as opposed to unbalanced signals referenced to ground with the RS-232. Differential transmission, which uses two lines each for transmit and receive signals, results in greater noise immunity and longer distances as compared to the RS-232. The greater noise immunity and distance are big advantages in industrial environments.

4. What is RS-485? Back to Top RS-485 (EIA-485 Standard) is an improvement over RS-422, because it increases the number of devices from 10 to 32 and defines the electrical characteristics necessary to ensure adequate signal voltages under maximum load. With this enhanced multidrop capability, you can create networks of devices connected to a single RS-485 serial port. The noise immunity and multidrop capability make RS-485 the serial connection of choice in industrial applications requiring many distributed devices networked to a PC or other controller for data collection, HMI, or other operations. RS-485 is a superset of RS-422; thus, all RS-422 devices may be controlled by RS-485. RS-485 hardware may be used for serial communication for up to 4000 feet of cable.

Pin Functions for RS-485 and RS-422

Data

TXD+ (pin 8) Serial Data Output (differential)

TXD- (pin 9) Serial Data Output(differential)

9

RXD+ (pin 4) Serial Data Input(differential)

RXD- (pin 5) Serial Data Input(differential)

Handshake

RTS+ (pin 3) Request to Send (differential)

RTS- (pin 7) Request to Send (differential)

CTS+ (pin 2) Clear to Send (differential)

CTS- (pin 6) Clear to Send (differential)

DSR (pin 6) Data Set Ready

Ground

GND (pin 1) Ground

5. What is Handshaking? Back to Top The method used by RS-232 for communication allows for a simple connection of three lines: Tx, Rx, and Ground. However, for the data to be transmitted, both sides have to be clocking the data at the same baud rate. Even though this method is sufficient for most applications, it is limited in being able to respond to problems such as the receiver getting overloaded. This is where serial handshaking can help. In this section we will discuss three of the most popular forms of handshaking with RS-232: Software Handshaking, Hardware Handshaking, and Xmodem.

a. Software Handshaking: The first form of handshaking we will discuss is software handshaking. This style uses actual data bytes as control characters, similar to the way GPIB uses command strings. The lines necessary are still the simple three line set of Tx, Rx, and ground since the control characters are sent over the transmission line like regular data. The function SetXMode allows the user to enable or disable the use of two control characters, XON and XOFF. These characters are sent by the receiver of the data to pause the transmitter during communication. As an example, assume that the transmitter begins to transmit data at a high baud rate. During the transmission, the receiver finds that the input buffer is becoming full due to the CPU being busy with other duties. To temporarily pause the transmission, the receiver sends XOFF, typically decimal 19 or hex 13, until the input buffer has been emptied. Once the receiver is ready for more data it sends XON, typically decimal 17 or hex 11, to resume communication. LabWindows will send XOFF when its input buffer becomes half full. In addition, in case the XOFF transmission was corrupted, LabWindows will also transmit XOFF when the buffer has reached 75% and 90% capacity. Obviously, the transmitter must also be following this protocol for it to succeed. The biggest drawback to this method is also the most important fact to keep in mind: decimal 17 and 19 are now off limits for data values. In ASCII transmissions this typically does not matter since these values are non-character values; however, if the data is being transmitted via binary, it is very likely that these values could be transmitted as data and the transmission would fail.

10

b. Hardware Handshaking:

c.

The second method of handshaking is to use actual hardware lines. Like the Tx and Rx lines, the RTS/CTS and DTR/DSR lines work together with one being the output and the other the input. The first set of lines are RTS (Request to Send) and CTS (Clear to Send). When a receiver is ready for data, it will assert the RTS line indicating it is ready to receive data. This is then read by the sender at the CTS input, indicating it is clear to send the data. The next set of lines are DTR (Data Terminal Ready) and DSR (Data Set Ready). These lines are used mainly for modem communication. They allow the serial port and the modem to communicate their status. For example, when the modem is ready for data to be sent from the PC, it will assert the DTR line indicating that a connection has been made across the phone line. This is read in through the DSR line and the PC can begin to send data. The general rule of thumb is that the DTR/DSR lines are used to indicate that the system is ready for communication where the RTS/CT S lines are used for individual packets of data. In LabWindows, the function SetCTSMode enables or disables the use of hardware handshaking. If the CTS mode is enabled, LabWindows employs the following rules: When the PC sends data: The RS-232 library must detect that its CTS line is high before sending data. When the PC receives data: If the port is opened and the input queue has room for data, the library raises RTS and DTR. If the port's input queue is 90% full, the library lowers RTS and leaves DTR high. If the port's input queue is nearly empty, the library raises RTS and leaves DTR high. If the port is closed, the library lowers RTS and DTR.

XModem Handshaking: The last mode discussed here is the XModem file transfer protocol. This protocol is very common in modem communication. Although it is often used for modem communication, the XModem protocol can be used directly between other devices if they both follow the protocol. In LabWindows, the actual implementation of XModem is hidden from the user. As long as the PC is connected to another device using XModem protocol, the LabWindows' XModem functions can be used to transfer files from one site to another. The functions are XModemConfig, XModemSend, and XModemReceive. XModem uses a protocol based on the following parameters: start_of_data, end_of_trans, neg_ack, ack, wait_delay, start_delay, max_tries, packet_size. These parameters need to be agreed upon by both sides, and standard XModem has a standard definition of these; however, they can be modified through the XModemConfig function in LabWindows to meet any requirement. The way that these parameters are used in XModem is by having the neg_ack character sent by the receiver. This tells the sender that it is ready to receive data. It will try again with start_delay time in-between each try until either it reaches max_tries or receives start_of_data from the sender. If it reaches max_tries it will inform the user that it was unable to communicate with the sender. If it does receive start_of_data from the sender, it will read the packet of information that follows. This packet contains the packet number, the complement of the packet number as an error check, the actual data packet of packet_size bytes, and a checksum on t he data for more error checking. After reading the data, the receiver will call wait_delay and then send ack back to the sender. If the sender does not receive ack, it will re-send the data packet max_tries or until it receives ack. If it never receives the ack, it informs the user that it has failed to transfer the file. Since the data must be sent in packets of packet_size bytes, when the last packet is

11

sent, if there is not enough data to fill the packet, the data packet is padded with ASCII NUL (0) bytes. This can cause the received file to be larger than the original. It is also important to remember not to use XON/XOFF with the XModem protocol since the packet number from the XModem transfer is very likely to increment to the XON/OFF control character values, which would cause a breakdown in communication.

3.6 Performing a Loopback test in LabVIEW

Note: For a free evaluation copy of LabVIEW, visit ni.com/trylabview

1. Start LabVIEW

[+] Enlarge Image

2. Select Help»Find Examples...

12

[+] Enlarge Image

3. Browse to Hardware Input and Output»Serial»Basic Serial Write and Read.vi

[+] Enlarge Image

13

4. Ensure the proper settings are selected, enter the string you would like to write in the "string to write" box, and then select the white run arrow on the toolbar.

14

3.7 Texas Instruments 2808 DSP Serial Port Specifications

15

16