<p>In my case the problem was due a wrong set of allowed round1 barcodes, therefore the filtering pipeline was removing most part of the reads. In particular, with the right barcode1 whitelist the total number of reads after filtering is 17M (about 100 times more).</p>

CC BY-SA 4.0
2018-10-04T14:40:20.053Z
2018-10-04T14:40:20.053Z
gc5
<p>I am following <a href="https://bioinformatics.stackexchange.com/a/5136/1771">this answer</a> to select reads with allowed barcodes from a Split-Seq run. In particular, I have a whitelist for each round of barcodes (3 rounds) and I filter out reads which have more than 1 Hamming distance from allowed barcodes.</p>

<p>However, after filtering, the number of reads remaining are only the 0.7% of the original number of reads before filtering (169k from 22M). Is this normal, or what may be the underlying issue here?</p>

CC BY-SA 4.0
2018-10-02T15:19:33.497Z
I would say that it is normal but I'm haven't done splitseq. Could you add some information to help people evaluate it? Like counts distribution across samples, or other plots relevant for QC?
llrs
CC BY-SA 4.0
2018-10-02T19:10:32.230Z
@Llopis I discovered that I was matching one barcode against the wrong whitelist of allowed barcodes. I think this solves the issue, do I need to delete my question?
gc5
CC BY-SA 4.0
2018-10-03T06:58:37.923Z
I don't think you need to delete your question. You could post as an answer how did you find what you where doing wrong, and why it is wrong. If you don't then it might be better to close the question or delete it. But I think it will be useful to know which pitfalls to avoid
llrs
<scrnaseq><reads><splitseq>
Low percentage of reads with consistent barcodes in Split-Seq run
# Low percentage of reads with consistent barcodes in Split-Seq run

(Asked by: username_0 on 2018-10-02)

I am following [this answer](https://bioinformatics.stackexchange.com/a/5136/1771) to select reads with allowed barcodes from a Split-Seq run. In particular, I have a whitelist for each round of barcodes (3 rounds) and I filter out reads which have more than 1 Hamming distance from allowed barcodes.

However, after filtering, the number of reads remaining are only the 0.7% of the original number of reads before filtering (169k from 22M). Is this normal, or what may be the underlying issue here?

**Tags:** scrnaseq, reads, splitseq
> **Comments:**
> **username_1**: I would say that it is normal but I'm haven't done splitseq. Could you add some information to help people evaluate it? Like counts distribution across samples, or other plots relevant for QC?  
> **username_0**: @Llopis I discovered that I was matching one barcode against the wrong whitelist of allowed barcodes. I think this solves the issue, do I need to delete my question?  
> **username_1**: I don't think you need to delete your question. You could post as an answer how did you find what you where doing wrong, and why it is wrong. If you don't then it might be better to close the question or delete it. But I think it will be useful to know which pitfalls to avoid  

---

## 1 answers

### Answer by username_0 on 2018-10-04. Score: 0 | Accepted answer

In my case the problem was due a wrong set of allowed round1 barcodes, therefore the filtering pipeline was removing most part of the reads. In particular, with the right barcode1 whitelist the total number of reads after filtering is 17M (about 100 times more).


---

