Amazon unintentionally solves "low cost lab automation device" challenges

[Jonathan Cline]

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
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################

[Bryan Jones]

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.

--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diy...@googlegroups.com. To unsubscribe from this group, send email to diybio+un...@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+un...@googlegroups.com.
To post to this group, send email to diy...@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.

[Jonathan Cline]

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.

## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################

[Bryan Jones]

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.

[Cathal (Phone)]

Honestly, the CHIP is my way forward for lab hardware in future. $9, Open Source, ARM32bit 1GHz, 512 RAM + 4Gb Flash, Wifi/BLE onboard, with LiPo charging circuit onboard.

Write control software in any language, host device control over TCP, HTTP or WebSocket, or direct HDMI/Component for display, bluetooth keyboard for direct input... It's cheaper than a Seeduino and infinitely better.

Websockets means you can integrate hardware with Antha's new framework, too. Which is potentially huge for future hardware.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Jonathan Cline]

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.

## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################

[Nathan McCorkle]

On Thu, Dec 3, 2015 at 3:50 PM, Jonathan Cline <jcl...@ieee.org> wrote:
> I would say writing the basic Android app itself fits into the "stupid easy"
> category while the analog circuit part does not.

I'd have to disagree on the first part. To back up a bit, Arduino is
an IDE and a library... you can write 'pure atmega' code, or even
assembly, in your source files.

The big difference I find with Android development vs Arduino
development is: download size, number of clicks/keystrokes to get
"working", ease of straightforward and compatible examples... i.e.
there's essentially only 1 version of Arduino library code API, but
the few times I've tried writing an Android app (with a year or two
between each attempt) everything was different. The API had a major
overhaul, IDE changes, etc...

I've never implemented any of the Android app ideas because of this. I
just can't remember how to do it, and when I have a cool idea, I can't
jump right in. With Arduino it's a single click to jump in (after
installation, which is minimal work, much less than getting Android
dev setup).

I guess you could call me lazy, but this is something the Apple crowd
have balked over for years, the 'fragmented' ecosystem of Android. Its
so much easier to open a text editor, type "import flask" and bam, I
have a web app (that could be accessed on Android or otherwise).


Also Arduino hardware is cheap... $2.50 is the going rate at the cheap
end of the spectrum (translates into longer shipping time) including a
USB controller. The ESP8266 chips are only a tad more expensive, and
have WiFi. That chip's successor, the future ESP32, will be dual-core
with WiFi (since the processor is used for handling the WiFi comms).

Honestly though, Android tablets and phones are commonly going for $50
or less... they aren't going to be the best, but a $30 android phone
is certainly going to be more tech-heavy than what you could otherwise
buy in parts.

But in this day and age... just use a cheap
microcontroller/microcomputer and add some wireless comms, then
require your customers to provide their own interface (read
smartphone, laptop, tablet). If some lab community thinks that's too
much of a hassle (puling your dirty phone out in the clean lab, or
contaminating your phone with lab juice)... then they can supply the
$30 Android device. In today's world supply chains seem to change
rapidly, especially with this highly integrated stuff. In that sense,
low-level designs are longer-lasting, just make sure they can be used
with whatever interface-of-the-month is (next month will probably
feature something face-mounted).

[Bryan Bishop]

On Thu, Dec 3, 2015 at 6:10 PM, Nathan McCorkle <nmz...@gmail.com> wrote:

I've never implemented any of the Android app ideas because of this. I
just can't remember how to do it, and when I have a cool idea, I can't

I seem to have entered into an alternate universe where Jonathan and Nathan have both forgotten everything they know about software. Amazon Fire and other Android tablets can run debian chroots and a number of other alternatives are possible with the android kernel kvm branch. You don't need to write Android apps to use an originally-Android device. Your flask web application can just as easily run in an chroot under Android as er, I guess you were wanting to run python stuff on an Arduino but not sure.

Additionally, if you really preferred the embrace of the web and web browsers for some reason, there are some WebGPIO and WebI2C standards floating around:

https://rawgit.com/browserobo/WebGPIO/master/index.html

https://github.com/browserobo/WebGPIO

https://github.com/browserobo/WebI2C

https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0035.html

http://we-io.net/hardware/

http://we-io.net/doc/jsAPI.html

- Bryan
http://heybryan.org/
1 512 203 0507

[Simon Quellen Field]

I also like the C.H.I.P. board.

Use your phone for the user interface (or tablet, or laptop).

I already use remote desktop for my Raspberry Pi's, meaning I have my 40 inch 4k monitor as a display, with four times the screen real estate that the HDMI port has (so I won't miss the HDMI port on the C.H.I.P.).

The Arduino (especially the $2.51 Nano clones) are nice when you absolutely need real-time behavior.

But with WiringPi software, GPIO on the Linux-based boards can be as easy to program, especially when you consider that languages like Python are available, which may be better suited to novices. And by the time you add WiFi or Bluetooth to make the Arduino wireless, you are close to the price of the 32 bit Linux board with 4 gigabytes of RAM and a real operating system.

I like tiny boards that don't need a lot of cabling. Getting rid of the keyboard, mouse, USB, and monitor cables makes the C.H.I.P. more easily integrated into a system. Put the board and its sensors and effectors into a box, and talk to it using a phone app, and your workspace gets a lot less cluttered. You have one workstation for all user interface work (your laptop or desktop computer), and all the devices in the lab can each be controlled by a little window on the computer desktop.

