[harrison]

Hello,
You need to go through the software instructions step by step. For example the SD card is just used for flashing the memory of the device, and so indeed it shouldn’t work right after you plug in the SD card (since it will be doing the flashing). The driver for the BEAGLEBONE is computer-dependent and is not something we designed – it is just standard Beaglebone. For this you’d need to look online at what is compatible with your PC (which I have no knowledge of)

[harrison]

Hello, you should be able to go in and directly add commands to turn it on when the stirring starts in each cycle and off when the stirring stops. Find those commands in the main loop and add it at that point.

[harrison]

Yes, all perfectly possible. There might be challenges if you want very unusual frequencis for the LED, it would be fairly easy to go down to a fraction of a second (say, >0.1s) pulses. If you wanted to do much faster you might need to implement it in a differnt way e.g. using the PWM chips on the device to pulse it on and off in hardware rather than software.

Assuming your frequencies are on the timescale of seconds it will be easy to do both of your requests with a a little programming in Python.

THe minimum culture volume is ~15ml, and is set by how far the extraction tube from the lid goes down into the tube. But, you cant put it below the optical sensors or they wouldn’t have anything to measure!

[harrison]

It is defined in the measureOD functions. You can define it in there, or if you wished do some external post-experiment recalibration to the OD – but of course this would mean your in-experiment set point OD would be different.

[harrison]

Hello Karl,

That is correct. The LED has I believe had a few changeovers at Labmaker depending on availability. Often these parts seem to go obsolete. The one you have identified (Wurth 15335327CA452) looks like a perfect replacement, in terms of wavelength and current/voltage profile. One difference between emitters is some have a focusing lens and others not. However, given its proximity to the test-tube this may not be supremely important as a large fraction of light will reach the cells regardless.

[harrison]

Hmm, so the system is still running and responding but it isn’t writing to csv? I have not seen this before and it is difficult to speculate on why that could be. I suppose the Beaglebone might be out of memory, but unlikely if a reboot fixes it, or one of the data arrays has managed to pick up an entry which the csv write function can’t handle. But again seems odd, not sure what that would be. Is there anything suspicious in the data that WAS stored?

[harrison]

Hello Karl,

The PCB design is available at the bottom of the page here: https://chi.bio/forums/topic/pcb-source-files-and-changelog/
It doesn’t have a changelog explicitly, I think the major change for V1.3 was removing a “I2C extender” chip that was between reactor->pumps because it seemed to be achieving the opposite (less reliable signalling).

[harrison]

Hello Paupasme,

I haven’t tested this but I would expect almost certainly they would not work. The peristaltic pumps are designed around a very specific dimension of tubing and if you depart from this by about more than 0.1mm they can either jam and not turn (if tubing too thick) or not make a sufficient seal and hence not pump (if tubing too thin). I would therefore strongly recommend getting the 2.5×4.5mm dimensions specified.

Harrison

[harrison]

I am not sure. I THINK I have heard of people succeeding in the past, perhaps a search through the forums? IMO it is generally much more reliable to have it attached on USB as therea re various other weird issues that seem to crop up sometimes with Ethernet (e.g. the Beaglebone dropping the connection for unknown reasons)

[harrison]

I am not sure – I expect if you have rewritten it it might have caused other issues I haven’t seen before. If the system doesn’t start with zero reactors plugged in then it very much sounds like a hardware fault.

[harrison]

If it happens when no reactor is connected then it implies it might be a fault in thhe control computer. If that is the case I suggest contacting Labmaker as it may be defective and they should be able to fix it.

[harrison]

Yes, most likely is the moisture sensor track was tripped by then wet (or now dry) residue. I’d suggest cleaning with ethanol and a q-tip. Look at the troubleshooting guide in the manual for more info.

[harrison]

Hello Marco,

Yes, if you see the supplementary of the PLOS Biology paper it details how the “normalisation” works. Basically it is looking at the amount of scattered (excitation) light and dividing the emission light by this to try to mitigate the OD effect. This reduces (by say ~90%) the influence of OD but it is not perfect, so the fluorescence vs cell at OD 0.5 vs 0.1 may be somewhat different.
In terms of the large FP2/X values it is entirely dependent on what the excitation and emission wavelength bands are. It sounds like your emission wavelength band is not far enough away (e.g. not high enough) compared to the excitation wavelength, hence loads of the excitation light is getting through and this will mean a very poor signal-to-noise ratio in the measurement.

[harrison]

Hello marco, I have just emailed you an example csv file!

[harrison]

Ahh, I see. It sounds like that might be a manufacturing defect. The 3D printed part that holds the two magnets SHOULD usually be glued to the fan. The fact that it was not is a problem and indeed you will certainly need to fix it to the fan somehow. Tape or super glue (i’d do the latter if I were you) aught to do it

[Author]

Posts