6 Suggested steps to be taken

It would be beneficial to have two pieces of data about S1883 UART:

1. What is its maximum baud clock rate and the resulting maximum baud rate?
2. Is the baud clock rate 16 times the desired baud rate, as with many other UARTs?

If the second spec cannot be found, the baud clock vs. baud rate can be discovered by measuring the current clock used for 9600 baud.

If the maximum baud clock rate is not known, it needs to be evaluated if it is safe to just try a higher rate of can it possibly damage the S1883. (Are spare parts available?)

I would suggest that AJB and/or JW try to find this information, if possible. (The Dwingeloo data book library was searched once, to no avail.)

This step will require:

1. The FS PC running a Kermit terminal emulator, either on MS-DOS or Linux. I (AMN) will supply this. Note that at this stage we are not yet verifying whether Linux is suitable for 115200~baud communications, we are verifying if the S1883 UART will do 115200~baud.
2. A suitable cable: the existing cable may be suitable, a 25-to-9-pin ``dongle'' may make it compatible, or a new cable can be made. I'd suggest that AJB and/or JW do this.
3. A ``test-mode'' oscillator for 115200 baud is needed. Again, I'd assume that AJB and/or JW will best be able to come up with one. I'll need assistance for a short period in using this test setup, something like 0.5--1.5 hours.

We need a suitable cable to connect the data buffer to the FS PC ``COM2:''. I'm not sure if this port is similar to the DigiBoard ports used this far, I'd suspect not and I'd assume it is a 9-pin port.

A computer-to-modem RS232 cable should be compatible with the data buffer, that is a cable which connects perhaps all 25 but at least the following lines (1, 11, 18, 22 are not used at the PC end, they are included just to show the lines connected in data buffer, schematics ``6004-076''):

PC                female DB25 --- DB25 m/f?  Data buffer
TxD   Transmit Data         2  -> 2       Data in
RxD   Receive Data          3 <-  3       Data out
RTS   Request To Send       4  -> 4       (RTS, not used)
CTS   Clear To Send         5 <-  5       Clear To Send (+12V)
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
DCD   Carrier Detect        8 <-  8       Carrier Detect (unused)
GND   Signal Ground         7 --- 7       GND   Signal Ground
DTR   Data Terminal Ready  20 --> 20      Data Terminal Ready (sensed)
                            1 -?- 1       (protective ground)
      unused               11 <-  11      (On-line status, +12V)
      unused               18 <-  18      (Dial initiate, -12V)
RI    Ring Indicator       22 <-  22      (Ring indicator,  unused)


Alternatively, a IBM PC 9-pin serial connector DB9-DB25 modem cable
(or a "dongle" that provides these crossovers) can be used:

PC                 female DB9     DB25 m/f?  Data buffer
DCD   Carrier Detect        1 <-  8       Carrier Detect (unused)
RxD   Receive Data          2 <-  3       Data out
TxD   Transmit Data         3  -> 2       Data in
DTR   Data Terminal Ready   4  -> 20      Data Terminal Ready (sensed)
GND   Signal Ground         5 --- 7       GND   Signal Ground
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
RTS   Request To Send       7  -> 4       (RTS, not used)
CTS   Clear To Send         8 <-  5       Clear To Send (+12V)
RI   Ring Indicator         9 <-  22      (Ring indicator,  unused)

If a suitable cable is not available ready-made and a new cable is decided to be built, the following minimal connections should do the trick. Note that to enable hardware flow control (that is the ``RTS'' signal on PC inhibiting further incoming characters from the data buffer) these cables must be used. Linux expects serial port devices to behave like modems. Modems do not sense ``DTR'' line to decide if they can transmit more characters to the computer: if ``DTR'' drops low, this is an indication to the modem that the computer (or terminal) connected to it has been switched off and the modem connection should be broken. (This is how RS232 describes these signals and their function with modems.) The confusion arises because there are many serial devices such as printers out there that use ``DTR'' to signify that they cannot accept more characters. The Mark~III data buffer was designed to be connected to a computer that is designed to communicate with these non-standard RS232 devices.

PC                female DB25 --- DB25 m/f?  Data buffer
TxD   Transmit Data         2  -> 2       Data in
RxD   Receive Data          3 <-  3       Data out
RTS   Request To Send       4  -> 20      Data Terminal Ready (sensed)
CTS   Clear To Send         5 <-  5       Clear To Send (+12V)
                            | (wire for 5 or 6)
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
                            |
DCD   Carrier Detect        8     8       Carrier Detect (unused)
GND   Signal Ground         7 --- 7       GND   Signal Ground
DTR   Data Terminal Ready  20
                            1 -?- 1       (protective ground)
                                  4       (RTS, not used)
                                  11      (On-line status, +12V)
                                  18      (Dial initiate, -12V)
                                  22      (Ring indicator,  unused)


