Дмитрий Анисимов написал top:
"Но если от Вас и дальше будут следовать уничижительные высказывания о других разработчиках-производителях - я Вас отключу"

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

А для top скажу, как бывший разработчик, что в какой-то момент любому разработчику после погружения в проблему кажется, что он может всё-всё объяснить - и так до того момента, пока не появляется факт, который, так сказать, не укладывается. Тогда опять начинаешь извилины разминать.
Спасибо и Вам, и, конечно, Дмитрию за очень интересную ветку.

Хорошо бы копенгагенам в этом деле в связи с актуальностью и насущностью вопроса лекцию тиснуть в "Школу Теплопункта" на эту тему (некоторые разъяснения и Дмитрия, и top прям-таки готовые абзацы из неё). Чтобы без ненужного наукообразия (и эскапад, конечно), но технически корректно и с пользой. Можете совместную написать, или по разделам распределиться - народ вам спасибо только скажет.

top написал:

[q]

Скорость выше

[/q]

В моем случае скорость 19200 и для коммуникатора, и для модема.


top написал:

[q]

буфер стека

[/q]

Не знаю, каков буфер у коммуникатора, а для модема я поставил настройку "0", т.е. данные передаются в канал без буферизации в темпе поступления на порт модема.


top написал:

[q]

А многие вычислители в принципе не имеют управлять потоком (нет CTS RTS)

[/q]

КАРАТ-307 точно не умеет - у него интерфейс RS-485.


top написал:

[q]

А если он сделан на OpenAT

[/q]

Используем модемы Maestro 100evo на OpenAT - с ними никаких проблем пока не обнаружено.

Так что, видимо, не в буферах счастье.

top написал:

[q]

Причём тут это ?

[/q]

При том, что выше Вы написали


top написал:

[q]

Дмитрий написал о том, что Robastel по ощущениям лучше работает. Он и должен работать лучше. У него выше класс. Скорость выше...

[/q]

А я говорю: в данном случае "скорость у него не выше".


top написал:

[q]

А куда она делась? Физически вы никакими настройками от буфера не избавитесь.

[/q]

В Open AT размер буфера задается командой. Если указан размер от 1 байта до максимума (по поводу 120 байт я не в курсе, надо будет уточнить), то данные в канал отправляются после заполнения буфера. Если указать размер "0", то данные будут отправляться без предварительной буферизации: байт пришел в модем и тут же ушел из модема.


top написал:

[q]

Интерфейс интерфейсу рознь... Можно ведь и управление потоком передавать через 485 используя ещё 4 провода.

[/q]

На этом беседу можно закончить.

Дмитрий Анисимов написал:

[q]

В Open AT размер буфера задается командой. Если указан размер от 1 байта до максимума (по поводу 120 байт я не в курсе, надо будет уточнить), то данные в канал отправляются после заполнения буфера. Если указать размер "0", то данные будут отправляться без предварительной буферизации: байт пришел в модем и тут же ушел из модема.

[/q]

Вот здесь я ошибся, каюсь: при настройке "не ноль" данные из буфера уходят по достижении заданного кол-ва байт, а при настройке "0" - по тайм-ауту (если задан), по длине пакета (если задана), по разделителю пакетов (если предусмотрен) или (вероятно) при "физическом" заполнении буфера.

А теперь по поводу всего остального. top работает в фирме, которая предлагает системы сбора данных, основанные на применении собственных устройств. Поэтому во всех своих сообщениях top пытается убедить читателей в том, что "стандартные" модемы не приспособлены для работы в сетях GSM, а устройства других ("не top") разработчиков - это вообще откровенный хлам. Парадокс: производители, выпускающие и продающие свои модемы десятками и сотнями тысяч штук не в курсе, что эти модемы ни на что не годны?

top пишет, что буфер в N байт в модеме - это очень и очень мало, а без аппаратного управления потоком (RTS-CTS) работать невозможно в принципе. Так ли это? Давайте вспомним, почему и для чего были придуманы линии RTS, CTS в интерфейсе RS-232 (выделяю название интерфейса, т.к. это важно).

RS232 был разработан для связи между терминалом и устройством передачи данных. В роли терминала обычно выступал (и выступает) компьютер, в роли устройства передачи данных - модем. В 1962 году (год появления первой версии RS232) передача данных модемом по телефонной линии была и еще долго оставалась очень медленным по сравнению с передачей данных между компьютером и модемом процессом. Понятно, что если компьютер "толкает" в модем данные со скоростью, например, 19200 бит в секунду, а модем способен передавать эти данные в линию (т.е. другому модему) со скоростью только, например, 2400 бит в секунду, в модеме должен быть буфер, и модем должен уметь сообщать компьютеру, что буфер заполнен, и нужно подождать. И процесс передачи данных в этом случае происходит так: компьютер на скорости 19200 забивает "порцию" данных в буфер модема и ждет, когда модем сообщит ему, что буфер освободился (данные "медленно" ушли в линию), после чего "быстро" записывает в модем новую порцию данных и т.д.

