Joshua Franz

Here is a screenshot of the start sequence:  Here is the first thing that happens on the bus (what triggers the capture), but it doesn't appear to be I2C...

I just tried it on Mac, and it works fine. The issue I was having was with Linux (Ubuntu 18.04).

I just tried unloading the `ftdi_sio.ko` kernel module, but it didn't solve the problem.

When I add one more `print(port.read_from(0x00, 2))`, the issue goes away. However, adding a 4th causes the issue to reappear. It seems like there needs to be an even/odd (unsure...

Do you have a recommended tool for this? I can procure a hardware or software tool to try and capture the USB transfers. I confirmed the commands sent to pyusb...

I'm currently working on wireshark captures, and I'm running into issues with differences between OSes as you mentioned. It does not seem to be different from the pyusb debugging outputs....

Another datapoint I forgot to include: Following the instructions in this stack overflow thread resets the USB port and gets the device working again https://askubuntu.com/questions/645/how-do-you-reset-a-usb-device-from-the-command-line Not sure if it helps,...

I found something possibly strange, although it might just be that I don't understand Python well enough. I'm using a class that contains the `pyftdi` objects, and its destructor calls...

Thanks for the advice! It seems like I misunderstood when to use `__del__`, although maybe I still don't understand. I'll keep reading to see what I can learn. It seems...

Yes, when I do not call `close/terminate`, sometimes the I2C frequency is incorrect causing NACKs on the bus. This no longer occurs when I call `close/terminate` before exiting the program.