How can I get the duration of the events in Nanopore?

Question

PacBio has the concept of IPD (InterPulse Duration) which is the time between two detected consecutive sequences in the raw signal. I have been trying to extract this value in the Nanopore, but I cannot find them in the .fast5 files. But this info must be there:

This is from the paper Nanopore sequencing technology, bioinformatics, and applications:

''Each current segment contains multiple measurements, and the corresponding mean, variance, and duration of the current measurements together make up the ‘event’ data.'' Directly quoted from the paper, which suggests we should have the information about the duration in the raw signal.

How can I get the duration, I appreciate it if can anybody help?

Some info I read was confusing to me (e.g. http://simpsonlab.github.io/2015/04/08/eventalign/ which is nevertheless a great source for understanding what is going on), I knew single measurements' speeds are controlled, however, I didn't know the block stride is fixed and it made me so confused at first.

What I found related to my own question: I guess I was not completely correct in the terminology I was using, which might cause confusion. In nanopore sequencing, translocation duration refers to the time a fragment of DNA/RNA passes through the nanopore. Also for better visualization, I made this plot after running albacore basecaller:

as @gringer has explained, the block stride value is fixed (=5). The figure shows a small portion of albacore Event Table: The x-axis corresponds to the relative time from the start of measurements and the y-axis shows the current level. Each black dot shows a single measurement from an ONT device; the dots are segmented by a set of block strides (=5) used by albacore to call an event. The red lines show the average of the measurements in one segment. The shaded area in light gray represents the event that resulted in calling a base (one to one). Dark gray areas show events that resulted in calling two bases (split events). The white area corresponds to events with no called bases (skipped events). The boxes below the x-axis correspond to bases called in shaded areas and the bold base is the base that is called for that event.

Answer 1

Unfortunately ONT no longer produce event data as default in their FAST5 output with the most recent basecallers, and they've been quite vague about how to generate it.

The easiest way to fix that is to use an older basecaller. If you tell Guppy v5.1.15 to output FAST5 files, it should include an event table that includes read start time and move information. This might also work with new Guppy, but ONT has told us that the event tables have gone away.

Processing the move tables to get information about signals per base is a bit complicated. Just using the metadata provided in the FAST5 files it's actually impossible, but you can get close enough to match what the ONT basecallers were trained on (which is probably close enough). To get closer than that, you need to process the raw signal yourself (e.g. see here).

Alternatively, you might be able to get that information out by following the tomboy documentation, which produces output that demonstrates signal-level changes:

https://github.com/nanoporetech/tombo

ONT have had various methods for basecalling over the years, and these methods change how the signal is chunked and processed.

When nanopore sequencing was first commercially available, base change points were resolved down to a single-sample level (as described in Jared Simpson's post which you linked). Or, at least, as accurately as they could at the time. Even with that approach, events were occasionally misclassified such that two consecutive events could represent the same base, or two consecutive events could involve a change of more than one base. To account for this, ONT created the move table, which described how many bases were shifted between one base and the next base. Initially ONT were using pentamers (i.e. 5 base sequences) for the output of their calling models (this had a physical reason, because 5 bases was about as many as would contribute to the instantaneous current), so the move table could have values of 0 [indicating two adjacent events described the same base], 1, 2, 3, 4, or 5. Although 5 was the maximum, because it was a pentamer model, what it actually meant was "there has been a large skip; we have no idea how large."

Unfortunately, sample-level signal parsing is no longer the case, which makes precise event alignment tricky. Most recently, individual signal samples are aggregated into what are called strides, which describe the smallest length of time that the basecaller accepts as representing a single base transition.

For this explanation, I'm going to assume that the directory location in the FAST5 file starts from /baseLoc/, with the FASTQ sequence found in /baseLoc/Fastq. This explanation may become quickly out of date, as ONT change their data and methods frequently.

Raw signal information is found at /baseLoc/../Raw/Signal. The stride length information is found in the block_stride attribute of /baseLoc/Summary/basecall_1d_template. This indicates the number of signal samples allocated for each stride. The move table is found at /baseLoc/Move, and represents the number of base shifts in each stride block (usually either 0 or 1). It sounds like that move table is the statistic you're interested in; multiply the number of 0s before a 1 by the number of samples per stride (plus 1 for the base transition), and that's the base duration in samples, which should be divided by the sampling rate to get the number of seconds per base. Sampling rate can be found in the sampling_rate attribute of /???/channel_id (sorry, don't have a precise location, because I usually just assume 4 kHz... which will probably be changing shortly, from the sound of it).

Some of the signal at the start of the read may have been clipped, and it's necessary to take this into account in order to properly align the move table to the signal. The signal offset is found in the attribute first_sample_template for /baseLoc/../../Segmentation_000/Summary/segmentation, and represents the number of samples (not strides) that should be clipped off the start of the raw signal. There's one more thing that may help for aligning bases to signal, and that's the base offset relative to the move table. The basecaller works in chunks of multiple bases (kmers), so the base corresponding to the move table is actually somewhere in the middle of the called/modeled kmer. ONT doesn't provide any insight into this (it's possible they don't know), so I just try some offsets between 1-5 bases and pick the one that looks the best.

I have a FAST5 annotation R script that may help a little bit more in understanding how the alignment works, see here, specifically the code starting from the comment ## Load data from called fast5 file.

Bear in mind that "number of samples per base" varies in a non-smooth fashion with quite a large dynamic range within an individual read sequence, and could be anything from 1 to over 50 (although I stop believing the basecaller if it reports anything over about 20). It doesn't make much sense calculating it as an aggregate statistic for each sequence, except possibly for detecting really poor basecalling (which is more easily picked up by looking at Q scores in the FASTQ file).