I'm currently working on changing the world!

[S James Parsons Jr]

Hi Seth,

I’m currently working on changing the world. Today is my second day on this forum. But I came here to get feedback on a machine I’m building. It's a laboratory robot for consumers. My main focus is on protein and cell production. The machine is structured around validation, repeatability, and ease of use. I’ll share more when the GUI interface is finished.

Best,
James

[Ravasz]

Hi there,

Can you tell us more about your machine? I am building something potentially similar (an automated alga growing machine that can be used for cell and protein production), but its hard to tell from your short description whether your design is something similar. If you are looking for feedback, don't hesitate to get in touch, we might even be able to help each other out.

Cheers,

Mate

[S James Parsons Jr]

Hi Ravasz,

In short, my robot is a mechanical laboratory technician. It has an eye, hand, brain. Its eye is an 8mp camera to validate every step in a procedure, which also includes a 100x microscope attachment (currently not working). Its hand has two fingers (for now), it can interact with tools using 8 pin data connector, water, gas, and vacuum pump. There are two classes of tools, bench tools, and hand tools. The current hand tools are pipette, inoculation loop, 506nm laser, and homogenizer. The current bench tools are computer controlled hotplate, a gel electrophoresis chamber, bioreactor, and more to come. All hand tools are placed in a toolbox and bench tools are addon nodes. The brain is the software suite, it follows user created protocols, validates each step of the protocol with relevant sensor data and images. The images can be processed using plug-in image processing code (currently only count cells, and mosaic image stitch), then all images and data collections are created into an HTML lab book.

My vision is to have a lab (kitchen) with 10 of these laboratory robots. 3 making reagents (line Chef), 5 making growth factors (line Chef), 1 for incubation and colony isolation (Sous Chef), and the last one to run the experiments (head chef).

[Dakota Hamill]

Ambitious goal, get it done! 

Check out https://www.emeraldcloudlab.com/

--
-- 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/b7b700b2-712e-454e-b756-7e63babc251b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Griessen]

On 3/13/19 5:26 AM, Ravasz wrote:
> Can you tell us more about your machine? I am building something potentially similar (an automated alga growing machine that can
> be used for cell and protein production), but its hard to tell from your short description whether your design is something
> similar. If you are looking for feedback, don't hesitate to get in touch, we might even be able to help each other out.

+1
I have already developed a biologist friendly microcontroller board
ecosystem with connectors running micropython and able to be a switching power supply
or most other things you could dream up and costs under $10 for the controller board,
and open hardware designed with gschem schematics and pcb-rnd layout. Perhaps you'd like to share
development and all move forward more quickly?

[John Griessen]

On 3/13/19 8:23 AM, S James Parsons Jr wrote:
> My vision is to have a lab (kitchen) with 10 of these laboratory robots. 3 making reagents (line Chef), 5 making growth factors (line Chef), 1 for incubation and colony isolation (Sous Chef), and the last one to run the experiments (head chef).

eVOLVER project has already gotten far on their bioreactor, and is interested in collaborators, but not to redo everything they've
done with new bits. For how to interact and use 3D printed containers to do so, they are a good read.
--
John Griessen

[S James Parsons Jr]

Thanks Dakota,

Wow, just wow.  I’ve seed other companies in the cloud lab space but ECL looks fantastic.

Something to think about.  I wanted treat the lab like the first computer, and get it out of the big institutions like the personal computer did.

Cloud Lab will definitely offer so cool data, but I need proteins for my experiments! 

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CAGdeWmRYhkPLyAw_A%3DzZ9crrbow5U6ogZ7uk4_OYPLWmcau5sw%40mail.gmail.com.

[S James Parsons Jr]

John that’s great,

What communication protocols does your bio-micro controller support? UART, i2c, SPI?

Do you have a pdf/product link?

Each bench tool node currently works off an Arduino Uno clone cost about $3. Would your boards get cheaper with bulk orders?

My number one priority is, “how can I make this affordable”!

> --
> -- 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/d858752b-f4ae-5b0e-8891-f1549213fae1%40industromatic.com.

[John Griessen]

