response pad stops responding from time to time

[achetverikov]

I use RB830 with pyxid and psychopy. Most of the time everything goes fine, but occasionally response pad simply stops responding. It happens even in the demo script from the readme (I just added printing of the response). It is not (i hope) the hardware problem as I have 2 RB830 and both of them have this issue.

[habboud]

Unfortunately, this is a bug in pyxid that was brought to our attention a month or so ago, but we do not currently have the resources to fix it. It is not present AFAIK in the C++ library.

[ta0kira]

I ran into the same problem when performing rapid responses. As far as I can tell, it's because sometimes fewer than the requested number of bytes are read from the serial port. This is a common issue when dealing with non-blocking reads. Ultimately the problem seems to be that input is processed even when it's incomplete, causing a perpetual misalignment of the input data. Since all of the reads are supposed to be 6 bytes here (see internal.py,) the solution seems to be to only process data in multiples of 6 bytes and leave the remainder until the rest of the 6-byte block can be filled in. If for some reason that fails, you can reset the input buffer at the possible expense of a few button presses.

I've written a patch to fix this issue, but as far as I know there isn't a way to attach it to this issue. I've created a "gist" for it, which is available here: https://gist.github.com/ta0kira/5a675eaa86312fc89b3c. The fix isn't heavily tested, but it seems to eliminate the issue. I've also added a replacement file as a gist (https://gist.github.com/ta0kira/0af12c70620c6cf4bd82), which you can just save over the old version of internal.py.

Kevin Barry

[cedrus]

@ta0kira (Kevin), thanks so much for making your patch available. You are correct to note that whenever the bug appeared it was coinciding with not enough data inside 'self.__response_buffer'.

Rather than apply your patch, I ended up doing a broader code-cleanup inside ' internal.py' (the file that you also worked on). If you are curious, feel free to have a look through the series of commits made today (June 10), culminating with 9e83558 .

Your diagnostics and groundwork saved me a lot of time and led me right to the code in need of the update. Thanks again.

Please let us know if PyXID exhibits any further 'freeze-up' behavior (failing to report responses after getting stuck on too many rapid ones). If you use the current codebase, the problem should now be gone.

Kelly

[harmadillo]

Just an FYI, the patch did not fix the bug. Now instead of not collecting responses, it starts printing "Serial bytes were found in the buffer, but they were unparseable." every time that a key is pressed. I am able to reliably reproduce this error on my RB-730 by quickly mashing multiple buttons. Generally, I wouldn't expect to run into this problem under normal conditions, but I have in fact lost several fMRI scans because of it. I did a bit of debugging myself and found that the buffer that pyxid pulls includes a few empty bytes before the k byte that signals the start of the packet. I tried writing the code delete those bytes and pull extra bytes from the buffer, but it didn't work immediately and I was in a bit of a time crunch. Rather than messing around with trying to save the current response, I just flush the buffer and bail from the response loop. Now it loses 1 response and recovers rather than having a cascade effect that lasts the entire session.

[cedrus]

@harmadillo, thank you very much for the FYI. Earlier today we got an email from the psychopy-users mailing list (thank you to @yarikoptic !) that contains a further patch to address the problem. We will be applying the patch soon.

[habboud]

pyxid has been superseded by pyxid2. There are no bugs in pyxid2 that we’re aware of.