þa‹Rþw5þ m Y<þhý oþ nSystem-wide^FO "" "Page ^P" "" ^FL 62 To: Debra Cantrall, E-Systems From: William Strang, GRiD Systems Subject: GCS observations with 89th FMS operators Date: 6/7/88 CC: Chuck Fay, E-Systems; Jim Young, E-Systems; Jim Hanson E-Systems On the afternoon of Tuesday, 17 May 1988, Dennis Stockman and I visited E-Systems and the 89th FMS at Andrews AFB for the purpose of observing the GCS in operation, including problems the 89th's operators have been having in using it. We spent from about 1:25 pm to about 4:00 pm on the plane, most of that time with operator Ed Moren and myself seated at the MCS console, with a small crowd of other interested parties standing behind us. The names I caught among the interested parties were Jim Hanson and Robert Owens of E-Systems; Kevin Carlton and Kenny Morris of Electrospace Systems, Inc (ESI), who represent DCA and are concerned with systems interoperability between the MCS and Mystic Star; and airman Whedon of the 89th FMS Avionics crypto shop. There were a number of others present. Jim Young of E-Systems came by at the end. Ken Busarow was not present, and I saw no WHCA people present. In this document, the term "circuit" is used to refer to the equipment in the MCS that the GCS is communicating through, which could be any one of many possible combinations of a crypto and/or modem and a radio or loopback. Ed Moren gave me copies of two MCS Action Items he had originated that concerned the GCS, with control numbers A-07 and A-17. Ed ran a number of communications tests for us, using the MCS and one or both of the two GCS stations. He did not communicate with anything outside the MCS as part of these tests. Release 1.0.4 of the GCS was in use. Following are discussions of a number of items seen or discussed during testing, in roughly chronological order. 1) Ed explained that almost any of the possible communications circuits would occasionally stay keyed after the GCS had keyed it and then unkeyed. Ed said that when this happened, keying and unkeying the GCS again would sometimes unkey the circuit, and that turning the 1137 or the modem off and back on would always unkey the circuit. He said that switching the computer out of the circuit would not unkey the circuit, and that the GCS software always acted like it had unkeyed properly when this problem happened. This is an occasional problem, not reproducible on demand. It did happen at one point during our testing, on a circuit consisting of a KG-84, a 233 modem, and an unknown radio. Ed demonstrated that switching the computer out of the circuit did not unkey the modem. When the problem happened, a breakout box between the 1137 and the switch showed the 1137's RTS line as correctly being in the False (negative voltage) state, which should unkey the switch. GRiD response: GRiD thinks that this problem is not caused by any deficiency in the 1137 or the GCS. The erratic occurance of the problem, the lack of any associated software symptoms, the observed correct state of RTS when the problem occured, and the failure of switching the computer out of the circuit to unkey the circuit, all support this position. 2) Ed noted that while the GCS computer was turned off, connecting it to almost any communications circuit would key that circuit. He demonstrated this on one circuit. Measurement with the breakout box's built-in voltmeter showed .891 to .895 volts (positive) on the RTS line from the switch when the computer was physically disconnected from the switch. GRiD analysis: The RTS pin has a high impedance state, close to (but not identical to) being open (unconnected), when the 1137 is turned off. Open is an undefined state for RS-232. Many serial receivers, such as those on IBM PC COM port compatible serial ports, interpret open as false. Some serial receivers, such as those on the GRiD 19 pin serial port, interpret open as true. We did not check how the switch interprets open on an RTS input. GRiD response: GRiD thinks that this problem is a function of the switch, and not caused by any deficiency in the 1137. Since the computer is turned off when the problem happens, it cannot be caused by the GCS, and hence it is not caused by any deficiency in the GCS. 3) Ed demonstrated operational problems relating to transmit character buffering and the Interrupt Transmit command. Specific items observed were: a) In Full Duplex, there is no visible indication when transmitting has stopped, due to either Interrupt Transmit or normal end of data, except that display in the transmit window stops if it is enabled. During some of our tests, it was difficult or impossible to tell from the GCS screen exactly when the system had stopped transmitting and lowered RTS. GRiD analysis: It would indeed be more informative to have some indication of when the system is transmitting while in Full Duplex, such as changing "Full" to "Full-T". For example, when transmitting files with transmit display turned off or in full screen edit mode, one cannot tell from the screen when transmitting has stopped or why transmitting has stopped, whether due to completion or CTS becoming false or external clock stopping. GRiD response: The handling of this field is specified on page 30 of the GCS Critical Item Product Functional Specification, and is documented on page 13 of the GCS CDR agenda, without any subsequent modifying directions from E-Systems, so any change would be out of scope. b) When the system is transmitting at low speeds such as 75 baud, it can take too long, from the operator's point of view, for Interrupt Transmitter to take effect and transmitting to stop. While sending from files or the editor, over 20 seconds can elapse from when the operator hits Interrupt Transmitter to when transmitting actually stops. Ed's opinion is that transmitting should stop immediately. GRiD analysis: The way Interrupt Transmitter actually works is that transmitting stops only after the current block of characters finishes displaying and transmitting, which can take a while. The block size is 256 characters when transmitting from files or the editor, which will take at least 25.6 seconds to transmit at 75 baud (10 cps). Thus, Interrupt Transmitter can take up to about 25 seconds to take effect. GRiD response: The logic used for transmit data buffering and the Interrupt Transmitter command is documented on pages 8, 11, and 12 of the CDR agenda, without any subsequent modifying directions from E-Systems. The block size to be used is documented on page 11 of the CDR agenda. Hence, any changes would be out of scope. c) While transmitting at 75 baud (10 cps) from Interactive Keyboard the user can buffer up a lot of characters by holding 2 keys down for a while, which puts keys in the buffer at about 40 cps, and the transmitter cannot be interrrupted and will not stop until all the buffered characters have been sent. Interrupt Transmitter does not work in Interactive Keyboard. GRiD analysis: Interrupt Transmitter is not implemented in Interactive Keyboard, but even if it were, the block size in Interactive Keyboard is all buffered characters. Transmission of a full buffer of over 65,000 characters can take a long time. The user can indeed put a lot of characters in the transmit buffer in Interactive Keyboard by holding down 2 keys for a while, but normally a transmit speed of 75 baud (10 cps) should keep up with a typing speed of about 100 words per minute, which is quite fast. GRiD response: The logic used for transmit data buffering and the Interrupt Transmitter command is documented on pages 8, 11, and 12 of the CDR agenda, and there have been no subsequent modifying directions from E-Systems. Hence, any changes would be out of scope. GRiD maintains that buffering lots of characters in Interactive Keyboard by holding down 2 keys is an artificial and unrealistic situation, and that a 10 cps transmit rate will keep up with operator input at normal typing speeds. 4) Ed demonstrated operational problems relating to receive character buffering and the Clear Buffer command. He explained that a receiving GCS station would sometimes display a large number of noise characters, either ahead of or instead of the data transmitted, and that there was no way to stop the display of these noise characters once it had begun. When he was transmitting from one GCS station to the other, in one test a large number of noise characters was indeed received. They were displayed, taking over 30 seconds, and both Clear Buffer and turning off Display Receive did not stop the display. In other tests, large numbers of noise characters were not received, but when large amounts of actual data were received and took a long time to display, both Clear Buffer and turning off Display Receive did not stop the display. Clear Buffer and turning off Display Receive did not stop display of noise or data even when receiving was completed and only the remaining buffered data was being displayed. GRiD analysis: The large numbers of noise characters sometimes received are not being created by the GCS itself; they represent real activity on the received data line. They may come from noise in the circuit, from non-synchronized or mis-synchronized modems or cryptos, from data inversions in the circuit, or from some combination of these causes. The pattern of occurance described suggests synchronization problems. The commands for Clear Buffer and turning off Display Receive do not work well while the GCS is busy receiving and/or displaying data at medium to high speeds, because they can take a very long time to take effect. Part of the problem appears to be that the process that displays received characters does so in blocks, and it will only respond to Clear Buffer and turning off Display Receive between blocks. The block size is all the characters in the buffer when the display process finishes the previous block. When a message is being received at 16000 bps, over 75% of the characters in the message can end up being displayed in one block, because characters are being received much faster than they can be displayed. Another part of the problem appears to be that while the 1137 is receiving characters at high speed, such as 16000 bps, most of the processor time is being used for interrupt handling, so the processes handling command detection and received character display will take much longer in wall clock time to respond to commands, because they are getting very little processor time. GRiD response: GRiD thinks that the noise characters received are a result of actual activity on the 1137 receive data input line, and are not the result of any deficiency in the GCS or the 1137. The GCS Critical Item Product Functional Specification does not mention any filtering of displayed characters for noise, and the Ammendment to the Minutes of the CDR for the GCS, in paragraph 3, says "The receive subsystem will not filter any incoming characters, including carriage returns and linefeeds, prior to capture." Therefore, any change would be out of scope. The logic used for Clear Buffer is documented on pages 8, 9, and 10 of the CDR agenda, without any subsequest modifying directions from E-Systems. The CDR agenda does not document the block size to be used. The ability to turn off Receive Display was added to the GCS design after the CDR agenda, but its logic closely follows that used for Clear Buffer. Since the long delays in responding to both these commands is inconsistent with their function, so GRiD considers this to be a GCS deficiency. The GCS should respond to these commands more quickly. Note that making the GCS respond quickly to Clear Buffer commands will not neatly solve problems with undesired noise being received ahead of desired data. Clear Buffer will delete data just as easily as noise, and cannot discriminate between the two. Paragraph 3.2.1.3.a of the GCS Critical Item Product Functional Specification specifies for the Clear Buffer function that "This function will clear the buffer regardless of the buffer contents and regardless of printer status." There is no way for the user to predict when to enter Clear Buffer to delete just the noise and not the following data. Turning off Display Receive briefly will avoid displaying buffered noise characters, but will also avoid displaying buffered data characters. A much better solution to this problem is to find and eliminate the source of the noise. 5) Ed demonstrated some tests they had done with communicating between 2 GCS stations set for different parities and/or data bits. The tests were: a) The sending GCS station was set for 7 data bits and odd parity. The receiving GCS station was set for 8 data bits and no parity. Both stations were set for external clock, with a 16 Kbps KY clock being supplied. The receiving GCS station would receive when transmitted to, but about half the characters would be properly displayed and the rest would be replaced by various "noise" characters, in no obvious pattern. Then, after some amount of data was received, the receiving GCS station appeared to stop displaying received characters for a while, though the transmitter was still sending characters. At some point, display of received characters appeared to resume, with about half the characters still replaced by "noise" characters. This behavior was repeatable. GRiD analysis: The "noise" was seen because the receiving GCS station was displaying about half the received characters shifted from the lower 128 characters (ASCII) to the upper 128, because the transmitted parity bit was being interpreted as the high order data bit. Statistically, about half the time the parity bit will be one, which adds 128 to the character value in this case. The upper 128 characters are displayed as various graphics and special characters under GRiD-OS, which would indeed look like noise when displayed this way. It is not clear what caused the GCS to stop displaying (or appear to stop displaying) received characters. I have not been able to reproduce this in my test configuration. It may be caused by several mechanisms interacting with each other, such as the effect discussed just below. One misleading effect caused by the 8 bit interpretation of 7 bit data with odd parity is that Line Feeds, containing 2 one bits, get a one parity bit and so are not interpreted as Line Feeds by the receiver. Carriage Returns, containing 3 one bits, get a zero parity bit and are properly interpreted. When lines of characters are received with Carriage Returns but without Line Feeds, each line is displayed overwritten on the preceeding line, instead of being displayed below it. Thus, all the lines of characters are displayed overwritten on each other, instead of scrolling down the screen. This can make it harder to tell that characters are still being displayed. If a group of received lines are identical, there will be no visible change on the screen as they are displayed, since each will overwrite the previous line with the same characters. In this case, it will be impossible to tell that characters are still being displayed. GRiD response: The GCS Critical Item Product Functional Specification does not contain any requirement that the software receive characters with a different number of data bits and different parity than it is currently configured for. Any change would be out of scope. b) The sending GCS station was set for 7 data bits, 2 stop bits, and no parity. The receiving GCS station was set for 8 data bits, 2 stop bits, and no parity. Both stations were set for external clock, with a 16 Kbps KY clock being supplied. The receiving GCS station would display only "noise" characters, though it seemed to be displaying about the same number of characters as was transmitted. Someone asked if the GCS could be modified to display the characters transmitted under these circumstances. GRiD analysis: The receiving GCS station was displaying all the characters that were received, but with the characters shifted from the lower 128 characters (ASCII) to the upper 128 because the transmitted first stop bit was being interpreted as the high order data bit by the receiver. The upper 128 characters are displayed as various graphics and special characters under GRiD-OS, which would indeed look like noise when displayed this way. GRiD response: The GCS Critical Item Product Functional Specification does not contain any requirement that the software receive characters with a different number of data bits than it is surrently configured for. Any change would be out of scope. c) Someone asked why the GCS was not reporting parity errors during the two preceeding tests, and whether it would report parity errors to the user. GRiD analysis: The GCS does check for parity errors in received data, and it will display the message "Parity Errors Found in Received data" on the Error/Prompt Line when parity errors are detected. The GCS can detect parity errors in received data only when the receiving GCS station is set for odd or even parity, which did not happen in either of the preceeding tests. In a related area, the GCS does not detect or report framing errors in received data. Framing errors can occur in some (but not all) situations where two GCS stations are set for different numbers of data bits and/or parities, even if parity errors are not occuring. Framing errors would not be caused by either of the two preceeding tests. GRiD response: The GCS does detect and report parity errors in received data, according to the parity set in the receiving GCS station. The GCS Critical Item Product Functional Specification does not contain any requirement that the software detect or report framing errors in received data, and there have been no subsequent modifying directions from E-Systems. Any change would be out of scope. 6) There were some questions about exactly how the GCS handles the Compass serial port control and clock signals. Specific questions were what sequence the GCS follows in keying a half duplex channel, and what the GCS does when the transmit clock signal goes idle during an externally clocked transmission. GRiD response: In keying a half duplex channel, the GCS does the following: a) It asserts (sets to true) the RTS signal; b) It waits (possibly forever) for the CTS signal to be or become true; c) It delays 3 seconds, to allow cryptos and radios to sync up; d) It starts transitting data. When the transmit clock signal goes idle while data is actually being transmitted on an externally clocked channel, the GCS transmit logic will freeze where it is until transmit clock is restored. While the transmit logic is frozen, the Interrupt Transmitter function will have no effect until transmit clock resumes. When transmit clock resumes, data transmission will resume from exactly where it stopped. If the Interrupt Transmitter function was selected while the transmit logic was frozen, it will take effect when the current block of characters finishes displaying and transmitting (see 3b and 3c above). 7) Ed noted that the GCS main menu scrolls up one line when the selection box is moved to the bottom line of the menu, even though the bottom line is fully visible before the scrolling. He asked if something could be done to avoid this scrolling. GRiD analysis: The main menu scrolls up in this case because otherwise there is not enough space for Common Code to display the selection box and border space it requires below the bottom menu line. There would need to be 6 pixels of empty space below the bottom menu line to avoid the scrolling. GRiD response: The location and sizes of the items in the GCS main menu screen display is fully specified in the GCS Critical Item Product Functional Specification, in paragraph 3.2.1.5. Because of the way the GRiD menus work, additional vertical space would be required to prevent the main menu from scrolling in this case. There is no unused vertical space on the screen to add to the main menu. The Minutes of the PDR for the GCS, on page 4, say "Menus can be done in the normal GRiD menu fashion provided that a +alpha key sequence may also be used." Any change would be out of scope. 8) Ed noted that in the GCS editor, the Return key moves the cursor to the next line, but not always to the left margin. If the current line is indented with space characters, Return will move the cursor to the next line, but indented the same amount as the current line. He asked if the GCS editor could be modified to make Return always move the cursor to the left margin on the next line. GRiD analysis: The above paragraph accurately describes how the Bufferedit library works. In GRiDWrite, from which Bufferedit is derived, the action of Return can be controlled to indent or not indent, by setting the "Automatic indent" field in the Options menu to "Yes" or "No". When Bufferedit was created, since it has no options menu, "Automatic indent" was permanently set to the GRiDWrite default state of "Yes". GRiD response: The GCS Critical Item Product Functional Specification, in paragraph 3.2.1.6, specifies that the GCS editor shall support the functions found in the Grid Bufferedit editor, with a specified set of changes. Further changes to Bufferedit were specified at the PDR and CDR for the GCS, but this change was not. Any change would be out of scope. 9) Ed noted that when the "Restart the Computer" line on the "System Options" menu is selected, it takes several minutes for the computer to restart and display the GCS startup form. He asked if a way could be made to move quickly from operating the GCS to the startup form. GRiD analysis: Booting the computer takes several minutes, and is definitely not a fast way to get to the GCS startup form. In the specification and design of the GCS, it was thought that the values set in the startup form would seldom be modified, so that relatively slow access to them would not be a problem. GRiD response: The GCS Critical Item Product Functional Specification, specifies the commands of the GCS and their actions. It does not specify a fast return to the startup form, and no such requirement was added by E-Systems. The "Restart the Computer" line on the "System Options" menu does what it is specified to. Any change would be out of scope. 10) Ed noted that in the menus for "Transmit Messages", "Print Messages", "Delete Messages", and "Copy Messages", the "..... All Messages" line is first and the "..... Tagged Messages" line is third. He asked if these two lines could be swapped in these four menus. He noted that the "..... All Messages" line is seldom selected, and the "..... Tagged Messages" line is often selected. GRiD response: The GCS Critical Item Product Functional Specification, in paragraph 3.2.1.4.c, specifies the form of the "Delete Messages" to be effectively as it now is. Informal discussion with E-Systems and 89th FMS personnel suggested that other menus adopt that form where appropriate. These four menus had their present form when demonstrated at CDR, and E-Systems gave no modifying instructions concerning them. Any change would be out of scope. 11) MCS Action Item A-07 describes an error condition wherein a message is added to a devices' directory, even though a mass storage error prevents the message itself from being stored on that device. GRiD analysis: The error condition described in MCS Action Item A-07 is repeatable, and a similar error occured when an attempt was made to store a message on a floppy disk when the floppy disk drive door was open. We were able to remove the message from the message directory by permorming "Delete Messages" on it, though another mass storage error occured because the message did not exist on the mass storage device. GRiD response: The GCS should keep the message directory file consistant with the contents of the mass storage device when mass storage errors occur. This does not occur in this situation, so GRiD considers this to be a GCS deficiency. 12) MCS Action Item A-17 describes a condition wherein large numbers of "noise" characters are received ahead of data characters, with the noise taking several minutes to be displayed on the GCS screen. GRiD analysis: This problem is the same as those discussed in section 4, in that it involves receiving characters that are not desired and the time required to display these characters. The same long delays in the GCS responding to Clear Buffer and turning off Display Receive will be seen. GRiD response: As in section 4, GRiD thinks that the noise characters received are a result of actual activity on the 1137 receive data input line, and are not the result of any deficiency in the GCS or the 1137. GRiD thinks that making making the GCS respond to Clear Buffer and turning off Display Receive more quickly can help the user control received noise more effectively, as discussed in section 4. But again, it must be noted that making the GCS respond quickly to Clear Buffer commands will not neatly solve problems with undesired noise being received ahead of desired data. Clear Buffer will delete data just as easily as noise, and cannot discriminate between the two. Paragraph 3.2.1.3.a of the GCS Critical Item Product Functional Specification specifies for the Clear Buffer function that "This function will clear the buffer regardless of the buffer contents and regardless of printer status." There is no way for the user to predict when to enter Clear Buffer to delete just the noise and not the following data. Turning off Display Receive briefly will avoid displaying buffered noise characters, but will also avoid displaying buffered data characters. A much better solution to this problem is to find and eliminate the source of the noise.