On 3/13/19 10:59 AM, S James Parsons Jr wrote:
> Each bench tool node currently works off an Arduino Uno clone cost about $3.

I prefer micropython over arduino language.
Some tools are so simple they can be done with 50 cent microcontrollers, but that lacks
easy reprogrammability.

Would your boards get cheaper with bulk orders?

Sure, that's how the world works. Also, you can reduce the specs. For instance, my controllers
have a USB power converter on board, and a battery monitor and battery for portability -- all that
can be left off. The MCUs for running micropython cost around $2.50 in 100's, so they
might not work out for the simplest tools unless you like the easy reprogrammability.

> My number one priority is, “how can I make this affordable”!

With that as the one true top priority, you need to be sure how large your number of customers is,
and ditch easy reprogrammability, because that always costs more.

It's normal how these decisions are not black/white, but grey areas.
I think keeping easy reprogrammability available is part of a system's appeal more than
$1 less cost per node.

[Simon Quellen Field]

I don't wish to hijack this thread, so I changed the subject line.

John didn't say why he preferred micropython to C++ (which he called "the arduino language"). But the compactness and speed of C++ code over an interpreted subset of Python gives it a substantial advantage on small processors, where both CPU execution speed and memory space are both limited.

C++ is a very rich and expressive language, and perhaps 95% of all microcontroller development is done in either C++ or the subset of it that is C.

With Arduino clones going for $1.42 with free shipping, there is also a cost benefit to using the Arduino platform.

John alludes to "easy programmability" as a problem with "50 cent microcontrollers".

It takes a few seconds to download a program into an Arduino Pro Mini using a $2 FTDI board. If that is too hard, you can simply plug a $1.83 Arduino Nano into a USB cable and program it in the same amount of time, at the cost of reduced battery life due to the onboard FTDI chip in the Nano. You can also do your development on the Nano, and run your production code on the Pro Mini since they use the same processor.

Micropython is a wonderful little language, and even though the cheapest board I could find was at $2.71 almost twice the cost of the Arduino, that is still peanuts, and the board you get has a 32-bit processor, WiFi, lots more processor speed and lots more memory. With the extra speed and memory, micropython is much less crippling, but at the cost of the loss of real-time processing (since WiFi needs to take control of the board often to look for packets coming in and to advertise itself).

But if the code was written in C++ (which is what the OS on that board is programmed in, and which the board supports using the same Arduino IDE as the Nano and Pro Mini), it would run up to 100 times faster and take up less memory, allowing you room for larger programs, or more data. And your code doesn't stop to garbage collect memory every once in a while, hampering real-time processing.

-----

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 https://groups.google.com/group/diybio.

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/65c84d7a-7d6d-d7bd-c4a0-e320808b6ee8%40industromatic.com.

[S James Parsons Jr]

Just read up on eVOLVER, that’s really epic. Never thought about using smaller volumes in an array. Is Bashor on this forum?

But at a >$2000 price point its to expensive for my project. My bioreactor currently cost >$60 (subject to modification and testing)

> --
> -- 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/4153a9d5-e218-f279-d273-0426a6da4722%40industromatic.com.

[S James Parsons Jr]

Thanks Simon,

I’ve been programming for about 20 years and I love python, all my visual processing plugins are written in python, and data processing is done with pandas, but I like octave and MatLab better. My GUI is written in xojo, all my micro controllers are (currently) written in c++, and the app is Swift for iOS and Java for android.

I have no desire to program in assembly language ;)   ADD, MOVE, STOP, END 

So it all demands in the task at hand!   Most likely the millions of programmers will make my open source laboratory run on everything under the sun.

To view this discussion on the web visit https://groups.google.com/d/msgid/diybio/CAA0yOM78Q%2BS2RmwbPRy2ub5AMj-WoQr6nT%3DieDZEF%3DT0iiPu3A%40mail.gmail.com.

[Nathan McCorkle]

On Wed, Mar 13, 2019 at 10:35 AM Simon Quellen Field <sfi...@scitoys.com> wrote:
>
> I don't wish to hijack this thread, so I changed the subject line.
>
> John didn't say why he preferred micropython to C++ (which he called "the arduino language"). But the compactness and speed of C++ code over an interpreted subset of Python gives it a substantial advantage on small processors, where both CPU execution speed and memory space are both limited.

