Ткните носом в стандартный дизайн драйвера модема.
Нигде толком не могу найти.

Я то сваял свою "конструкцию" уже давно и она даже работает, но как-бы всё не покидает меня мысль, что сделал я это криво...


К примеру моя реализация заточена под то, что по каналу гоняется сырец и строки типа \n\rNO CARRIER \n\r никогда не встречаются в потоке.
А вот сейчас задумался: а как нормальные люди делают? Первое, что приходит в голову: таймером измерить время и если после \n\rNO CARRIER \n\r ничего не пришло на протяжении нескольких секунд - считать соединение разорванным...Однако если передаваемые данные были таковыми, что строка NO CARRIER просто являлась последним передаваемым сообщением, а сообщения передавалсь с интервалами 5сек., то драйвер ошибется и подумает, что модем разорвал коннект....
Ну в общем всё такое, вокруг да около ))))

Да да, забыл. Поправка на то, что используется только Tx и Rx пины порта.

Думается мне, что это уже шаманство и реально толково ничего сделать не удастся, правильно я понимаю?

...модема чего? x25 ePCI 4 Linux или tty через телефонную линию 2.4 kbps с импульсным номеронабирателем?

Когда-то на форуме кидали исходник софтмодема... "поиск" в помощь ...

А какая разница? главное AT команды и UART интерфейс.
Цепляется это дело к контроллеру, никакого линуха.

Я, чтобы с такой ерундой не заморачиваться, сделал максимально совместимый. Потом посто inf файл написал. Это ещё на win98 было. Так даже на Win7 работает.
Если железо твоё, то какие поблемы - сымитируй все команды- ответы.

И причём здесь в потоке NO CARRIER. Пусть будет. Модему это по-барабану. Он выходит из состояния connect по "+++" переданных пауза +++ пауза. Всё расписано в регистрах модема.

Не после, а до. Пауза будет до появления "NO CARRIER" и эта пауза не менее, чем Вы сами запрограммировали для времени детектирования потери несущей.

Не не, модем не мой!

Но от того модема только tx и rx выходят.
Связано это с тем, что изврат на изврате.....

Задав вот вопрос и сам понял, что по сути без отдельного аппаратного карриер детекта особо не разгонишься....

Да да, модему то пофиг. Но драйвер модема в моём случае следит за состоянием модема по его ответам. Т.е. в состоянии коннектед фильтруется какраз но карриер.
Поскольку ответы модема и данные идут по одному каналу - драйвер то не в силах различить от модема пришел но карриер или это в потоке данных встретилось... В этом я вижу проблему...
Т.е. драйвер модема неадекватно себя поведет и будет считать соединение разорванным, хотя оно таковым на самом деле не будет являться(правильно, модему то по-барабану).
Вот.

Теперь понятно.
Ну в общем то да. Обычно используется Carrier Detect и Data Terminal Ready. Как только модем снимает DTR происходит разрыв соединения. А по CD с некоторой паузой.

Хотя, всётаки на паузах можно сыграть. При разрыве соединения, модем выдержит паузу прежде чем выдаст No carrier. Можно попробовать это обработать.
А вообще надо требовать от поставщика оборудования элементарного соответствия документации. Задолбало! Сколько времени и здоровья уходит на борьбу с чужими косяками. Сейчас HART модем переписываю - потому что входной сигнал - прямоугольник, в нарушение всех спецификаций. В некоторых датчиках не следят за фазой и меняют частоту до 15%. Из-за этого пришлось всё переписать. И моделирую уже 2 недели. Психую.

Ну и что? Он управляется через AT? Этого достаточно.

Управляется то через AT, но есть только TX и RX. Я об этом)

Тут как-бы танцами с бубном эти TX и RX были найдены, так что ни о каком сотрудничестве с поставщиками оборудования речи быть не может )

Ну я понял в общем... Работает, и хорошо! Без сигналов Carrier Detect и Data Terminal Ready всё равно по уму не сделать как не крути

Как сделать - я написал. Перечитайте и ознакомьтесь с базовым набором AT команд, дабы узнать о программировании времени детектирования потери несущей да и о, например, софтовом flowcontrol. Te-же Apple на RS232 не имели ни CD ни RI... И ничего - жили.

Ага. Щас гляну, мож чё упустил.

Не, ну софтовый флоуконтрол вроде как не катит ибо и без того ширина канала едва удовлетворяет требованиям, а в случае его использования как минимум потребуется байт-стаффинг на служебные коды, что внесет некоторую избыточность....

ну flowcontrol поможет только с RTS/CTS и то при условии что они вообще нужны. Если скорость порта выше скорости модема, то управление потоком можно и опустить.
S10 - интервал потери несущей в 0.1 сек

Как это - управление потоком не нужно?
А как модем будет сообщать "у нас тут на линии помехи, подождите секунд n-цать" ?
Буфер у "самого обычного модема" небольшой, его переполнить несложно...

А xon/xoff, если я правильно помню - решение "бесплатное": полосу пропускания модема не ест (скорость порта, как правило, много выше), линий лишних не требует...