[Oberon] monitoring an RS-232 interface.

[eas-lab at absamail.co.za]

André Fischer wrote:
> Here is a Bluebottle module for tracing. The Bluebottle machine is an
> observer inserted between another machine and the device it is 
> supposed to control, for example a box recognizing AT commands.
> Bluebottle is totally transparent.
> It should run on the the latest version of Bluebottle which has the new
> AosV24.Mod - Comments are found at the end of the source:
> "In Bluebottle, the generalization of the serial port support lead to the 
> following adjustments" etc.

What's happeing to this project ?
I think that looking before the 'output wires' has limited value.
But being able to see what is realy happening on the 'wires'
makes for a valuable instrument.  Which is confirmed by these
posts:

eas-lab at absamail.co.za writes:
> >After I get an unintended disconnect during or after ppp negotiation,
> >the next time I try to dial, I see the modem lights respond but I can't
> >get dial tone.  Powering the modem off/on does not solve it.
> >
> 
> Greg wrote:
> Time to connect an RS232 line analyzer and see what commands are
> being sent to the modem and what the modem's responses are.
> 
> I think you'll find that the proper AT commands are being sent to
> dial the modem, and the modem is echoing the characters in the AT
> command, but the modem is not performing the action in the command
> (i.e., going off-hook and dialing the phone number).
> 
> This is usually because the modem has not recognized the characters
> as forming an AT command.  Usually due to a speed mismatch:  the modem
> is listening for AT commands exclusively at one speed, but the computer
> is sending them at a different speed.  Sometimes due to a parity mis-
> match:  the computer is sending the Return character at the end of the
> command string, but with parity enabled, so it looks to the modem like
> a graphics character instead of a Return.
> 
> As for the "leaves the port in a funny state", you're probably starting
> at too low of a level.  It's far more likely the instance of the serial
> driver which controls the port is in a funny state.  The driver software,
> not the hardware, is in a funny state.  (though it allowed your process
> to open the port, apply ioctls, and read/write data)
> 
> When you don't get the expected response from the modem, you must start
> troubleshooting at the modem interface.  I.e. check the data that the
> modem sees over the RS232 cable.  Then use what you learn there to move
> your troubleshooting in the direction of the modem or in the direction
> of the computer.

I think I looked at Aos* sources, and judged the cost/benefit as failing
my requirement.
 
Chris Glur