I think the bigger reasoning for choosing Micropython to deploy on
programmable lab gear is the end-users often lack reasonable coding
skills. For example many biologists I knew in my undergrad stuggled
with email and Excel spreadsheets... biologists John and I have tried
interfacing with as beta testers for the open-source electroporator
have struggled with deleting and copying files from a github clone to
a Micropython 'drive'.

So I don't have a sliver of hope that the **average** biologist or
chemist would be able to handle hacking on C++ to automate or alter
lab gear. Now after some thought, maybe these folks wouldn't be able
to handle Python either... but I think there's certainly less barrier
and an easier ramp to climb.

As you said, Micropython itself is written in C++... so performance
really isn't an issue since their documentation provides good examples
of writing C modules for Micropython.
This is exactly what I did to use the DMA feature of the
microcontroller John chose for the culture-shock electroporator, when
I wanted to collect ADC samples from the High-Voltage output while
actively pulsing, and to start working on an automated solution to
voltage-limiting (so the user didn't have to specify the low-level
pulse-width timings, which is unlike any existing electroporation
protocol which just deal with overall time-scale and max voltage).

[Simon Quellen Field]

This makes little sense to me.

1. Any device that requires programming requires a programmer and is not a consumer device.
2. Python is no easier to learn or use than C++. They both have the same control-flow constructs and the same programming model.
3. You chose to use Micropython because you thought it was easier. You ended up using two different languages, making your life, your workflow, and the difficulty for someone to work with the code all that much harder.
4. C++ lets you get at everything on the machine.
5. C++ on microcontrollers is real-time -- no garbage collection, no paging, no timesharing.
6. C++ is orders of magnitude faster.
7. There are over a million hobbyists who cut their teeth on Arduinos, writing their first code in C++.
8. There is a lot more code to steal and use as examples for the Arduino than for Micropython.
9. You save a buck or two because C++ doesn't require the more powerful processor with more memory.

If you thought you were saving your users pain by giving them an easier language to learn, you haven't learned from your experience with non-programmers using your device. Your customers are either programmers or they aren't. If they are programmers, C++ is as good as Python, except C++ has more example code around, and a bigger hobbyist base. If they can't handle email and Excel, and can't copy files to a USB drive, they aren't going to benefit from any version of Python.

Python is a wonderful language.

But running an interpreted subset of it on a microcontroller just adds to your headaches.

C++ just isn't that hard to learn, and Python isn't easier to learn.

There are easily 10 times as many self-taught C++ programmers as Python programmers.

All because of the ubiquity of the Arduino platform.

I taught C++ programming to artists with no technical background at all and wrote that textbook for the course.

They all did beautifully (literally -- they made beautiful things).

Now, all that said, if you want to make your platform programmable by anyone, you might start with the BBC Micro:bit.

You can program it in Blockly (similar to Scratch, where you drag and drop blocks onto the screen that connect into programs).

I've put children in front of a laptop running the Micro:bit version of Blockly, and they picked it up quickly without any help from me, making shapes on the LED display, making it change the lights when tilted or shaken, and all kinds of other fun. No syntax, so you can't make syntax errors. Everything is visible. And the Micro:bit has Bluetooth, runs off of batteries or USB, has a 3-axis accelerometer and 3-axis magnetometer, buttons, light sensor, and is easily interfaced to other things using nothing more than alligator clips. And if you don't like programming by dragging and dropping blocks on a screen, it accepts Javascript (the blocks are compiled into Javascript) and Micropython (which is not as easy to program in as Javascript on the Micro:bit, but easy enough).

-----

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 https://groups.google.com/group/diybio.

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

[Gerald Trost]

Hi!
 

just some programmer's thoughts:

1.)

could it be that "C++" on Arduino is merely a C interpreter ?

So far I never extended a class and never implemented an interface

and I never saw generic types ...

Well, it might be that I am less familiar with C++ on Arduino compared
to C++ on Windows but it it still worth considering that it might not be
a proper and full "C++" compiler.

 

2.)

As you said:

"Now after some thought, maybe these folks wouldn't be able
to handle Python either..."

