Data ending up in scrap file from trim.flows

I just recently have begun working with mothur and have a lot to learn. I am working on following the Ion Torrent SOP on the mothur website and have run into an issue with most of my sequences ending up the scrap file output from trim.flows.
I set up my oligos file as such:
barcode CTAAGGTAAC base1_001
barcode TAAGGAGAAC folUp1_002
barcode AAGAGGATTC base5_003
barcode TACCAAGATC folUp5_004

First I ran sffinfo and that seemed to run just fine.

Once I ran the trim.flows step with my oligos file, I find it seems that the scrap file output file is highly populated.
I used the default arguments suggested:
mothur > trim.flows(flow=IonOct.flow, oligos=IonOct.oligos, pdiffs=1, bdiffs=1, order=I, processors=16)

If I run it with the oligos file indicating that I don’t want mothur to screen for the reverse primer, then I get the following files and their sizes : -rw-r--r-- 1 barbj MSCL 570527 Jun 10 14:33 base1_001.base1_001.flow -rw-r--r-- 1 barbj MSCL 570527 Jun 10 14:33 base1_001.trim.flow -rw-r--r-- 1 barbj MSCL 203745671 Jun 10 14:33 base1_001.scrap.flow -rw-r--r-- 1 barbj MSCL 25 Jun 10 14:33 base1_001.flow.files -rw-r--r-- 1 barbj MSCL 1018 Jun 10 14:33 mothur.1402425117.logfile
Is there any particular reason why most of my data is ending up in the scrap file? Do you see something that stands out that could be wrong? My oligos file looks like it is set up correctly. we also tried adding in a linker or spacer argument to the oligos file and it does not improve much. Does anyone have any thoughts on this? thank you.

You might check the number of flows in your sequences and then adjust minflows/maxflows. Our default is 450, which is probably much more than you have. I suspect you probably want to use 250 or 300 flows.