[harrison]

Hi siggi

Thats a strange one. Have you tried connecting it to a DIFFERENT PC/Laptop? If you have flashed it there should be few possibilities for the software on the Beaglebone to go wrong, and rather more likely seems the host PC is playing up.
I’d try a separate computer (and use a different mini USB cable for good measure) to get it to connect. It might be that your current computer has for some reason blocked it with antivirus or such, though I have not seen that happen particularly frequently.

Harrison

[harrison]

Hello, yes, indeed we have this, but had just not uploaded it to the site. It is now available on the Hardware page or here:
https://chi.bio/wp-content/uploads/2022/12/CBLid_5Port.zip
Particularly if you are using a large number of ports, make sure you have the rubber washer on the lid underside to improve the seal!

[harrison]

Hi Liza,

If you are having issues with crashing then 95% probability the issue is the seal of the lid onto the glass for the vial. It can be solved by adding a rubber washer in there which is mentioned in the operation manual troubleshooting guide. This issue arose with a change in 3D printing technique for the lid recently, but seems to be resolved for almost everyone by following this fix.

[harrison]

Hello,

The microplate reader and the chi.bio fluorescence work in different ways. In short, the Chi.Bio one has an array of photodiodes with various filters each of which admits something like a ~30nm band of light. Consequently if there is lots of background fluorescence / media autofluorescence it can leak into this band and wash out your measurement. In contrast plate readers usually have a diffraction grating type spectrometer which allows you to look at narrower wavelength bands.

The answer to this is, as in the manual, you should use non-fluorescencent media (e.g. M9) rather than LB which is massively autofluorescence. If you do use such media then you should be able to detect fairly small fluorescence signals, particularly if they are time changing. But if not, it will be very difficult to distinguish small fluorescence signals in LB.

I should also say, the whole point of the turbidostat system is that you can measure time changing fluorescence, and it is MUCH better at this than trying to compare various batch growth curves (e.g. without pumping) in which the dynamics of growth mess with your fluorescence. Doing batch growth is difficult in such a large volume since it inevitably leads to larger inter-experiement variation (e.g. due to media/growth/optics inhomogeneity) than small volumes, and this is why we recommend inducing things DURING experiments rather than before with Chi.Bio, as you then get much higher quality data. I.e. you put your biosensor in, grow it to exponential phase for a while, then add inducer chemical, then see how it responds over time – gives you great data w.r.t dynamic and absolute response levels.

Another note in this direction is that the system is designed to return fluorescence per cell, rather than absolute fluorescence (as in a plate reader). So, the output it gives in the UI is more like a plate reader if you calculate fluorescence/OD.

[harrison]

Hello;
1) What media are you running it in. If it is a strongly fluorescent media (e.g. LB) with a not particularly fluorescent strain, it will be difficult to pick out the signal.
2) The FP graphs show you a value that is normalised to number of cells (approximately) – i.e. it is fluorescence/cell in a.u.. So if you start with cells that are already maximally fluorescent and grow them in the device then you would expect it to stay steady or even go down, as EACH CELL is not getting more fluorescent over time. This is what a plate reader SHOULD show if you put in already fluorescent cells and divide by OD – though in practice you never get such good data from a plate reader due to the impact of different growth phases. If you want to see an uptick in fluorescence in the device during exponential turbidostat growth, then you need some construct which is inducible (via chemical, light , something else…)

[harrison]

Hello Johanna
Yeah, basically you could just adjust the main loop in the code to start the stirring BEFORE doing OD measurement. Or, add a new line to do a second OD measurement after the stirring has started. It wont cause any issues with the running of the device, however it will make the measurements more noisy particularly if you are doing some violent stirring since there will be so many bubbles + vortex in the way!
Harrison

[harrison]

Good stuff. You should be able to fit them around the circular raised part of approximately 15mm diameter underneath the lid. Might require use of some tweezers to get it well seated on the lid’s upper surface.
Harrison

[harrison]

Hello Jess,
Not directly in the current system. A group I collaborate with in the past has done it by having a CO2 tank upstream and bubbling gas into the headspace, and then potentially linking the device with a CO2 sensor (there are cheap ones available off-the-shelf) to measure outflow. Alternatively it is no issue to put the whole thing in an atmospheric control cabinet.
Harrison

[harrison]

Hello Julia,

We did actually also have this issue recently, which we think is down to a change in 3d printing technology used to manufacture the lids.
We solved it by putting O-rings on the underside of the lids. This is the part we are using:
https://uk.rs-online.com/web/p/gaskets-o-rings/1965666
But anything similar should work. Important quantities are the internal diameter (external can be a little different and still fine), and material (such that it is autoclavable).

We found that putting these in our lids and screwing them down tight fixed the issues.

Harrison

[harrison]

Hello Johanna,

I think the first approach would be to just try it and see what happens.
In terms of potential problems, one might be that the pumpiing and/or temperature control might be impacted. The pumping runs on its own cycle which is set to be longer than the main cycle time, so perhaps you would wish to instead make this a separate time (i.e. keep it 60 seconds) so that the pump runs at similar intervals.
Similarly the temperature control does intermittent measurement and heating which, if you change the timing, might make it less precise. So again, I’d suggest making sure that one is running at a fixed timestep so that you don’t end up with very variable temperatures.

Is there a logistical reason why you really MUST change the cycle time? It might be that you can achieve your goals via some other mechanisms (i.e. leaving the cycle time fixed but telling the code to just not do certain things every cycle).
harrison

[harrison]

Hello Saurabh

Yes, basically you need to edit both the html and the javascript. You can do so by just copy-pasting the existing code and adjusting it to reflect the data you wish to show. For growth rate, there is actually a plot for this which will appear if you use the dither OD mode. You could also try using the code for that as a template to help you implement other plots. Try clicking Dither OD next time you run an experiment (it will control OD in a slightly different way – making a zig zag) and you will see the plot appear.

Harrison

[harrison]

Hello Jenny,
Yes, that should be possible. Assuming that your sensors integrate with your PC rather than the reactor, you could approach it a few different ways:

1. Use the SSH connection to the control computer to transfer files with information on the sensor readings to the Beaglebone Black at regular intervals, and then read these into the Python software at regular time points to implement control.
2. Instead, send data via HTTP POST requests or similar – you can look at how this runs in the GUI of the system (e.g. the html/javascript files), and by writing a python function to receive these you could similarly figure out a way to transfer the control parameters into the python back-end on the Beaglebone Black.

If you have someone with software engineering experience neither option should be too hard, though it will require some good knowledge of python etc to get it to work.

Best wishes
Harrison

[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!

[Author]

Posts