I fully agree with this.

And I think it might be even worse:

Just BECAUSE Python seems to be easier at first glance will
they most probably write less structured code any doing so
they might soon come to a point where source code gets
over-complicated and no longer managable ...

I strongly encourage everybody to first deeply dive into
programming larger projects before deciding what language
is to be preferred.

 

as I said - just a programmer's thoughts

Gerald
 

_________________________________________________________________________
<experience comes shortly after it was needed>

Gerald Trost
Software Developer / Programmierer
phone: +43 (0)650 2311057
skype: gerald.trost

https://xing.com/profile/Gerald_Trost
https://linkedin.com/in/gerald-trost-57ba80ab
https://facebook.com/gerald.trost.3

_________________________________________________________________________

 

 

Sent: Monday, March 18, 2019 at 8:04 PM
From: "Nathan McCorkle" <nmz...@gmail.com>
To: diybio <diy...@googlegroups.com>
Subject: Re: [DIYbio] Micropython vs C++ for microcontrollers

--
-- 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/CA%2B82U9JdrkCDpVfguCMc0vh8m8HsApL-VebHr7conZQzfKi8gQ%40mail.gmail.com.

[Cathal Garvey]

Something to remember: Scientists are more likely to know Python as a result of statistical/graphing know-how.

Quite besides which, the old "all languages are the same" gimmick doesn't hold that much water. If it were meaningfully true outside of a purely rhetorical case, then all programmers would be equally comfortable in all languages, yet we find that programmers have strongly held opinions on which language lets them do what they need at the pace and convenience they need.

