[Oberon] The Oberon answer to Arduino

Wed Dec 26 19:08:06 CET 2012

On Wed, Dec 26, 2012 at 2:28 AM, Arnim Littek <arnim at actrix.gen.nz> wrote:

> > > On Tuesday 25 December 2012 11:29:25 you wrote:
> > > > I am getting some hard questions on my KickStarter
> > > > project<
> > >
> > > http://www.kickstarter.com/projects/1378252804/681865516?token=bfb4
>
> Maybe I'd better get a higher level view before I say anything about the
> schematic.  Simply the fact that the design stems from 2004, means that
> most
> of a decade later, you might be wise to consider your options in light of
> your
> highest level objectives.
>
> a) understandability for your students - OK, got that.
>
> b) serial control of lab instruments - is RS232 still the best way for you
> to
> do this?
>

This depends on whether it is my instrument, or logging data off of an
existing instrument.  That probably means that those details should all be
on a daughter board.

For a new instrument, I would not use RS-232.

Some of the applications that are unique to me are leaking into this
"general" device.  Actually, if I call this "a case study" it is a good
thing.

My specialty in chemistry is analytical chemistry.  It is important to
weigh items to a reliable 0.000 1 g.  I have students each weigh the same
set of clean nickels (US $0.05 coin that is nominally a metric 5.00 g
standard, readily available in the US, resistant to wear, and has "serial
numbers" embossed on them) on each analytical balance in the lab, and then
take apart the data to see how each balance, and each student, are
performing.

To take this lab to the next level, I want to record the time, barometric
pressure, temperature, humidity, and the balance output.  The analytical
balances cost about $5,000, so I am pretty much stuck with legacy
interfaces or a converter board.  In the case of the Mettlers in our lab,
this is RS-232 out of a DB-9 connector.  The environmental stuff should be
recorded inside the weighing chamber of the balance without heating it up,
the RS-232 port is on the outside.

So, for this project, the daughter board should receive RS-232 and a host
of other transducer inputs.  It should transfer, with very high
reliability, the data to a database server.  I probably want to use WiFi or
IR for this.  I don't know the practicality of IR.

All of this is backstory stuff.  I think I should hide it from the
KickStarter project, but I am just guessing there.

>
> c) you've got a socket for nearly everything.  Is that because you weren't
> confident in your design, or for other reasons?  Sockets raise the price,
> and
> reduce the reliability of the finished assembly.
>

Interesting that you notice that.  I am astonished at how much the sockets
and headers add to the cost.  I am pretty dissatisfied with the every I
have thought of.

I socket the LEDs so that I can swap them out, and generate current-voltage
curves for different parts.  I could accomplish this in a lab by having
different models of board with directly soldered parts.
I socket the hobby part so that I can swap out whatever I am working on
that moment.  That probably could be a customer added socket.
I have mixed feelings about the transparent latch.  My firmware defaults
to transparent and I don't think I have ever actually pulled the chip to do
an experiment.  I might want to have 1 or 2 socket-ed in a lab, and have
the rest of them directly soldered.  Another situation for 2 models, I
suppose.

I pulled parts from one prototype to build out the next prototype.  LOL.  I
even de-soldered sockets to go to the next board.  I think this was a bad
time-money tradeoff decision, but I grew up poor and have some poor people
habits that keep me poor.

Since the board is also a programmer, I have put a ZIF socket on some
revisions.  That really adds to the cost.  The current board is a little
too tight for a ZIF socket.  I worry about students destroying chips prying
them out of a socket.  I have good luck with a chip puller, or even a slim
bladed pocket knife inserted under the chip and twisted, but some students
have bad attitude and a streak of vandalism.

It seems feasible to make this a customer decision in the KickStarter
environment.  I would then have hard numbers at purchasing time, and I
could buy 5% excess of everything for those who make an after purchase
change of mind.

>
> d) ref. b), if you use USB, then you can simplify the power supply.
>  However
> there are provisos on power via USB.   For my own part, I find FTDI USB
> interface chips good for anything I've wanted, and because the drivers are
> widely, and well, supported, which matters to me as a Linux proponent.
>

The original revision, back in 2008, was to go to the PIC 18F4550 part.  I
changed the board to take power from USB, and to have fairly short traces
for the USB data.  I uploaded those EAGLE
files<https://docs.google.com/open?id=0Bx35YZ-0A4ffajNRVzd0R1BxZVE>
.

I forgot about the FTDI part in the past 8 years.  I dropped an FTDI
daughterboard into a prototype board, and ran jumper wires over to my
board.  It worked really well.  I have laid out artwork where that chip is
on my board.  I can't remember if I ordered that artwork or not.  I seem to
have a pipeline of built out prototypes, bare board prototypes, files with
ECOs on them, files with unrelated projects that might fill an empty spot
in a prototype run.  It's getting too complex for me to manage.

>
> e) how much help did all of those LEDs provide you on the existing samples
> of
> the board?    Are there better ways to communicate the same information?
>
>
The LEDs let me and a group of students see what is going on very quickly
and without any new tools intruding in the experience. If I directly solder
them, the total support is only about USD $1.10 for the board.

> I'll leave that as a starting point, and we'll see where it takes us...
>
> Arim
>

-- 
Aubrey McIntosh, Ph.D.
211 E. 5th St.
Morris MN 56267
(512)-348-7401
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20121226/5284dbc9/attachment.html 