Hi all!

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

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

- - - - - -

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

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

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

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

- - - - - -

Yes, I may be confusing myself regarding "I/O device driver" versus "driver" for the sonde...  However, I'm pretty sure that all I need is a vanilla "RS232 device driver" that will "just work" for any number of "com" ports by allowing some vanilla terminal emulation package (preferably one that has scripting capabilities) to talk to multiple RS232 ports.  I could be wrong about this, in which case I may need to write some code, or perhaps the manufacturer might be thinking of supporting Linux.  I don't do the day-to-day instrumentation work, but I am supposed to worry about it none the less.  In terms of the "sondes going to sleep", this is based on concerns expressed by the lab along the lines of "if you hook-up the sonde and let it sit too long, you have to start over because it will turn itself off."  Also, I use the term "vanilla" a lot because the staff aren't computer types - this has to "just work" like any other tool in the lab.  Dear lord - we are talking about biology types after all!  ;-)    (Unlike engineering/geoscience types!!)

- - - - - -

So, the other question was about the necessity of having certain signals present.  Again, I'm told that the sonde needs all the signals present in a DB-9.  I'm guessing this may have more to do with not really knowing for sure and erring on the side of caution, but since there is hardware available that will do this and I can't spend all of my time chasing this down, I'll assume the information I'm getting on this topic is correct.  (Biologists not withstanding.)  I think this is where the multiport boards or a terminal server would come in...  One of the replies mentioned writing a script, and that is what I was thinking about...  Specifically, I was wondering if it could be as simple as a script sending the proper bit patterns to get the sonde to do the right things, pipe the serial data through the script and append the data to a file, and s on...  (Was that you, John?)

- - - - - - -

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

Thanks!  If you have any more thoughts, please let me know!!

Steve



On 5/21/07, Stephen C. Daukas < scd@daukas.com> wrote:


-------- Original Message --------
Subject: Re: [Wlug] Multiple RS232 Com Ports...
Date: Mon, 21 May 2007 15:44:09 -0400
From: John Stoffel <john@stoffel.org>
Reply-To: Worcester Linux Users Group <wlug@mail.wlug.org>
To: Worcester Linux Users Group <wlug@mail.wlug.org>
References: <4650752A.1020203@daukas.com> <18001.54171.525952.976484@stoffel.org> <20070521181244.GH4900@angus.ind.WPI.EDU> 


Chuck> On Mon, May 21, 2007 at 01:15:07PM -0400, John Stoffel wrote:
>> darn good things about the Cyclades stuff as well.  Stay away from the
>> Legacy Avocent (who bought Cyclades...) serial port stuff, it's crap.


Chuck> Hmm I have to disagree here.  We have the Avocent/Cyclades ACS line 
Chuck> and are very happy with them.  They run Linux inside and support many 
Chuck> connection protocols, like Telnet, SSH, Reverse Telnet, Bidirectional, 

Chuck> etc.  Full RTS/CTS control lines including DTR are available.  They 
Chuck> support console logging to RAM, PCMCIA flash card, or remote syslog.

Chuck> Perhaps you are referring to their older Cyclades TS line.


I'm talking about the old Avocent designed CPS line of crap.  You're
talking about the Cyclades designed stuff, including the TS and the
ACS.  

I've got an ancient Cyclom-Y ISA 8-port serial card in my main home

computer and it's been working great for for years.  Wish I could
afford the newer stuff.

John

_______________________________________________
Wlug mailing list

Wlug@mail.wlug.org
http://mail.wlug.org/mailman/listinfo/wlug