Even leaving aside the compiled/interpreted thing for minute, look at the enthusiasm from C++ devs (present and past) about the rapid maturation of Rust. The warm comparisons are made here between two languages at the same level of development and (if we don't discard externalities like correctness, security, and reliability) the same level of difficulty. Despite appearances, Rust is not a C-family language and has some semantic differences to C++. Yet if you asked me which I'd prefer coding in... I have a very strong opinion on the subject. And though I won't, I could reel off the reasons for that opinion. It's not just "preference".

So, yunno, not all languages are alike.
And, if part of the goal of a project is to make a device customisable by end users, there are plenty of reasons to pick a more expensive, interpreted-language chip. Even if it means you need to maintain some low-level "crunchy bits" in C++ to enable them.

If easy hackability is not a great concern, then for cost and energy-efficiency reasons it _does_ make sense to go with a C++ (or Rust, soon) solution. The people who really need to modify may still learn the language and clone the codebase, it's just a trade-off of difficulty and efficiency.

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

[Simon Quellen Field]

The Arduino IDE uses a full-blown version of the GNU C++ compiler.

It was free, and all of the chip manufacturers port it to their chips during development, so it was there to use.

People tend to like the language they are most familiar with.

That just makes sense, since the learning curve has already been paid for.

In the case of a language that needs a C++ programmer to do the fiddly bits close to the machine, what you end up with is a system that no one is completely comfortable with since they need to be familiar with two languages, and people are bound to use one language more than another, just by chance.

When you already have a powerful, widely known language supported on a platform, with lots of example code to steal, lots of libraries full of code for dealing with all of the hardware you might want to attach to it, the only reason for choosing an interpreted subset of another language is that you are more familiar with that other language, and feel more comfortable there.

That's OK.

The original post said as much, simply that he preferred Micropython. And there is nothing wrong with that.

I felt the need to point out that there are significant tradeoffs being made due to that decision, and that if he had preferred a language that was faster, produced smaller code, was supported on more hardware, had more hardware libraries available and could do real-time programming, those tradeoffs disappear.

Cathal's point about data scientists being more likely to know Python is relevant and has support from other sources.

But the Python libraries they are used to using won't fit onto a microcontroller.

And the language #9 on the list in that link (C, not C++) is described as being largely used in embedded systems, which is what we are discussing. The largest programming systems I have worked on (several million lines of code) such as operating systems, browsers, compilers and IDEs, have all been written in C++, and there are lots of excellent tools available to work with in that language for supporting very large systems. But we are talking about very small systems.

I also like Cathal's other point about all languages not being the same. He seems to favor picking a language based on its suitability for the task at hand, instead of using the programmer's favorite language. As someone who has spent much of his career writing compilers for dozens of different languages, I have had to learn many different languages. This makes me biased towards just telling people to learn the language that is best for the task, as once you know one or two, becoming competent in another is really pretty easy, especially if the new language is based on C, as Python, Java, Javascript, PHP, C#, and so many others are.

The case for an interpreted language on microcontrollers is easily debunked.

In a small memory, slow processor environment, stuffing your editor and compiler into the same memory footprint as your target code means that none of the three will be what it could be. Cheap microcontrollers that are programmed via USB are very easy to modify using a laptop computer with a good IDE. Push a button and your program downloads onto the chip, while you get the advantages of a powerful editor, a very powerful full-blown compiler with impressive optimization capabilities, and often a simulator that makes debugging and learning all that much easier (check out the simulator for the BBC Micro:bit, built into the IDE. You can learn all about how to program the device before you even buy one.)

-----

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/trinity-468181b5-c870-45d0-94da-9caa2967d873-1552975316260%403c-app-mailcom-lxa05.

[John Griessen]

On 3/19/19 10:38 AM, Simon Quellen Field wrote:
> Cathal's point about data scientists being more likely to know Python is relevant and has support from other sources

> <https://www.analyticsindiamag.com/top-10-programming-languages-data-scientists-learn-2018/>.

> But the Python libraries they are used to using won't fit onto a microcontroller.

I chose micropython for the "familiar to customers reason", even though I don't really expect them
to create new code with libs they use on data. I expected them to tweak sequences and possibly
data output format related to the existing functions of the machine. So, I made code that has those
functions nicely named so they can be tweaked by a casual coder. There is so little response on this diybio list
that I wonder if that was a wrong guess and 0.1% of customers will do any code tweaking, even if it seems easy
to hardware developers.

Micropython has a python prompt like an OS that you can
use for testing code that generates different waveforms, which is very handy
with a hardware/software programmable switching power supply like this. So, another reason I chose it was speed
of development by not having to write a REPL in C code.

The machine makes high voltage in a very power limited way with series of fast pulses used
to get one slower high voltage pulse result,
measures the output and gives that waveform data back on an OLED display or sends it out the serial port,
and responds to buttons that let it be run standalone with no other computer attached.

Maybe I should have gone native code and used C libraries from ST or the libopencm3
FOSS libraries for STM323F4 micros. It's too late now though... :-)

After hearing about rust, I searched around some and found this:

https://tinygo.org/faq/why-go-instead-of-rust/

I really like this part of the intro description:

"Go prides itself on being a simple and slightly dumb language, sacrificing some expressiveness for readability.

Built-in support for concurrency with goroutines and channels that do not rely on a particular implementation threads. This avoids
the need for a custom RTOS-like framework or a full-blown RTOS with the associated API one has to learn. In Go, everything is
handled by goroutines which are built into the language itself.

A batteries-included standard library that consists of loosely-coupled packages. "

but then there are cons also:

"Rust has stronger memory-safety guarantees.

In general, Rust is more low-level and easier to support on a microcontroller."

So now I am so far OT for diybio I'm stopping. :-)

[Jonathan Cline]

The BBC micro:bit is useless in real world designs because the major design failure of not having a voltage regulator on-board which means it can't be run from battery packs or rechargeables, only alkaline.  This is a significant design flaw which renders the board relatively useless on its own.

 

On Mon, Mar 18, 2019 at 11:01 PM Gerald Trost <gerald...@mail.com> wrote:

Hi!
 

just some programmer's thoughts:

1.)

could it be that "C++" on Arduino is merely a C interpreter ?

So far I never extended a class and never implemented an interface

and I never saw generic types ...

Yes, the compiler is grammatically C++ capable.  No one writes full-featured C++ code on arduino platform regardless of what the compiler is capable of.    Calling a library or writing a very basic class is about all that is done in practice, and use of those trivial features does not equate to "oh yeah we use C++" any more than a diybio group doing strawberry DNA extraction in a shotglass equates to real wetlab work.    Runtime speed comparisons between micropython and C show that micropython is very useable especially considering that lab equipment does not have to be real-time and the IC should be actively in Sleep most of the time as well.  Parts of the design where speed are a true concern would implement in assembly anyway (most likely inline-assembly in the C source).  C++ shouldnt be used on time-critical functions due to overhead regardless.   

