Open Gel Box 2.0: Update
Tito Jankowski
Bryan Bishop
<titoja...@gmail.com> wrote:
> http://openwetware.org/wiki/DIYbio:Notebook/Open_Gel_Box_2.0
> I'm sure you've got questions -- ask away!
Yep, you bet I do. For starters, what's up with this thingy called
Pearl Biotech?
http://www.pearlbiotech.com/ "Do you dream of engineering biofuels,
creating new species as pets, and exploring your genome? So do we. And
we need new tools for our work, not square pegs cut to fit round
holes. At Pearl Biotech, we make bioengineering accessible by
designing cool, smart equipment for the modern genetic explorer."
Just seems like something you didn't mention when you were saying how
nobody was contributing to the gel box- maybe it's because they feel
left out of the company? I don't know how that works, honestly, so I
can't say much on that I guess.
Why are you using a 64 LED array? Is this for a transilluminator, and
if so, why not a lamp?
I see a lot of photographs of materials being cut or PCBs being
assembled, but I don't see any links to files that contain schematics,
or anything useful like that. It's possible that there is a conflict
of interest in your company and providing schematics, instructions, or
any documentation (other than random photographs). It's also entirely
possible that I have completely missed a link, or something, to where
the information is .. but even with Mike Katsevman on the project, and
no link to his python script that generates gel box designs for
acrylic laser cutting, makes me wonder about this whole operation.
Tito, what's going on? You made it sound completely different last
night.
Meredith L. Patterson
artifact of the release process. My understanding is that Pearl
Biotech will be following the same general principles as Arduino --
releasing the schematics for "release versions" to the commons once
they're tested, validated, and known-good. Consider -- the Arduino
community now has the full specs for the ATMega version of the Arduino
board, which has been a long time coming, but they've had previous
versions available ever since Arduino debuted on a much simpler
processor.
I agree that community access to the hardware development process is a
desirable goal; Tito, how can we go about implementing that in the
DIYbio community? What "lessons learned" from Arduino and other open
hardware projects can we adopt and improve?
Open Hardware in general is still in its infancy, and we have the
opportunity here to contribute to the general engineering standards in
a way that electronics-alone projects haven't necessarily envisioned.
Cheers,
--mlp
Tito Jankowski
Thanks for your questions!
Norman and I started Pearl to make better biotech hardware available
to 2 groups: those who love building their equipment from scratch--
and those who want to just plug it in and go. The Open Gel Box project
began as an RFC, available on Openwetware. The team got together and
described each of the requirements for building an OGB product.
Creating this RFC was step 1.
Step 2 involves turning that RFC into a real, working device -- and
making that device available to the community. Talking with community
members, some DIYbiololgists love to work from blueprints -- and
others want to buy a gel box and start using it immediately. Norman
and I started Pearl to make the hardware available to *both* groups.
We hope to continue working with the community on other hardware
projects, such as an Open Thermocycler.
If I got your next question right, it's "where are the blueprints?".
In short, the design is getting closer to being finished -- with
feedback from Tom Knight, Kay, Mac, Meredith, Jonathan, and DIYbio SF.
In the coming weeks, full design documents will be available, free to
use and hack. Kits and pre-built boxes will be made available at the
same time.
Finally, the 64 LED array serves as a bright, low-energy, low-heat
illuminator. This is our implementation of #7 in the RFC: "Must
support in-box visualization of stained molecules".
Tito
Mackenzie Cowell
ben lipkowitz
> The documentation at
> http://openwetware.org/wiki/DIYbio:Notebook/Open_Gel_Box_2.0 is not an RFC;
> you have to follow the instructions in BBF RFC 0 (
> http://dspace.mit.edu/handle/1721.1/44960) to get an RFC number. So you
> can't say the Gel Box began as an RFC or is currently an RFC.
> Thanks,
> Mac
the IETF RFC infrastructure was set up before the internet, obviously.
Why model your standards-making procedure on something that came out of a
completely different context?
list of all authors and email address in plain text? that's ridiculous.
manual intervention required to initiate creation of a document? ridiculous.
assign copyright to biobricks foundation? hmm. what does this have to do
with DIYbio anyway?
Bryan Bishop
<clon...@gmail.com> wrote:
> I agree that community access to the hardware development process is a
> desirable goal; Tito, how can we go about implementing that in the
> DIYbio community? What "lessons learned" from Arduino and other open
> hardware projects can we adopt and improve?
Many. Here is an index of relevant discussions on that front:
> Open Hardware in general is still in its infancy, and we have the
> opportunity here to contribute to the general engineering standards in
> a way that electronics-alone projects haven't necessarily envisioned.
Standards have been briefly drafted and discussed frequently; I've
mentioned them on this list and with Tito numerous times, and even
something that partially resembles the ideal of having a file uploaded
or something wouldn't be terrible (in comparison to what he (hardly)
put up). It just feels kind of all done wrong, that's all. This is
also why I was talking about a 'social contract' in one of my earlier
emails re: "what's all this about 'open', anyway", but that might have
been hidden in all of the 'signal'.
Josh Perfetto
the open gel box project needs to be related in any way to a BBF RFC though.
The issues that were brought up really are about how to run an open hardware
project, and when Meredith mentioned standards I think this was the type of
standards she was talking about.
I don't think there's any need to standardize the open gel box itself yet.
That would be more if there were people making accessories, pre-cast gels,
or whatever else that needed to be compatible with the gel box, and there
were multiple open gel box designs floating around, and everyone thought it
would be more advantageous for everyone involved if we standardized on one
design.
-Josh
Nathan McCorkle
Nathan McCorkle
Rochester Institute of Technology
College of Science, Biotechnology/Bioinformatics
Jason Songhurst
Request For Comments - http://en.wikipedia.org/wiki/Request_for_Comments
Tito Jankowski
Great question. What *are* some good examples from open hardware that
is non-electronics based? The OGB is in its infancy and we'd love a
few examples to inspire :)
The big kahuna:
The Open Thermocycler can adapt frameworks established by Arduino --
it's much more electronics-heavy than the OGB and therefore more
simple to analyze and share. A thermocycler is $100 of electrical
components -- sold for $3000. This is a problem that open hardware, at
its current state, can tackle.
Tito
Bryan Bishop
> Meredith --
> Great question. What *are* some good examples from open hardware that
> is non-electronics based? The OGB is in its infancy and we'd love a
> few examples to inspire :)
Did you read the examples I cited yet?
http://heybryan.org/om.html
specifically, there's a list of OSH projects here:
http://p2pfoundation.net/Product_Hacking
Citations/references on an OSH hardware format-
http://groups.google.com/group/openmanufacturing/browse_frm/thread/8465dc23eb48e332#
http://groups.google.com/group/openmanufacturing/browse_frm/thread/f3904def613e1ce4/f1c75c4b297ced32?lnk=gst&q=zip+files#f1c75c4b297ced32
http://groups.google.com/group/openmanufacturing/browse_frm/thread/3f991441a6860b51/a9c7b0f65a8fde5a?lnk=gst&q=zip+files#a9c7b0f65a8fde5a
In particular, I'd be happy to package up an open source hardware
project for anybody, in particular all that I need are some CAD files,
instructions/README, and maybe some discussion with me so that I can
make sure I know what the hardware is actually doing (i.e., to not do
something stupid). This goes back to the deb/rpm-style packaging of
open source hardware ideas that I was throwing around a few months
ago.
http://en.wikipedia.org/wiki/Package_management
"""
A package management system is a collection of tools to automate the
process of installing, upgrading, configuring, and removing [hardware]
packages from a computer. Linux and other Unix-like systems typically
manage thousands of discrete [hardware] packages.
Packages are distributions of [hardware] and metadata such as the
[part]'s full name, description of its purpose, version number,
vendor, checksum, and a list of dependencies necessary for the
[hardware] to run properly. Upon installation, metadata is stored in a
local package database.
A package management system provides a consistent method of installing
[hardware]. A package management system is sometimes incorrectly
referred to as an installer.
William Heath
Bryan Bishop
> Based on my research storing such specifications in the collada format is
> standard for complex hardware systems. I am not sure what the best tool to
> use for this is however, any ideas?
Other formats like IGES, STEP, STL, DXF, SVG, etc., are just as easily
applicable. I don't know anything about COLLADA though, where does it
come from and why do all of the open source CAD packages not support
it?
ben lipkowitz
COLLADA is a graphics format like VRML. Granted, STL and DXF are largely
graphics formats too, in that they don't contain any data such as
tolerances or materials, but they _are_ generally used in CAD systems,
whereas COLLADA is mostly for video game models. it could be extended to
cover tolerances, materials, relational dimensions, etc. but then it
wouldn't exactly be COLLADA anymore would it?
there is no "best" format; STEP claims to do it all but it's an enormous
bloated expensive standard that will be difficult or impossible to ever be
completely implemented by independent open source developers; STL is only
polygons and can only reprepsent one solid; IGES is a freely available
standard and is actually pretty good for many physical objects, but lacks
metadata; SVG is a well defined open standard but only does 2D, and is
too new to have been integrated into a lot of CAD tools yet the way DXF
has.
Bryan Bishop
> On Mon, 13 Apr 2009, Bryan Bishop wrote:
>> On Mon, Apr 13, 2009 at 1:23 PM, William Heath <wgh...@gmail.com> wrote:
>>> Based on my research storing such specifications in the collada format is
>>> standard for complex hardware systems. I am not sure what the best tool to
>>> use for this is however, any ideas?
>>
>> Other formats like IGES, STEP, STL, DXF, SVG, etc., are just as easily
>> applicable. I don't know anything about COLLADA though, where does it
>> come from and why do all of the open source CAD packages not support
>> it?
>
> COLLADA is a graphics format like VRML. Granted, STL and DXF are largely
> graphics formats too, in that they don't contain any data such as
> tolerances or materials, but they _are_ generally used in CAD systems,
> whereas COLLADA is mostly for video game models. it could be extended to
> cover tolerances, materials, relational dimensions, etc. but then it
> wouldn't exactly be COLLADA anymore would it?
You're right, that does sound kind of pointless overall.
> there is no "best" format; STEP claims to do it all but it's an enormous
> bloated expensive standard that will be difficult or impossible to ever be
> completely implemented by independent open source developers; STL is only
> polygons and can only reprepsent one solid; IGES is a freely available
> standard and is actually pretty good for many physical objects, but lacks
> metadata; SVG is a well defined open standard but only does 2D, and is
> too new to have been integrated into a lot of CAD tools yet the way DXF
> has.
Right, that's why I think we should be saving models and designs in as
many formats as possible, or at least using some free software that we
can all use to access the same information. Otherwise this is going to
go nowhere fast. Some formats capture information that other formats
don't, so providing multiple saves (from the original design) will
hopefully (for now) provide more information.
JonathanCline
> Meredith --
> Great question. What *are* some good examples from open hardware that
> is non-electronics based? The OGB is in its infancy and we'd love a
> few examples to inspire :)
>
>
> > The fact that they haven't released full schematics yet is simply an
> > artifact of the release process.
Norman are of the "let's finish this version and test it first, then
we will release the details with the test results" type. The
programming analogy is a project which doesn't commit the code to
source control until it's tested.
In contrast, in some projects (more "agile" based mentality) there's a
"publish early, publish often" approach. So the idea is "let's get it
out there even if it isn't tested, so people can check the up-to-the-
minute results". The programming analogy is a project which requires
everyone to commit code on a daily or weekly basis.
Each method has +'s and -'s. It's best to state the method being
used so everyone knows what's going on. Otherwise others may get the
idea that the first method is holding back, or the second method is
sloppy hackwork.
By the way the h/w architecture I've been playing with for a
thermocycler uses Processing.org + Java + USB microcontroller board (<
$10), where a user would program the cycles via a laptop, so the
thermocycler itself doesn't have a keypad, display, or etc., yet it
can manage complex cycles and remember protocols. It's a very
compatible approach across PC, Mac, Linux, and can be made very user
friendly. (Some details on my blog.) The usability question is if
this is a proper approach, given that the user would need to use a
computer (PC or laptop) to program the thermocycler; what's the
minimum user interface on the device itself necessary for operation,
or if it's possible use the end device without any user interface
except a "go/stop" switch.
## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################
Bryan Bishop
> On Apr 13, 1:40 am, Tito Jankowski <titojankow...@gmail.com> wrote:
>> Meredith --
>> Great question. What *are* some good examples from open hardware that
>> is non-electronics based? The OGB is in its infancy and we'd love a
>> few examples to inspire :)
>
> Norman are of the "let's finish this version and test it first, then
> we will release the details with the test results" type. The
> programming analogy is a project which doesn't commit the code to
> source control until it's tested.
Yes, somewhat. On the other hand, if you're going to actively complain
about a lack of participation of others, and you don't even have the
files uploaded anywhere reasonably accessible, then presumably you're
already at a stage where such complaining makes sense, so you should
already have those files up somewhere. I really really encourage
others to start thinking about some sort of open source hardware
social contract when it comes to diybio. What this would mean is that
some technical folks will become 'package maintainers', and they will
package the hardware up into computer-legible formats (and such), and
be subject to the community 'social contract'- to include a package
under the diybio brand (or however you want to say that), it has to
pass a few tests- like being free, open source, or subject to some
particularly useful licensing, or something, What incentives are there
for this? Well, for one, it means that we can be reasonably certain
that everything is packaged in a consistent way and we can all access
it using free tools. And on the other hand, it would help the
community have a process for development and building up labs and so
on in a systematic way.
> Each method has +'s and -'s. It's best to state the method being
> used so everyone knows what's going on. Otherwise others may get the
> idea that the first method is holding back, or the second method is
> sloppy hackwork.
slop slop slop
> By the way the h/w architecture I've been playing with for a
> thermocycler uses Processing.org + Java + USB microcontroller board (<
> $10), where a user would program the cycles via a laptop, so the
> thermocycler itself doesn't have a keypad, display, or etc., yet it
> can manage complex cycles and remember protocols. It's a very
> compatible approach across PC, Mac, Linux, and can be made very user
> friendly. (Some details on my blog.) The usability question is if
> this is a proper approach, given that the user would need to use a
> computer (PC or laptop) to program the thermocycler; what's the
> minimum user interface on the device itself necessary for operation,
> or if it's possible use the end device without any user interface
> except a "go/stop" switch.
May I make a few requests? It would be absolutely awesome if you would
write a shell script to convert the "pcr.xml" file into whatever
details your thermocycler needs to hear about. This way, we can have a
toolchain from protocol XML all the way down to your thermocycler.
Different pcr.xml files could be distributed for different projects.
I'm sure you understand how neat this will be :-). Have you met with
fenn here in Austin yet?
JonathanCline
> > By the way the h/w architecture I've been playing with for a
> > thermocycler uses Processing.org + Java + USB microcontroller board
> write a shell script to convert the "pcr.xml" file into whatever
> details your thermocycler needs to hear about.
Since it's java-based, the graphical user interface would likely read
the file directly, even fetch it from the web if needed, all that is
standard java. Including being able to "remote control" the
thermocycler from any internet-connected location.
(I'm not a big fan of java however it does get the job done in an easy
PC-compatible & internet-compatible & graphical interface way.)
Certainly bio would seem to benefit greatly from more standardization
(and optimization) on lab protocols across labs and across experiments
by sharing the raw procedural data. This leads to computer-aided
design and automation.
Like I mentioned though, one possible bottleneck of this design is
having to physically connect the device to a laptop with USB to
configure it (or needing a more costly wireless module to talk to
it). It's not a problem for repetitive runs however if it has to be
re-configured often, this might be a bottleneck in the lab. There's a
commercial thermocycler which allows connection of a palm-pilot (or
some PDA) for a similar approach, putting the main processing power in
the PDA, which can be disconnected after device configuration.
Bryan Bishop
> On Apr 14, 11:07 am, Bryan Bishop <kanz...@gmail.com> wrote:
>> On Tue, Apr 14, 2009 at 10:54 AM, JonathanCline <jncl...@gmail.com> wrote:
>> > By the way the h/w architecture I've been playing with for a
>> > thermocycler uses Processing.org + Java + USB microcontroller board
>
>> It would be absolutely awesome if you would
>> write a shell script to convert the "pcr.xml" file into whatever
>> details your thermocycler needs to hear about.
>
> Protocol share-ability is a good idea. No need for a script though.
> Since it's java-based, the graphical user interface would likely read
> the file directly, even fetch it from the web if needed, all that is
> standard java. Including being able to "remote control" the
> thermocycler from any internet-connected location.
I would gladly do some programming if it means not having to rely on
java. There are many other possible choices that run on multiple
patforms and are either similar to scripts or are interpreted
languages that will do the trick.
> (I'm not a big fan of java however it does get the job done in an easy
> PC-compatible & internet-compatible & graphical interface way.)
Why do you need graphics? Anyway, if you really need them, you could
use gtk, wxWidgets, or something like that, which is cross-compatible.
I think there's even java bindings for them, but I'm not entirely
certain.
> Certainly bio would seem to benefit greatly from more standardization
> (and optimization) on lab protocols across labs and across experiments
> by sharing the raw procedural data. This leads to computer-aided
> design and automation.
Maybe if I yell loudly enough this will happen sooner? (Okay, maybe it
doesn't work like that.)
> Like I mentioned though, one possible bottleneck of this design is
> having to physically connect the device to a laptop with USB to
> configure it (or needing a more costly wireless module to talk to
I don't know if I would mind the USB requirement, especially if I
could just wire up a PCB or breadboard with another USB-compatible
interface and make my own controller if I wanted to. Doesn't sound
like a terribly big deal. Although I do wonder why you're choosing USB
over something like RS232 or LTP or a COM port. Even laptops have some
of these ports. USB is guaranteed to be on everything, but on the
other hand, it's easier to hack at RS232 because you just jam wires
together (more or less).
> it). It's not a problem for repetitive runs however if it has to be
> re-configured often, this might be a bottleneck in the lab. There's a
> commercial thermocycler which allows connection of a palm-pilot (or
> some PDA) for a similar approach, putting the main processing power in
> the PDA, which can be disconnected after device configuration.
That's funny. I don't know anybody who uses a PDA-compatible thermocycler yet.
JonathanCline
>
> Finally, the 64 LED array serves as a bright, low-energy, low-heat
> illuminator. This is our implementation of #7 in the RFC: "Must
> support in-box visualization of stained molecules".
>
haven't seen it already:
Adapted liquid crystal display backlighting unit
for densitometry of stained polyacrylamide
electrophoresis gels
ELECTROPHORESIS
Volume 30 Issue 6, Pages 987 - 990
Han Yen Tan 1, Tuck Wah Ng 1 *, Oi Wah Liew 2
1Department of Mechanical & Aerospace Engineering, Monash University,
VIC, Australia
2Technology Centre for Life Sciences, Singapore Polytechnic, Singapore
email: Tuck Wah Ng (eng...@gmail.com)
*Correspondence to Tuck Wah Ng, Department of Mechanical & Aerospace
Engineering, Monash University, Building 31 VIC 3800 Clayton, Victoria
61-3-99054647, Australia Fax: +61-3-9905-1825
Keywords
Coomassie-stained protein • Densitometry • Electrophoresis • Flatbed
scanner • SDS-polyacrylamide gel
Abstract
Appropriate monochromatic illumination that is spatially uniform will
ensure densitometry of stained polyacrylamide electrophoresis gels
with high sensitivity and repeatability. The approach of using an
array of LEDs as an illuminator has practical limitations. Here we
describe an alternative method based on adapted liquid crystal display
backlighting. By changing the fluorescent light source and using a
region where light intensity is uniform, we demonstrate the ability to
achieve highly sensitive and repeatable densitometry measurements of
polyacrylamide electrophoresis gels with Coomassie-stained proteins.
Received: 10 June 2008; Revised: 31 August 2008; Accepted: 4 September
2008
DOI 10.1002/elps.200800363
Tito Jankowski
Jake
with an 8888 style (clock type) LCD segment display and it works just
fine. The only feature I'd like is a heated lid. USB connections and
all that are way overkill, unless you can actually do it cheaper than
an old MAX232 chip for serial communication. And the only real point
to having a computer connection would be to save on the keypad and
display costs (since you wouldn't need them). I once built a board
with an Atmega8 controller chip and a MAX232 serial connection.
Something like that would work plenty well. A cheap little chip like
that can controll 8 buttons or so (with seperate IO lines for each) or
use those pins as logic switches. With something like that you could
use the serial connection to set most of the settings and then just
have a few cheap buttons for on/off, start, etc. If you really wanted
to get fancy you could even put in a cheap LED segment display also.
But really I think a design with a few buttons and a couple lights
(power, program number, running/finished) would work just great.
I don't really think a thermocycler is all that much of a challenge.
It's just a peilter junction attached to an aluminum block with a
thermisistor attached and a graphing calculators worth of processing
power.
I think a real challenge would be a real time PCR machine. The prices
on those are sky high and it can't really be all that complicated to
make one, can it?
The other thing I'd like to see is a pulse field electrophoresis
machine. I'd think you could make a simple relay controller that
could switch around a standard gel box power supply amongst the
poles. You could maybe even make a mechanical one based on a geared
motor and a rotating electrical contact playing across a properly
designed PCB.
-Jake
Tito Jankowski
thermocycler?
For Instance:
"I was working with X and I needed the temperature to change from A to
B to C over the period of 1 hr, which I looked up in a chart on D. I
wanted to take my X and get Y"
Stories like this helped us develop the built in illuminator for the
gel box. When using a gel box, users want to see their DNA bands - and
a gel box should focus on that.
Thanks!
Tito
Sent from my iPhone
Cory Tobin
> (power, program number, running/finished) would work just great.
Yeah, I agree with that, mostly. For selecting a pre-defined program
and running it, a small LCD display and maybe a couple of LEDs is
perfect. Although, for defining the program I am a bit unsatisfied
with my current thermocycler. It has a small 60 character LCD
display, 4 buttons and 2 LEDs (and costs over 2 thousand dollars).
Programming it is not intuitive at all. I've been using it for two
years and I still have to bust out the manual each time. I would love
to be able to write the program on my laptop and then transfer the
program to the machine. Maybe something like the following would be a
good compromise between cost and functionality...
- Use a graphical interface on my laptop to specify the program. It
would write the program to a file, say, hello_world.pcr
- Copy the file to a cheapo flash drive
- Plug the flash drive into the thermocycler
- The thermocycler would then find all of the .pcr files on the disk
- I would scroll through the file names a pick the one that I want to run.
I realize this would require a USB port and more processing power.
But if I'm going to ditch my old thermocycler for a home-brew machine
it needs to actually have better functionality. Also, as Jake said, a
heated lid is a must.
> I think a real challenge would be a real time PCR machine. The prices
> on those are sky high and it can't really be all that complicated to
> make one, can it?
I've partially taken apart a Roche LightCycler 480 (don't tell my
boss). Building one would definitely be more than a weekend project.
There are some serious optics in that machine. It has a mercury arc
lamp shining through a dichroic mirror down to the PCR plate. The
emitted light bounces off the dichroic mirror, passes through a
bandpass filter (attached to a mechanism to rotate in different
filters), two focusing lenses and then hits a CCD. The heating and
cooling mechanism is also much more elaborate than a typical
thermocycler, probably to precisely control the ramp-rate. There's
also a couple of other critical parts that I can't describe in words;
I would have to draw pictures. Anyways, it's definitely do-able but
it would be quite a project. I bet you could do it for a couple
thousand, depending on the quality of the optics you use.
-Cory
John Cumbers
Thomas Knight
an ethernet cable. Period. They should have an embedded web server
interface, and we should use them remotely. I would accept ones that
have only a power cable and use wireless.
JonathanCline
> I would love
> to be able to write the program on my laptop and then transfer the
> program to the machine.
knowing what's really going on inside. Drag & drop functionality for
the equipment. Perhaps the operator doesn't know (or care) how the
machine is actually cycling - if the protocol has been verified, the
task is to run it, get the result & move on.
The couple commercial machines I've seen have rather complex menu
systems & 6-line matrix displays. Compare that to the recent post
regarding why biologists prefer web interfaces to command line
programs: they're "easy". Ideally all lab equipment would have a
"web-like" interface and allow remote users to configure them &
retrieve test results. I believe some thermocyclers have network
connections for this purpose.
> I've partially taken apart a Roche LightCycler 480 (don't tell my
> boss). Building one would definitely be more than a weekend project.
> There are some serious optics in that machine. It has a mercury arc
> lamp shining through a dichroic mirror down to the PCR plate. The
> emitted light bounces off the dichroic mirror, passes through a
> bandpass filter (attached to a mechanism to rotate in different
> filters), two focusing lenses and then hits a CCD. The heating and
> cooling mechanism is also much more elaborate than a typical
> thermocycler, probably to precisely control the ramp-rate.
solid state electronics, that's all. Using all solid state
electronics probably can eliminate all the optics. There's several
designs using LED's for spectrometry that have comparable results to
the optics counterparts within specific test ranges.
ben lipkowitz
> - Use a graphical interface on my laptop to specify the program. It
> would write the program to a file, say, hello_world.pcr
> - Copy the file to a cheapo flash drive
> - Plug the flash drive into the thermocycler
> - The thermocycler would then find all of the .pcr files on the disk
> - I would scroll through the file names a pick the one that I want to run.
it would be much easier (cheaper) to either
- make a device which plugs directly into the usb port in your laptop and
appears to the operating system as a serial port
- use SD (MMC) or microSD cards and a USB adapter
John Cumbers
That's more what I had in mind. Automation implies abstraction from
knowing what's really going on inside. Drag & drop functionality for
the equipment. Perhaps the operator doesn't know (or care) how the
machine is actually cycling - if the protocol has been verified, the
task is to run it, get the result & move on.
Len Sassaman
lab equipment shipping with embedded web interfaces that are reachable
from the outside, it's essential that they don't come with default admin
passwords, unencrypted communication protocols, etc., by default.
(Configuration should be part of the setup phase for the ethernet access.)
I bring this up, because though it may be obvious to the IT and systems
folk here, it's decidedly not obvious to the medical device community. (I
recently was briefed on a flaw in a very popular model of pacemaker, where
an attacker using fairly standard radio transmission equipment could
actually send an instruction telling the pacemaker to *stop* the heart,
and not restart it -- with no security measures aside from lack of
documentation of the control protocol.)
Obviously the damage one could do by breaking into your thermocycler is
not on the same scale as remote pacemaker disabling, but it's still a
concern.
--Len.
ben lipkowitz
> I'll add to that an implicit "secure by default" configuration. If we have
> lab equipment shipping with embedded web interfaces that are reachable
> from the outside, it's essential that they don't come with default admin
> passwords, unencrypted communication protocols, etc., by default.
> (Configuration should be part of the setup phase for the ethernet access.)
before adding lots and lots of features and complexity to the device,
perhaps it would be better to agree on a price range. here are some
possible candidates for "the brain" and their costs:
ATmega48 20MHz microcontroller, easy to interface to sensors and relays;
can be configured as an insecure webserver and/or USB device with the
addition of some inexpensive external electronics; intermediate
difficulty to program $2.58 @ digikey
AT91SAM7S256, an ARM system on chip with integrated ethernet and usb
"slave" support, rather advanced programming/development, might be able to
implement encryption protocols if you knew what you were doing
$12.58 @ digikey
makezine controller; same as above but already soldered and comes with a
simple operating system and connectors, fairly easy to program; you'd have
to make sure that the included AES encryption code is actually secure
$109.00 @ http://makezine.com/controller
TS-7200 full blown linux server running debian, in a tiny package, easy to
program, perhaps too easy.. but you can use ssh and ssl for encryption
$149 @ http://embeddedarm.com/products/board-detail.php?product=TS-7200
JonathanCline
> > That's more what I had in mind. Automation implies abstraction from
> > knowing what's really going on inside. Drag & drop functionality for
> > the equipment. Perhaps the operator doesn't know (or care) how the
> > machine is actually cycling - if the protocol has been verified, the
> > task is to run it, get the result & move on.
>
> Many PCRs are more complicated than that unfortunately, the melting
> temperature (Tm) of the primer-DNA is just an estimate and often the
> annealing temp. needs adjusting with each template and primer used.
> Likewise the extension time is also often adjusted depending on the product
> length in order to speed up the total time it takes to run,
> cheers
> John
variables for you, starting from a single manually-loaded sample?
And then you save the solution of the optimal result? (Assume this
is also done as RT-PCR.)
Or, describe further how "each PCR needs some manual adjustment". It
may be solvable to eliminate this busywork.
Thomas Knight
mechanically rotates the gel tray to achieve the angled fields. I
think they attach the gel to a platform on a bearing, and drive from
below with a permanent magnet coupled link. There might be an issue
with distorting the current flow around the magnets.
ben lipkowitz
> before adding lots and lots of features and complexity to the device,
> perhaps it would be better to agree on a price range. here are some
> possible candidates for "the brain" and their costs:
>
> ATmega48 20MHz microcontroller, easy to interface to sensors and relays;
> can be configured as an insecure webserver and/or USB device with the
> addition of some inexpensive external electronics; intermediate
> difficulty to program $2.58 @ digikey
>
> AT91SAM7S256, an ARM system on chip with integrated ethernet and usb
> "slave" support, rather advanced programming/development, might be able to
> implement encryption protocols if you knew what you were doing
> $12.58 @ digikey
>
> makezine controller; same as above but already soldered and comes with a
> simple operating system and connectors, fairly easy to program; you'd have
> to make sure that the included AES encryption code is actually secure
> $109.00 @ http://makezine.com/controller
>
> TS-7200 full blown linux server running debian, in a tiny package, easy to
> program, perhaps too easy.. but you can use ssh and ssl for encryption
> $149 @ http://embeddedarm.com/products/board-detail.php?product=TS-7200
i should add Arduino to this list; basically the same as atmega48 but
already soldered to the board; with usb connector
$30 @ sparkfun + $45 for ethernet module
On Tue, 14 Apr 2009, Thomas Knight wrote:
>
> What about the linux "wall wart?"
> http://www.linuxdevices.com/news/NS9634061300.html
it has no i/o so you're back to square one (equivalent to a laptop with
USB port and ethernet)
all of the above have at least an analog to digital converter and some
kind of easily accessible on/off pins, (GPIO) which you'd need to actually
control anything. i suppose it might be possible to connect some i2c gpio
and temperature sensor chips directly to a computer's i2c bus, but that's
a bit too hackish for me.
Bryan Bishop
>> I would gladly do some programming if it means not having to rely on
>> java. There are many other possible choices that run on multiple
>> patforms and are either similar to scripts or are interpreted
>> languages that will do the trick.
>>
>> use gtk, wxWidgets, or something like that, which is cross-compatible.
>> I think there's even java bindings for them, but I'm not entirely
>> certain.
>
> discuss this in person next time. None of the scripting solutions
> work as a packaged solution. Think of end user products that are
> easily packaged without needing heavy user installation. There's
> nothing that runs across PC/Mac/Unix as well as java, unfortunately.
> I don't like the language much either, though it has these benefits.
> No other language is bundled into these O/S's like java is.
On the linux platforms, there is no installation requirements if you
use the proper methods- like the packaging systems. That's the whole
point. Some of this exists for Windows as well- for instance, python
and perl both come with repository systems kind of "hard wired" in
(pypi and CPAN, in particular).
> Graphics are a requirement. End users absolutely don't want to use
> command line or text-based graphics. Having a "pretty" solution
> counts for a lot.
That's fine. Just keep it separated. Give me a shell or give me death.
> If it were to be built on open source libraries only, it would be
> better to use SDL. But that's C. Each O/S would need separate
Wait, what? SDL is more for games than anything else.
> Which languages did you mean? tcl? python?
Tk/Tcl is dead. Python probably. perl would be terrible but less
terrible than java.
What's so graphical about PCR? A progress bar or something? wtf.
Cory Tobin
I don't see much use for pictures or animations but something similar
to an HTML form might make a lot of biologists happy. Drop down
boxes, text fields, etc. That way I could enter numbers into boxes...
Step 1: "95C" "00:30"
Step 2: "55C" "00:30"
Step 3: "72C" "02:00"
Goto Step1 25 times
Step 4: "4C" forever
I guess a progress bar wouldn't hurt but a count-down timer would
suffice just as well. Anything involving a full QWERTY keyboard would
be a huge improvement over most thermocycler interfaces.
-Cory
Tito Jankowski
profile that you download from igem.org. It's preconfigured to the Taq
you're using. Click the profile and go!
The same with the "Bioweather Maps" profile that you get from Jason
Bobe -- amplify ribosomal RNA.
Or, if you're amplifying another sequence, you copy/paste in your
primer sequences and the PCR machine does the rest of the calculations.
(Other experiments might require very different approaches)
Tito
Nathan McCorkle
I think an arduino would be fine, or some other tiny controller, or an atmel chip, bx-24, etc... there are even "expensive" options like gumstix. I think RS-232 would be fine to keep costs down, and people could buy a serial to USB converter if they wanted... the USB modules I saw on futurlec.com were about $25.
Here is some info on DIY wifi/bluetooth http://todbot.com/blog/2006/02/03/adding-wireless-wifi-bluetooth-to-your-project/comment-page-1/
Going to a decent techie school, I could most likely machine the aluminum with ease, but hooking up the peltier junction is something I'm not sure about... I think they have a hot and cold side, if so how do you separate them so they don't "recombine", some way to throw a heatsink on one, and the PCR block on the other?
I would def want a top heated machine, as oil layers are just dumb if avoidable.
Nathan McCorkle
Rochester Institute of Technology
College of Science, Biotechnology/Bioinformatics
John Cumbers
Nathan McCorkle
I think that would be pretty nice.
Optical integration would be nice, but I don't know how to set up optics :(
Tito Jankowski
Tito Jankowski
requirements, and specs:
http://openwetware.org/wiki/DIYbio:Notebook/Open_Thermal_Cycler
I've combed through our discussions and put some of the info on OWW:
Requirements (what the user might want to do): http://openwetware.org/wiki/DIYbio:Notebook/Open_Thermal_Cycler/Requirements
Specifications (what we might end up using to implement this): http://openwetware.org/wiki/DIYbio:Notebook/Open_Thermal_Cycler/Specifications
Tito
John Cumbers
Josh Perfetto
Actually, I even think it would be worthwhile to skip USB and add a networking interface and control the thermocycler via some web services interface. This way you need not tie up a dedicated computer to run the thermocycler, but you will also encourage the development of lab automation software that can do more than just control the thermocycler. There’s a lot of work going on with using semantic technologies to describe an experiment, and it would be great to have downloadable protocols that can directly configure the lab devices. There’s a lot of innovation that can take place here, and all that is required to get it started is an open interface on the hardware.
-Josh
On 4/14/09 10:55 PM, "Nathan McCorkle" <nmz...@gmail.com> wrote:
java is in my opinion more cross-platform than python (yeah I know it's just a download away), speed is no concern, and the prog doesn't need to be a progress daemon. If you want a progress daemon, maybe python would be better, but I really don't know.
I think an arduino would be fine, or some other tiny controller, or an atmel chip, bx-24, etc... there are even "expensive" options like gumstix. I think RS-232 would be fine to keep costs down, and people could buy a serial to USB converter if they wanted... the USB modules I saw on futurlec.com <http://futurlec.com> were about $25.
Nathan McCorkle
JonathanCline
> I think almost all modern lab equipment should have a power cable and
> an ethernet cable. Period. They should have an embedded web server
> interface, and we should use them remotely. I would accept ones that
> have only a power cable and use wireless.
w-layout complexity. Which is why there are so few networked coffee
machines in the world today.
I was looking at some other alternatives. All the lab equipment
really needs is a low bandwidth (<9600bps) bidirectional data stream.
It's a microcontroller project, not a mini server.
- Tether lab equipment to a larger network device (like a small
server) that handles the bus communication to the lab equipment.
This would offload the network processing to a mini-server and allow
the lab equipment designer to focus on the lab equipment rather than
network design and test. Could be wireless-infrared, depending on
light interference and line-of-sight. Could be wired-bus, depending
on a lab's ability to run wire. Downside: physical wire or
infrared's limitations.
- Use power-line networking. Eliminates additional wired tethering.
There are several component options here, I haven't looked into
tradeoffs in this area for years. Downside: Lab power may have
interference issues, not sure; and again, need a separate mini-server
as a gateway.
- Use much simpler wireless radio freq protocols, like FM or mesh, to
a larger network device (small server acts as gateway between lab
equipment and network). Downside: interference, network system
complexity, and custom physical layer protocol.
- Use an off-the-shelf dongle that acts as a serial-to-network
module. So the lab equipment really only needs to send serial data to
the dongle interface, and the optional dongle handles the networking.
Then the user can choose if they want to add the networking feature or
save the $$. Downside: probably more expensive for a dongle than
integrating it directly. Upside: could change to different physical
layers over the years as cost or availability wins out (WiFi or XBee
or wireless USB or etc). I'm not sure the common bluetooth modules
have long enough range for a typical lab.
As far as the graphical interface goes, I'd imagine the lab equipment
would send current equipment data back to the remote user (as much
data as it is currently measuring). In the case of the thermocycler,
it would be a temperature graph vs time, and florescence vs. time.
Test engineers love to see such graphs for many reasons. Even though
biologists don't typically use such data now (because it isn't
available from the standard lab equipment), it could find uses
later. Essentially it's a free feature with intelligent devices.
Nathan McCorkle
javagu...@gmail.com
Lots of IO's, A/D and D/A converters.
Jake
deserves it's own thread.
Nathan McCorkle
So the monel wire is a fine substitute for platinum wire?
Let's start another thread instead of jacking this one. The Gel Box
deserves it's own thread.