Try saving the data as text. Matlab, QUB and QUB Express can all read and write comma- and tab-separated text files. (In Matlab, use the dlmread and dlmwrite functions.) QUB interprets a blank line as a segment break.

QUB and QUB Express can also import data from the following formats: ABF (Axon/Molecular Devices binary), Acquire (Bruxton), PUL (Patchmaster), TACIDL (TacFit transition table textual output), LDT (legacy QUB format) and DWT (QUB idealized dwell times), along with our native binary format, QDF. We can also read raw integer and floating-point binary files, if you know the correct sampling rate and scaling factors.

k: per second
k0: per [e.g. millimolar] per second
k1: per mV

Here is a derivation of Vs from forms of the Arrhenius equation:

k = (k0 * conc) * exp(Vs * mV) 
k = (k0' * conc * kB*T / h) * exp(-( charge*mV / (kB*T) )) 

Vs * mV = -( charge*mV/(kB*T) ) 
Vs = -charge / (kB*T) 

The units of charge are electrons. The units of T are degrees Kelvin. kB = 8.617x10^-2 meV/K, so kB*T = 25.9 meV. At 300K:

Vs = -charge / 25.9

Vs can be positive or negative depending on its excitatory or inhibitory effect.

Temperature dependence is not directly supported yet. We may add it to the model in the future, but you can do it with today's model... Whereas our rates are calculated

k = k0*P*exp(k1*Q), 

temperature dependence is calculated

k = k0 * T * exp(k1 / T) 

In other words, P=T and Q=1/T. You can emulate temperature dependence by making a rate both P-sensitive to temperature and Q-sensitive to (1/temperature). For ramp simulations, this means adding a d/a channel in the acquisition protocol, from (1/T0) to (1/T1) and assigning it (channel 2) to "Voltage." Assign the original temperature signal to "Ligand." For "Mac Rates" analysis of recorded data, you have to save the data as a text file, load it into a spreadsheet, add a column calculated as e.g. "=1/B$1" (if temperature is in column B), then open it back up in qub and assign the new column (a/d channel) to "Voltage."

This is the classic "missed events" problem -- an event is shorter than the rise time, so it is mis-identified or missed entirely. The MIL rates optimizer avoids this problem by applying a "dead time" (td) to the model and the events. It erases any events shorter than td, and optimizes the likelihood given that all short events are missed. Set td longer than the longest bad event. You can set td in the upper right. (click "td" to switch between [samples] and [ms].) You still see the erroneous short events, but they don't go into the MIL log-likelihood.

When two states are not connected, it is still possible to go from one to the other after one sample's time. The distribution of events is exponential, and some are much faster than the sampling rate; there could be several transitions from one data point to the next. This may be rather unlikely, but the total likelihood also includes the Gaussian probability of the current being of that color. In my experience the Gaussian probabilities dominate the result.

It may help to exaggerate the amplitude distributions -- increase the std.dev of closed, and maybe decrease the std.dev of the other colors. Also, slower rate constants will decrease the probability of jumping between unconnected states. In Idealize Properties, turn off "re-estimate" so it has to use your estimates.

In model properties, under "kinetic constraints", you can specify, for example, "Scale rates 1 2 2 3", meaning the ratio k12/k23 will be kept constant during MIL. In other words, if they are equal, they will stay equal, although they may vary together. Likewise, if one is double the other, it will stay double, though the actual numbers may change. [QUB Express:: right-click one rate and choose "Add constraint", "ScaleRate", then double-click the other rate.]

Identical binding sites are usually modeled as a chain:

      4k           3k           2k              k
1 ----------- 2 ----------- 3 ----------- 4 ------------ 5
      k'           2k'          3k'            4k'

with all the binding rates proportional to each other, and maybe also with the unbinding rates. k12 = 4*k45 because there are four times as many available binding sites. Once you have set up these ratios, you can use Kinetic Constraints (Model properties) to "scale rate" between k12 and k23, k12 and k34, k12 and k45, k21 and k54, etc. This will preserve their ratios during MIL, and if you check the box "enforce constraints" it will preserve the ratios when you edit by hand.

It is also valid to optimize without constraints. If the unconstrained one has significantly higher likelihood, it suggests the binding sites are not independent. It's also valid to try different models -- especially if you have recordings at various ligand concentrations -- rates that aren't involved in binding shouldn't change too much across concentrations, if the connections in the model are right.

(I'm not an experimental scientist but...) People say, the fewer states the better. If you could e.g. saturate it so the ligands stay bound, and the histograms indicate one open and closed state each, then you could first solve the gating rates and go from there.

In QuB, microscopic reversability is optional. By default it is ignored -- the rate constants can take any values. In model properties, kinetic constraints, there is a button to "Balance loops," which identifies the fundamental cycles in the model (>= 3 states) and constrains them so their product clockwise equals their product counter-clockwise. (In QUB Express, this button is in the Models table.)

With the constraint(s) added, you can right-click in the background of the model and choose "Enforce constraints." This changes the rate constants as needed to fit the constraints. To have the constraints enforced every time you edit a rate constant, check the box "Enforce constraints" in Model properties, under Rates. Algorithms such as MIL and Mac Rates will always honor the constraints.

Unfortunately, we can't constrain a rate to stay within certain bounds. The only constraints are Fix (hold constant) and Scale (constant ratio between two rates), along with detailed balance for loops.

It may help to fix all but one rate constant, so the program is fitting only one rate constant at a time. In QUB Express, right-click the rate constant, choose Add Constraint -> Fix rate. Or you could constrain the ratios between the three opening rates (scale a::b, then scale b::c, and a::c is implied). Then remove the constraints one by one.

Yes. Use the Model Merge function. It takes two or more source models, and generates the cartesian product. An example:

A <--> B    merged with     X <--> Y <--> Z

AX <--> AY <--> AZ
 |      |       |
BX <--> BY <--> BZ

Model Merge also generates constraints in the product model, so that k(AX, AY) == k(BX, BY), and k(AX, BX) == k(AY, BY), etc. You can selectively remove these constraints to allow for cooperative behavior.

Of course, it gets more confusing with several models.

QuB Classic: click "Model Merge" or "mmerge" on the right, under "Modeling" (you may have to click the header "Modeling" to make the Model Merge button visible, or alternatively, use the Actions menu -> Modeling -> Model Merge. To remove constraints, right-click in the background of the model -> Properties..., Kinetic Constraints Tab.

QUB Express: in the Models panel, click the menu icon next to the File menu ("Modeling Tools") -> Model Merge. To remove constraints, go to the Tables panel, Kinetic Constraints tab.

I think k0.std is the standard error (SEM?) It is the square root of the diagonal of the inverted Hessian matrix of the log likelihood function.

QuB can do this. You record each voltage level in a separate file, open all of them, and idealize each one separately, then fit together.

Classic: add voltage sensitivity to the model, by editing a rate and checking the box "Q". "k1" is the voltage sensitivity, which can be a negative number. To fit all the files together, right-click MIL, choose Data Source: file list, put a check next to each file name ("Use"), and enter each file's voltage in the table. You could also use the file list for different concentrations of Ligand, using the "P" checkbox.

Express: Right-click a rate and choose "Voltage-sensitive", then enter a reasonable starting guess for k1, the voltage sensitivity constant (maybe +/- .05?). To fit all the files together, go to the Modeling:MILRates panel and select "multi-file". This will use data from all open files with the specified group number. Assign group numbers in the "Data" table.

Open the Start menu (All Programs), go to the QuB menu or subfolder, and choose "Uninstall QuB."

It generates successive events at infinite resolution, with a dwell length that's exponentially distributed about (1/sum(exit rates)), followed by a transition to another state, picked at random, weighted by exit rate. Rate constants are recalculated whenever stimulus changes. Blatz and Magleby were focused on reconstructing an imperfect filtered thresholded event record, while QuB just samples the record and adds Gaussian noise.

When a rate is extremely fast compared to the sampling frequency, that method can be very slow due to simulating millions of short events per sample. When we detect a fast rate, we switch to an A matrix method, using the sampled transition probability matrix A=e^(Q*dt). Starting in state s, we pick the next state randomly, weighted by the entries in row s of A.

In QuB Classic, there is an option for "macroscopic" simulation, which simulates mean current from the sum of exponentials.

In general, the way to save a figure in QUB Express is via its Notebook menu. I just fixed some bugs in the Data's notebook, so make sure to 'git pull' or update to version >= 0.12.1.

To save the onscreen data and model-fit curve, click the notebook at bottom of data, and choose Save -> Data Table, or if you prefer, Save -> Pick Columns... (there's an option to add the column selection permanently to the Notebook menu).

To save a large or arbitrary selection of data with its model-fit, use Tools:Extract.

Both of these should be recordable in the Admin:Scripts panel.

I think the net charge is the integral of current: charge = integral|from a to b|(I dt). Or in discrete computer terms: charge = sum(I[i] * delta_t). Using the mean value theorem for integrals, or the fact that mean(I) = (1/N)*sum(I[i]), we can substitute to get charge = N*delta_t*mean(I) = duration(in seconds)*mean(I).

You can customize QUB Express's measurement script to calculate this and other quantities:

• In the Data panel (lower half), click the ruler (Measurement) icon and choose "Measurement Script" -> "Edit Script..." It will load the measurement script into the Admin:Scripts panel.
• Find the line:
  

  measured['%s Mean' % signal.name] = samples_included.mean()
  

• and below it, add:
  

  measured['Net %s' % signal.name] = measured['Duration']/1000 * measured['%s Mean' % signal.name]
  

• Make sure to indent with the same number of spaces. We divide Duration by 1000 to convert from milliseconds to seconds.
• Save the script

Now if you have a signal named "Current", "Net Current" should be included in all of QUB Express's measurements in the future.

Of course, it's important to set the baseline correctly first.

Not as automatically. You can read the "Avg" and "Length" from the data tooltip, then type them into the Calculator field of the Report window; e.g. with Avg=2.0 and Length=1.0: type "1.0/1000 * 2.0" to get the answer.

In QuB Classic, it's not automatic. You can read the "Avg" and "Length" from the data tooltip, then type them into the Calculator field of the Report window; e.g. with Avg=2.0 and Length=1.0: type "1.0/1000 * 2.0" to get the answer.

The protocol in the Simulation panel is usually used for simulations, but it can also be used to add a voltage signal to an existing data data file. After building the simulation protocol, right-click the voltage waveform inside the Simulation panel and choose "Add signal to data file." The voltage signal will appear in the Data panel. Verify that it is correct, then Save As, and continue analyzing the new file. (In the original file, voltage is a live reflection of what's in the Simulation panel, but the saved copy preserves a snapshot of when it was saved.)

You can use the Python Scripts window for custom analysis of idealized data. Here is a basic example which lists all events from the Data Source:

idl = QUB.getChosenIdealization()
for dataset in qubtree.children(idl, 'DataSet'):
     for segment in qubtree.children(dataset, 'Segment'):
         classes = segment['Classes'].data
         durations = segment['Durations'].data
         n = segment['DwellCount'].data[0]
         for i in xrange(n):
             QUB.Report("%i: class %i for %f ms" % (i, classes[i], durations[i]))

The output is shown in the Report window. (The Report window is faster handling many lines of output, so it's preferable to use QUB.Report instead of the builtin print function.)

You might report only lines which match your criteria, e.g.

...
         for i in xrange(n):
             if ( (1 <= i < (n-1)) # not the first or last event
                 and (classes[i] == 0)
                 and (classes[i-1] == 1)
                 and (classes[i+1] == 2) ):
                 QUB.Report("%i\t%f" % (classes[i], durations[i])) # class<tab>duration

More extensive scripting, such as modifying the idealization, can also be done.

When you Idealize or "chop" idealization, it generates measurements into a table e.g. Segments or List. Then you can plot some per-segment value such as Popen (occupancy probability of the open class) vs. segment index, and apply color(s) to that plot, in order to exclude outliers or break the data into multiple populations.

Using QuB (classic):

To analyze just the segments you've colored red in "Results: Select", right-click the red square on the left edge and choose "Make selection list..." It will make a list of only the red segments. Then choose Data Source: list and continue analyzing with the new red list.

Using QUB Express:

"Select" is renamed Figures: Charts. In version 0.9, it can plot info from the Segments or List table. (Chop is in the Lists menu, at upper-right of the Data.) After coloring points from the Segments table, use Tools: Extract with Source:other, Segments: group 1, to create a new data file with only the red segments, then continue analyzing the new file.

If you've used Figures:Charts to color some points from the List table, look at List in the table view, and click "Copy sels to list," which will make a new list with only the red selections. Then use Tools:Extract with Source:list to create a new data file, and continue analyzing that file.

In the panel Modeling:Stimulus, you can set "latency" to a negative number of milliseconds, in order to shift the voltage signal to the left. For short pulses, make sure "min dur" is small enough to characterize it accurately.

First, install XCode from the App Store. Then open the Terminal and install Homebrew:

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Homebrew's default gtk+ works with an X server, but we want native Quartz graphics, so we use specific taps:

$ brew install marcsowen/gtkquartz/pygtk gsl homebrew/python/scipy boost

As of this writing, the marcsowen/gtkquartz tap is not compatible with osx 10.10. To make it compatible, go to /usr/local/Library/Taps/marcsowen/homebrew-gtkquartz/ and edit two files: In gtk+.rb, change the 'url' on line 5 to version 2.24.25, and in pango.rb, change the 'url' on line 5 to version 1.36.8. Also delete the 6th line of both files (the line starts with 'sha256'). Then remove and reinstall both recipes:

$ brew remove gtk+ pango && brew install marcsowen/gtkquartz/gtk+ marcsowen/gtkquartz/pango

To select the right compiler, add these to the ".profile" file in your home directory:

export QUBX_CCP="/usr/local/bin/g++-4.9"
export QUBX_PYTHON="/usr/local/bin/python2.7"

and restart your terminal, or type "source ~/.profile". The system should be ready for QUB Express:

$ cd qub-express
$ make clean
$ make all

To make an app (bundle) and disk image in the dist folder:

$ make bundle
$ make dmg

QuB's transition matrices can have numerical instability for certain combinations of rate constants and dead time. However, optimization usually succeeds, maybe because the unstable combinations were steps in the wrong direction, and so correctly discarded? The message is there in case it totally fails, so there's an indication of where and why.

Yes. By default the states all have entry probability "Pr" == 0, and it will pick a completely random start state. (QUB Express has a checkbox to start simulations at equilibrium.)

This looks like probably a scaling issue. QuB stores data as integers, so it's important to choose a good "scaling" factor:

stored_int = round(pA * scaling)

To adjust the scaling, right-click "Simulate" and choose "new data file." After clicking OK (Simulate), scaling is in the next dialog (new data file options).

Our newer program, QUB Express, uses floating-point formats to avoid most scaling issues.

You get confluent eigenvalues when, for example, you have multiple rates with identic values. Tha'st the most common situation I encountered. It mostly happens because we generally initialize models that way (e.g., all rates are 1000s-1).

The std values are only meaningful in the last iteration, when they are actually calculatd. In rest, they are junk in memory, and reported as NAN by the Format routine. At least I think so.

Try the Histogram window (View menu -> Histogram). The first panel makes amplitude histograms; right-click, properties for options. In particular, turn off "Autoscale." Then press OK, and click the little blue icon to update the histogram. Note that it operates on data from the "Data Source." To extract the histogram, right-click it and "copy data", "extract" (text file), or "extract to excel".

The "Fix Noise" option is not used anymore in IDL/Base. Instead, one can apply amplitude or noise constraints using the constraint editor in the model.

To access the constraint editor, RightClick on the model, choose "Properties", and select the "Amplitude Constraints" panel.

The amplitude and noise of the closed states ("black") are regarded as a reference. The amplitude and noise of open states (other than "black") can be seen as absolute values, or as "excess" relative to the reference values. Thus, the constraints can be formulated in terms of absolute, or excess values. By definition, the excess amplitude and noise of the closed states are both zero.

The constraints available in the editor have the following meaning:

Fix Amp/Var:

• fixes the absolute amplitude/variance of a conductance class;
• takes one argument: the index of the class (1 - "black", 2 - "red"...)

Fix exc Amp/Var:

• fixes the excess amplitude/variance of a class, relative to the reference class (the "black" states). The absolute Amp/Var may change upon reestimation but the difference (the "excess") is fixed;
• takes one argument: the index of the class;
• does not apply to the closed states.

Fix diff exc Amp/Var:

• fixes the difference in excess amplitude/variance between two classes. The absolute Amp/Var of either class may change upon reestimation but the difference between them remains fixed;
• takes two arguments: the indexes of the two classes.

Scale exc Amp/Var

• keeps fixed the ratio between the excess Amp/Var of two conductance classes;
• takes two arguments: the indexes of the two classes.

Scale diff exc Amp/Var

• keeps fixed the ratio between the differences in excess Amp/Var for two pairs of classes;
• takes four arguments: the indexes of the two pairs of classes.

For example, when idealizing data with 3 subconductance levels that are assumed to be of equal amplitude, one can use a set of two "Scale diff exc Amp" constraints:

2 1 1 0 
3 2 2 1 

With these constraints, the re-estimation of amplitudes will make sure that the difference between "black" and "red" (the first level, 0-1) is the same as between "red" and "blue" (the second level, 1-2), and the same as between "blue" and "green" (the fully open level, 2-3).

Here is a trick: change the colors in the model so all of the in-burst states are red, and all the inactive states are black. Now the simulation will be "open" for the whole burst, and you can look at the open-duration histogram.

When you simulate, make sure to check "Idealized data: Class". Then choose Data Source: file, and go to the Histogram window. Right-click the third panel and choose "properties." Select class "1" (sorry, in this window 0==closed/black, 1==open/red) and adjust Bin count and log [log10 x axis]. Then close the properties and click the green button to draw the histogram.

Right-click the histogram to copy to the clipboard, or to Extract it to a text file or excel spreadsheet.

When you're working with real data, you can use a similar trick. First idealize. The next steps will modify the idealization, so you might want to save and work on a copy. Next, find the bursts using ChopIdl, e.g. terminating with a dwell in class 1 longer than Tcrit ms. (To get an estimate of Tcrit, run MIL with a 2-state model and "show iterations.") Now there is a selection list of "chopped events"; choose Data Source: List, click "EditIdl", and "change class 1 events to class 2."

At this point the idealized line is "open" for the whole burst. Use the Histogram window, as above, to see the open-duration histogram.

QuB can chop data into 20 second chunks, measure P0 of each, and make a table of start time and P0 per chunk:

1. make sure the whole file is Idealized.
2. set Data Source: file, and click Chop Data (skip 0, get 20000 msec, skip 0)
3. set Data Source: list, and click Stat (the Stat button may be hidden; to show it, click the Modeling header in the right-hand button bar).
4. In the Results window, "Segments" tab, find the column "occupancy 2". Highlight the whole column, right-click, Copy. Paste into a program that can make a histogram.

First, Idealize your data.

Then, create a list of bursts. To create it by hand, use the Actions under "Lists": First "Add List", then for each burst, highlight it and "Add Sel".

To quickly create a list of bursts, use ChopIdl. It will list all of the data regions whose closed events are shorter than Tcrit.

When you have a list of bursts, choose Data Source: list, and run "Stat" (Actions -> Modeling). In the results window, go to the "Segments" tab, and look at the column "interburst". Alternatively, go to the "Select" tab, and "show var..." -> 'interburst'. Interburst is the number of milliseconds since the end of the last burst. If there was no prior burst in the same data segment, 'interburst' is the number of milliseconds since the beginning of the data segment.

After idealizing, go to the Results window and click the tab "Segments." Scroll the table to the right and you should see columns including "DwellCount" -- the combined number of baseline and pulse events; "nevent 1" -- the number of baseline events; and "nevent 2" -- the number of pulse events. Also, "occupancy 2" -- fraction of total time spent in pulse state; and "lifetime 2" -- mean duration (milliseconds) of a pulse event.

Two basic operations are in the data's right-click menu:
Join Idl -- extend the event which is at the beginning of the selection across the entire selection
Delete Idl -- remove idealization from the selection

You can do more with the "Edit Idl" button (under Preprocessing on the right). For example, to insert several open events quickly:

• make a new selection list (Lists: Add List)
• highlight each event and press the S key (shortcut for Lists: Add Sel)
• set Data Source: list (upper right)
• Edit Idl: fill blanks with class 2

I think maybe your data lost some precision on the way into QuB. Was the input file also text? When you open a text file, one of the number it asks for is "scaling." For historical reasons, QuB represents data internally as integers, and converts them to real numbers by

real = int / scaling 

So when you enter the scaling factor, it effectively quantizes the data to increments of (1/scaling). Next time you open the input file in QuB, click into the "scaling" box; a calculator will appear with the maximum possible value and the resolution. Hopefully if you change the resolution to 0.01, Extract will work properly. Please let us know if it doesn't.

Extract the simulated recording ('Ext' button) into ASC format without checking any of the options of the 'output format' box and checking the box 'Join Segments' ('Only active channel' also checked) - I select in the window that appears next '4 bytes' and check 'Float' (although this is only to show the ASC data into QUB again, I think). This generates a TXT file.

Open the TXT file using the pClamp software - the program I use is called Clampfit and the version is 9.2.0.09 (I hope all this doesn't change with the version). In the window that appears next I check 'Gap-free' and 'Add a time column', assigning the correct sampling interval value. This imports the recording into Clampfit so that we can see the same recording we had in QUB now in Clampfit's window.

Last, save the recording as (File/Save as... option) an ABF file.

To fix the report window, delete the file c:\program files\qub\console.txt. This file preserves the contents of the report window across runs, but it is probably corrupted.

To build a list of clusters:

1. click Lists:New List
2. with each good cluster: select it and click Lists:Add Sel

To join them together in a new data file:

3. choose Data Source: list
4. click Preprocessing:Extract
5. choose Output format: QDF (or DAT), and check "join segments"
6. double-check the output file name, and click OK

--or--

To see amplitude and duration histograms for the listed clusters:

3. choose Data Source: list
4. View -> Histogram -- the first pane is amplitude, the third pane is duration
5. right-click in a pane -> Properties to adjust bounds, choose a class of events, etc.
6. click the graph icon at upper-left of a pane to re-generate the histogram from the Data Source

For duration histograms, you have to Idealize the data first (click Modeling:Idealize).

It's kind of a feature: What you're seeing is not k0, but k0*Ligand at the active point in the data. So if Ligand varies (it's assigned to a data channel in data properties: data: experimental conditions), clicking different parts of the pulse changes the effective rate constant shown in the model. If you'd rather see the raw k0, go to model properties: display and check the boxes "write rates along arrows" and "show k1".

Typically, we AMP a section, idealize the whole file w/ SKM (re-estimating the amps and rates), fit with MIL, then re-SKM (no estimation of amps or rates), and then fit with MIL, etc. until everything is stable.

As you have seen, we have written copy and paste for some types of files, but not all of them. The answer, for sampled data like IBW, is to change the file into a supported format like QDF. In Qub, "Extract" the whole file to QDF format, and copy/paste using the new file.

For idealized data you'll need a text editor like notepad. In Qub, do "File->Idealized Data->Save...", then open that file using notepad.

After idealizing, click the "Stat" button (on the right under Modeling; if it's hidden click the Modeling header). It does the lifetime etc. measurements and histograms using existing idealization. Right-click Stat to choose whether to apply the dead time (drop short events) before measuring.

There is if you use MultiFit. After doing "Fit All", and closing the fitting window, go to the Results window (View -> Results), Segments tab. You can drag across this table to select, then right-click: "Copy".

1. Building a new list from pieces of an old list, one at a time: Choose the source list in the overlay window, then create or choose a destination list in the Data window. When you click a trace in the overlay, this selects it in the Data window. To add this selection to the dest. list, click in the lower pane of the Data window (to give it input focus) and press 's'.
2. Building a new list from corresponding pieces of an old list, all at once: Choose the source list in the overlay window. Optionally drag a rectangle over the overlay: this excludes all data before and after the rectangle, as well as any selections (traces) that are entirely outside the rectangle. Remove the checkmark from any selections that should be entirely excluded from the new list. Right-click in the lower pane and choose "new list of selected"
3. Like (2) but implicit: Choose Data Source: list. As long as there is a list loaded into the overlay window, 'Data Source: list' refers to just those parts that would be included in "new list of selected". This is visible as a blue background in the Data window, if 'data properties: draw selection list' is on.

QuB receives acquired data into a buffer (memory region). Because of OS and disk delays, it's not possible to write each sample to disk when it arrives, so we operate on one buffer full of samples at a time. If the buffer length is too short, and QuB can't write one buffer to disk before the next one arrives, you may lose data (you'll know because the file is shorter than it should be). The default buffer length of 1000 ms is generally sufficient.

QuB does not currently support Digidata or other hardware from Molecular Devices. If Molecular Devices provides a programming interface, it is possible for a programmer to build a QuB acquisition plugin. For an example, see the folder QUBACQNM in the QuB source zip.

The scaling factor has units integers-per-volt. QUB calculates this from your acquisition setup -- integer range e.g. 16 bits = 32768, divided by voltage range e.g. +10 - -10 = 20.

In addition, there is a second scaling factor, for each A/D channel. This one has units of volts-per-unit, and is sometimes called the "calibration factor." So for example, if a 3V signal from the amplifier means 1pA, the calibration factor is 3.

You can change scaling and calibration factors after the fact, in data properties. You can set up calibration factors for future experiments in Options -> Acquisition Channels, or with Options -> Calibration Assistant.

When you create a new file for acquisition, it totally ignores the user-input scaling and writes the correct value for your acq setup. After that, you can change it and QUB won't know better. I think all files acquired on the same system should have the same scaling (not necessarily the same calibration), so it should be easy to check and fix.

We can write a function to scale one x value:

def scale_x(x):
    return (x-Fitness.data.xMin) / (Fitness.data.xMax - Fitness.data.xMin)

From the Python menu, choose Environment, and paste the function onto the end of the startup script. Then press Reload. Now, in your formula, replace all the "x" with "scale_x(x)", for example: "a*x**2 + b*x + c" becomes "a*scale_x(x)**2 + b*scale_x(x) + c".

Of course, it will be slower, because it will call scale_x for each data point, each iteration.

WAVES /D Sweep, Transition, PreAmplitude, PostAmplitude, Level, TagValue
BEGIN
2	47.872479	2.4789430E-012	7.4789430E-012	1	0.000000E+000
2	47.872848	7.4789430E-012	2.4789430E-012	0	0.000000E+000
2	47.874586	2.4789430E-012	7.4789430E-012	1	0.000000E+000
2	47.874683	7.4789430E-012	2.4789430E-012	0	0.000000E+000
2	47.988804	2.4789430E-012	7.4789430E-012	1	0.000000E+000
2	47.988911	7.4789430E-012	2.4789430E-012	0	0.000000E+000
2	48.008335	2.4789430E-012	7.4789430E-012	1	0.000000E+000
2	48.008452	7.4789430E-012	2.4789430E-012	0	0.000000E+000
2	48.014088	2.4789430E-012	7.4789430E-012	1	0.000000E+000
END

Since QuB Classic 2.0.0.9 and QUB Express 0.9.0, we can read intervals/dwells/events from TacFit tables. Some notes:

• the table has to be saved in a file with the extension '.tacidl' (if there is a preferred extension, we can change it, but it has to be unique, unlike e.g. '.txt')
• the table has no duration for the first and last dwell, so we arbitrarily set them to the shortest duration in the record

        Model 1: C1<--->C2<--->O1 or Model 2: C1<--->O1<--->C2
        

There is no theoretical way to tell them apart using simple equilibrium data. However, if you optimize with multiple recordings at different concentrations of ligand, or voltage/pressure levels, the models should be distinguishable by log likelihood. If you optimize the correct model one data file at a time, most rates should agree, with only one or two changing with concentration; in other models, all rates might change. Similarly, point mutations of the channel have been seen to affect only one or two rate constants.

I think it can happen when there is not enough data to precisely quantify the rate constant. If no likely transitions are observed, the rate constant will approach a limit of 0.0; if transitions seem to happen much faster than the sampling rate, the rate constant may approach positive infinity, because of the approximate missed events correction. One approach is to add constraints to the model -- to fix the problematic rates at constant values, and optimize the others. In QuB Classic, go to Model Properties -> Kinetic Constraints; in QUB Express, right-click the rate constant and choose Add Constraint. In principle, more iterations are always better. The most likely rate constants are those which have been iterated until no more improvement is possible. In practice, the optimizer can get stuck, so we keep max iterations between 50 and 100, and run MIL repeatedly until there is no improvement in log-likelihood.

A ramp is never at equilibrium, unless maybe if it's very slow. With steps, it waits some time at each voltage until the current reaches a stable amp, but a ramp stays at each voltage only momentarily.

This is a difficult question...

The simplest answer is to go to the open state's properties, and make Std smaller, then re-Idealize.

The rate constants also have an effect on idealization. In particular, fast opening and closing rates cause it to detect more short events, so you could try smaller rate constants. Some people idealize first with a simple model, use MIL to find a more likely model, then use that model to re-idealize.

The re-estimation options in Idealize can also help. "Fix kinetics" locks in your rate constants. "Fix std", class 2, will lock in your custom open std.

There are yet more options in Idl/Base (idealize with optional baseline correction) -- try various "re-estimation" and "most likely sequence" options, and be aware the "Fix" settings have no effect.

Due to finite rise times, events shorter than some threshold can't be detected reliably. The MIL likelihood algorithm uses a "dead time" -- events shorter than Tdead (td) are discarded, and the math is adjusted. This happens invisibly each time you click MIL Rates, so you can adjust td (at upper right) and see how MIL behaves with different dead times. You will still see the short events on screen, unless you lock in a particular dead time and permanently discard the short events, by Idealizing with the option "apply dead time to idealization." So if the false events are shorter than the dead time, which is typically 2 to 3 samples, then you can ignore them because MIL ignores them too.

Of course if they are rare enough you can 'J'oin them, but that can be a lot of work.

It depends on which rate constants you are interested in. If it's just the one fast transition between closed and open, you can choose the shortest Tcrit, and model the bursts with a 2-state model. Or you can pick a longer Tcrit, and use a model with more states.

You're probably right about keeping the bursts with only a few events. We have a lot of tools in QuB for discarding various kinds of data, but it's up to the scientist to decide when it's appropriate, and why.

QuB filters by convolution with a Gaussian in the frequency domain. In data properties, you can choose the "moving average" filter, which is faster but more approximate.

The numbers in the blue report are sum squared deviation, followed by the color of each datapoint in the best trial. I don't know how to definitively choose K, but I have heard the suggestion to plot K vs SSD and look for the inflection point.

Two sources of variability in the output:

• K-Means is an example of an Expectation Maximization algorithm; as such it converges slowly and gets caught in local minima. Try increasing the number of trials (starting colorations).
• arbitrary color-numbering: [1, 0, 0] == [0, 1, 1]

Fitting data with conductance states that are close in amplitude is difficult. It looks like the states differ by less than 1 pA.

When fitting "difficult" data, it's important to take care in assigning amplitudes and standard deviations for the states (both matter for SKM). You can use the amp tool to assign amplitudes (I think it works for more than one conductance), or do it manually with the grab function. It is very important to run amp or use grab at the same digital filter (or unfiltered) you run SKM at to idealize the data.

I would try to collect data at 2.5 times the frequency of the physical filter, ie filter at 10 kHz and record at 25 kHz, or filter at 5 kHz and record at 12.5 kHz, or filter at 2 kHz and record at 5 kHz.

Set the dead time to 2.5 samples.

Filter at low frequency for display purposes only. Select a conductance state and "grab" unfiltered (or at the highest number digital filter possible), repeat for all your states.

When you run SKM, also run it unfiltered. Or both grab and SKM both at the highest number filter possible for good results. Make sure the idealization approximately follows what you would do by eye.

When running MIL, it works best in practice to start with simple models and build to more complex models. Start with C-O1-O2-O3 with your three conductance states first. Then build your more complex model one state by one. Make sure all the components are visible in the histogram at each step.

SKM also depends on the model and the rates that are in it. Once you have a reasonable idealization and fit, it may be useful to reSKM and MIL.

I'm not an expert on fitting binding, but I think it works best if you fit across concentrations, is this what you're doing? For the purposes of fitting at a single concentration, just set the rates to scale appropriately for your model. When I fit binding, it can be difficult to keep track of the units, make sure the units are correct for the concentration to give appropriate units on the rates.

With infinitely fast sampling we would see every transition; however, the exponential distribution of event durations means several events are faster than the sampling interval. This plays out mathematically: take a three-state model that starts in state one, with connections between states one and two, and two and three. The initial occupancy probability vector P0 is [1, 0, 0]. The rate constant matrix Q has zeros at 1,3 and 3,1, since 1 and 3 aren't directly connected, but the probability of being in state 3 after one sample is nonzero (it's the third entry in the vector P=P0 * exp(Q*dt)).

LL is roughly proportional to the number of events. I think they can look at the change in LL because their experiments generally have a similar number of events. I went over and asked; around 5,000 events; i.e. the threshold in terms of LL/event is around 0.002. As you guessed, this number is arbitrary, based on their experience. To get an idea of how sensitive LL/event is with one of your models, try simulating some data, then running MIL with and without extra states.

The text report window shows several things including the previous LL. To my chagrin, it seems LL/event doesn't show enough significant digits -- maybe next month, along with a better Tcrit solver. And we're kind of out of room to show e.g. delta LL/event.

Since you asked, there is a more fundamental mystery in the LL from MIL: "log likelihood" is log probability; that is, e^LL should be between 0 and 1. Instead, it's calculated by multiplying probability density matrices (Qin et al 1996) whose elements are proportional to the rate constants. So we get a "likelihood" proportional to K^(num_events), for an average rate constant K; and LL ~= num_events * log(K). Perhaps the salient quantity is (LL/event) / log(mean K)?

The simplest, if the amplitudes stay stable, is to type or "grab" them by hand, then use amplitude constraints to fix each class's amp (and maybe std too).

QuB 1.5 has a button "Edit Idl" under Preprocessing, which for example can change class 3 events to class 2. If you see two indistinguishable classes in the idealization, you could use EditIdl to merge them into one.

Or, idealize with a 2-color model, 3-color model, 4-color, ... and pick the largest n with unique classes.

Also, you can repair idealized data after the fact by selecting a piece, right-clicking, and "Fill Idl" -- it sets the whole selection to the class of your choice. Then to compute updated Results (occupancy, etc.), click "Stat" under Modeling.

Sorry about the delete function. I've heard it doesn't always work right. Instead, try "delete idl" (leaves a gap in the idealization) or "join idl" (replaces selected idealization with the level at the beginning of the selection, e.g. closed).

Sublevels and brief closings can hopefully both be detected with a bigger model. For sublevels, add a state with a new color, e.g. blue, select a piece of data at the sublevel, right-click the blue state and "grab." Connect it as you see it in the data; i.e. between closed and open, if it happens during the transition. For brief closings, add a closed state, connected to the open state, with a really fast exit rate. The idealization is somewhat sensitive to rate constants, so it might get better as you tweak them. Also experiment with the idealization options: "fix kinetics" (rates), "fix amp", "fix std", and "re-estimate" (if re-estimate is un-checked, all rates, amps and stds are fixed).

Some missed events are okay. They're inevitable due to finite rise time in your equipment, so the rate constant optimizers MIL and MSL discard all events shorter than the cutoff "td" (dead time), in the upper-right corner. Then they adjust mathematically for their absence. The adjustment is valid as long as the missed events take up a small fraction of total time, and the rate constants are slower than 1/td.

If you really want to get the brief ones, though, you could try modeling them as their own color of substate, then use the "Edit Idl" button to change e.g. class 4 events into class 1.

QuB can save a table of each event with its mean current (as a text file):

File -> Idealized Data -> Save idealized with event stats...

[QUB Express: Tools:Idealization:Save...]

Hopefully you have a stats program which can take it from there.

Search engine optimization (SEO) frequently makes use of Markov models to learn the characteristics of a body of text, for example, user comments on a forum. The trained model is then used to generate fake comments, which look realistic but are actually meaningless vehicles for link spam. While QuB uses very similar mathematics, it is not well suited for SEO because our observed and simulated data consist of continuous numerical readings rather than discrete words or phonemes.

Please DO NOT post advertisements on this page. Every submission is hand-screened, and will only be posted if it is relevant to QUB and molecular analysis.