[harrison]

Hi Sefrem,

If you turn on the LED there should be a faint glow in the visible range you can see. It is quite high up on the side board on the reactor, directly above the main LED (i.e. the white one with lens).
You could modify the code in this way, by messing with the measureFP function to instead turn on the UV LED.

In practice the UV LED is fairly small optical output power (i.e. because UV LEDs are far less efficient than visible light ones), and on top of this it is a smaller/less input power device than the main multi-colour LED in the system, hence it might be difficult to get particularly strong fluorescence signals out of it…
I guess the best bet is to try to make the strongest fluorescent concentrated solution you can and put that in and see how much signal you get, but I have a feeling it will be still on the low side!

[harrison]

Hello Katie. It doesn’t go on the PC, but rather on the control computer itself. Look at Section 6 of the operation manual here (https://chi.bio/wp-content/uploads/2022/04/Operation1.pdf) for instructions
good luck!

[harrison]

Hello Algaeboy, fitting name…

1) Not really. The LED is a single device with 7 emitters on one dye. We are limited to the wavelengths that the manufacturer supplies on a single device. HOWEVER, since there are 7 LEDs in there you can potentially approximate a 4500k spectrum by adding together some combination of them at different intensities. I am not sure how close exactly you could make it, but if you have some reasonable spectrometer you can probably do some fiddling and get it fairly close.

2) In our lab we grow Cyanobacteria and Algae, but this is not a major focus of ours so I couldn’t tell you the limits of applicability (e.g. what conditions/systems WONT work). I have also heard of others working with both these. Are there particular species you are looking at with some uncertainty?

[harrison]

Hello!
The errors are consistent with some kind of noise/misadventure on the I2C digital communications. It could be moisture sensor partially triggered, or something else. What I’d recommend is taking some ethanol and wiping down the moisture sensing lines, and then also using either ethanol or an air duster aerosol can to clean the USB connectors on all of the reactor/control computer/pump board (if you put ethanol in them, plug/unplug the USB 10 times, then leave them to dry that would probably do it). The most likely explanation for why the system would (at some random timepoint) STOP working is that there is mess/contamination on those connectors which is leading to those signals getting lost.

[harrison]

Yep, almost. It is in the ZigZag function of the code. In particular around line 2013 of the current version there is this code:
if (iteration>6 and TimeSinceSwitch>5 and current > 0 and last > 0): #The reason we wait a few minutes after starting growth is that new media may still be introduced, it takes a while for the growth to get going.
dGrowthRate=(math.log(current)-math.log(last))*60.0 #Converting to units of 1/hour
sysData[M][‘GrowthRate’][‘current’]=sysData[M][‘GrowthRate’][‘current’]*0.95 + dGrowthRate*0.05 #We are essentially implementing an online growth rate estimator with learning rate 0.05

return

So you can see it does a difference in the (log) OD and then converts this to units of hours. It then has a moving average filter with ~0.05 learning rate. If you wish it to respond more quickly you could for example change the 0.95 to 0.8 and the 0.05 to 0.2 (make sure they add to 1). Hope this helps!

[harrison]

Hello,
The growth rate data is “smoothed” compared to the raw derivative of the OD. This smoothing filter would therefore introduce a lag into the data i.e. it takes some time from an actual growth rate change until the estimated growth rate converges on the true value. This is done to make it as robust as possible in as many scenarios as possible (i.e it minimises the impact of noise), but as you observe, it takes a little bit of time to converge in your case. You could decrease the width of this filter which would mean your data would be noisier, but respond faster to changing growth rates. Probably the easiest way is for you to try some post-processing (i.e. process the OD data yourself in Excel/R/Matlab/Python) and decide on a filter width that looks good for your system, and then edit the Chi.Bio code to reflect this.

[harrison]

IIRC I made some McFarland standards with medium ODs (i.e. 0.5 or something) and use those as a proxy for cells in media to do the scattering.
http://www.dalynn.com/dyn/ck_assets/files/tech/TM53.pdf
Another easy standard-ish solution to make is mixing small amounts of condensed milk with water.

[harrison]

Hello Saurabh
I guess there are a few challenges
The first is how you measure the LED intensity with the spectrometer. In practice the spectrometer is at 90 degrees to the LED path so you only get a particularly good signal if there is something in the way (i.e. a test tube with media/cells) to scatter light into the spectrometer. Otherwise, what you are measuring is somehow the random internal reflections in the device which may be very sensitive to geometry. What I’d reocmmend is making some cloudy solution as your standard “scatterer” and then using this in all reactors.

Second, yes, there are sources of variability in both the LED output and the spectrometer. Probably the largest amount of this comes from small changes in alignment made during assembly when the lens is glued to the LED and the spectrometer is soldered in place. There is also variability in the individual LED emitters and spectrometer, which are off the shelf parts so there is nothing we can really do about this. We try tocalibrate this variation out for fluorescence measurements by doing the ratiometric measurement as you stated, but in your case you need a constant ABSOLUTE amount of light. I’d start by doing the above (standard scattering solution) and seeing how different it is, but if the answer is still “not good enough” then ultimately what you may need is to buy an off-the-shelf light meter that can be inserted into the top of the device so you can have a consistent measurement across reactors. This way you will know exactly the light output and have the same sensor for each (i.e. not using potentially variable AS7341 chips) to have the best possible calibration. You can get cheap light meters for <100 USD usually which are probably more than good enough to do the trick.

[harrison]

Hello John,

As to timing, all of this is run on the Beaglebone so it should make no difference what computer it is plugged in to.

