Prevent FTDI Reset on Serial Open/Close (Raspberry Pi OS)

[BioCam]

The Problem

When using the Inheco Incubator Shaker (IIS) on a Raspberry Pi I noticed the following issue:

When I use a Jupyter notebook with the IIS it works very well, but when restarting the kernel not only is the IIS not found but the actual port has disappeared completely!

Chat thinks:

1. Jupyter kernel restarts → Python process dies → its serial fd is closed.
2. Closing the fd / reopening the port causes pyserial / kernel driver to touch DTR/RTS.
3. On the Inheco board specifically, DTR/RTS appear to be wired so that: toggling them resets or power-cycles the FT232B or the controller.
4. That reset shows up to the Raspberry Pi as a real USB disconnect.
5. The kernel then logs device disconnected, and removes /dev/ttyUSB1.

This is confirmed by my system logs:

ftdi_sio ttyUSB1: ... now disconnected

-> even though the cable never moved!

Note: I never saw this behaviour when using the IIS on a Mac - this might be specific to RPi Linux (Raspian)...

PR Content

This patch changes the behavior of PyLabRobot's Serial class so that after the serial port is opened, the following commands are applied:

self._ser.dtr = False
self._ser.rts = False
self._ser.setDTR(False)
self._ser.setRTS(False)

This ensures that the FTDI driver does not toggle the DTR or RTS lines when opening or closing the serial port.

By doing this:

• The Inheco device no longer disappears from /dev/ttyUSB1
• Jupyter kernel restarts do NOT cause USB resets
• You no longer need to unplug/replug the cable
• Serial communication is stable across notebook restarts

Please let me know whether you can see any issue that this might cause for other machines or other OSs.

[rickwierenga]

very interesting find!

[rickwierenga]

we should avoid machine specific comments in the io layer

[BioCam]

I agree - but the io layer is where these commands have to be set in the right chronological order it seems?

One way we could get around this is by having an attribute for this in the io layer, default to None, i.e. leaving out this new code section, and have the backend provide the attribute if needed?

But in this scenario, I was wondering whether this is a truly unique IIS+Raspian combo or whether other machines might erroneously disconnect to the control PC too;
if others are doing the same, and this change provides no down-sides, it should be permanently added to the io I believe - just a couple of big ifs 😅

[rickwierenga]

do you know which versions these are?

[BioCam]

Unfortunately I do not - this is all very new to me

[rickwierenga]

ok but where did you notice you have to use one or the other? is one even supported on platforms where the other isn't?

[rickwierenga]

I would prefer to have explicit io.Serial.set_dtr etc. methods instead of doing this silently during setup. the backend can call those, and they will also be useful for machines that actually require them.

Do you actually need to set rts to false? The serial object is already initialized with it disabled.

We don't yet pass the dsrdtr parameter to serial.Serial.__init__, which we should probably do. if you set that to False on init is setting dtr explicitly still needed?

[BioCam]

I do not know why it is needed at exactly this location - I can test on Monday all permutations: [dtr/rts] x [true/false] x [ attribute/setter] to see which ones do and which ones do not trigger this error.

It seemed to me that

      self._ser = await loop.run_in_executor(self._executor, _open_serial)

...might be resetting any previous states?

and hence we need to set dtr and rts right afterwards?

Really not sure about this though - but can be figured out with step by step testing :)