-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mismatch (offset?) of data where zero=1 in PGF #8
Comments
Hi tuanpham, my apologies for the late response to this issue. Could you send me an example file to see what's going on? I would have to check what exactly Patchmaster does when the zero-ing is turned on. Is your holding potential perhaps at -70 mV during the experiment? Thanks. |
Hi tuanpham, so according to the Patchmaster manual, the number in the "zero" column defines the number of the segment in which the zero-offset will be calculated. So I am assuming that the -140 mV in the data trace results from the measured -70 mV holding potential subtracted by -70 mV zero-offset. In my understanding, however, the baseline of your recorded trace should be at 0 mV (-70 mV recorded with -70 mV zero offset), so I am assuming that Patchmaster does not apply the zero offset when displaying the trace? When displaying traces with zero offset and without (both at -70 mV holding), does Patchmaster display them the same, i.e. both starting at around -70 mV? I think the issue might originate in the following lines in which the TrZeroData is added and not subtracted from the data HEKA_Patchmaster_Importer/@HEKA_Importer/HI_ImportHEKAtoMat.m Lines 326 to 328 in 4b09e19
Is this variable indeed -70 mV in your files in which zero offset is active and 0 in files in which zero offset is turned off? |
Thanks for your reply, I'd have to check back with you on these questions when I'm in the lab in the next couple of weeks just in case. As far as I can remember, what I did for data that I believe are already offset (or don't need offset) was basically this:
I'll check back with you within a week or two about your questions. |
This is a very great tool. However, I have found that for some of the protocols I inherited, the data read from .dat files were offset. For example, here's the file as loaded within PatchMaster
And here was the same data read in using the importer and plotted with MATLAB
At first I thought it was somehow multiplied by a factor of 2, but looking closely I realized it was shifted around -70mV (for example, the AP amplitude). I tried exporting these traces to an ITX file and it was fine.
I noticed that I had this particular issue with protocols that has this:
whereas protocols with
Zero=0
are fine (as in no offset).Do you know what's happening?
System info:
PatchMaster v2x90.1
on Windows 7MATLAB R2018b
on Windows 10EDIT:
Apparently the data have already been zeroed when saved (I think). I have turned this line assignment to 0.
HEKA_Patchmaster_Importer/@HEKA_Importer/HI_readPulseFileHEKA.m
Line 250 in a0ef82a
tr.TrZeroData = 0; % instead of fread(fh, 1, 'double=>double');%
And it worked for some reason. Is this right? Is there a place that we can check for that?
The text was updated successfully, but these errors were encountered: