Importing PGF data

[ChristianKeine]

Hi curiousgeorgie,

I recently used your PatchMaster Import to Matlab and it works great so far.
However, is it possible to import the parameters of the PGF (in a bundled file) in order to reconstruct the actual stimulus? The script seems to import the name of the PGF-Template, but I failed to locate the respective parameters to recreate the actual stimulus (# of sweeps, sweep interval, Voltage and Duration of different segments etc.)
It would be awesome if this feature could be implemented, or maybe it is already and I just overlooked it?

Thank you very much in advance.

[sammykatta]

The ImportHEKAfromMat function is just a slightly modified version of the ImportHEKA function from sigTOOL. I was never able to find the stimulus data in the data tree it imports into Matlab.

It does seem like that data must be in the .dat file somewhere, since it's possible to import the .dat file into Igor and get a trace of the stimulus as well. In fact, I now see that the description of the .dat file type also says that data is there, but I'm not sure how to figure out where it is in the raw data file at the moment.

I'll look into it and see what I can do (or if the sigTOOL coders/HEKA can help). Thanks for the suggestion - you're right, it would be really helpful to have that data imported!

[ChristianKeine]

Any news on recreating the actual stimulus from the PGF file?
Did anybody of the sigTool or HEKA guys have suggestions?
While I can find the position of the actual PGF part in the .dat file I still fail to obtain the actual sequence parameters to recreate the stimulus used.

[sammykatta]

Hi Christian,

I've figured out how to read pgf parameters from the .dat file - the metadata tree for stimulus parameters is now an optional output from the ImportPatchData function. Make sure to replace ImportHEKAtoMat in the sigTOOL folder with the newly updated version.

At some point in the future, I will modify SplitSeries.m to put some of the stimulus parameters into the ephysData struct with the rest of the data (once I figure out what all the flags are and how the different levels correspond to the recordings), but for now, you should be able to access them on a file-by-file basis during import, if you want to try and work that out yourself.

[ChristianKeine]

Hi Sammy,

I did not see your update until a few days ago, my apologies for the late reply. Thank you so much for adding the pgf readout to the functions, this is tremendously helpful. I was able to reconstruct the stimuli without problems and it appears that the structure is organized in Rec#/Channel#/Segments. So far, I have only used it for simple stimuli, e.g. series of square pulses, but will test more complex ones in the future.
Thank you again for adding this feature.

Hi Sammy/Christian,
Would you be able to share the code that reconstructs the stimulus from the output of ImportPatchData? I am unable to make sense of the stimTree variable and relate it to ephysData.

Thanks,
Anand

[sammykatta]

Hey Anand,

I actually haven't completely put together code to reconstruct the stimulus - my main stimulus is mechanical and I use a copy of that stimulus command passed in as an input to my amplifier, which I use to keep track of the command (it's more useful for me anyway). For my needs, I only need to be able to read the frequency of the sine I used for any given series. But I can tell you what I've gleaned from that:

In order to combine stimTree and ephysData, you actually have to look at dataTree as well. Column 2 in stimTree ("stim") corresponds to column 3 in dataTree ("series"). Column 3 in stimTree divides the stimulus into channels, and each entry in column 4 under one of those channels corresponds to a stimulus segment from the pgf.

...Actually, give me an hour. I can probably help you out at least a little bit with the stopgap measure of including the relevant sections of the stimTree aligned with their series in ephysData, even if I haven't figured out how to put together the stimulus for all types of segments (because that includes square/sine/incrementing/changing durations/interleaving/etc.).

I'm also going to include the file format specs I downloaded from HEKA in the Import folder, which might help you make some sense of the fields in the struct. (Hint, indices start at 0, so if seClass = 0, that means a "Constant" segment).

[sammykatta]

Okay, ephysData now includes the relevant sections of stimTree for each series within a group. I can't tell you exactly what every parameter means because I haven't figured them all out, but here's maybe a few useful ones from each level of the tree outside of the more obvious ones (e.g., Square/Sine Amplitude):

Stim:
stEntryName (should match the protocol names)
stNumberSweeps
stSampleInterval

Channel:
chHolding - holding potential (or holding current in CC mode, and I'm not sure what chLeakHolding is)
chCRC - number of segments

Segment:
seClass - 0 = constant, 1 = ramp, 2 = continuous, 3 = sine, 4 = square, 5 = chirp
seDuration - length of segment in seconds
seVoltage - voltage commanded in pgf, prior to any scaling

For the increment modes, check Import>FileFormat for StimFormat_v9.txt.

Hi Sammy,
Thank you for the explanation and the changes. Your changes work with our data without any error. And now the stimTree info is aligned with the ephysdata columns.

Thanks a ton,
Anand

[ChristianKeine]

Hi Sammy,

after you did a great job in making the .pgf part of the .dat file available, I was wondering, if it would also be possible to extract the solution-base data. I guess the different solutions from the solution base are again stored as a tree and the variables "TrInternalSolution" and "TrExternalSolution" in the last column (traces) of the data tree point towards the solution used in the particular trace.
If those data could be read out from the .dat file also, this would be a great way to have a more comprehensive documentation directly linked to the data, since solutions can differ quite substantially between experiments/lab.
Let me know, what you think.

Best,
Christian