As the cost of lab supplies is well into the hundreds per project, the difference between a $2 board and a $8 board since it is a one-time lab equipment capital asset purchase is relatively meaningless. The chassis ends up costing more than either.   Once a wetlab scales to need enough devices to matter, the lab equipment budget will have already increased far in excess to compensate so the accumulated difference is also insignificant.

Micropython is a good choice although assuming enhancements will be made by end users is not a good goal.   Yes, Bioinformatics is focused on python, so skills are transferrable.  Studies of the much-hyped long tail of open source have already shown that nearly all development work for projects is done by the original project owner(s), not by end users or many-small-contributors down the road.   Especially in biology as stated, the end users, even if they are advanced users, are unlikely to enhance a piece of lab equipment.  Large companies have been working at this problem for decades and designing and refining supposedly "easier to use" graphical device control languages to little avail.  Biologists have their hands full and are in a different mindset in the lab and do not want or are not qualified to reprogram equipment.  Not even beta testers will want to modify or even study the code if given the opportunity.   Focus on building solid, ready-to-use tools, minimize the avenues of customization (especially since features allowing end-user modifications increase R&D effort anyway).   Interoperability among other vendors devices, and adoption of standard file and communication protocols, is a far more important priority.

-- 

## Jonathan Cline

## jcl...@ieee.org

## Mobile: +1-805-617-0223

########################

[Jonathan Cline]

Nordic Semi
nRF52840 Micro Dev Kit USB Dongle*

A small and low-cost nRF52840 Micro Development Kit in USB Dongle Form Factor
Description

The nRF52840 Micro Dev Kit USB Dongle is a small and low-cost
development platform enabled by the nRF52840 multiprotocol SoC in a
convenient USB dongle form factor.
The nRF52840 Micro Dev Kit USB Dongle features a programmable user
button, RGB LED, up to 12 GPIOs and 2.4G Chip antenna on board.
The USB Dongle can be used as a low-cost
Bluetooth5/Tread/802.15.4/ANT/2.4GHz multiprotocol node or development
board. Alternatively the USB Dongle can be used as a Network
Co-Processor(NCP) with a simple connection to a PC or other USB
enabled device.


(* SOC core is 32-bit ARM® Cortex™-M4 CPU with floating point )

This board should very likely be the #1 way forward. Bluetooth lab
gear finally realized and useable code space for product
implementation. Note this SOC and board is the big brother to the
design of the (as previously mentioned 'useless for a product') BBC
micro:bit board.

[S James Parsons Jr]

Does anyone know if eVOLVER has a website showing how to build one?

[Jonathan Cline]

It would be better to ask /does it actually work/ first, because there
is the small burden of proof and reproducibility regardless of lab
publication. https://www.fynchbio.com/documentation

On 3/23/19, S James Parsons Jr <sjamesp...@gmail.com> wrote:
> Does anyone know if eVOLVER has a website showing how to build one?
>
>

[Dakota Hamill]

That motherboard seems pretty intense being a non EE.  Would be cool to recreate just a single reactor with that sleeve and the arduino. 

--
-- 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/CAAhtNQvVidv-13Q8Pqfw9vKv__P1%3DU6onHJ--bYcteSWTLvbWA%40mail.gmail.com.

[Dakota Hamill]

https://www.fynchbio.com/tutorials/2018/7/1/building-a-smart-sleeve-for-continuous-culture

[Jonathan Cline]

Before spending any time fabricating or building, run some napkin math
with real-world fudge factors. I remember this style of heater (maybe
on evolver itself) was discussed before (the sleeve). Do you really
believe that the laws of physics allow precise temperature control of
a piece of aluminum which touches a "heating resistor" and is
close-loop controlled by a thermistor? I do not. Not at all. It
might look pretty in the pictures. Feel free to prove me wrong, thats
what science is all about. Perhaps it's a question of "whatdya mean by
'precise'? Works well enough in the uni lab.." (which itself is a
carefully temperature-controlled environment of 20C)

