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