Most of the Arduino projects I've been building send data back to the host computer to save in a database and graph for display on the web. With the C.H.I.P., all that can be done with the $9 board itself. With IPv6, all my lab equipment can have public IP addresses, making collaboration with remote partners all over the globe possible (I have a couple dozen public IPv4 addresses, but billions of public IPv6 addresses).

I build the Arduino Nanos into equipment, since they are cheap. At $9, I'll be building the C.H.I.P. into the equipment, gaining tremendously over the Arduino (fast processing, windowing OS, Internet, PHP, Apache, Python, MySQL, 4 gigabytes of RAM, hardware floating point, more I/O pins, X-Windows, a GPU for serious number crunching, terabytes of external USB storage, and the huge amount of free Linux software out in the world).

If you ever need to make the Arduino do something like store data in flash memory, draw a graph, talk to the Internet, do speech output, or run a program that has more than 32k bytes of data, you will quickly find that the Linux board is much easier to program and use, and most likely cheaper than the Arduino plus all the stuff it needs to do any of those things.

For many applications, the Raspberry Pi Zero, at $5 a board, is also a great device. You have to add your own MicroSD card (the C.H.I.P. has 4 gigabytes soldered in), but since you can get 16 gigabytes for seven dollars, or eight gigs for $4, someone who wants more room for data logging might opt for the Zero. If your project needs HDMI output, the Zero has it, and the C.H.I.P. needs a $13 add-on board.

-----

Get a free science project every week! "http://scitoys.com/newsletter.html"

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/087F4097-F970-438E-AFAF-CDBDA947A72B%40cathalgarvey.me.

[Simon Quellen Field]

But in this day and age... just use a cheap
microcontroller/microcomputer and add some wireless comms, then
require your customers to provide their own interface (read
smartphone, laptop, tablet).

​Since the customer has already paid for a very nice phone, tablet, laptop, or desktop computer, making him pay another $30 for an inferior user interface (smaller screen, stuck to the device, etc.) will seldom be optimal.

Now that cheap boards are available with WiFi and web servers built-in​, I can control everything from my desk, or from a coffee shop, or a beach in Bermuda. I can monitor a dozen devices at once on one screen. I can send screen shots in emails, or publish them. I can see the data plotted on a huge monitor. I get to use my mouse, and not get fingerprints all over the screen.

There will be times when you want everything to be in one gadget. I like having my GPS built-in to the car, and there might be value in having a $30 tablet glued onto some particular piece of lab equipment, but I'm having a hard time finding an example. I thought, maybe a microscope controller, but then I look at the one I built, and it has a 1080p monitor so I can see the detail, and I can point with the mouse at a single pixel, which is hard to do on a $30 tablet. A weather station? Much better to be able to check it from my phone, from an armchair by the fire, or from that beach in Bimini.

If the device you are building costs $10, adding a $30 tablet is a lot of budget overhead. But if it costs $1000, you can add the tablet, and still have it remotely controllable over the 'net, so why not have both?

As for programming the Android, just make it a web page, using HTML and Javascript. Now it works on the tablet, or remotely, with only one program to write. And you never have to worry about Android getting upgrades that change the API.

The killer is that the tablet doesn't have the GPIO pins available. So go with the $9 computer and the web page, and control it from any of your other web-connected devices. If you want the interface glued to the device, glue on the tablet, and its web browser can control the device, via WiFi. Or Velcro it to the device you are using this week, and move it to the next device next week.

-----

Get a free science project every week! "http://scitoys.com/newsletter.html"

--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diy...@googlegroups.com. To unsubscribe from this group, send email to diybio+un...@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+un...@googlegroups.com.
To post to this group, send email to diy...@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/CA%2B82U9JvcYjV2ewYPumz2NMeOJQTMasDDr4U%3Dpqp6hzAu4HqCg%40mail.gmail.com.

[Jonathan Cline]

The following distinctions might be useful:
  what can be installed via the amazon store (by a regular, simple user)
  what can be installed by rooting (by an intermediate user) then via the google store after loading that store to the Fire
  what can be done by rooting and installs via shell or indie app stores (care-free tech savvy users)
  and, the anything goes category via complete reinstalls (hack-the-device users, which also requires basic dev knowledge to install prewritten software, or a really good installer).

To use the device features most directly and most easily installable, best write the most easily installed GUI app, and that's one which will be on the regular Android app store.  The best minimal design approach using my suggestion would be to build basic analog-only hardware circuits, then allow the progressive stream of lower cost tablets (un-modified, plus a simple app store install) -- that's the design boundary which constantly evolves to better capabilities at lower price points-- to be the user-facing front panel of the analog sensors and circuitry.  The idea of *tactile electronic paper* is an old one, this is just a price-sensitive realization of that concept, and in the future, implementing voice controls.  The open question today is if it requires hardware hacking to couple the interface cleanly.  Building well-working prototypes for home hacking is one occupation, while building near ready-made product is another.  An embedded project works great as long as you remember the technical details of how to use it by tweaking the project-specific knobs, and after a year of forgetfulness, the developer is the same as an uninformed user.   Web apps are never as good as native apps by definition, whether locally served or remote.  Installing a local web server to act with a browser as an interface is a common avoidance technique instead of learning the platform-specific GUI development software.  It's better to write the native GUI app and then allow exporting the data to a data cloud somewhere.

