Rolling data display?

[Wiktor Phillips]

Hello,

I am setting up a rig for ephys and imaging with ACQ4, slowly getting all the pieces to work together. I can see from the documentation that 'continuous' acquisition in the Task Runner is not yet implemented. I primarily record spontaneous oscillations in neurons that occur on a slow time scale (e.g. 3-7 seconds), so quite often I prefer to acquire whole cell data in a 'gap-free' chart mode. While continuous acquisition would be ideal, it is understandable if that particular feature is simply not yet developed. We can make do with long sweep times... 

However, the data from each acquired sweep is displayed post acquisition in the Task Runner. (Unless I am missing something...) Would it be a straightforward modification to have a rolling display of the data as it's recorded in real-time (or nearly so)? Or is it a headache to work out given how the platform is built? I would much prefer to be able to monitor activity as it is happening across 10-30 seconds without a delay. The only other solution I can think of would be to dedicate an external oscilloscope for signal monitoring? 

Side note: I am using an unsupported manual amplifier (NPI SEC-10LX), so for the moment I don't have access to the Patch module. Not sure if that would make a difference. (I am attempting to use the Axopatch 200B class as a template to gain use of the Patch module--work in progress)

If you have any advice/can point me in the right direction I would really appreciate it. 

-Wiktor

  

[Luke Campagnola]

Hello Wiktor,

You have hit on a couple of places where acq4 could use some work--getting continuous acquisition has been on the list for a log time, but none of the labs doing the bulk of the development have had a need for it yet. Can you say more about how you imagine your experiment going, in the ideal case? It sounds like you would be continuously acquiring from the amplifier at least so that you could monitor the cell. Would you also want to store all of this data to disk? Would you be applying stimuli during this time, and would those stimuli need to be synchronized with any other devices? Would it be ok for the stimulus/response recordings to temporarily interrupt the continuous acquisition?

If you did not need to use any of the features of the task runner during continuous acquisition, then there is a relatively simple path forward here--write a new user interface module that bypasses the task management system entirely and basically behaves like an oscilloscope, possibly generating its own stimuli as well. This would actually behave in a similar manner to how the live camera display works now--the camera free-runs most of the time, but it can be interrupted if you need to synchronize the camera with another device during a task run.

I have also worked on another acquisition system (see github.com/pyacq) that is more focused on streaming from continuous acquisition. It's a bit less mature, but certainly worth looking at. I have a distant dream of being able to integrate pyacq into acq4 to provide the kind of oscilloscope-mode acquisition described above.

Luke

---

From: ac...@googlegroups.com <ac...@googlegroups.com> on behalf of Wiktor Phillips <wsphi...@gmail.com>
Sent: Sunday, March 11, 2018 3:11:42 PM
To: ACQ4
Subject: [acq4] Rolling data display?

 

--
You received this message because you are subscribed to the Google Groups "ACQ4" group.
To unsubscribe from this group and stop receiving emails from it, send an email to acq4+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/acq4/730871a4-4acd-4eda-ae89-b554e15fd8b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wiktor Phillips]

Luke,

I record excitatory interneurons in the brainstem that are responsible for respiratory pattern generation. In slice preparations, they exhibit synchronized bursts of action potentials. Network activity can further be monitored on motor nerve rootlets contained in the slice. Over the years classification schemes have been proposed that parcel these rhythmically active neurons into categories based on the trajectory of membrane voltage during each cycle, latency of activation (with respect to the population as a whole) and also by a suite of membrane currents and pharmacological sensitivities. To arrive at a conclusion about "what kind" of rhythmic respiratory neuron you are recording from one typically has to record baseline activity for awhile and pair that with suction electrode recordings of fictive motor output. After that I would (by hand/feel) adjust the bias current up and down to look for baseline dependent non-linearities or voltage-dependent pacemaker properties. This would be followed by a more 'standard' recording where membrane currents are elicited in synaptic isolation/with pharmacology. So the first half of experiments lends itself to gap-free acquisition, while the second half is more of a traditional sweep-based stimulus-response recording.

