DIYbio has a diverse audience so there's a broad range of skill set. A design based on a tablet and analog circuits requires some development skills so that fits into either the "I'm a beginner but willing to spend a lot of time to get up to speed" or the "I already do these things so I just need to interface to the bio side of things" people. That's where my suggestion is aimed and the steps are straightforward, not too difficult, and also aimed at making a basic yet scalable diy instrument. Gigs of memory or CPU performance also means little if there's no screen or input method included to simply interact with the user.
(As a tangent, what I really want is a semiconductor, rather than glass, pH probe.)
I think your aim is "I'm a beginner at comp sci and electronics but also too busy doing science to spend a lot of time on it" which is neither of these categories, it's different. Therefore my suggestion for tablet + interfacing would be "rather difficult" to do. With that said, if a nine year old can publish an iPhone app on the app store based on an Apple example then it shouldn't be too tough for a science-but-not-computer-science person to likewise write an Android app using Android examples - the remaining problem would be the analog hardware design and interfacing which would require a chunk of time and a chunk of collaboration for a beginner to learn. I haven't written Android apps, only iOS apps, although the effort is similar (with iOS being even more unified because it's a single vendor, so it's easier; the annoying fragmentation from many vendors is the main reason I've stayed away from Android). I would say writing the basic Android app itself fits into the "stupid easy" category while the analog circuit part does not. *If what you are using right now is working for your own couple of setups, then stick with it, and save the time.* For making multiple devices for others, or scaling up to a more capable feature set, Arduino hardware and by extension Arduino software is not where it is at. Arduino hardware and software is an educational learning platform or a prototyping platform, it is not suitable "for distribution to others as an end use product". If you are dead set on using arduino style "easy to write" software, then look into single-board-non-arduino-hardware-which-doesn't-need-extra-shields while still running arduino-like software (I've said before that arduino GUI software is actually just a different-colored version of MIT's Processing software). There are several non-atmel powerful choices of hardware and easy software combos. Frankly I can't believe that a solid science project might be done using arduino, because arduino software is an educational toy, and I can say that having read masters thesis which used Lego controllers for some of the lab automation. I have seen 3d printers made with plastic protoboarded circuits, under the idea that they would be sold as "real, functioning" 3d printers or lab automation devices, and that is snake oil on every level, that is not a product - at least layout and etch a custom board if dead set on those components, not make spaghetti with wires stuck into a plastic protoboard (these boards have terrible mechanical and electrical characteristics anyway, they are not to be trusted especially in a vibrating robotics platform), and using Java in a real time control situation such as robotics is just not acceptable, it will be glitchy by definition. Real designers have done worse, like running Microsoft Embedded Windows in ATM cash kiosks (which were then hacked via Microsoft exploits, incidentally). Recently there was a quote of OpenPCR being used in a research publication, and it likely fit the job -- however, it does not use arduino software, it uses the atmel board directly. How would you feel if your car was factory assembled using robot built on a Jenga tower of Legos? The same points I am making here can be similarly years ago about the BASIC Stamp, which was enjoyed by educational beginners and recommended against by advanced students or professionals. There is also Python For Microcontrollers which has compatible, minimal hardware boards. It would be great to see if that works in a prototype situation first, with the idea to scale it into a "real diy product". There might be performance issues. This means learning the very basics of python, which is great because it is directly applicable to computers as well, and powerful with the advanced features. Python is a great starter language. I haven't tested these microcontroller python solutions myself, only compared the tech details a while ago, so it's an informed armchair opinion. I purposely wrote in long paragraphs today to weed out the skimmers, only those really interested will dig in.
What would normally be done in an open source community is for someone to build a bare-bones framework project as the example platform, based on the agreed constraints and features, and then others would expand on that same platform in an iterative design process. Some communities are very unified and collaborate towards a common goal, using a common web collaboration site, and development can be very rapid due to iteration. The DIYbio community is not like that, though. Maybe due to the outside influences (media, hype, or presumed publication goals). It is more common for the history of this group for someone to build an okay project, without thoroughly investigating prior published research; then someone else comes along and doesn't do any homework, even though there are great resources like openwetware.org, and builds their own less-great project and gets some glimmer of limelight; then a third person comes along, still doesn't do any homework, and builds an even worse hackneyed version of their idea, then suggests making a new wiki and a new mailing list for it. The lack of movement towards a common platform might be inherent in biologists somehow, as it was remarked to me by a few MIT people long ago, "biologists just don't seem to move towards standardizing efforts", maybe it's a genetic trait, that determination is still an experiment to be done.
(As a tangent, what I really want is a semiconductor, rather than glass, pH probe.)
I think your aim is "I'm a beginner at comp sci and electronics but also too busy doing science to spend a lot of time on it" which is neither of these categories, it's different. Therefore my suggestion for tablet + interfacing would be "rather difficult" to do. With that said, if a nine year old can publish an iPhone app on the app store based on an Apple example then it shouldn't be too tough for a science-but-not-computer-science person to likewise write an Android app using Android examples - the remaining problem would be the analog hardware design and interfacing which would require a chunk of time and a chunk of collaboration for a beginner to learn. I haven't written Android apps, only iOS apps, although the effort is similar (with iOS being even more unified because it's a single vendor, so it's easier; the annoying fragmentation from many vendors is the main reason I've stayed away from Android). I would say writing the basic Android app itself fits into the "stupid easy" category while the analog circuit part does not. *If what you are using right now is working for your own couple of setups, then stick with it, and save the time.* For making multiple devices for others, or scaling up to a more capable feature set, Arduino hardware and by extension Arduino software is not where it is at. Arduino hardware and software is an educational learning platform or a prototyping platform, it is not suitable "for distribution to others as an end use product". If you are dead set on using arduino style "easy to write" software, then look into single-board-non-arduino-hardware-which-doesn't-need-extra-shields while still running arduino-like software (I've said before that arduino GUI software is actually just a different-colored version of MIT's Processing software). There are several non-atmel powerful choices of hardware and easy software combos. Frankly I can't believe that a solid science project might be done using arduino, because arduino software is an educational toy, and I can say that having read masters thesis which used Lego controllers for some of the lab automation. I have seen 3d printers made with plastic protoboarded circuits, under the idea that they would be sold as "real, functioning" 3d printers or lab automation devices, and that is snake oil on every level, that is not a product - at least layout and etch a custom board if dead set on those components, not make spaghetti with wires stuck into a plastic protoboard (these boards have terrible mechanical and electrical characteristics anyway, they are not to be trusted especially in a vibrating robotics platform), and using Java in a real time control situation such as robotics is just not acceptable, it will be glitchy by definition. Real designers have done worse, like running Microsoft Embedded Windows in ATM cash kiosks (which were then hacked via Microsoft exploits, incidentally). Recently there was a quote of OpenPCR being used in a research publication, and it likely fit the job -- however, it does not use arduino software, it uses the atmel board directly. How would you feel if your car was factory assembled using robot built on a Jenga tower of Legos? The same points I am making here can be similarly years ago about the BASIC Stamp, which was enjoyed by educational beginners and recommended against by advanced students or professionals. There is also Python For Microcontrollers which has compatible, minimal hardware boards. It would be great to see if that works in a prototype situation first, with the idea to scale it into a "real diy product". There might be performance issues. This means learning the very basics of python, which is great because it is directly applicable to computers as well, and powerful with the advanced features. Python is a great starter language. I haven't tested these microcontroller python solutions myself, only compared the tech details a while ago, so it's an informed armchair opinion. I purposely wrote in long paragraphs today to weed out the skimmers, only those really interested will dig in.
What would normally be done in an open source community is for someone to build a bare-bones framework project as the example platform, based on the agreed constraints and features, and then others would expand on that same platform in an iterative design process. Some communities are very unified and collaborate towards a common goal, using a common web collaboration site, and development can be very rapid due to iteration. The DIYbio community is not like that, though. Maybe due to the outside influences (media, hype, or presumed publication goals). It is more common for the history of this group for someone to build an okay project, without thoroughly investigating prior published research; then someone else comes along and doesn't do any homework, even though there are great resources like openwetware.org, and builds their own less-great project and gets some glimmer of limelight; then a third person comes along, still doesn't do any homework, and builds an even worse hackneyed version of their idea, then suggests making a new wiki and a new mailing list for it. The lack of movement towards a common platform might be inherent in biologists somehow, as it was remarked to me by a few MIT people long ago, "biologists just don't seem to move towards standardizing efforts", maybe it's a genetic trait, that determination is still an experiment to be done.
## Jonathan Cline ## jcline@ieee.org ## Mobile: +1-805-617-0223 ########################On 12/3/15 1:44 PM, Bryan Jones wrote:
One reason I've gone with arduino instead of an android device is that it's stupid easy to write a simple program for, especially with simple digital or analog inputs/outputs. I have very little programing ability and wouldn't know where to start with android. What's the learning curve for programming an android device to interface with inputs/outputs via the USB port or, like you mentioned for analog, the headphone jack? Do you think that today without the fire being "ready-made with *three simple metal contacts", is it very feasible for someone with only low level programing skills?
I'd love to start using cheap android devices to control lab equipment, but I wouldn't know where to start.
On Thu, Dec 3, 2015 at 3:20 PM Jonathan Cline <jcline@ieee.org> wrote:
My answer applies to various lab devices, not looking to make this only about OpenPCR. The arduino board or other microcontroller board can very likely be designed out, if using the Fire tablet. You only need an op amp circuit to convert the analog inputs to "something the tablet can read" (suggestions below). In cases where this isn't the best design, then only a simple external A/D chip is needed. No other processor such as arduino is needed, and especially no extra firmware. Having zero firmware eliminates a big chunk of the design effort which also translates into hidden cost. Lab devices are low volume, so the development costs are a big factor. I am still against using Arduino in designs due to their "high cost, low performance" results. Other solutions are better as I've mentioned before, and progressively appear. The $5 Raspberry Pi Zero just announced is powerful and a good fit, but still, an external controller can be eliminated with good design, by allowing the tablet hardware and tablet software to do the work. The only external hardware should be the minimal analog hardware, such as the analog buffers and sensors and transducers themselves.
I agree, no one buys an extra laptop specifically for communication to lab automation devices, but having that as part of the overall design is clunky, complex, and if USB is needed, then there is a limited-length physical wire involved. "Here's my great low cost device, now just bring along your $1000 laptop or $600 smart phone to use it!" - No thanks, and that is often not practical in field use anyway. Which is why many published-then-hyped-by-Wired-magazine devices fail to really deliver. Total system cost and complexity must be considered, as well as ease of use. Simplicity is often the better design.
When I say above "something the tablet can read", there are analog inputs & outputs on the Fire that are available to interface to external circuits. They just aren't as easy. If the Fire is someday ready-made with *three simple metal contacts* on the outside of the case, for I2C communication, it would be a cakewalk. That's why Jeff Bezos needs some email sent to him :-D For example, the headphone/mic jack of the iPhone has been used to plug in several popular analog measurement devices. The Square credit card reader for example, or the little spinners to measure wind speed. On the low end Fire, these are available too. Although not as convenient, the overall cost is lower and the design is simpler. Even the recent thread about conductivity measurement could be done on the $35 Fire without any external controller needed, and thus also no firmware needed, by using some simple analog chips in a nice design. It's likely that the OpenPCR or any temperature controller could use a temperature sensor directly wired to a voltage controlled oscillator which connects directly to the microphone input, for example (LM35 to an LM555). The OpenPCR already uses the LM35 or a similar sensor. The LM555 designed with bias components costs only an additional $0.30, max. If multiple temperature sensors are required then the analog design could mix those in too, the tablet would easily discriminate the inputs of each sensor.
I don't have OpenPCR's Bill of Materials and I don't know if it was ever published (it should have been, in order to be named Open). Assuming the costs involved, $5-$10 LCD display, $25 arduino w/ USB, $1 USB cable, $2-$3 added enclosure cost due to cut outs for the LCD and arduino mounting hardware, the current BOM definitely loses. Plus firmware development costs and firmware support costs (time & effort). It should be noted that OpenPCR is "Not arduino, it is atmega firmware" (OpenPCR does not use arduino software because arduino software was not sufficiently powerful). Additionally the features added with the tablet (wifi, bluetooth, touch screen, near HD display, memory card slot, internet/cloud support, web browser), make the Fire possibly a huge winner. Likely the Fire should be looked at to serve as the basis for other lab devices such as, cell counting, gel photography (note; the 720p camera is not comparable to current high end smartphones, but is probably comparable to 2nd generation iPhones), pH meters, colorimetric / fluorescence meters, PCR or incubator temperature controllers, lab robotics controllers, pump controllers, and so on. The added feature of having the hi def screen even when purposed as a simple control device allows for graphical plotting directly to the user, of historical data or real time data. What are the device's limitations? Are the Amazon adverts a limiting factor to usability? Is the Bluetooth capability limited by the hardware? Is the camera sufficient for imaging use? Is Amazon's pricing structure going to limit the longevity of the low end Fire line, thus diminishing the Fire's value as a common platform? It should be noted that the low end Fire has been rooted to run android, so presumably low level software development is possible. Amazon has resumed normal pricing of the low end Fire so it's back to $50, though I assume it will ultimately return to the $35 price.
Note- If anyone does use the Fire or another inexpensive tablet or smartphone as the basis for a lab device platform, then make sure to physically disable any unused hardware for when the device inevitably gets hacked from outside. I wouldn't want a device in the lab which has a hacker, or a government, monitoring the microphone, or snapping unauthorized photos from the built-in camera. Simple black electric tape over each camera solves the photo hacking problems, and wire cutters for the microphone and speaker. Don't trust any internet-connected device to be safe even if it is set to airplane mode.On 12/3/15 10:50 AM, Bryan Jones wrote:
Good thoughts Jonathan. The openPCR would be sexier, and more convenient with a nice big 7" touchscreen. But this would still be a slight increase in cost. You'd still need the arduino board to monitor analog inputs, so you already have a USB. The only thing you could cut out would be the $5-10 display. You wouldn't need a PC, but I doubt anyone bought a dedicated computer to run the openPCR.
On Thu, Dec 3, 2015 at 12:21 PM Jonathan Cline <jcline@ieee.org> wrote:
Over the years in this and related groups, those who are building lab
devices rehash the same engineering tradeoffs of cost vs functionality
vs ease of use. The basic lab automation requirements come down to
these major points: an electronic controller of some kind, some
electronic sensors of some kind, a simple display, a simple touchscreen,
flash memory for data logging, and a safe enclosure. Various ways
around these requirements are hashed & rehashed, such as offloading
communication features to a laptop or web browser, either via USB or
Bluetooth or Wifi, all of which add cost and reduce ease of use, while
providing a few new computer networking benefits. Consider the OpenPCR
machine for example, which is expensive considering it's feature set,
some of this base cost necessary due to the requirement of user controls
and display (USB and LCD, and extra software). Even the simplest lab
automation device, such as a networked digital thermostat for an
incubator, or a data logging pH meter, need at least a minimal user
input method and a user output method. These increase the cost by a base
amount, and that cost provides for rather clunky "1970's NASA" style
electronics - LEDs, LCDs, 7-segment displays, some knobs and switches.
This past month with Amazon dropping the price of the lowest cost Fire
tablet to $35 -- a retail price made available to Lab26 by virtue of
manufacturing volumes and potential future advertising revenue -- the
challenges of low cost vs ease of use vs computer networking for lab
automation devices are solved, even if this product version currently
has some minor quality limitations. Now if Jeff Bezos could hear the
hint that the only item missing from the low end Fire to truly seal the
deal to make the product into "electronic paper" is a bidirectional
general purpose input/output contact on the outside of it's case (in
function, similar to iPad Pro's bidirectional data contact "keyboard
dock"), then the only remaining challenge, of basic interfacing to the
outside world to read sensors and control transducers, would be very
easy to solve in the lowest cost way. Someone send him some email. I2C
contacts would be an obvious design choice. Imagine the OpenPCR machine
with the $35 tablet docked into it's front panel, to use it's touch
screen and memory card slot, instead of OpenPCR's existing display and
USB port. The more general trend of technology convergence continues:
the curve favors those solutions which share in technology gained from
the relentless march of better communication devices.
--
## Jonathan Cline
## jcline@ieee.org
## Mobile: +1-805-617-0223
########################
--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diybio@googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/diybio?hl=en
Learn more at www.diybio.org
---
You received this message because you are subscribed to the Google Groups "DIYbio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diybio+unsubscribe@googlegroups.com.
To post to this group, send email to diybio@googlegroups.com.
Visit this group at http://groups.google.com/group/diybio.
To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/5660880C.4070402%40ieee.org.
For more options, visit https://groups.google.com/d/optout.
0 comments:
Post a Comment