Issue with analog input module while using TrialManager

tly627

Hi Josh,

I have another issue with the analog input module after I started using TrialManager in my protocol. I am using the analog input module to monitor and record the signals from a joystick. My protocol consists of a state for triggering the start of logging of the analog signals and another state for triggering the stop of logging of the analog signals. I also have a line "BpodSystem.Data.Rawevents.Trial(currentTrial).JS = A.getData.y" at the end of my main loop for saving the voltage data recorded in each trial. This was working fine when I was using an equivalent protocol that is based on RunStateMachine() before. However, once I have changed the code into TrialManager-based, I get the following error immediately or after running a few trials:

Error using ArCOMObject_Ain/read (line 290)
Error: The serial port returned 0 bytes.

Error in BpodAnalogIn/getData (line 381)
            nSamples = double(obj.Port.read(1, 'uint32'));

Error in Joystick_TrialManager (line 226)
        BpodSystem.Data.RawEvents.Trial{currentTrial}.JS = A.getData.y;

Error in run (line 91)
evalin('caller', strcat(script, ';'));

Error in NewLaunchManager>LaunchProtocol (line 707)
run(ProtocolPath);
 
Error while evaluating DestroyedObject Callback.

For the first few trials that could be run through occasionally, the logging of the analog inputs seems to be terminated at a timing that is earlier than what it should be. Also, the analog input module will go into a "crashed" state such that the red light inside it will be completely turned off and I will have to unplug the USB cable to make it functions again.

Do you know how to fix this issue?

Many thanks,
Tin

P.S. I noticed that in TrialManager-based protocol, the serial interface seems to work in a slightly different way? For example, I get an error saying "The last state machine sent was not acknowledged by the Bpod device" if I start logging by "AnalogIn1, ['L' 1]", which didn't occur in my old RunStateMachine-based protocols. This is also not specific to the analog input module, as the same thing happens in "WavePlayer1" as well. However, I was able to solve this issue by using LoadSerialMessages().

Josh

Hi Tin,

I'll need to see the rest of the code to determine what's wrong.
Please send your protocol to support@sanworks.io.

Thanks!
-Josh

tly627

Hi Josh,

I have sent my protocol to the above email address just now. Thank you very much!

Best,
Tin

Josh

Hi Tin,

The issue is that the analog input module can only store a single recording at a time. Here's its usage:
A.startLogging() from MATLAB or ['L' 1] from the state machine: Starts recording analog data, overwriting any previous data.
A.stopLogging() from MATLAB or ['L' 0] from the state machine: Stops recording analog data.
Data = A.getData(): retrieves the most recent dataset recorded.

Using TrialManager, if you send a state machine with the 'RunASAP' flag, the next trial begins immediately after the current one ends. If you then try to retrieve the analog data, you'll run into a crash because the state machine has already instructed the analog module to start logging, wiping the previous trial's recorded data. The solution is to omit 'RunASAP' as follows:

   SendStateMachine(sma); % Omitting 'RunASAP', this still sends the next trial's state machine while the current trial is ongoing
    RawEvents = TrialManager.getTrialData; % Hangs here until trial is over, then retrieves full trial's raw data
    MyData = A.getData % Retrieve analog data
    TrialManager.startTrial(); % Start processing the next trial's events (call with no argument since SM was already sent)

This will result in a "dead time" period between trials, but a much smaller one than using RunStateMachine() because all processing except for analog data retrieval (computing + sending state machine, updating plots, saving data, etc) will occur on the PC side while the trial is ongoing.

I hope this helps!

-Josh

tly627

Hi Josh,

Thanks so much for the explanation! I have removed the 'RunASAP' tag and moved the line with A.getData to be above TrialManager.startTrial() as you suggested, and now the analog input module no longer runs into a crash.

However, when I look into the data retrieved from each trial, the y-values are completely wrong as they always stay at -5 V (normally should fluctuate between 2.5-5 V when I move the joystick). I have checked the joystick with scope() and the analog input module could read the voltage perfectly fine so I am pretty confident that this is not a hardware issue with the joystick. I would greatly appreciate it if you could give me some advice regarding this additional issue.

Many thanks,
Tin

Josh

Hi Tin,

If you set the number of active channels to 8, does that fix the issue?

-Josh

tly627

Hi Josh,

Unfortunately, that doesn't fix the issue.

FYI, I have tried to use both the master and development branch of the firmware for the analog input module and both of them have problems with the y-values.

Thanks,
Tin

Josh

Hi Tin,

If you're seeing the minimum value of the given range for data retrieved from the microSD card but not data streamed over USB (i.e. scope()), one possibility is that the microSD card was jarred loose. If you turn off the module, remove the microSD card and press it back into place, does it work?

You can also test the microSD capture manually, outside of a protocol:

A = BpodAnalogIn('COM3'); % Where COM3 is the analog input module's port
A.startLogging();
pause(10);
%
% You have 10 seconds (measured by MATLAB) to create a signal to be captured
%
A.stopLogging();
Data = A.getData();
figure; plot(Data.x, Data.y(1,:))
clear A

If this doesn't help, please send in your revised protocol.

Thanks,

-Josh

tly627

Hi Josh,

Removing the microSD card and pressing it back didn't work.

However, I just tried to put in another microSD card and now the data logging is functioning normally. I am not sure why this is the case since there aren't any observable damages on the surface of the original microSD card.

Anyway, thank you so much for pointing out the possibility that the problem could be due to the card!

Best,
Tin