Aanalog Input module powers off

PrsaLab

Dear Josh,

We have encountered an issue where the AI module powers off during a trial causing our protocol to crash.

We load the following serial messages:

LoadSerialMessages('AnalogIn1', ['L' 1], 88);    % start logging

LoadSerialMessages('AnalogIn1', ['L' 0], 99);    % stop logging

Early in the trial we send a Serial Message to the AI module to start acquiring (go cue state):

GoCueOutputActions = {'AnalogIn1', 88, 'Wire1', 1, 'WavePlayer1', 12, 'PWM2', 255};

Late in the trial we send a message to stop acquiring (timeout state):

TimeoutOutputActions = {'AnalogIn1', 99};

We notice that if the elapsed time between the two states is less than roughly one second (which happens in some trials), the AI module powers down and the protocol crashes. For the moment, we solve the issue by making sure that the time elapsed between the two states (i.e. the start and stop serial messages sent to the AI module) is greater than 1 second.

Is there a way to fix this without having to worry about the timing of the successive serial messages sent to the AI module?

Thanks!

Josh

Hi PrsaLab,

Does the AI module literally power off - as in the orange LED turns off?
If you developed your protocol using TrialManager (https://sanworks.github.io/Bpod_Wiki/function-reference/running-statemachine/#bpodtrialmanager), you have to make sure that the ['L' 0] message to stop logging is sent from the state machine to the AI module before the MATLAB-side code tries to pull the trial data from the device with A.getData(). TrialManager allows you to save data, compute and send the next trial's state machine, etc. while the current trial is running - but you'll need that code to know whether ['L' 0] has been sent - so you may want to have the state machine send a soft code in the same state:

TimeoutOutputActions = {'AnalogIn1', 99, 'SoftCode', 1};

and handle SoftCode 1 with a soft code handler that updates a global variable. You can then check the state of the global variable in your main loop before running A.getData().
This would not be an issue for protocols written without TrialManager (i.e. using RunStateMachine()).
Please let me know if this helps!
-Josh

PrsaLab

Hi Josh,

Thank you for the prompt reply!

Yes, the AI module power shuts down (LED turns off on the Teensy) ... and we need to unplug/plug the USB connector to power it back up.

We are not using TrialManager, so the AI.getData(); command always executes after the ['L' 0] message is sent.

We did some testing and the issue really only happens if the ['L' 1] and ['L' 0] messages are sent in quick succession (roughly less than 1 s apart). The AI module does not shutdown upon sending the ['L' 0] message. It subsequently shuts downs only upon execution of the AI.getData() command and then yields an error:

Error: the serial port returned 0 bytes

The shutdown however does not happen if:

- ['L' 1] and ['L' 0] messages are sent more than roughly 1 s apart
- The ['L' 0] message is not sent at all. The AI.getData() still pulls the correct data from the AI module in that case (it just acquires a longer data trace ... up to the point AI.getData() is executed).
- The ['L' 1] message is not sent at all. No data is pulled by AI.getData(), but also no shutdown or error occurs.

So the issue really has to do with successive serial messages being sent to the AI module too quickly.

Josh

Hi PrsaLab,

Wow, that's quite a bug! Surprising it didn't surface earlier - most use cases must have longer recording sessions.
I was able to replicate it and released a fix on the 'develop' branch of the firmware repository, here.

Please let me know if this fixes the issue on your side.

Thanks,
-Josh

PrsaLab

Hi Josh,

Beautiful!
We tested the new firmware and it all works great.

Thanks!