The motherboard is not complex, it looks like simply a bunch of
connectors and resistors. I guess it is supposed to plug daughtercards
in. It is a large and unnecessary expense. Maybe they had a large
grant award and felt no need to constrain the budget. There's no need
to make that PCB. Any real lab will specialize in a particular area
of experimentation, with a well defined and limited set of protocols,
and thus will not need so many variations of arbitrary plug-in boards.
Just point-to-point solder together what is needed. Cabling is far
easier and in most cases more reliable (consider RF noise, crosstalk,
power distribution) and less expensive compared to building a
backplane interconnect system (which is what the evolver design seems
to represent). Should any design really use a backplane of long
traces for analog lines (ADC or DAC)..probably not.

There have been other prototype systems similar to this built over the
years and discussed in this group.. including much-hyped ones, MIT
etc.. call up the original lab and ask if they still use the machine,
they will say: No, it's sitting in a corner covered in dust. Due to
various aspects of practicality and design failure.

[John Griessen]

On 3/23/19 12:35 PM, Dakota Hamill wrote:
> That motherboard seems pretty intense being a non EE.  Would be cool to recreate just a single reactor with that sleeve and the
> arduino.

It seems large and not so trivial to me being a chip head EE. I've asked and they say still working on it, no published
explanation of the liquid handling or much about that large motherboard last I checked 2 months ago. The overall intro describes
the motherboard as holding standard cards that have a standard setup of microcontroller and code on each one so they can rapidly
update them for different tasks. That is something every EE has an idea about and few agree until a defacto standard chip set
comes along with enough traction and gets used a lot.

On 3/23/19 1:37 PM, Jonathan Cline wrote:> Should any design really use a backplane of long

> traces for analog lines (ADC or DAC)..probably not.

No, probably not.

I think they may be passing only digitized messages though and that is easier to agree to,
and easier to see if data is moving and good and pinpoints where to fix when it breaks.

[John Griessen]

On 3/23/19 1:37 PM, Jonathan Cline wrote:

> Do you really
> believe that the laws of physics allow precise temperature control of
> a piece of aluminum which touches a "heating resistor" and is
> close-loop controlled by a thermistor?

https://www.fynchbio.com/tutorials/2018/7/1/building-a-smart-sleeve-for-continuous-culture

The fan along with the aluminum tube and "heater resistors" doesn't seem like it
would be in feedback control, does it... More like the fan dominates and the whole
collection of sleeves stays at room temp.

The fan has magnets added and 1/8" laser cut acrylic pieces added though, so maybe
it doesn't move much air. There is a mention of, "verify that the two small 2-56 holes on the aluminum sleeve align with the
holes on the heating resistor.", so the heating resistor must be a real heater bolted on with heat transfer paste.
This description is not complete it seems -- no bill of materials listing that special heater resistor.
It seems more like something that will work after noticing these details. Odd that fasteners are in inch sizes
as if it was designed with screws from some organizer drawers that were filled up in the 80's.

I guess the hardware is easy to improve on. I like their code concept and am curious to hear more about the fluidic
system. I bet Wong has more to say on it now -- we need to ask him.

[Jonathan Cline]

On 3/24/19, John Griessen <jo...@industromatic.com> wrote:

> https://www.fynchbio.com/tutorials/2018/7/1/building-a-smart-sleeve-for-continuous-culture

>
> the heating resistor must be a real
> heater bolted on with heat transfer paste.

The part numbers for the manufacturer are given in their docs. 2x 20 ohm 1%
resistors 15W max in series and no thermal paste. The board
connector is shown in pics.
It is not possible to heat well using the power given to that board through
that connector with 1A max per pin. There is a thermistor in the
design but uncalibrated,
and taped to the tube.
The fan motor is for a magnet-stir setup, I dont think it is for air
flow. There is no need
to use a PCB for this functionality.

Skim the Nature publication.

Read the source code- it's not good either. (For the Nth time: No
one should use arduino in professional projects!)

