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@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