Сигнализировать компьютеру о заполнении буфера можно по-разному. Например, можно отправить какой-нибудь специальный код по тем же линиям, по которым идет обмен между компьютером и модемом. Но при общей тогдашней "слабости" вычислительной техники это было бы долго и ненадежно. Проще воспользоваться некой дополнительной (не занятой в передаче данных) линией, выставляя на ней сигнал "нуля" или "единицы". Поэтому в интерфейсе RS232 и появились линии RTS (Ready To Send - терминал сообщает, что готов передавать данные) и CTS (Clear To Send - модем сообщает, что тоже готов ("чист", "открыт", т.е. можно передавать).

А вот в стандарте RS-485 этих линий никогда не было, т.к. это стандарт связи между "равными" устройствами по общей двупроводной шине. Вообще RS-485 регламентирует только электрические параметры и не описывает (в отличие от RS-232) разъемы / контакты / дополнительные линии.


Вернемся к нашим модемам. С течением времени росли и скорости передачи и вычислительные возможности устройств (причем не только терминальных, но и передающих). Поэтому от аппаратного управления потоком и, соответственно, от использования линий RTS / CTS в RS-232 стали отказываться. И это не помешало модемам работать. Вы ведь не сомневаетесь, что USB-модемы работают нормально, хотя они никаких RTS / CTS не знают в принципе? Тогда почему вы сомневаетесь, что модем с RS-232 без RTS / CTS не сможет работать или будет работать плохо?

Но top пишет, что:

[q]

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

[/q]

И вот тут он прав! Да, производители модулей ДЕЛАЮТ, а производители модемов РАЗРЕШАЮТ НЕ ИСПОЛЬЗОВАТЬ, для чего и придуманы AT-команды игнорирования этих сигналов. И мы не используем (а с RS-485 это и в принципе невозможно), потому что в нашем случае скорость "потока информации" многократно ниже "скорости передачи в эфир"! В предыдущих сообщениях я специально дважды подчеркнул - в описываемой в данной теме ситуации скорость передачи "вычислитель - модем" составляет всего 19200 бит/c. А когда мы работаем с Эльфами - так и вообще 4800. Т.е. модем, даже несмотря на все типичные для GPRS задержки передает данные "влет", и его буфер при этом освобождается раньше, чем вычислитель успевает его заполнить.

Поэтому ни размер буфера, ни отсутствие линий RTS / CTS, ни скорости передачи в нашем случае теоретически влиять на работоспособность модемов, коммуникаторов и т.п. не должны. Я в этой теме описал недостатки каратовских коммуникаторов, выявленные как бы "до связи": коммуникаторы зависают в непонятном состоянии и не могут (в этом состоянии) выйти на связь (зарегистрироваться в сети, соединиться с сервером), коммуникаторы "сбиваются с расписания" выходов на связь и т.п. Модем Robustel не зависает и всегда выходит на связь по расписанию, т.к. в нем, очевидно, лучше продуманы алгоритмы обработки всевозможных внештатных ситуаций. Но об этом я напишу позже в теме про этот модем. Сравнение логов обмена с модемом и с коммуникатором, стоявшим на том же объекте до модема, показывает, что коммуникатор время от времени переставал выходить на связь (оживал только по СМС-команде), а при выходе на связь часто просто вообще не отвечал на запросы сервера. Т.е. не посылал в ответ ни байта. Почему? - думаю, в моих условиях (коммерческие узлы, да еще и очень далеко от меня расположенные) разобраться в этом сложно, а в "лаборатории" ситуация не воспроизводится.

В реальности существуют только 2 вида телеметрии:
1)
Ч1<-любой интерфейс->Ч2<-GSM|GPRS->Ч3<-оборудование БС->Ч4<-internet->Ч5
сравнивать проще на людях ))))
Ч1 - человек 1 - источник информации.
Ч2 - человек 2 - передающий информацию с помозью радиостанции
Ч3 и Ч4 - имитируют оборудование БС( базовых станций оператора)
Ч5 - принимающая сторона
Главный НЮАНС: Ч3 и Ч4 ОБЯЗАТЕЛЬНО И ВСЕГДА отдают предпочтение реальному общению ( голосу, CSD) , а не работе с радиостанцией.
В случае с прозрачным каналом скорость передачи и качество передачи определяется самым слабым звеном.
В данном случае это GPRS. Даже если на модеме написано до 170 Кбод - это не так. ДО - не значит, что это реальная скорость.
РЕальную скорость определяет - захочет ли человек 3 и 4 работать с вами и как много времени они готовы вам уделять. При этом они не предупреждают никого, они просто не слышат вас, а вам не приходит подтверждение сервера.
Человек 1 может бесконечно долго передавать информацию через Ч2, чтобы тот передал её Ч3, но он не слышит подтверждение и хранит эту информацию в голове на определённый объём ( который нельзя увеличить), по превышению которого данные теряются.
Дмитрий, вы наивно полагаете, что скорость передачи Ч1 - Ч5 определяется скоростью последовательной передачи от Ч1 к Ч3 - но это же бред. Теоретически и особенно практически
Если человек Ч1 не слышит/не слушает Ч2 , что изза плохих метеоусловий , Ч3 и Ч4 могут принимать данные только со скоростью 30 , а не 100 слов в минуту, то Ч5 многократно будет давать новые запросы по каналу( о чём вы выше свидетельствовали) . В итоге скорость передачи упадёт пропорционально кол-ву запросов на каждый пакет. В итоге эффективная скорость может упать и до 10 слов в минуту, вместо выдаваемых 30. Пропорционально вырастает и трафик, который надо оплачивать.

2) Способ реализации второй ( который вы назвали "собственное оборудование").
Сначала Ч1 надиктовывает в блокнот для Ч2 с низкой , устойчивой к помехам или ограниченной производителем, скоростью , после чего Ч2 выдаёт Ч3 эти данные настолько быстро, насколько данные подтверждения приёма приходят от Ч5. При этом исключается куче запросов, которые отвлекают Ч1 ( в приближении к тепловычислителю - садят его батарею).

ЗЫ И дело тут не в регламенте, не в "производитель разрешил", "Интерфейс позволяет" - а в реальности.