This is the kind of system that an EE/ME undergrad team would throw
together over the summer break for fun, it is not publication-worthy
or innovative in any of its dimensions.

> I guess the hardware is easy to improve on.

No, I think the design and the publication is irresponsible, and it
should be ignored.
It's vaporware, it's hype, and the laws of physics are not possible to
violate regardless of
how nice the pictures look, or how many mentions of "3D printing" and
"DIY" there are.
It's not even price competitive, considering comments made here so far and the
system's reliance on laser-cut this and that.
Pretty much, the advisors and authors should not feel good about themselves
for this work.

-- Quote --

Author information

Author notes
Brandon G Wong & Christopher P Mancuso
These authors contributed equally to this work.
Affiliations
Biological Design Center, Boston University, Boston, Massachusetts, USA.
Brandon G Wong, Christopher P Mancuso, Szilvia Kiriakov & Ahmad S Khalil
Department of Biomedical Engineering, Boston University, Boston,
Massachusetts, USA.

Brandon G Wong, Christopher P Mancuso & Ahmad S Khalil
Program in Molecular Biology, Cell Biology and Biochemistry, Boston
University, Boston, Massachusetts, USA.
Szilvia Kiriakov
Department of Bioengineering, Rice University, Houston, Texas, USA.
Caleb J Bashor
Wyss Institute for Biologically Inspired Engineering, Harvard
University, Boston, Massachusetts, USA.
Ahmad S Khalil
Contributions
B.G.W., C.J.B., and A.S.K. conceived the study. B.G.W. developed the
system with guidance and input from all authors. B.G.W. and C.P.M.
performed and analyzed experiments. S.K. generated reagents. C.J.B.
and A.S.K. oversaw the study. All authors wrote the paper.


-- End Quote --

[John Griessen]

On 3/24/19 11:57 AM, Jonathan Cline wrote:
> It is not possible to heat well using the power given to that board through
> that connector with 1A max per pin.

They report doing cultures with it, so there must be something missing from
your take on it. They won't get to 1 Amp with a 40 Ohm heater -- that would be 40 volts and this is
a low voltage looking system. Maybe the whole thing is usually in a low air flow clear plastic box.
maybe they put on some insulating covers when they use it.
Why say they are to be ignored? You're not putting out anything similar/better.
I think it is a good proof of concept. I can believe they get +/- 2 deg C
temperature control. They do mention heat transfer paste, so they discovered
the low heat flow you suspected and did a first cut fix of it.

I'm not responding to any more eVOLVER bashing, only constructive criticism.

[Nathan McCorkle]

On Sun, Mar 24, 2019, 9:57 AM Jonathan Cline <jcl...@ieee.org> wrote:

 (For the Nth time:  No
one should use arduino in professional projects!)

Sure, and no restaurants should use pre-packaged milk for the pudding they serve for dessert. Geez, arduino is just a brand and collection of Board Support Packages, declaring "this microcontroller will easily compile and upload your GNU C++ code with a standard toolchain driven by a standard ooen-source GUI".

[Jonathan Cline]

And because designs use that platform,
- it is more expensive
- it is less functional
- it requires multiple daughtercards to add the missing functionality
- each external board means adding connectors which adds to cost
- it requires a large "motherboard" (backplane) for those daughtercards
- each daughtercard means creating additional small PCB's
- lack of functionality means using a separate more expensive
controller: the raspberry pi
- and then raspberry pi itself is designed to be a television
computer, not an embedded host for peripheral boards
- it requires much more silicon resources than other choices otherwise would


But sure, it is neophyte-friendly and designed for lower-division education.


Considering the evolver mandates custom PCB's anyway, for the multiple
daughtercards, the use of a generalized and generic platform is just a
bad choice. The better solution would be to pick a more powerful
platform at the start and not require a custom PCB, or avoid generic
platforms and put a fully-functional controller on the custom PCB's.
They made the wrong initial design choices for what purpose, was it so
that makers could buy all their supplies through ladyada? If so that
is definitely a bad set of product requirements, to restate again,
since they require so much further fabrication to build the project.
(Laser-cut acrylic.. Tapping aluminum pipe for 4-40 thread, etc..
Double-sided PCB's with odd shapes, etc.. )