Recording interrupt of a digital input

[João Pedro Junqueira]

Hey,

I’ve been having an issue with one of my digital inputs, from an external lickometer that
sends TTL outputs at 5V, suddenly interrupting recording during sessions.

I’ve checked that inputs are neither logged to data or plotted, but the licking device has an LED that lights up when it detects licks, so I know it’s working properly. Also, I have the impression it might be a software issue, since stopping the experiment and starting again completely fixes it, without any changes circuit-wise or even restarting the GUI or the board.

It’s a relatively rare issue, and it happened both right at the beginning of the session and after about 10 minutes. Maybe about one every 8 sessions or so.

I included attachments of my task script, hardware definition and session log. I wish I had checked the GUI script prompt everytime it happened, but this is a traceback that I received last time. I noticed it was there after I had already stopped the experiment and started again, without restarting the GUI.

 Traceback (most recent call last):
  File "C:\Users\joao_\Downloads\pyControl\gui\run_experiment_tab.py", line 361, in update
    subjectbox.update()
  File "C:\Users\joao_\Downloads\pyControl\gui\run_experiment_tab.py", line 510, in update
    self.stop_task()
  File "C:\Users\joao_\Downloads\pyControl\gui\run_experiment_tab.py", line 499, in stop_task
    self.run_exp_tab.experiment_plot.active_plots.remove(self.setup_number)
ValueError: list.remove(x): x not in list

​

[thoma...@neuro.fchampalimaud.org]

Hi Joao,

Does the input stop generating events completely or does the task just stop responding to them?  Do other inputs continue to generate events as normal?

For the electrical connection between the external lickometer and breakout board, have you connected the ground between the two systems in addition to the signal line?  If the grounds were not connected that might cause the problem.  If you have access to an oscilloscope it would be worth measuring the signal from the lickometer, with the oscilloscope ground connected to the ground of the pyControl system, to make sure the lickometer output is behaving as expected.

To check if it might be a problem with the specific input pin, you could try connecting the lickometer to a different input.

You could also try resetting the pyboard filesystem (using the instructions here) and reinstalling the pycontrol framework and hardware definition, in case a file has got corrupted. 

Let me know how you get on.

T

[João Pedro Junqueira]

Hello Thomas,

Thank you for your answer.

The licking input stops generating events completely. Other inputs continue working as normal, and the grounds are connected correctly. It also happened on different ports.

From reading the section I decided to try that and also doing the method for the board being correctly recognized. I'll get back to you if it happens again after that.

Joao

[João Pedro Junqueira]

Hello again,

I'm sadly still struggling with this interruption of input from my IR beam lickometer and would like to ask for some more help.

Here's the troubleshooting I tried:

1 - Looking for errors in the log files and command prompt windows

2 - Checking if the input is detected at the lickometer side (it is - an LED indicates licks)

3 - General troubleshooting from the docs - Installing specific pyBoard drivers, updating MicroPython and pyControl, doing a factory reset of the board.

4 - Checking if the input is registered in the data files despite not showing during recording (it is not saved)

5 - Trying different ports, different cables, and a different breakout board.

6 - Trying to replicate the issue by disconnecting different pins/connectors mid-recording, including lickometer power line, lickometer output and ground pins (connected to the breakout board). Input could be reinstated after reconnecting (whereas when I get the issue nothing can reinstate it except restarting the session).

7 - Measuring voltage when the issue occurs by splitting the lickometer output with a T-junction connecting it to an oscilloscope.

It should also be noted that the lickometer is not powered by the board.

As I mentioned, I found it very peculiar that every time the issue occurred I could get it to work again without touching the hardware by stopping the experiment and starting again in the GUI. Although it's something that only happens with this device, what could this indicate?

One thing is that I don't know how to correctly connect the oscilloscope to the pyControl ground. For this case is it okay to use a ground pin from a different port than the one where the lickometer is connected? The test I did had it connected to the lickometer ground pin.

Best,

Joao

[thoma...@neuro.fchampalimaud.org]

Hi Joao,

Sorry to hear you still having issues with this.  Its pretty puzzling because the fact that the input starts working again after you stop and restart the session suggests it is a software problem, but the code for handling digital inputs is some of the oldest code in the pycontrol framework and if there was a bug that caused inputs to stop registering like this I would have expected to encounter it before.  A couple of questions and suggestions:

- When you tried different ports, cables and breakout board did this affect the occurrence of the problem in any way?

- What is the lickometer that you are using and how is it connected to the breakout board?

- What did the signals coming from the lickometer look like on the oscilloscope, what voltage do they go to in their low and high state, and are the edges clean or ragged?  Did the lickometer output continue to behave as normal when the problem occurred?  (Note - to connect the scope ground to pycontrol ground you can just connect a BNC cable from the scope to the breakout board)

- Can you try disabling debouncing on the lickometer input by setting the argument debounce=False when you instantiate the digital input.  This simplifies the code on the pyboard that runs when an edge occurs on the input and might help identify if it is a software problem.  

T

[João Pedro Junqueira]

Hello,

Thank you very much for the suggestions.

I've tried disabling deboucing (used to be enabled at 5ms) and it seems to have solved it!

I've gone a lot of sessions without the problem occurring.

The lickometer is this one:

https://ohara-time.co.jp/products/licking-unit-module-of-operant-test/

it sends a 5V TTL signal on beam interruption. it's currently connected the board with a BNC cable

I have to understand the oscilloscope use a bit better to say for sure

whether it has jagged lines or not, though. The readings appear okay, but maybe I have to use higher precision.

I noticed that the signals from licking seemed to increase after turning off deboucing, but not very much.

Best,

Joao.