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:
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
/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).