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

[harrison]

Hi Matt,

1. I have never heard of a control board fail in that manner. Does it still happen if you disconnect the Beaglebone itself from the control PCB? I.e. just a bare, standard beaglebone sitting alone ont he desk?
If I were to guess the cause it might be that somehow the beaglebone’s internal power regulators got shorted, since some of these are used on the control PCB, but not sure how this could happen if as you say there was no liquid in contact.

2. Have you flashed the old beaglebone with the current version of the Chi.Bio operating system? This will update the underlying linux distro as well, which might solve this. I am unclear on what you mean w.r.t the specific board type: the Chi.Bio should be using a Beaglebone BLACK. Are you saying that you were shipped a Beaglebone GREEN? can you send me a picture of the board you _were_ sent?

The control board is designed for Beaglebone Black Rev C. I do not know whether it will work with other versions of Beaglebone Black, nor do I know whether it would work with beaglebone Green.
As to the pins – if they are going into the sockets as intended then it should be OK.

[harrison]

In principle – whatever you calibrate it for. Very high ODs will go beyond the _linear_ range of the normal setup, but you can fit a curve to compensate for this if you are mostly interested in that regime.

[harrison]

Let me know if any of that is unclear!

[harrison]

I hope my answer to your other post answers this: https://chi.bio/forums/topic/questions-regarding-od-measurement/#post-1251
If I recall correctly the confusion might be arising from inconsistent parameter names on my behalf, it looks like “CF” is the same as “P0” discussed in the paper (i.e. equation S3).

[harrison]

Dear Jeff,

P0 is meant to reflect the “raw power” of the excitation LED – i.e. to compensate for the fact that a LED in one reactor might be slightly brighter than that in another reactor.
M0 is how much scattering there is from the media itself – this is conceptually similar to the OD0 value from the Laser measurement approach (i.e. eqn s1 in the supplementary of the paper), which in that case reflects the absorption of the media.

You can see what these factors do by looking at Figure S10 middle or right column. In the top row you have the raw data – the transformation in eqn S3 is then used to get the second row. So, divide by approximately 1000 (ballpark value of P0), which takes our values of ~10000 to ~10. In the top row you see there is a non-zero baseline (i.e. the measured intensities are approaching some positive asymptote ~500 or there abouts) – this corresponds to M0. So, this is then removed in the second row and we see the asymptote is now the x axis (M0 ~0.5 in this case since we are subtracting it _after_ division by P0).

I think the approach I used was: To get P0 measure the amount of light when you just have a blank test tube in the reactor (and the appropriate LED is on) to give us an approximate raw power level of the LED. Then, put blank media into the reactor and measure this to give M0.

[harrison]

Australian mains supply power is compatible with the converters – so the easiest way would probably be to buy a UK-to-AU power adapter.

For example, like this

There should be stacks available online and from local electronics shops in Aus.

• This reply was modified 5 years, 1 month ago by harrison.

[harrison]

That’s a significant oversight! Contact Labmaker and let them know…

[harrison]

Thanks for the update François, that sounds about what I expect – given it is a single copy. One challenge of week-to-week reproducibility for small signals might be movement of the test-tube when you take it in or out. Your best bet might be to have it “auto calibrate” at the start of experiments (or whenever you expect there is ~zero fluorescence) or something like that.

Do your reactors have (white plastic) diffusers in their spectrometers? There could be a small white sheet just behind the apperture of the spectrometer (i.e. the circular part with hole in the middle). If not, I can mail you some – they can significantly improve signal-to-noise for small measurements (mostly it improves OD measurement, but also fluorescence to some extent).

Harrison

[harrison]

Hi Wijaya,

That is very strange. It is saying it is unable to connect to the thermometer on the control board (i.e. the one connected to the beaglebone).

Was your system working when it did have a pump board connected? If so then it seems the error must be somewhere in the code you have edited.

If not, the problem could be with thermometerExternal itself. That thermometer is the chip on the underside of the small “arm” jutting out of the control board, right next to where the ethernet plug is.
Can you take a look at it and see if it looks like it is soldered correctly (i.e. none of its pins are short-circuted to each other)?

[harrison]

Hi David,
Yes, that’s easy enough. Go into App.py and remove (or comment out) the lines in the turnEverythingOff function that refer to the pumps.

In particular, within that function comment out:
setPWM(M,’Pumps’,sysItems[‘All’],0,0)
SetOutputOn(M,’Pump1′,0)
SetOutputOn(M,’Pump2′,0)
SetOutputOn(M,’Pump3′,0)
SetOutputOn(M,’Pump4′,0)

As to using one pump module between two, yes, you can do this. Take a look at this thread:

Reprogramming P3 and P4 on the Chi.bio

I think Zoltan Tuza has nicely implemented this functionality here:
https://github.com/HarrisonSteel/ChiBio/pull/4/commits/fc5e468a894e59163fee93533b08a52d42c9ab22

That said, if you only have two devices and plan to stay that way, you could make a more “hacky” implementation that tells the setOutput function to activate Pump 3,4 on M0 whenever you command pumps 1,2 on M1 (i.e. assuming that the pump is connected to reactor M1).

[harrison]

Dear Diego,

Thank you for raising this. I’ve taken a look at trying to come up with additional fixes. Consequently, I have pushed a new version of app.py to the GitHub here:
https://github.com/HarrisonSteel/ChiBio/blob/master/app.py
Could you download this and try to run it on your device? It has several small changes that hopefully fix this issue (though it is difficult for me to diagnose it precisely).

That said, you are the first person I have seen have any new issue introduced after updating to the V2.0 software. Are these multiplexer-induced crashes only appearing after this upgrade?
Also, I am interested in what you said that “a restart of the beaglebone” is necessary to fix the problem. Does this mean that simply restarting the Chi.Bio software (i.e. with bash cb.sh) does not fix it? How about if you restart the chi.bio code (but leave the beaglebone on) and also power cycle the reactors? It seems very strange that there is a problem that requires the beaglebone to be power cycled, since this implies it may be somehow an issue with the underlying operating system (which should be pretty robust…). Out of interest what Control computer PCB version do you have (is it V1.0, V1.1, or V1.2?)

[harrison]

When you have been doing these past checks – I assume you have got the pump board connected to the reactor too, right?

Beyond that, I am not sure at this point – it seems as if there may be a more serious fault in the hardware somewhere. It could be in either the control board or the reactor – with only one of each it is difficult to diagnose which is not working. Most likely there may just be a poorly soldered connection that is corrupting the electrical signals. The best approach would probably be to contact Labmaker and ask if they can replace it, they are usually very good at this.
Sorry to not be of more help!

[Author]

Posts