"
Team:ETH Zurich/gameplayexperiment
From 2013.igem.org
| Line 4: | Line 4: | ||
<h1> Gameplay overview </h1> | <h1> Gameplay overview </h1> | ||
| - | <p>We had problems with the leakiness of our system and the missing promoter library in Lyon, but solve those for Boston. <br>After finding out the <b>analytical solution</b> (see here of rhte solution) needed for the second promoter detecting two mines around, we decided to do partial sensitivity recovery of the first P<sub>LuxR</sub> variant (G1)(see here for the library). This worked very well and we isolated promoters with different EC<sub>50</sub>. Then thanks to the model prediction we could easily select one of those 7 promoters which fits well in our system (single mutant 1 , SM1).<br> Meanwhile the <b>leakiness could be reduced</b> by introducing a <b>positive feedback loop</b> (see here the optimization of the circuit) and our <b>two problems were finally solved</b>.</p> | + | <p>We had problems with the leakiness of our system and the missing promoter library in Lyon, but solve those for Boston. <br>After finding out the <b>analytical solution</b> (see [https://2013.igem.org/Team:ETH_Zurich/Modeling/Analytical_Approximations here] of rhte solution) needed for the second promoter detecting two mines around, we decided to do partial sensitivity recovery of the first P<sub>LuxR</sub> variant (G1)(see [https://2013.igem.org/Team:ETH_Zurich/Experiments_5 here] for the library). This worked very well and we isolated promoters with different EC<sub>50</sub>. Then thanks to the model prediction we could easily select one of those 7 promoters which fits well in our system (single mutant 1 , SM1).<br> Meanwhile the <b>leakiness could be reduced</b> by introducing a <b>positive feedback loop</b> (see [https://2013.igem.org/Team:ETH_Zurich/Optimization here] the optimization of the circuit) and our <b>two problems were finally solved</b>.</p> |
<h1> The GFP-RFP gameplay</h1> | <h1> The GFP-RFP gameplay</h1> | ||
| - | First of all we set-up a simple version of the game using GFP and RFP as reporters for 1 and 2 mines respectively, using the newly isolated P<sub>LuxR</sub> (SM1) as promoter in the BBa_J09855 construct with RFP as reporter | + | First of all we set-up a simple version of the game using GFP and RFP as reporters for 1 and 2 mines respectively, using the newly isolated and predicted P<sub>LuxR</sub> (SM1) as promoter in the [http://parts.igem.org/Part:BBa_R0062 BBa_J09855] construct with RFP as reporter and the native [http://parts.igem.org/Part:BBa_R0062 BBa_R0062] in the [http://parts.igem.org/Part:BBa_J09855 BBa_J09855] construct with the GFP as reporter. |
<br clear="all"/> | <br clear="all"/> | ||
{{:Team:ETH_Zurich/templates/footer}} | {{:Team:ETH_Zurich/templates/footer}} | ||
Revision as of 16:05, 28 October 2013
Gameplay overview
We had problems with the leakiness of our system and the missing promoter library in Lyon, but solve those for Boston.
After finding out the analytical solution (see here of rhte solution) needed for the second promoter detecting two mines around, we decided to do partial sensitivity recovery of the first PLuxR variant (G1)(see here for the library). This worked very well and we isolated promoters with different EC50. Then thanks to the model prediction we could easily select one of those 7 promoters which fits well in our system (single mutant 1 , SM1).
Meanwhile the leakiness could be reduced by introducing a positive feedback loop (see here the optimization of the circuit) and our two problems were finally solved.
The GFP-RFP gameplay
First of all we set-up a simple version of the game using GFP and RFP as reporters for 1 and 2 mines respectively, using the newly isolated and predicted PLuxR (SM1) as promoter in the BBa_J09855 construct with RFP as reporter and the native BBa_R0062 in the BBa_J09855 construct with the GFP as reporter.
