[harrison]

Hello Sophey,

I’d try unplugging and plugging everything back in. Then, also try starting the software with no reactors connected to the control computer.
Assuming you have done that, double checked all the connections are correct, power is on, etc, then I’d say the most likely explanation is the reactor may have been assembled with a defect or picked up one during shipping. In that case there isn’t a whole lot you or I can do; I’d recommend emailing Labmaker and letting them know (send a screenshot of the error), and they should be able to sort it out for you

harrison

[harrison]

Hello Garret,

When the system starts up it tests pretty much all electronic systems in the reactor, and if ANY of them fail it will return a crash. Similarly, when it is running normally each system is called into use regularly, so if any of them fail again it will crash. In contrast, if you just swap a reactor around (while the software is running) and then click “Scan Devices” all it does is poll the internal thermometers to check if the reactors are there. Therefore, it is possible for this to work, even if other parts of the system are not working.

So, what I’d recommend is 1) Cleaning the top moisture sensing tracks on the reactor (parallel silver lines on top level) carefully with ethanol, as this is the most likely fault (dried liquid on there causing it to crash). If that does not work you could try taking two of the sides off to swab internally the lower moisture sensing track (about half way down inside the reactor, should be able to see if when looking in the top). If THAT doesnt work then it might be something wrong with one of the voltage regulation chips on the side PCB, which you could contact Labmaker about and ask if they will replace it.
Harrison

[harrison]

Yeah sure, try that!

[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).

[Author]

Posts