Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

response pad stops responding from time to time #4

Open
achetverikov opened this issue May 15, 2012 · 5 comments

Comments

@achetverikov
Copy link

commented May 15, 2012

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

This comment has been minimized.

Copy link

commented May 15, 2012

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

This comment has been minimized.

Copy link

commented Jun 6, 2013

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

This comment has been minimized.

Copy link

commented Jun 11, 2013

@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

This comment has been minimized.

Copy link

commented Oct 16, 2013

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

This comment has been minimized.

Copy link

commented Oct 16, 2013

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.