Hello Chris,
The bottom of the figure shows the index read (reverse complement of on of the two reads, whichever one was barcoded).
I believe that by default, the sequencing software is set to read two reads (read 1 and 2). I've attached an example runparameters.txt file from the MiSeq at our facility (*don't* use this one, it's just an example for comparison with the settings are your sequencing facility). In it, there are lines like this:
<Reads>
<RunInfoRead NumCycles="151" Number="1" IsIndexedRead="N" />
<RunInfoRead NumCycles="13" Number="2" IsIndexedRead="Y" />
<RunInfoRead NumCycles="151" Number="3" IsIndexedRead="N" />
</Reads>
You may be missing the Number 2 (index) read above.
There is an alternative possibility that the index read was done, but rather than being processed into a third read, it was added to one or both of the reads, or perhaps written to the fastq labels of your read(s).
You might look at a few of your reads, type:
head Path_To_Fastq_file
And see if there are barcodes written to the labels. If not, you might search for barcodes in the fastq files by doing the following:
grep -c AATTCCGG fastq_file
and replace AATTCCGG with some of your barcodes (and the reverse complement of the barcode might be tested as the reads can come out in this orientation).
Hope this helps,
Tony Walters