[harrison]

Hello – just to let you know I think this issue may be arising from recent updates made to some of the packages used by the software. Specifically, the way in which it recovers from errors in the I2C bus communiations. Could you possibly let me know what version of the Debian operating system is installed on your device, and what version of the Adafruit packages are on there? (these can be found by executing “pip3 list” in PuTTy).

[harrison]

I’m afraid I think it is most likely down to manufacturing – unless you make crazy changes to the code/setup I am unclear on why this would happen absent a hardware issue, given it works on many hundreds of other Chi.Bios

[harrison]

Hmm, OK so you have tried many permutations of reactor-pump-computer, and it seems the issue persists.
I now understand better your experiment, so agree it is probably not an issue with the moisture sensing.

Given that it seems all the errors you see now are Pump related, I suppose it points to issues with your pump boards.

I assume you have told Labmaker about this? In the past they have been good about replacing faulty devices. I know at some point they found there were several pump boards on which the micro-USB connector was making a very weak connection (due to insufficient solder). Perhaps you have boards from this batch.

So, one option would be ask them to replace the pump boards. Alternatively, if you (or one of your colleagues) has good soldering skills you can easily fix the connections yourself. I assembled dozens of these by hand, if you are experienced at soldering small components and have good equipment it is not particularly difficult. If you want to try that let me know and I can give you more detailed guidance.

[harrison]

Hello,
It looks like the device is unhappy with several things – the OD measurement/spectrometer, and also the pumps.
One possibility is that you have been very unlucky and gotten several reactors with electrical faults in them – meaning they cause these errors intermittently.

But, perhaps more likely is that you are having issues with the moisture sensing circuit – the narrow tracks on the top of the device. These are designed to deliberately crash the system if it encounters liquid, in case whatever protocol has been programmed is overflowing the device. This sensor can manually power down the device, which can lead to various different error messages (since the next command sent will fail). It might be possible that your pumping in air is in rare circumstances leading to drops being ejected from the lid and landing on the moisture sensors.

To fix this I would suggest trying pumping out air. You will get the same effect (i.e. replacement of head-space gas), but that way all the moisture will be travelling out through the pump, rather than directly out of the lid where it may then encounter the moisture sensors.

Harrison

[harrison]

Hello,
Have you checked and confirmed that the device is connected to the internet?
I was under the impression from your email yesterday that you had the system up and running – are you now trying to re-install the software?
Harrison

[harrison]

Hi Yong,

Indeed, what it does is check if you have just changed the devices – and then update the FP settings accordingly. I cannot recall off the top of my head whether it is essential – perhaps you can remove it and it will still work. If i was to guess what issues it could create I would say perhaps if you try to update those selections whilst the user is trying to use them (i.e. if they have one of the FP seting dropdown boxes open) perhaps the HTML front-end would close the menu – making it hard for them to select the right option before it disappears!

If you can get away without that line I expect all is fine!
Harrison

[harrison]

Interesting – I have never seen this before and I have characterised some of them with measurments every second for ~days.
I don’t think the problem is overheating – unless there is some fault in the electronics – since the lasers are dissapating fairly low power so shouldn’t heat up very much. Have you tried doing it with the intensity set to a lower value and see what happens?

Off the top of my head I imagine the most likely scenario is there is a fault the laser diode – they are fairly cheap mass-produced items, probably with far more variability than anything else in the circuitry. In that case asking for a replacement is probably your best bet – unless you fancy soldering in a new laser diode (assuming that is indeed the problem).

[harrison]

To tell you the truth – I am not sure. I have run them up to about 50C for characterisation experiments and that was fine.

The electronic parts themselves all generally are rated to minimum 70 degrees, and in practice most of the sensitive ones (spectrometer etc) will usually be at a lower temperature than the liquid (since the internal air temperature is generally < liquid temperature). But, other aspects of the design might not tolerate this. I am not sure what the first thing to cause issues would be - perhaps the resistors on the heat plate at the bottom of the reactor, which are already substantially hotter than the liquid temperature, might melt their solder. In practice that is not a terribly difficult thing to fix, but it could happen. My feeling is probably 60 should be fine, but I wouldnt go much higher than that. Obviously test it on one reactor first and see how it goes before subjecting more of them to it...

[harrison]

Hi Boaz,

I don’t know how much mutagenesis the UV LED introduces in biological terms (i.e. rate of DNA damage / LED intensity), however, if you look in the Chi.Bio paper in PLOS Biology one of the figures shows how different intensities impact E.coli in terms of slowing down their growth (which they eventually adapt to), so that may provide you with some good initial estimates of the intensities you might use.

