|
|
|
|
|
|
by raggles
1314 days ago
|
|
|
I like it too, but as a comms engineer working in electrical substations I have encountered many, many situations where it didn't just work, rs485/22 too. Issues with inter-chatacter delay, timing of control signals, different earth potentials, electrical interference, mangling of signals when going through multiplexers or media converters are common. Now that everything is fibre Ethernet my commissioning times are waaaay faster. |
|
|
As I recall, there was a 1990s Macintosh where the serial port used a proprietary connector (of course) with fewer pins, so Apple decided to double up and use one pin for both Data Terminal Ready (DTR) and Clear to Send (CTS). (Or we had cables that connected two pins?)
Many modems would hang up if you dropped DTR. Enabling this is a good practice to prevent the modem from accidentally staying connected after you're done.
Enabling hardware flow control is also a good practice. If the Mac can tell the sender to wait for a moment, that's better than dropping data.
Perhaps you can see where this is going. If you enable both of these, everything appears to work fine for a while. That is, until the Mac falls behind (scrolling a lot in a terminal window, for example) and needs to actually use hardware flow control. Then, rather than pausing the flow of data, it hangs up the modem.
And your first thought when a modem hangs up out of nowhere is that it's a modem issue: noise on the phone line, a bad modem implementation, an incompatibility between two different modems, etc. So you waste time looking at those as causes.
The solution was to either disable hardware flow control or to configure the modem to ignore DTR and use +++ ATH to hang up instead. Disabling hardware flow control makes PPP (etc.) perform horribly because packets get corrupted and re-sent. And this is another deceptive problem because the modem speed appears to have plummeted but actually the modem is working fine.