Unfortunately there is a lot of effort needed to call a duck a duck... To that end, I want to build a data set that I can use to train a classifier (post hoc) and later apply that trained algorithm to help predict cell classifications (in the best case, online during live cell experiments) without having to spend 30+ minutes washing in drugs and iteratively assaying membrane currents. My short term goal is to hopefully apply such a classifier toward PatchSeq in order to more rapidly sample isolates of "known" phenotype. The more distant goal is to use it for more elaborate experiments involving synchronized calcium imaging and/or stimulation. BUT I need good, clean, standardized training data that simply isn't out there on any repositories right now. To get it I will be making recordings in the paradigm I described above--thus the desire to have some sort of running data display or acquisition. To get the many many replicates I will likely need it would seriously help to semi-automate my work flow, so that's why I am here. I think there is enough I can use or build off of in ACQ4 to ramp up the rate at which I acquire cells both for the training data set and later PatchSeq sampling. 

To answer your other questions directly:

Yes--we would want to store to disk during continuous acquisition.

I would primarily want to roll holding current slowly up and down, which I could do manually from the amplifier. For the immediately planned experiments, no. I would not need to access other devices during that time.

Yes. Stimulus-response could interrupt continuous acquisition. At that point, we will have the network silenced via synaptic isolation.

Are you able to elaborate on your suggestion? For now I am just running my signal through a external digital oscilloscope so I can see what is going on. When I am finished getting the amplifier more tightly integrated and have my Sensapex manipulator interacting as it should, I might have a go at it. 

Cheers,

Wiktor 

[Luke Campagnola]

It sounds like you have some simple needs up front (recording / displaying streamed data) and more complex requirements down the road (online analysis / adaptive sampling of cell properties). I think the best way to start here is to build a new module (see http://acq4.org/documentation/devGuide/modules/index.html). This module would initially do the following:

1. Ask the acq4 manager for access to the DAQ and amplifier devices (Manager.getDevice)

2. Use the DAQmx API to set up a continuous acquisition task (but first query the amplifier device to determine which DAQ channel(s) to record from)

3. Use the amplifier device to determine the correct scaling, and to collect metadata about the state of the device for storage

4. Plot and store data as it streams in  (maybe see pyqtgraph/examples/scrollingPlots.py for inspiration)

Once that is working, there are many optional places to go:

* How to make this module play nicely with the acq4 task management system, so that the streaming task is automatically interrupted whenever the task runner is working.

* Online analysis / adaptive sampling of cell type information

* Maybe integrating continuous acquisition more deeply into acq4, rather than accessing DAQmx directly--first nidaq.SuperTask, then the task management system?

* I should write a PatchClampAmplifier device base class from which MultiClamp, AxoPatch, and your amplifier class will inherit so that all amplifiers can be used interchangeably across all acq4 modules

Let me know how that goes; I am happy to help more along the way. I'm also curious to hear how things go with the sensapex manipulator--we have a couple of uMp devices that are mostly working, but we haven't had time to test them very much.

Luke

To unsubscribe from this group and stop receiving emails from it, send an email to acq4+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/acq4/2ce8b19c-ae99-41e1-ba04-22b12a071414%40googlegroups.com.

[Andrew Penn]

Hi Wiktor, Luke,

I wrote a simple standalone python script that mimics a free running oscilloscope and I attach it here. Not sure if it helps though since it reservea the DAQ device; so it cannot run while you are running the Patch module or acquiring data with the Task Runner. 

I too would be interested in a seemingly simple related feature. I'm not necessarily interested in continuous acquisition of data, more changing how the data is displayed in the Task Runner when acquiring data. At the moment when you run say a 30s protocol all the data is plot at the same time when the 30s sweep of acquisition has completed. It would be much nicer if there were point-by-point plotting of the data in the Task Runner as the sweep is being acquired. Wouldn't it be relatively simple to run a thread to acquire the data in small blocks (as I did in the attached script) and run a separate thread to periodically update the plot?

Best

Andy

Luke

To unsubscribe from this group and stop receiving emails from it, send an email to ac...@googlegroups.com.

[Andrew Penn]

Regarding the Scope.py attachment, I just checked it more thoroughly and it seems that the software timing imposes significant delays and so it doesn't manage to reach/maintain 10 kHz sampling. Possibly I can play a bit to reduce this latency but hardware timing would be better but I haven't discovered the right function in nidaqmx for real-time continuous acquisition...

[Andrew Penn]

Ok I worked something out using nidaqmx with hardware timing. Module with function attached... it's basic and currently only supports 1 channel but it records too (in TDMS file format).