Harrison

[harrison]

I updated the setup script and github to include the old version of the Adafruit BBIO library because of this – does it not fix it for you? Now it should not download it at all, instead use a local copy you put there yourself.

[harrison]

Hello!
Interesting question – I am not sure that your suggestions will work QUITE as you might hope:

1. Changing the tubing MAY be possible, but if you change it too much it will either be too narrow for the pump head (meaning a poor seal will be made and it won’t be able to generate sufficient suction) or the tubing may be too thick leading to the pump stalling since it cannot compress it. Potentially you can work within these limitations – what you would need to do is pick a new tubing with a smaller Inner Diameter (so flow is less), but the same total wall thickness. For example, the current default tubing is is 2.5 Inner/4.5 outer diameter. So, the total wall thickness is 2mm – I believe any replacement tubing needs to keep that quantity constant, otherwise (as I mentioned before) the clearance between the pump head rotor and the wall inside the pump will be wrong. Maybe (for example) you could try 3.5mm outer diameter 1.5mm inner diameter tubing.

2. Changing the PWM frequency won’t help too much – but changing the PWM duty cycle might help you. Currently it is set at 100% when pumps are on. You could reduce this, which will reduce the voltage to the pumps when on, which would in turn slow them down. But, if you reduce it too much the pumps will have insufficient power to start and may stall. Play around with it a bit. TO do this you need to go into the PumpModulation function and change lines:

if (sysData[M][item][‘target’]>0 and currentThread==sysDevices[M][item][‘threadCount’]): #Turning on pumps in forward direction
sysDevices[M][item][‘active’]=1
setPWM(M,’Pumps’,sysItems[item][‘In1’],1.0*float(sysData[M][item][‘ON’]),0)
setPWM(M,’Pumps’,sysItems[item][‘In2’],0.0*float(sysData[M][item][‘ON’]),0)
sysDevices[M][item][‘active’]=0
elif (sysData[M][item][‘target’]<0 and currentThread==sysDevices[M][item][‘threadCount’]): #Or backward direction.
sysDevices[M][item][‘active’]=1
setPWM(M,’Pumps’,sysItems[item][‘In1’],0.0*float(sysData[M][item][‘ON’]),0)
setPWM(M,’Pumps’,sysItems[item][‘In2’],1.0*float(sysData[M][item][‘ON’]),0)
sysDevices[M][item][‘active’]=0

Where you see “1.0*float(sysData[M][item][‘ON’])” reduce the 1.0 to something smaller, say 0.8.

Alternatively you could set up the pump to pulse on/off every second or so which would allow you to have a lower average (but yet still fairly “constant”) inflow of liquid.

Let me know how you get on!

[harrison]

Hah! You raise a good point. This is on my to-do list but evidently not high enough to get seen-to in a reasonable amount of time. Some things to get you started:

If you look at the SI for the PLoS Biology paper there is a superior modelling SI section which includes some additional diagramatic description of the software:
https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3000794

After reading that I would look at how the “customprogram” sections are structured in the python code, as these are easily adaptable for many experimental protocols one might want to implement.

If you want more customisation (i.e. new features in the GUI) it is also not too difficult, there are essentially four primary things you need to add, and each of these can be copied from any of the features already in there. They are:

1. You need to add new buttons/fields to the html file with new “id” attributes related to what you want them to do.
2. You need to add new scripts at the bottom of the html file which define how the data from the above buttons/fields is sent to the python back-end.
3. You need to add new lines to the .js file that update any labels/fields in the html that need to dynamically respond to changes in the python back-end.
4. Finally, you need to adjust the python back-end to do the hardware implementation of whatever function you are trying to do.

I realise just looking at those instructions is a bit confusing – to figure it out in practice just pick one of the features (say, the stirring interface) and trace through its corresponding html / javascript / python code.

[harrison]

Sure, I have emailed you the draft schematics and PCB files, let me know how you get on.

[harrison]

Sure – What file format can you use? Do you have access to any PCB software? If you do not have editing software I can send you Gerbers that you can use to get it fabricated and a BOM.

[harrison]

Hi Filippo,
Yes, this is no problem to implement. There are 4 pumps, so assuming 2 are used to implement a turbidostat-like mode, the other two are free to program as you please. Adding a custom program which switches which pump (or a combination of the two) depending on OD is quite straightforward.

[Author]

Posts