[Wlug] [Fwd: Re: Multiple RS232 Com Ports...]

[John Stoffel]

Stephen> Lots of good info...  I hadn't stopped to think about a
Stephen> terminal server!

They're a great way to get a bunch of serial ports, especially since
they can be on the network and near the equipment to manage, but not
near the server room, etc.  

Stephen> OK, lets see about answering some of the questions...

Stephen> - - - - - -

Stephen> Yes, cabling will be fun.  The sondes are used for sampling
Stephen> water...  The sondes we use are cylinders approximately 2.5
Stephen> feet in length and about 3 inches in diameter (one, called
Stephen> "big Bertha", is about six inches in diameter) .  One end has
Stephen> a data connection that uses a round, screw-on, water tight
Stephen> serial connector, and the business end has several sensors
Stephen> sticking out (optical, chemical, conductivity, a little
Stephen> propeller for mixing water to be sampled, etc., etc.), all
Stephen> within a screw-on cage that protects the sensors from stuff
Stephen> like rocks passing by in the current (fast currents equate to
Stephen> rather large rocks).

Not a problem.  If you already have the DB9 -> screw on connectors,
you should be all set.  

Stephen> The idea is to have a tank of water (fish tank, cooler,
Stephen> whatever) fitted with Plexiglas that has multiple holes
Stephen> through which the several sondes are positioned upright, data
Stephen> end pointing up, with a bunch of cables hanging in-place
Stephen> above each sonde - think of the device that sets the bowling
Stephen> pins in place at the end of the alley...

Sounds like a good plan.  

Stephen> Anyway, you place a bunch of sondes into the tank (that has
Stephen> circulating water being maintained at a precise temp, %
Stephen> dissolved Oxygen, and so on), plug each sonde into the cable
Stephen> available directly above it, and then go to the *insert Linux
Stephen> solution here* and initiate communication, data upload, and
Stephen> calibration routines.  (By the way, the tank is just about
Stephen> done - its is being debugged as we speak.)

This is the key part here, and the one which I think is quite easy to
do.  As you mentioned before, the sondes have their own built-in menu
structure, so they must provide some basic serial support.  So I think
that you'll be able to easily talk to them.  Esp if you only need to
use 'hyperterm' on Windows to talk to them.  Heck, I bet you probably
don't even need all the serial pins to talk to them, but getting hold
of the documentation from the vendor is the key thing obviously.

Stephen> After upload and calibration (using the water in the tank),
Stephen> configure each sonde for the next deployment (how often to
Stephen> sample, etc.), turn them off, unscrew the cables and screw on
Stephen> a waterproof cover, remove them from the tank, and place the
Stephen> entire sonde into another protective chamber (6" PVC pipe
Stephen> with holes drilled in a specific pattern and capped on both
Stephen> ends) for another few weeks in some river/lake/coastal
Stephen> location.

I'd seperate the calibration and the configuration steps, probably
into seperate scripts.  This way you can just say:

	calibrate 12

And the calibrate script knows how to go and find serial line 12,
which is hanging over slot 12 and drive  a sonde.  Then you just have:

	config 12 -i <interval> ...

Which again, knows how to talk to cable 12 to configure your settings.
You can even have the script just prompt for all the settings and then
it goes off and does the work.  

You hide all the knowledge of how you actually get to serial port 12
in either a library shared between the scripts, or in a configuration
file.  Something like:

	1	/dev/ttyS1
	2	/dev/ttyC0
	12	termserver1:7001
	13	termserver1:7002

This tells the script which port to access.  The nice thing about a
terminal server is that they're actually quite easy to drive over the
network.  Esp if the serial port doesn't need a ton of hand holding.
And in this case, once you've got the configuration setup properly,
you can just set *all* the ports to that setup and forget about it.  

Stephen> Yes, I may be confusing myself regarding "I/O device driver"
Stephen> versus "driver" for the sonde...  However, I'm pretty sure
Stephen> that all I need is a vanilla "RS232 device driver" that will
Stephen> "just work" for any number of "com" ports by allowing some
Stephen> vanilla terminal emulation package (preferably one that has
Stephen> scripting capabilities) to talk to multiple RS232 ports. 

