Establishing Seatalk Communications

The first step in the project was to get some minimal hardware and software running to communicate with the autopilot.  This would help to clarify ideas and ensure that the protocol described by Thomas Knauf was properly understood.  The hardware and software would also provide a core around which the complete project could be built.

The aims of this step were therefore to create the hardware and software to echo Seatalk datagrams to the PC, and to be able to send Seatalk datagrams to the autopilot under control of the PC.
 

Hardware Design

It was decided at the outset that the hardware would be based around the PIC16F628 from Microchip Inc.   The choice was mainly based on the fact that a number of these chips were to hand, however it has the following advantages that make it suitable for this project: The PIC's signal levels must be converted to interface with the Seatalk bus and with a PC's serial port.  Basically this is done with a single common-emitter transistor on each line.  The PIC is programmed to use its internal oscillator, so no other components are needed.  More details of the hardware and a circuit diagram are provided here.
 
 
 

Software Design

It was decided that the Seatalk pins should be driven under programmed control ("bit-banged") since the on-board UART is more usefully connected to a PC for debugging (or, in future, the NMEA0183 output of my GPS).  Rather than use in-line timing delays as is commonly done with PIC serial software, it was decided to use Timer 2 (which has a period register) to define the bit period, 208us for 4800 baud.  However the first version of the software still uses a tight loop to wait for the timer so it is.functionally identical to an in-line delay.  The major shortcoming of this type of code is that the CPU is not available to perform other operations while processing a receive or transmit operation.

The commented MPASM source code for these routines is given here.  A functional description of the various routines that complements the in-line comments is given here.

The source code includes routines to test the receive and transmit routines, both together and individually.    A simple Visual Basic program that interfaces with the test software and enables the user to view received bytes and send commands is given here.
 
 

Results and Comments

Tests of the receive routines with the ST 2000+ connected to the circuit reliably reported the "84" and "9C" datagrams regularly transmitted by the autopilot.

Tests of the transmit routines were able to cause the autopilot to respond to all remote-control commands, including "set auto" and "set standby"   Multiple commands sent immediately after one another (eg. 20 "+1"'s)  repeatedly produced the correct change in the autopilot course display showing that collision detection was probably functional. However this could not be explicitly tested.

One possible shortcoming of the collision detection routine is that the bus is that the check is performed at the end of each bit period, instead of at the centre which gives the highest probability of detection.  While it is unlikely that this has any real effect on performance, it needs to be verified preferably in a busy Seatalk environment.

The greatest shortcoming of these routines is that it is not easy to run both the transmit and receive functions simultaneously as well as do other tasks.  While a simple transmit-only remote control is entirely possible with these routines, the PIC is obviously capable of doing much more.

In summary, the routines were successful in that data was reliably transferred to and from the autopilot, however the strict timing requirements meant that the integration of these routines in a useful program of any complexity would be difficult.