As to the slow down mechanisms, things you might try:
1. Change the PWM value of the pumps when on. Currently it is at 100%. This is done in the “if” statements at line 722 and onward here: https://github.com/HarrisonSteel/ChiBio/blob/master/app.py
For example, to reduce it you need to reduce the number “1.0” in the line “setPWM(M,’Pumps’,sysItems[item][‘In1’],1.0*float(sysData[M][item][‘ON’]),0)”
2. If you want the pumps to be even slower, you could leave the cycle time at 1 minute (probably better since you then get more measurments) and instead put some “if” statement into the pump Pumpmodulation which depends on sysData[M][‘Experiment’][‘cycles’] and only turns on the pump if this is equal to 1 modulo something. For example if sysData[M][‘Experiment’][‘cycles’] is a multiple of 30 then it activates the pump, otherwise it does not. This would give you a more robust and easy way to have the pump turn on every X cycles, and thereby achieve very low media influx rates.
3. If you are ultimately looking for a constant media input over long time periods, and you don’t need to control it directly from the Chi.Bio UI, you could also consider buying a different kind of pump and hooking it up – something more expensive and precise than the low-cost items in the Chi.Bio platform. For example you can get stepper motor driven peristaltic pumps pretty cheaply which can then be run at very low rates, and with less pump-to-pump variation than the cheap DC motor pumps in Chi.Bio at present.

Hope that helps

[harrison]

Could you link to one of the .csv files so that I could see what the OD trace looks like?
I think that if they saturate around 1, then 0.5 is WAY too high and will be firmly within “weird behaviour” territory. my impression has always been that things start to change significantly well before you reach the point at which it is obvious that exponential growth is ending. For example at 37 degrees I have found best regularity at OD~0.1 and below – which is far less than one might “traditionally” claim as the cut off for exponential growth.

[harrison]

Hello Viktor,

Thanks for the message. I am afraid we have not implemented a simulation mode of this kind on the system. At some point a group at Imperial was doing some early steps in this direction but decided that it was easier to just get a second beaglebone/chi.bio reactor and have that sitting on a bench as a test dummy, rather than trying to keep up to date a massive simulation software package. Furthermore, that way you can test if your code is having some unexpected interaction with the hardware, which would be difficult to catch in a simulation.

I guess that is what I’d recommend. Alternatively, you could go into the code and whereever it sends an I2C command comment it out, and ask it to just print the command. This would be a bit of a mess, in that you’d get a lot of commands printed and they would be difficult to interpret, but at least you could test if your code compiles/runs without massive errors.
Harrison

[harrison]

Hello,
For the controller, i’d adjust “Gain=2.5” parameter to be about half. Then, adjust the line a few down from where you pasted. For example:
I=I+0.0005*dt*e
Change the 0.0005 to 0.00025 or such. This would mean it has a slower integration step and hopefully will sit more stably around the set point.

Back to your challenge at hand, I’d say decreasing both the size of the OD dither, and also the absolute value of OD you are dithering around, might be beneficial. At low temps they may enter stationary phase at quite low ODs, and hence if you are sitting them at or near the point of transition (or where it begins) you might get lots of variability since this you are pushing then back and forth across that phenotypic “switch” in behaviour.

I’d also look at the data – is it obvious where the variation might be coming from? I assume that by doing some time-averaging of the OD measurements you get a pretty smooth signal, so at that point the variations in estimated growth rate are likely down to differences in conditions experienced by the cells (e.g. inconsistent feeding/temperature), rather than measurement drift over time (which should be minimal).

[harrison]

Hello,
I assume that at low temperatures cells are growing more slowly – what, then, does the coefficient of variation look like in growth rate? I.e. the standard deviation divided by the mean?
One might assume that if you are measuring long doubling times you would get larger standard deviations, since any systematic noise is compounded over a longer time.
What do you think the IDEAL system standard deviation would be – accounting for biological replicates always having differences due to randomness of biology, small changes in media temperature/consistency over time, and so on?

If you are looking for other things to help improve it I’d suggest trying to reduce the gains in the temperature control algorithm so hopefully it sits closer to the set point (since you are at low temps), and also try putting your fresh media bottle on top of a magnetic stirrer (since otherwise we often find some ingredient/s settle out slightly meaning what is pumped into the reactor is varying over time).

[harrison]

Hello,
We do not at present log these anywhere other than the PuTTy window. In principle you could get it to write to a file in the Python back end, but this had not been implemented.
Usually what I do is copy-paste or screenshot the putty window as needed.
It sounds based on your description that the output pump (the physical items) is not performing so well. If it is making a bad seal on the tube then indeed it could fail to remove liquid and it can overflow. It could be a manufacturing defect – in the first case I’d try swapping it out with pump 3 or 4 on the board and see if that fixes it.

[harrison]

Hello,

Yes, what you propose sounds sensible. You would need to calibrate each pump to get the conversion factor between set point (e.g. number from 0.0001 to 1) and what this actually means in terms of mL/minute. Then, it would be fairly straightforward to implement in a cusotm program. In short, make a custom program which when activated turns the pump ON and starts incrementing some counter (i.e. some number that starts at 0 and each minute/algorithm-iteration you add 1 to this). Then, have the Pump1 (or whichever pump) set point update each minute depending on that counter value. Thus, you would have a mechanism which starts counting when you press “go” on the custom program, and counts upward (i.e. increases pump rate) according to whatever formula you desire, until you turn it off.
Note that if you are adding some liquid over time you will also need to make sure you are removing it at a greater rate (i.e. set pump2>>pump1) such that the system does not overflow!

I would see the major potential weakness of this approach being if you wish to add very small amounts of glucose at low concentrations which would mean (because the pumps will not effectively deliver volumes significantly less than ~0.1ml) the batch culture being significantly diluted over time – but maybe this is OK for your application?

[Author]

Posts