[harrison]

No worries, let me know how you get on.

[harrison]

Hello,

Indeed this is possible. There are two approaches
1) (Best approach) use the In-built “zigzag” function (labelled as “Dither OD” in the UI) which will allow the cells to grow in a zig-zag shape that can yield an accurate calculation of growth rate over time. To do this it would (for example) grow cells from OD 0.45 to 0.55, then rapidly dilute back to 0.45, then repeat. That is, it doesn’t keep them EXACTLY at your OD set point, but dithers the value of OD by a small amount about this point so you can more accurately estimate growth. You can adjust the size of the dither by editing the parameters that drive it in the software (see function ZigZag(M) in app.py)

2) (Worse approach) as you suggested, the system does record the input pump rate over time, which you can then use to crudely estimate growth rate and how this changes over time. All pump behaviour is logged when running an experiment in the output .csv file. The problem with this approach is that the pumps are not paticularly accurate, and the pump rate (i.e. how much liquid ACTUALLY flows when pump set to 0.01) varies significantly between different pumps. So, to use this approach you would need to spend a lot of time calibrating individual pumps so you know how each performs. As I said, approach (1) above is much better..

Harrison

[harrison]

Thank you for posting – I got back to you in the existing thread here https://chi.bio/forums/topic/app-failed-to-load-not-sure-if-this-is-a-software-or-a-hardware-problem/page/2/#post-1295

[harrison]

Thank you for the very detailed analysis – that is great.

First thing – so you were shipped a 7V power supply? This is very much not expected – the supply needs to be 12V at least to (as you said) give that 6V supply sufficient power, and also to make sure the UV LED which has a high forward voltage can be turned on. The first thing I’d suggest is swapping out to a 12V supply (or just plug it in to a benchtop power supply set to 12V) and see if this clears it up. Maybe the 7V is insufficient headroom for some components on that LaserMeasure board…

Second – the 300 ohm resistance on I2c lines – this is indeed suspicious. Does this resistance change in different conditions, e.g
1) LaserMeasure PCB disconnected from everythig.
2) LaserMeasure PCB connected to the side PCB but system powered off
3) LaserMeasure PCB connected to the side PCB with system powered on.
I’d be interested to see what it does in each case. I am on holiday at the moment so can’t tell you what this resistance SHOULD be, but can try in a bit over a week… Regardless, it certainly shouldn’t be doing this locking up!

Third – I agree with your diagnosis that it seems like a fault on the LaserMeasure board is likely. The I2C devices on this are the a) Infrared thermometer b) air temperature thermometer c) DAC (driving laser intensity) and d) The AS7341 spectrometer. Out of those I think the most suspect device is the spectrometer – it has the narrowest pin spacing (so a connection might be accidentally bridged with solder) and interestingly it also runs off a 1.8V power rail, which is suspiciously close to the 1.7V figure you mentioned! So, perhaps your best bet would be to try to de-solder the spectrometer breakout board (you’d have to simultaneously remove the four x 90 degree header which connects it to LaserMeasure). It might then be that the AS7341 is internally faulty, or there are issues in the soldering to the PCB. In practice it is possible to fix this by hand (I have soldered those AS7341 chips on by applying solder to the PCB then heating the whole thing up on a heat plate), but it is quite fiddly…

Harrison

[harrison]

Hi Jeff,

Usually when people want to measure higher ODs what they would do is dilute it down into the instrument’s linear range. The reason they struggle with high ODs is because of the light bouncing around on many cells in the solution, and hence the measurement ceases to be a “linear” measurement of absorption.

So, I would make a sample high-OD solution. Dilute this to OD<1 to measure it in the spectrophotometer, then (knowing the dilution factor you used) calculate the true OD. Then you can put it in the Chi.BIo and calibrate it against this (true/high) OD.

For the evaporated milk I did something similar - made a bunch of sequential dilutions, measured their "true" ODs in a spectrophotometer, then measured their ODs in the Chi.Bio to calibrate.

WBW
Harrison

[harrison]

Hi Neythen,

Yes – you are right. I think the answer is that there are small differences in the glass (i.e. thickness) and also slight positional differences as you rotate/move it. There are two primary ways to address this:

1. Install a diffuser – this is a small rectangular piece of platic which goes in front of the spectrometer and spreads out its receiving area to reduce noise (by about a factor of 10!). If you email me your postal address and tell me how many reactors you have I can mail you some. They are meant to be installed on future purchased Chi.BIos but I guess you bought yours a while ago.

