Looking at the discussions on the Ion Community website, I came across an entry that mentions something interesting about the flow order. For both 454 and Ion torrent, sequencing happens by flowing one dNTP (base) at a time over the template. For each read, one or more of these bases gets incorporated, or none at all (see also an entry on this at my other blog).
454 has been using the same flow order since the beginning: TACG. This can be seen from the ‘header’ part of the sff file, which lists the flow order under ‘Flow Chars’ (see here and here for examples).
The first Ion Torrent runs on the 314 chip used the exact same flow order as 454. The Ion Community entry I mentioned explains how for the 316 chip, for which the first data were released not too long ago on the Ion Community website, an entirely different flow order was used. Instead of a four-base repeated cycle, the following 32 base (!) sequence was used repeatedly:
TACGTACGTCTGAGCATCGATCGATGTACAGC
Why would this ‘weird’ flow order be used? The different flow order apparently helps to remove incomplete extension, yielding longer read lengths. Incomplete extension happens when a subset of the template molecules on a single bead wrongly does not incorporate a base, making them out of sync with the rest of the molecules, and causing noise during later flows. The new flow order allows for these molecules to ‘catch-up’, so the different template molecules are better synchronized. A drawback of the 32-base flow order is the (on average) lower number of incorporations per flow, meaning more flows are needed for the same read length.
It looks like Ion is experimenting with other flow orders to get even better results. Now there is something 454 might give a try (although Life probably has or will take a patent out on this)…
For those of you who have access, the post is located here, and another one here.
In between lines of code 