I may be the odd one out, however I don't want to use a personal smartphone in a lab as an instrument, whether it's physically plugged into a device or by browsing to a web device (unless it's for status notifications).  Even if I owned a smartphone, which I don't.  I like where WebI2C has been going, it's been a work in progress for a while, though the proof will be in the browsers (coupled with both the hardware support and O/S support).  It should be noted that there is no way to query I2C devices on an address bus, I mean, it is not communication for arbitrary plug-and-play, the communication is designed for purpose-built hardware only, so any web apps would have to ask the browser which would have to ask the O/S which devices exist and what their device addresses are; and hardware-hacking a new device on the chain won't make it magically available to the web app if the O/S doesn't know it's there.

## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################

[Patrik D'haeseleer]

By the way, Make has a nice comparison of the $9 C.H.I.P. vs the $5 RasPi zero:

http://makezine.com/2015/11/28/chip-vs-pi-zero/

The built-in WiFi, memory, and battery charging circuit on the C.H.I.P. are awesome. Then again, unless you happened to get one during their kickstarter, you won't be able to get your hands on one until May 2016 or so. The Pi Zero is available now-ish, supply issues notwithstanding...

Patrik

[Cathal (Phone)]

Yep, Chip's biggest weakness is "I can't get one". :)

There is a use-case tradeoff between the boards as-they-come. So if you need display but not wifi, the zero is a good choice, and vice versa. The Make article does a decent (but imperfect) comparison on cost-of-ownership if you want both and they come to rough parity.

Rough, though; the CHIP has a more powerful processor and is open source most of the way down, whereas the Pi Zero is same clock speed but older chip design (probably missing some performant instructions?), and requires a secret-sauce blob to boot and run. The CHIP is apparently getting mainlined into Linux so distro options should be massively improved whereas RPi will be limited by that blob architecture and will likely never reach that level of support.

IDK though, I don't have either yet. Planning a CHIP as soon as they leave preorder. :)

I bought aa BlackSwift and it's nice but I didn't do my research: MIPS architecture isn't supported by Go and is harder generally to target. Should Have Bought ARM™.

[Josh Perfetto]

Jonathan,

The OpenPCR BOM was published years ago and is linked to from the website, and published in this forum several times.

Honestly no OpenPCR customer has ever complained about the cost of the USB port and wished to save a few bucks on SPI. Similarly no Open qPCR customer has ever complained about the cost of the ethernet port. 

These data interface technologies are very cheap. The OpenPCR is several years old, and the majority of its cost relates to thermocycling and its low volumes. The majority of the Open qPCR cost relates to its optics. When Amazon comes out with a $35 fluorescence detector it will be great.

-Josh

--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diy...@googlegroups.com. To unsubscribe from this group, send email to diybio+un...@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+un...@googlegroups.com.
To post to this group, send email to diy...@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.

[Jonathan Cline]

OpenPCR is great and everyone should buy one.  The initial cost of a lab device is still dwarfed over it's lifetime by typical running costs anyway.  And if discussing with typical lab buyers accustomed to $10,000 equipment price tags, in comparison it is a breakthrough.  With that said there have been many comments about it's cost. Including threads like this -

(2012) https://groups.google.com/forum/?hl=en#!searchin/diybio/openpcr/diybio/tlPUBoCTf-Q/DA44Xuk9-M0J
" OpenPCR is a cool thing. The only thing is, it's still quiet expensive
for a kit. .. I see that there are lots of parts. Can we build a simpler version,
just like we have simpler Arduinos available? .. Any ideas for simpler lid unit, cheaper heat-block, PSU, and MCU? "

(2014) https://groups.google.com/forum/?hl=en#!searchin/diybio/openpcr/diybio/t3nhq0az1es/vCV5o55FiGsJ
" All in all im not sold on the current "Low Cost" devices on the market. OpenPCR is tragic for the price range especially if it's a kit where results may vary greatly. "


Design is always worth discussing.  These items are fair game.  OpenPCR made history as a landmark project and yes, has been out for a while (but let's not revise history, there weren't any public discussions on designing down the materials costs in this group during it's development or initial release).  Open qPCR is a different animal in terms of benefits and capabilities[*], as you mention, and it is another breakthrough device compared to the competition.  I mentioned OpenPCR originally because it is a great example of a diybio device.  Although it isn't a great example in terms of percentages because a big chunk of the cost is the metal, transducers, and machining, which are going to cost what they cost.  Every so often I get queries from diy equipment hackers discussing how to build different devices, and tradeoffs to make.  Convergence has moved technology forward.  Laptops no longer have ethernet ports.  I wouldn't expect a bio customer to complain about a device feature such as "That hard-line networking is useless, isn't it?" because in many situations, the customer base is the last to know about the next step in technology - often only seeing the end result, rather than the design.   There's also differences in the customer base.  Simon mentions he prefers cutting the entire electronics design out of his devices, because 'everyone has a smartphone in their pocket to use as the interface'.  Perhaps that is true of Simon's diy homebrew/educational audience.  Most of my experience is of a project manager (granted, a non-bio environment) saying: "Uh, we don't use our personal devices for that.  In fact it's against company policy.  Here, let's acquisition you a [laptop or smartphone or tablet] from the IT dept.  And we'll have to wait for IT approval to get this device on the network."  Related to fluorescence detection, that's one good question isn't it, how good is the camera.  Fluorescence detection projects have been published using smartphones with add-on optics.  Wouldn't it be great if a mass-produced off-the-shelf $35 tablet could fit directly into designs to replace the custom components?

*  - Anyone unfamiliar with Open qPCR should read Biocoder Issue #6, "Open qPCR: Open Source Real-Time PCR and DNA Diagnostics"

## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################

On 12/4/15 2:46 AM, Josh Perfetto wrote:

[Simon Quellen Field]

On Thu, Dec 3, 2015 at 6:07 PM, Jonathan Cline <jcl...@ieee.org> wrote:

Web apps are never as good as native apps by definition, whether locally served or remote.  Installing a local web server to act with a browser as an interface is a common avoidance technique instead of learning the platform-specific GUI development software.  It's better to write the native GUI app and then allow exporting the data to a data cloud somewhere.

​I disagree. :-)

Standards are important, and there are no standards for app development.

What you build on the Android won't work on a PC, a Mac, or an iPad, unless you use standards that work on all platforms.

Those standards are HTML5 and Javascript, and there are good tools for making apps for the Android and IOS platforms from HTML5 and Javascript. You will not be able to tell the difference between an app done this way and one done the hard way.

All of the devices compile the Javascript into native code. Javascript has access to all of the sensors and effectors on the phone, tablet, etc., just like any other native app on the device. And it is much easier to write the app, and much faster. If you don't like Javascript, there are platforms that allow you to program in Java, Ruby, or C# using the same techniques.

If you think that you have to have a local web server on the tablet and have the Javascript talk to that in order to get things done, you have not seen the direct Javascript APIs for talking to the device. Check out PhoneGap, Apache Cordova, Xamarin Studio, Appcelerator Titanium, B4X, Ionic Framework, Kurogo Mobile Platform, eMobc, Codename One, RhoMobile, MoSync, Intel XDK, RubyMotion, Infinite Monkeys, appMobi, Convertigo, App.js, WebDGap, Trigger.IO, MobileSmith, Zuznow, or appdeck.

They run just as fast as any other native app, and they have as much polish as you want. But unlike raw Android or IOS, they use standards, and work on all platforms. Most of them will build for all of the mobile platforms (Android, IOS, Windows, Blackberry, etc.) with one click.

​

​And disconnecting the user interface from the hardware does not mean that you are forced to use your personal device in a corporate lab. That same $30 tablet will now just work on all of the devices in the lab, instead of each device​ having to have its own $30 tablet glued on. But more importantly, the computer you use in the lab to write the papers, collect the data, draw the graphs, etc., can also control the lab equipment, or just monitor the experiment.

Even if you do glue the $30 tablet to each device, make sure it is connected to the Internet, so you can get alarms on your phone when you are at lunch and the temperature goes out of bounds because the janitor reset the building thermostat. Being able to check on things from home, and make adjustments in the middle of the night without driving to work, is a good thing.

[Josh Perfetto]

I'm all for discussing how to make things cheaper, and make user experiences better with LCDs :)

With the $5 Raspberry Pi and the $35 Amazon tablet, we're really at the point where the computing and LCD components are insignificant parts of the cost. I agree with your point that this makes it less interesting to rely on the user's smartphone which is inconvenient, when you can just get the dedicated computing/LCD for not much more.

This makes it very cheap to make something like a remote temperature sensor, but the reduction in computing costs is doing little to lower the price of more involved devices. The cost of OpenPCR and other cyclers haven't come down over the years along with the costs of computing boards, because its cost is not really driven by the computing.

The $5 Raspberry Pi, $35 Amazon Tablet, and also BeagleBone Black & Edison, are so cheap because of volumes. So are the CCD cameras you pointed out which can be used in fluorescence detection systems. Cheapo CCDs driven to low costs by smartphone volumes are more than adequate for fluorescence detection, but the performance of fluorescence detection systems is now being limited by the filters, which unfortunately no mass volume consumer product is driving down the costs of. Similarly more complex projects like Open qPCR and OpenTrons have so much engineering in them that price necessarily has to stay above component levels.

Our community and everyone else has enjoyed the freeloader gains from consumer electronics volumes like smartphones. But to see further significant reductions in the cost of lab hardware, our community has to absorb greater volumes. Other communities like 3D printers and drones have seen this, but it hasn't really happened in DIYbio yet.

-Josh

[Nathan McCorkle]

On Dec 3, 2015 5:24 PM, "Simon Quellen Field" <sfi...@scitoys.com> wrote:
>
> ​Since the customer has already paid for a very nice phone, tablet, laptop, or desktop computer, making him pay another $30 for an inferior user interface (smaller screen, stuck to the device, etc.) will seldom be optimal.

My thoughts on that were toward a sterile lab, cleanroom, or any environment where a dirty dirty smartphone/tablet would be disallowed for consistency of the environment. Or a lab which works on harmful stuff, say infectious or poisonous... I wouldn't want to whip out my phone casually in there. In fact I'd probably want most/all things in the lab to be able to be dipped in a sterilization solution of bleach or something (This was an actual requirement of the tablets used during the Ebola outbreak not too long ago).

If the devices were connected wirelessly, and your lab didn't degrade the WiFi/radio signal appreciably, your personal smartphone/tablet might still connect when you're outside the lab containment area.

[Simon Quellen Field]

It would not be easy to sterilize a tablet.

It might be a little easier to pot a C.H.I.P. board in epoxy, but I still wouldn't put it in the autoclave.

However, having the controls and output in another room, or outside the sterile box, means less to have to sterilize.

-----

Get a free science project every week! "http://scitoys.com/newsletter.html"

--

-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diy...@googlegroups.com. To unsubscribe from this group, send email to diybio+un...@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+un...@googlegroups.com.
To post to this group, send email to diy...@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/CA%2B82U9KRnub37zw7WWE_yQ0TK9O3KaUa9Rd5p_dty7iTMn8Bvg%40mail.gmail.com.

[Nathan McCorkle]

On Dec 5, 2015 12:09 PM, "Simon Quellen Field" <sfi...@scitoys.com> wrote:
>
> It would not be easy to sterilize a tablet.
> It might be a little easier to pot a C.H.I.P. board in epoxy, but I still wouldn't put it in the autoclave.
> However, having the controls and output in another room, or outside the sterile box, means less to have to sterilize.
>

Sounds like wireless charging and a polycarbonate enclosure (and maybe mil-spec waterproofing) were good enough to withstand ebola-killing chlorine dip.

http://www.wired.com/2015/03/google-builds-new-tablet-fight-ebola/

[John Griessen]

On 12/03/2015 03:20 PM, Jonathan Cline wrote:
> The only external hardware should be the minimal analog hardware, such as the analog buffers and sensors and transducers themselves.

And the plastics and switches and buttons.

Like this concept. But I'd go even more minimal than a tablet. There needs to be a product for that purpose.
Beyond breakout boards. Prototyping tools for such systems with OSHW licenses for the circuitry
and the plastic enclosure. It's on my to do list.

On 12/03/2015 07:23 PM, Simon Quellen Field wrote:
> Now that cheap boards are available with WiFi and web servers built-in​, I can control everything from my desk, or from a coffee
> shop, or a beach in Bermuda.

> The killer is that the tablet doesn't have the GPIO pins available. So go with the $9 computer and the web page

Yes, and with the utility of being waterproof, the audio jack may go away on most cell-phone-like-computers soon.
Near filed communications, NFC, could be a way to utilize standard tablets soon.

The exposure to the open internet of attackers is trouble that needs to be dealt with. I still like the idea of a gateway
computer dealing with the IPv6 address assignments, firewalling, and encrypted access. Then you can make that box about security,
whereas firewall and encryption in each little lab equipment seems too costly so leaving it out gives security holes.

So letting the equipment be a specific IO and button UI and readout UI and safety-housing design without a "cell phone like
tablet" attached to each makes sense and plugs some attack avenues and portholes.

The chips and boards seem to have good choices, but I've found a gap in availability of plastic housings for systems
with any narrow app like lab equipment. You can print something light that fits in your hand for $8, and you can hire protomold
to make 3000 of them for $2k setup and maybe $.50/piece ==> $1.20 each. If you want a batch for beta testers to try that
you *KNOW* will be getting changes, the protomold way would waste several $2k tooling charges just learning as you go. 3D
printing is great for learning some things that you see obviously when you turn it over in your hand, or fit two parts together,
or add circuit boards, sensors, cables, solar cells, but at $8 each you're not going to ship many to beta testers, are you?

So I'm learning the prices of some smooth plastic 3Dprinting from Stratasys called polyjet "ABS-like" material. It can be used as
low volume injection molding tooling for 100 shots they say. Next I'm learning about small DIY extruders for hot plastic that
can be built for $300 and I'll add automation to see if they could be made ready to use by contract manufacturers. That would
fill the gap of no $2 per part 100 to 500 part batches available now. Some things you learn by using, so then you can upgrade
your 3D design easily cheaply if done by low volume molding. Maybe tablets will become building blocks to use when NFC is everywhere.

On 12/03/2015 08:07 PM, Jonathan Cline wrote:> The best minimal design approach using my suggestion would be to build basic

analog-only hardware circuits, then allow the
> progressive stream of lower cost tablets (un-modified, plus a simple app store install) -- that's the design boundary which
> constantly evolves to better capabilities at lower price points-- to be the user-facing front panel of the analog sensors and
> circuitry.

Have you identified any usable tablets, or are you meaning, use them when OS support for webi2c starts or when NFC is similarly
"built-in" to linux and android?


On 12/03/2015 08:07 PM, Jonathan Cline wrote:> I like where WebI2C has been going, it's been a work in progress for a while,

though the proof will be in the browsers (coupled
> with both the hardware support and O/S support).

So, that would require a kernel module for running linux? What would WebI2C need on android?

[Jonathan Cline]

On Sunday, December 6, 2015 at 11:44:45 AM UTC-8, John Griessen wrote:

  

  I've found a gap in availability of plastic housings for systems

True.  Reduce the number of cutouts to simplify this, by eliminating any buttons as well, other than a power switch. Everything else is via touchscreen, either way, enclosures manufactured in low volumes have an annoying base cost.  NFC for power won't be in low end devices for many more years so don't wait for that.  There is a hardware hack demonstrated where the low end Amazon tablet was modded to use an NFC power receiver.  The priority to use a low cost tablet is negated if the NFC peripherals cost more than the tablet so NFC is best used only in higher end gear.

I haven't been thinking in terms of sterility simply because the microbio wetlabs I've frequented are not rigorously clean environments.  The biologists scratch their noses with their gloves on, I don't know what's up with that, but for simply pipetting, it doesn't matter much, does it.  Probably a wrap over the instrument would be the way to go there, just guessing.

 

On 12/03/2015 08:07 PM, Jonathan Cline wrote:> The best minimal design approach using my suggestion would be to build basic
analog-only hardware circuits, then allow the
 > progressive stream of lower cost tablets (un-modified, plus a simple app store install) -- that's the design boundary which
 > constantly evolves to better capabilities at lower price points-- to be the user-facing front panel of the analog sensors and
 > circuitry.

Have you identified any usable tablets, or are you meaning, use them when OS support for webi2c starts or when NFC is similarly
"built-in" to linux and android?

I'm saying amazon's lowest end tablet likely fits the bill today.  The couple ways which allow interfacing to the tablet without hardware modification can be used today, they just take more work, compared to the tablet having simple external pads available.  Presumably with simple hardware modification (presumably, because, have not yet hacked one, but very likely the traces are available), there are standard bus methods available to interface to it with easy hardware mods, and the external circuits can be simplified further, and those would probably require a kernel update.  And of course the tablet would require the simple hardware mod.   (If that term, "today," is taken literally, then, the price is back to normal, no longer $35 --- but of course I assume the price will drop again.)    As background info, the Amazon Paperwhite can be very easily hardware modded to provide a serial port and that port is directly available to homebrew applications to interface to external devices already (see http://88proof.com/hardware/kindle-20131009-2.html ).  The drawback to working with the Paperwhite is that GUI development is very custom and without advanced users rooting their devices as well, there's no way to install the new apps; aka: there is no app store.

Compare:  $50 beagle board + $50 touch screen + $10 case vs. $35 amazon tablet.

On 12/03/2015 08:07 PM, Jonathan Cline wrote:> I like where WebI2C has been going, it's been a work in progress for a while,
though the proof will be in the browsers (coupled
 > with both the hardware support and O/S support).

So, that would require a kernel module for running linux?   What would  WebI2C need on android?

I don't suggest waiting for W3 "javascript hardware access" like webi2c or anything else. That won't be a general solution for many years if ever.  I2c is not a plug and play bus so generic app support could be tenuous.  I like the concept but unless there is a huge market demand it won't pan out, W3 has had a lot of cool standards with nice concepts which never make it into widespread browser use.  Even in the unlikely case that arbitrary hardware twiddling is supported in javascript, the browser still has little or limited ability to process/save/reload data streams.  It violates the fundamental browser model.  The original concept of the web was to launch external applications from URI protocols, not make the browsers into a super-power-do-everything-app.  One significant reason the make-the-browser-do-it bandwagon has kept rolling so long is because IPv6 adoption didn't take off like it was always hoped -- hence IPv4 translation problems due to NAT, so arbitrary socket communication made it impossible to add services -- but after IPv6 is everywhere, the point is that end devices will be directly addressable again -- there will finally be enough addresses to support communicating directly with them -- so why would the browser keep this foothold; it won't, the tide will go out and browser functionality will slim down again.  But that is also years in the future - the future where Google Docs do not exist inside a browser.

This past week I was given a demo of a next gen 4G-to-5G cellular RF instrument that likely costs over to 4 staff salaries fully loaded and the designers of that box got the user interface completely wrong too (note, it is not a great idea to keep embedding junky Microsoft Operating Systems into really expensive pro test gear and force users to plug a mouse into the instrument and click everywhere when running incredibly expensive experimental procedures).  They had the privilege of implementing a sky high cost model and could have realized the best design in the world, yet still did not design a good user interface.  Their excuse to work around this horrible design was:  "Well, if you really want to use a tablet (read: use the instrument intuitively) then you can use a remote desktop app to remote into the instrument.  We've done a pretty good job of making the O/S stable, finally."  -- as if I believe that.   Anyone who has had a test bench loaded with an experimental setup and attempted to use a mouse somewhere on this bench will instantly understand the design's horrible flaws in usability.  Quite simply, their project managers do not know good design.

[Jonathan Cline]

The low end Fire supports USB On The Go, therefore connecting custom external peripherals is possible via USB.   This is from the xda dev pages:

Working
    Full size Qwerty Keyboard
    USB Mouse
    USB to SD card converter
    USB Ethernet
    USB to Serial (FTDI)
    USB Webcam
Not Working
    USB to Serial converter (?)
    Parani-UD100a USB Bluetooth Adapter
    Parani & TP-Link did not show in Network Info II app
    " It does not appear to support OTG + charging."
Reference: http://forum.xda-developers.com/amazon-fire/general/otg-2015-fire-kffowi-ford-t3245644

Overall this is pretty good convergence to tactile electronic paper.  My design suggestion for a production product (not talking educational or toy use) would be to use a Microchip PIC18 or PIC24 both of which have full speed USB and solid peripherals on chip (such as 16-bit A/D on PIC24).  Software development with MPLABX toolchain.  Or for the non-C programmers, an option is to write in python and use micropython on chip.  Unfortunately these days I'm away from my lab setup otherwise I'd have a demo up already.  

By the way to answer a previous comment, the MIPS cores, such as 4K (now considered a microcontroller range), and MIPS-based chips are technologically superior to ARM in many ways.  There's a billion types of ARM based chips out there because ARM licensed the core in a more widespread way (but not the bus!) based on royalty whereas MIPS did not license their IP in that "saturate the market" type of way.  Also from a software developer standpoint it is usually better to go with the vendor with the more singular solution (MIPS in this example) rather than the highly branched solution (such as, ARM core in ST chip which uses a third-party ARM peripheral bus running with third-party software tools and open source libraries and bundled driver libraries that are demo quality in my opinion, if you look deep into the code, and incredibly bloated).

On 12/3/15 4:21 PM, Bryan Bishop wrote:

 Amazon Fire and other Android tablets can run debian chroots and a number of other alternatives are possible with the android kernel kvm branch. You don't need to write Android apps to use an originally-Android device.

If the device (tablet in this case) is customized, then that is branching off of the convergence line.  The result in the long term will only gain from the technology convergence up to the point of the branch, and won't benefit from the further technology gains (without continual custom development).  Stay on the convergence curve, rather than branch off, for best results.   That means building software which is distributable directly on amazon's default app store and accessory hardware which plugs in without hardware modification.  However - it's more rare for companies take the approach of building an accessory for a device on the convergence curve because the priority of a company is to create ecosystem lock-in, basically the expression "We don't want to be a peripheral on someone else's device."  Fighting the "Let's just branch!" instinct can be difficult on both the business side and the developer side.

The major limitation of these tablets is that they are not readable under sunlight - so outdoors use in the field could be limited.  The e-ink readers would be the natural choice but the software development is more difficult (proprietary libraries, and custom development).

[Cathal Garvey]

I suppose on-subject; I recently came into possession of a CHIP (the
open source 1Gz ARM board for $9), and I'm really impressed even though
I've done next to nothing so far with it. The *details* are what impress
me:

* The USB power socket also handles data, so you can plug it into your
laptop and then send/receive serial data over the same wire. Apparently
you can also multiplex somehow to do OTG through the same wire, perhaps
when a battery is attached (see below).
* It also has a single USB A socket on board, don't know much about
current draw so far but I expect they learned RasPi's lesson about
delivering insufficient current.
* Wifi/BLE
* A socket for a LiPo battery, and an integrated charging circuit wired
from the USB power supply, with automatic power switching so a cheap
LiPo gives you a UPS or on-the-go power supply
* Compatible with Debian, mine came pre-flashed
* 4 GB storage onboard

So that's a $9 computer that can easily connect via bluetooth or wifi to
controlling devices, with enough beef onboard to handle moderate data
processing, and enough storage onboard for pretty generous logging.
Coupled with a cheap or free service to expose local servers on
convenient domain names (such as ngrok.com or pagekite), you could very
easily set up "garveylab-pcrblock.ngrok.com" or similar and have a rich
webapp for setting up, logging from, and tearing down experiments.

Anyways, sorry to gush. I'm excited about uses for this thing, wish I
had five more so I could more easily commit to at least one idea without
feeling I'm wasting it. :)

> --
> -- You received this message because you are subscribed to the Google
> Groups DIYbio group. To post to this group, send email to
> diy...@googlegroups.com. To unsubscribe from this group, send email to
> diybio+un...@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+un...@googlegroups.com.
> To post to this group, send email to diy...@googlegroups.com.

> Visit this group at https://groups.google.com/group/diybio.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/diybio/567850BE.1060707%40ieee.org.

[Jonathan Cline]

Keep in mind that any device which emits radio signals (wifi, bluetooth)
has to pass some regulatory hurdles ($$$) if sold as an end product.
Developer build-it-yourself kits get around these restrictions but that
is not an option for an end-user product. There are some bluetooth
vendor chipsets where simple regulatory waivers are available directly
from the vendor if new designs use their hardware reference design. I
haven't heard of this for wifi chipsets but it may be out there.

CHIP has digital I/O (at 3.3V only) but does not have A/D (other than
microphone-in and one 6-bit, 250 Hz, 2-volt-maximum A/D that is not
buffered) or D/A (other than stereo headphone-out and 1 simple PWM).
This means adding on shield(s) for basic tasks, reminiscent of Arduino's
hardware limitations. That's a pretty serious design limitation in the
Internet of Things era, where interfacing to the real world (analog
signals) is a basic functional requirement. Analog requirements and
real-time clocks are a common oversight in computer science circles.
Look at their libsoc readme: "Future ideas are: - A/D Converters"
That's not a future idea, it's a 1970's idea. (It is also ridiculous
that they named it CHIP. Try googling that. They should have picked a
unique name.) 1-wire not net implemented. I notice on their schematic
that their I2C SDA pin does not include an on-board pullup resistor so
connecting a simple sensor (such as TMP102 temp sensor) needs a few
external components as well - similar to interfacing to Raspberry Pi -
and yet strangely includes composite video output. The touchscreen pins
could be hijacked for analog input but that might not work well and
still, signals would need external hardware for buffering. CHIP would
likely be a great tool for Mhz intensive embedded image processing if
using an external camera module. Reference: Datasheet
https://linux-sunxi.org/images/e/eb/A13_Datasheet.pdf and CHIP
Schematic CHIP_ALPHA_V_021.pdf . Small embedded unix computers have
been made previously. If the device is network-capable, the data
processing is best offloaded to the cloud, where development is easy,
and both Mhz and storage space are unlimited. The web server or
database for that data is also best offloaded to the cloud. So in terms
of looking at cost tradeoffs, it's far better to place the simplest
analog data acquisition/control, basic user interface, and networking
hardware at the point-of-use, and the computer science tasks in the
server farm. The antithesis is the NEST thermostat, a simple
temperature acquisition and relay controller device, running linux, for
$200 (down from $250). "But it's cute," I hear the mass market saying -
oh, okay then. It also has had segmentation faults, the full software
code base is too large to audit, and yet it controls the environment of
a user's home. (That product also exists in one of those funny market
segments where installation costs significantly more than the devices
themselves.)

Hypothetical convergence graph of the internet of things;
https://en.wikipedia.org/wiki/Internet_of_Things#/media/File:Internet_of_Things.svg

## Jonathan Cline
## jcl...@ieee.org
## Mobile: +1-805-617-0223
########################

[Nathan McCorkle]

On Thu, Dec 3, 2015 at 10:21 AM, Jonathan Cline <jcl...@ieee.org> wrote:

 This past month with Amazon dropping the price of the lowest cost Fire tablet to $35 

It seems the cheapest I can find with Prime 2-day shipping is now $39.99, and this doesn't seem to be a recent generation

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

I wonder if wires are needed these days with the ESP8266 or ESP32 (wifi microcontrollers). That Fire tablet has Wi-Fi... so things could be even more flexible.

[Simon Quellen Field]

Android tablets can host OTG USB connections (including USB to serial converters and USB to parallel converters).

And they have a microphone and earphone jack, which you can send and receive data on, using a bit of software.

And at $37, you save two bucks.

WiFi, Bluetooth, 1024x600 touch screen, quad core 1.3 GHz processor, half a gig of RAM, 8 gigs of flash, TF card slot, and front (0.3 mp) and back (2 mp) cameras.

-----

Get a free science project every week! "http://scitoys.com/newsletter.html"

--
-- You received this message because you are subscribed to the Google Groups DIYbio group. To post to this group, send email to diy...@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 diy...@googlegroups.com.

Visit this group at https://groups.google.com/group/diybio.

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CA%2B82U9%2B6DRWTL4uNxzHgi5qGb6yBQquLt4HbHzQ6fYuHddracw%40mail.gmail.com.

[Simon Quellen Field]

And if you want a smaller cheaper Android device, here is a phone for $34.

Smaller (4.5 inches) so it takes up less space when glued to your equipment.

854x480, 0.25 GB RAM, 1GHz single core processor.

And it's a phone, so you get cellular capability, not just WiFi and Bluetooth.

Pretty wimpy compared to the 7 inch tablet, but it's a phone, so you can take it out in the field and still have Internet.

For sterilizing, there was some guy (here maybe?) who was putting phones and tablets into laminating machines at copier stores.

Completely seals them, and the touchscreen still works.

You charge it wirelessly for another two bucks, using Qi dongles plugged into the charging port.

Just dunk it in a bucket of bleach and come get it the next morning.

-----

Get a free science project every week! "http://scitoys.com/newsletter.html"

[Marc Juul]

Beware that Amazon's cheapest tablets are not able to use USB OTG while charging. This seems to be due to lack of kernel support. Possibly putting CyanogenMod or similar on there might fix this but I haven't tried. If anyone knows anyone in the San Jose headquarters of Lab126 maybe you could let them know about the issue?

On Sat, Nov 11, 2017 at 4:24 PM, Simon Quellen Field <sfi...@scitoys.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CAA0yOM6uji4vUCU9%2BOVRO8UTha_1_GyBxk1YqF4hw_QfLMXcNw%40mail.gmail.com.

[Simon Quellen Field]

How would you charge the device if the USB port being used for charging is also the port connected to something that needs to get its power from the tablet/phone through that same port?

I have some Windows 10 tablets that charge through the only USB port they have, and to connect an external keyboard/mouse I have to stop charging.

Or at least I thought I did, until I read your email.

I will have to try charging from a USB hub that has the keyboard/mouse attached to its other ports, and see if that works.

I may have some cheap Android tablets around with the same configuration, and I will try those as well.

-----

Get a free science project every week! "http://scitoys.com/newsletter.html"

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CAL4ejvQB5-XQcnkEKn8867OgET313uvbzdwFQ%2Bu1%2Becn2vcTFA%40mail.gmail.com.

[Marc Juul]

On Mon, Nov 13, 2017 at 6:03 AM, Simon Quellen Field <sfi...@scitoys.com> wrote:

How would you charge the device if the USB port being used for charging is also the port connected to something that needs to get its power from the tablet/phone through that same port?

You can use a special Y-splitter cable or hub but unfortunately only on some devices. Apparently a 100k resistor between the Sense pin and ground is the signal for OTG + power and if the USB chipset and kernel driver supports this feature then it should just work:

https://sites.google.com/site/sonicboomworld/my-projects/otg-diagrams

 

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CAA0yOM4E8rtqwmcaSZq7mPhvwOeDtgiCMVuYbBMrc55qQ6q-kw%40mail.gmail.com.