Alternatively, a IBM PC 9-pin serial connector DB9-DB25 modem cable:

PC                 female DB9     DB25 m/f?  Data buffer
RxD   Receive Data          2 <-  3       Data out
TxD   Transmit Data         3  -> 2       Data in
DTR   Data Terminal Ready   4
GND   Signal Ground         5 --- 7       GND   Signal Ground
DSR   Data Set Ready        6 <-  6       Data Set Ready (+12V)
                            | (wire for 5 or 6)
CTS   Clear To Send         8 <-  5       Clear To Send (+12V)
                            |
DCD   Carrier Detect        1     8       Carrier Detect (unused)
RTS   Request To Send       7  -> 20      Data Terminal Ready (sensed)
RI   Ring Indicator         9     22      (Ring indicator,  unused)

The cable used must be first verified by trying it with the unmodified 9600~baud data buffer. A terminal emulator program like Kermit is invoked on ``COM2:'' (or ``/dev/cua1'' in Linux) with the settings ``9600 baud, 8 data bits, 1 stop bit, hardware handshake'' and an ``ESC'' character is sent to data buffer. The green ``Active'' LED on the data buffer back panel should be lit now. (The buffer should also respond with a maximum of four characters which are in binary and appear like more or less garbage in a terminal emulator.)

Other command characters that can be tested by just typing them at the terminal emulator are:

• ``%'': Should switch off the ``Active'' LED. After this, the data buffer will require another ``ESC'' to reactivate it to respond to other command characters, not just the ``ESC'' character.
• ``!'': Arm the buffer to wait for incoming data, lits up the ``Arm'' LED.
• ``:'': Reset the armed state, switches off the ``Arm'' LED.
• ``23+'': Set the active block number to be hexadecimal ``23'' for a subsequent ``?''. This should show up in the 4-character response as a ``#'', ``24+'' as ``$'', ``25+'' as ``%'', and so on.
• ``?'': Start downloading 512-byte block of buffer data. Should show garbage characters on screen: it is a message of 516 more or less random bytes coming into the terminal emulator program.
• ``0-'': Load a test pattern in data buffer RAM. ``0'' can be a hex digit 0--C to select different patterns, see page DB-17 of the data buffer manual. Should first lit the ``Take'' LED and after the pattern is loaded, the ``Hold'' LED. The pattern invoked by ``6-'' should be quite visible when looked at with ``?'' because it consists of a sequence of ``55, 55, AA, AA,...''

If the cable connection seems ok, then a (temporary?) higher baud rate clock should be fed into the circuitry at pin 19 of ``5046'' (with the ``5046'' removed from its socket.)

The baud rate of Kermit should be changed to 115200 baud and the tests above repeated. An oscilloscope comparison of incoming/outgoing RS232 signals should reveal if the pulse forms are ok.

If the S1883 UART fails to perform at 115200 baud we have to:

After I have received a FS PC compatible hard disk that I can use in both FS PC and my Dwingeloo PC I'll be able to test new software that I'm writing that will interact with the data buffer, either unmodified or the ``new'' 115200 baud one.

I will need to test my software with the unmodified data buffer first to make sure it performs the functions required at the standard speed. After this we could have the temporary 115200 setup for a couple of hours (or the permanent one described in the next step, if that is deemed easy enough to create.) During this period the true throughput after all software overhead effects can be measured and the final decision if we'll permanently modify the buffer can be made.

Tests with a ``simulated'' 115200 baud data buffer (an MS-DOS PC running a dedicated program acting like the ``real'' data buffer) seem to indicate that:

1. Readout of the complete 128~kB buffer is feasible in under 13~seconds.
2. With 16450 UARTs this won't simply work, Linux (nor any other operating system) cannot handle serial interrupts arriving that often.
3. With 16550A UARTs with their 16-byte FIFO buffers dropouts are very seldom, but they do occur. It is expected that this can be easily recovered by requesting a retransmission of the failed 516-byte block.
4. DigiBoard (or other serial cards with large input buffers) should prove ideal to this data buffer application and they should be able to guarantee that no data loss can occur.

Since I suspect that the ``5046'' baud rate generator chip won't run with much higher crystal frequencies than the current 5.0688~MHz, I'd suppose that the easiest way to have a new ``permanent'' oscillator would be to fit a crystal oscillator module with a TTL output into a socket and put that into the place of ``5046'' chip. Again, I assume that AJB and/or JW can provide a good solution to this.

I will continue to create a replacement ``pcalr'' phase cal detection software combining there ingredients of my diagnostic data buffer software, the existing ``pcalr'', Sergei Pogrebenko's multiple phase cal tone detection algorithm (presented in VLBI Memo #029), and possibly another version of the algorithm developed by Kaj Wiik at Metsähovi.