Yes you are right!

You cannot use the Livak et al formula. In your case, I don't understand why do you need to analyze gene expression in control group for different time points?! I mean since you have not treated with anything, the gene expression usually tends to be similar in controls. Or if you have something else in mind, please do share.

All ddCt really does is boil two numbers down to one: converting expression A and B into 'log fold change between A and B' (or if 2^ddCt, linear fold change).

There is no pressing need to do this (though it can make graphical representation easier under some circumstances).

dCt is...basically normalised log data, and 2^dCt is linearised normalised data (it also assumes the efficiency of your reference genes and GOI PCRs are all 100%).

If these assumptions are correct, there's no reason you couldn't compare 2^dCt values between 0, 24 and 48 hr timepoints.

How many biological replicates do you have?

@Pushkal Sinduvadi Ramesh

Thanks for your kind answer.

I alreadly got the data from the experimental groups.

However, I additionally would like to analyse the change of gene expression in the control group by time.

@John Hildyard

Thanks for your kind answer.

Could you explain this sentence in more detail?

'it also assumes the efficiency of your reference genes and GOI PCRs are all 100%.'

If your efficiency isn't 100% (i.e. if you don't double your amount of amplicon with each cycle), then 2^dCt isn't actually a linearised value (and indeed dCt methods should be used with caution).

The 2 here represents the doubling nature of PCR, so an efficiency of 90% would need to use 1.9 instead (each cycle produces 1.9x the amount of amplicon), and for dCt methods (where you subtract one Ct value from another) you really want both PCRs to be of equal efficiency (and ideally 2, i.e. 100%)

Usually efficiencies of 95-105% are considered close enough to 100% as to be fine, but if your efficiency for one PCR is, say...80%, which is not necessarily uncommon in PCR, then you might be in trouble, because PCR is exponential, thus small differences are magnified over multiple cycles.

Consider:

20 cycles of PCR at 100% efficiency, starting with 10 template molecules: 10485760 amplicons.

20 cycles of PCR at 80% efficiency, starting with 10 template molecules: 1274823 amplicons, or almost ten-fold fewer than you would expect if you assumed 100% efficiency.

In other words, PCRs with low efficiencies give the illusion of lower expression than is actually the case.

I personally tend to avoid dCt methods, and linearise my data immediately into relative quantities:

Sample RQ = efficiency(lowest Cq - sample Cq)

Where lowest Cq is the lowest Cq value for that gene out of all your samples, and sample Cq is the Cq value for that particular sample, and efficiency is your doubling per cycle (so for 100% efficient, this is 2).

What this does is render ALL your data immediately linear (from 0-1), and allows individual efficiencies to be factored in. If sample 1 has an RQ of 0.8 and sample 2 has an RQ of 0.4, you can see immediately that sample 1 has twice as much template as sample 2, without needing to work out the logs in your head.

You can then normalise your GOI RQs by simply dividing by the ref gene RQs (because it is linear: this is the same effective operation as subtracting the log values).

The numbers you get are essentially arbitrary in terms of actual expression: they won't tell you how many transcripts they represent (but neither will dCt methods). They will tell you exactly how your samples compare, though, and this is all you need for statistical comparisons.

Attached is an example excel spreadsheet using the same Cq values, but analysed via dCt and RQ respectively: the answers are the same either way, but the maths is easier to understand using RQ (in my opinion).

@John Hildyard

I totally understood.

Thanks for the detailed explanation.

I'll read it once again.

See figure 2 in this paper:

Article Effects of Warm Ischemic Time on Gene Expression Profiling i...

That's almost perfect!

@ Jochen Wilhelm

Thanks for the paper.

It helped me a lot:^)