Exactly.  You just want some way to talk to a bunch of ports in a
simple manner.  Heck, I'd even look into using 'expect' to drive the
'c-kermit' program to do the serial port connections.  I even found an
article on the web which talks about using c-kermit as the scripting
language itself.  

Also, there's an expect script which will follow along with you as
you do a sample session, and then let you play back the session
again and again.  The script is called 'autoexpect' and can be found
with a bit of poking... on my Debian box it's in
/usr/share/doc/expect-dev/examples/autoexpect*  which is a pain since
you have to install the development package to get it.  Oh well...

Stephen> I could be wrong about this, in which case I may need to
Stephen> write some code, or perhaps the manufacturer might be
Stephen> thinking of supporting Linux.  

I don't think you'll need to get the manufacturer involved at all,
beyond figure out exactly what the serial connection settings are, and
the command language.  

But you will need to script out some stuff using something like
'expect' or 'c-kermit' to do the work.  This shouldn't be too hard,
esp if they calibration part is very mechanical and doesn't change.  

Stephen> I don't do the day-to-day instrumentation work, but I am
Stephen> supposed to worry about it none the less.  In terms of the
Stephen> "sondes going to sleep", this is based on concerns expressed
Stephen> by the lab along the lines of "if you hook-up the sonde and
Stephen> let it sit too long, you have to start over because it will
Stephen> turn itself off."  

Oh, this shouldn't be a problem, unless you have to do something funky
to bring it back to life.  I assume that the scientists hook up a
sonde, run (walk, saunter...) back to the PC and start they're
interaction over the serial line to configure sutff?  And if they walk
away for a coffee and the Sonde waits at a prompt too long, it shuts
down?  In that case, expect will do just great, since you'll be
automating all the boring parts of talking to these things.  

Stephen> Also, I use the term "vanilla" a lot because the staff aren't
Stephen> computer types - this has to "just work" like any other tool
Stephen> in the lab.  Dear lord - we are talking about biology types
Stephen> after all!  ;-) (Unlike engineering/geoscience types!!)

Hey, Biologists are scientists too!  They just like squishy living
stuff more than the cold hard electrical stuff we like.  :] 

Stephen> So, the other question was about the necessity of having
Stephen> certain signals present.  Again, I'm told that the sonde
Stephen> needs all the signals present in a DB-9.  I'm guessing this
Stephen> may have more to do with not really knowing for sure and
Stephen> erring on the side of caution, but since there is hardware
Stephen> available that will do this and I can't spend all of my time
Stephen> chasing this down, I'll assume the information I'm getting on
Stephen> this topic is correct.  (Biologists not withstanding.)  

Just do a quick test with a standard calbe and you'll know more.  

Stephen> I think this is where the multiport boards or a terminal
Stephen> server would come in...  One of the replies mentioned writing
Stephen> a script, and that is what I was thinking about...
Stephen> Specifically, I was wondering if it could be as simple as a
Stephen> script sending the proper bit patterns to get the sonde to do
Stephen> the right things, pipe the serial data through the script and
Stephen> append the data to a file, and s on...  (Was that you, John?)

Yup, that was me.  And don't get too low level here, you won't be
sending bit patterns, not unless these things are more cryptic than
has been made out to be.  

Could you fire up a copy of hyperterm and take a log of some sample
interaction with these devices?  THat would answer alot of questions. 

Stephen> Anyway, I'll have to take a look at the product references
Stephen> mentioned and contemplate what I might need to do in the
Stephen> world of scripting...  I haven't heard back from the
Stephen> manufacturer yet, but I'm hoping this will turn out to be a
Stephen> simple project when all is said and done!!  Also, I haven't
Stephen> used a terminal server before, so that should be interesting
Stephen> as well.

Just hook one Sonde upto a linux box using serial port /dev/ttyS1 and
fire up kermit like this:


    > kermit -l /dev/ttyS1
    c-kermit> set speed 9600
    c-kermit> c

    <hit return> a couple of times and see what happens.  


You can escape back to the c-kermit mode with Control-\ I think,  It
will tell you. Thne you can try other speeds.  You might have to do:

    c-kermit> set carrier-watch off

if it whines at you about that.  Or change the speeds, etc.  Just find
out what settings they use in hyperterm and you'll be all set.

Really, this isn't going to be that hard at all.  And just automating
this process will make you alot of friends down there in the lab.

Cheers,
John