Pre and post window are too short about online-psth HOT 3 OPEN

The reason for the upper bound of 1000 ms is because all of the trial-aligned spike times are stored in memory to allow the window size and bin size to be reconfigured on the fly. We wanted to limit the maximum window size to avoid using too much RAM in the case of high spike rates.

I think there are two options here:

• We can send you a custom version of the plugin that caps the post_ms parameter at 20 s. You'd just have to pay attention to memory usage to make sure it doesn't get too high.
• You could create a separate condition for each parameter change and use the TTL+MSG triggering method to indicate which parameter is linked to which TTL event.

Let us know which one you'd prefer!

from online-psth.

Thanks for getting back to me.

Ah yes I had not thought about the memory issues... I think this will not be feasible then on our current setup.

Wtih the TTL+MSG you would still only have a PSTH visible for 2-3 parameters at a time but it would be labeled? Am I understanding right?

Would using the matlab interface to create plots in realtime use less memory?

from online-psth.

You could even have a separate condition for each parameter, so each one gets its own PSTH. That would allow you to show the conditions in a randomized order, which would prevent the responses from being biased by whatever stimulus was shown previously.

If you'd rather plot the events in Matlab, you wouldn't necessarily need to store all the spike times in memory, so it could be more efficient. The Matlab Interface only streams continuous data, so instead you'd want to use the Event Broadcaster, which sends a message for every spike and TTL event.

from online-psth.