Host port states proposal (version 1)

Hi guys,

We've been discussing how a host can detect when a new PUCK-enabled instrument has been plugged into an observing system, and how to detect when an instrument has been unplugged. We've been looking at the following scenarios:

A. An instrument is plugged into a previously empty port

B. An instrument is removed from a port

C. Instruments are exchanged on a port - one instrument is removed and replaced with another.

From the experience at UPC, Kiel, and MBARI we've identified a few issues:

1. To "discover" and identify a PUCK-enabled instrument on a port, the host must issue a PUCK "soft break" at several baud rates until the instrument responds with the PUCK prompt. The host then must request the instrument's UUID and perhaps other information. This process can take many seconds. If an instrument driver is already running on the port, the discovery protocol can interfere with instrument sampling. This is especially problematic when trying to automatically detect when instruments have been exchanged (scenario C).

2. It is difficult to determine when an instrument has been unplugged and the port is empty (scenario B). When an instrument is physically removed, then of course the host will not receive any response  to serial commands (including PUCK commands). But there are cases when an instrument remains physically plugged in, but is unresponsive (e.g. lost power, instrument malfunction).

As Jesper points out, we could modify PUCK protocol such that the instrument "announces" itself when it is plugged into a port. However then manufacturers might have to make extensive changes to their instrument firmware as well as instrument utilities (e.g. GUIs). Also, we want to keep PUCK protocol unobtrusive; users should not have to deal with PUCK if they don't want to.

As an alternative, I propose the following strategy for host computers, assuming that PUCK protocol does NOT change:

1. The host can automatically determine when a PUCK-enabled instrument is plugged into an empty port (scenario A), through the discovery protocol described above.

2. The user must manually notify the host when an instrument is being removed, with an "eject" command. Note that this is not part of PUCK protocol; rather it is a command issued by the user, telling the host that an instrument has been removed from a specific port.

The host software must track the port state, as shown in the attached PDF. Now scenario A (new instrument plugged into empty port) is very automatic; the host just issues PUCK soft breaks to an empty port until it receives a response. Scenario B (instrument removed) now has a manual step; the user must issue an "eject" command when unplugging the device. Scenario C (instruments exchanged) is now viewed as a sequence of scenario B followed by scenario A. This requirement for a manual "eject" command is perhaps not too terrible; after all, this is also strictly required for USB under most operating systems.

What do you think?

Regards,
Tom