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
## 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/eb73862b-3bb5-4bd4-a0b4-a1f5b055256b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
0 comments:
Post a Comment