Question about baselines in Real-Time PCR - (Dec/16/2014 )

Hello everyone!

I have questions regarding baselines in real-time PCR.  Our specific protocol runs 40 cycles, with the baseline set between cycles 3 and 15.  I'm curious as to why the first two cycles are excluded from this range.  Why not just start your baseline at cycle 1? I can't ask questions about the protocols due to the nature of the work we do, so I'm just looking for a generalized answer, if there ar any!

Occasionally, when we plot delta Rn v. cycle (amplification curve), the background noise at the beginning of the run crosses the threshold, although the software never assigns a Ct value (as expected).  Additionally, my boss is always worried about this pre-baseline noise to a large extent, although many times the background near the end of the run isn't anywhere close to the threshold.  Is there any reason we should be extra cautious with the pre-baseline noise?

Thanks for all of your help and thoughts!

I guess first cycles are know to make certain jumps, that can interfere. You don't need the baseline that long, so the usual was set to 3-15.

I can say that in certain applications (running SYBR on once used plate) I can see jums up and down in first few cycles. The nature of that problem is not well known, or they just simply don't want encourage people to use half a plate in one run and the half in next run (as we do, since it's a waste of plastics otherwise).

So just experience I guess. You can move the baseline setting if you want, but I see no point there.

Naturaly software doesn't take into consideration any data crossing threshold before the baseline (and only takes the baseline range for .. well baselining).

I just don't get why is your boss woried about pre-baseline noise, when that is far beyond the even quantifiable limit. Or did you mean he is affraid of the negative samples crossing the threshold at the and of the run (i.e. late cycles)?

Well you don't get a Ct by simply a line crossing a threshold, that is the oversimplifying the real-time PCR detection principle. You need to get an amplification first to call a sample "positive", if there is just noise, it is not positive, it's noise. If it interferes with a a "real" amplification curves to a noticable extent, it may mean some problems in the detector or other technical problem in the cycler. 

If it's not noticable, just plain noisy, and you don't want the analysis algorithm to "catch it", you simply adjust the noise band (I'm not sure now, which cycler brand are we discussing, but I have a feeling all of them should have adjustable noise bands). The reason that some curves may cross the threshold, but not call a Ct value is simple, as far as I know, the algorithms are not simply intersecting lines, but plotting some fit points onto each curve and intersecting projected line through those to the  threshold line. Since noise doesn't have significant portion of data above  threshold, no fit points are created.

So cautious, yes, for implications of a possible technical problem. Worried by noise? No.

Also, if you feel your noise is too high, compared to positive signals, it may be the other situation, that your curves are actually too low. You may inspect the raw signal values to see if that is not the case. In all other cases, the noise should not make any considerable troubles in analysis.

Hi Trof,

Thanks for your reply. 

I understand what you mean about true amplification vs. noise crossing the threshold.  We use ROX as a normalizer and FAM as a reporter; I usually check the individual dye plots for anything suspicious during the run, ruling out false positives.  My lead scientist was indeed worried about pre-baseline noise; as I alluded to, we very, very rarely get late-cycle noise that crosses the threshold.  And while I would love to take your advice about adjusting the threshold and baseline settings, our protocols do not allow for either!  Frustrating but necessary for our work. But thank you for your insight, it does clear up a few things for me!

I see, a set protocol.
In that case if you also need to autocall to be 100% correct, the only thing you can do is trying to keep the reagents and the pipetting enviroment, make as little variations as possible, change reagents in the first moment you even suspect some and so. It's far more expensive, than just using the "common sense" in anylyzing, but if you need to have zero variations in your results, there is no other way (all this requires of course also scheduled checkups of the machine with a calibration protocol, because the machine itself may be the source of variations). But only few labs actually do require such very strict measures, I don't know if you are one of them.