2. Another way, which I commonly do, is put my test tube + fresh media into the reactor, screw on the lid, THEN calibrate the zero OD, and only then pippette in the cells that you want to grow through a hole in the lid. This way you never move the tube post-calibration so there is minimal error.

I should also say, the errors you are seeing are generally mitigated as cells grows since they act as a natural diffuser (spreading out the light). THe zero-OD point is the worst from that perspective…

[harrison]

Hi Yzhang,

Yes – if the software does start without the reactor connected it seems the reactor is most likely the source of issues. As I said the most common cause of such a problem is moisture (even just dried liquid somewhere hiding) on the moisture sensing tracks – but if not that then it may well be a fault in the hardware that they (Labmaker) will have to fix.

I think Labmaker will hopefully be able to send you a replacement device rather than spending so long fixing it, you will have to ask them – I am not involved in their business or manufacturing process.

[harrison]

Morning,
Yes – if it is failing without anything plugged in to the control board it is indicative of the control board being faulty. (presuming you have the latest software image installed – did you do this?)

Harrison

[harrison]

Hi Andrew,
I see, that is annoying…
So you are finding that even if you have no reactor plugged in to the control board it fails to start, and you see the errors above?

The “correct” booting sequence is usually to have the reactors + pumps connected and powered on (i.e. with wall power supplies) when you start up the device. However, I was asking YZhang to try starting the code without anything connected as this would test if the problem is in the reactor, or in the control board.

If you are finding that the software doesn’t start even when there is nothing connected (i.e. no reactors) to the control computer it is indicative that the control PCB might have a fault.

[harrison]

Dear YZhang
Can you be a bit more specific with regard to your response:
“Tried that and it seemed that we can still communicate with the beagle board using PC. But still the same error message.”
Does this mean that you:
1. Unplugged reactor from control board
2. At that point you could communicate with the beaglebone itself
3. But, you could NOT start the Chi.Bio software (even though no reactor was in place?)

As to the reactor – Labmaker should be able to send you a new one which you can then use (i.e. don’t have to wait for the existing one to be fixed).

• This reply was modified 4 years, 8 months ago by harrison.

[harrison]

Another check – have you tried booting the software with no reactor plugged in?

[harrison]

In that case it seems highly likely the problem is hardware related. If the software worked _once_ it should work again.
From what you said – it was working at one point, right? Did anything else happen that might have caused damage to it? For example liquid spill, or knocking it over, or breaking off one of the micro-USB connectors?
I assume you have only one reactor and therefore couldn’t try plugging a different reactor into your control computer to see if you can identify the issue?

[harrison]

Hi Yi,

The most likely explanation is that there is some moisture or residue on the sensing tracks (the closely spaced silver lines) at the top of the reactor. These are designed to sense if there is any overflow or other issue with the pumping – but if you accidentally get some liquid on them it can cause you problems. I’d disconnect the reactor from the power/connections and then carefully wipe down the top with alcohol (even if it LOOKS clean), then give it another go.

[harrison]

The main differences are that V1.2 has an extra ability to cycle power to the multiplexer in error cases. However, this should have no impact if your system is failing to start due to some hardware fault…

[harrison]

Hello,

For the first challenge – that some of them won’t start when connected – I would say the most likely issue is indeed the moisture sensor circuitry being tripped (internally or externally) including perhaps by a defect in the hardware manufacturing. If this is the case then it can show up at happening on M0 at startup (EVEN IF nothing is connected to M0) since that is the first reactor that is probed by the initialisation script. The second log you posted looks like it has the same root cause (i.e. multiplexer not connecting because something is shorted on the I2C lines), but it is strange that it then leads to a Kernel panic. This is not something we saw before updating to the new Kernel – so I would be very interested to know if it happens mid-experiment (rather than as part of the thing crashing for a separate reason).

Out of interest, what control board (V1.1? V1.2?) do you have?

You mentioned a light is always on in one of the reactors – is it on at very high power? Or just low/medium power? If the former then it is likely an issue in the OmAmp upstream of it, whereas if the latter it is probably that one of the resistors that provides bias to the (LED) current regulation circuit is not soldered perfectly.

It sounds like in general you have had several issues which may stem from manufacturing faults – for which the best solution (unless you want to pull everything apart and find the defect yourself) is probably to ask for a replacement from Labmaker! Sorry that this has been so difficult to fix/debug…

[Author]

Posts