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

[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 ( в приближении к тепловычислителю - садят его батарею).

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

top написал:

[q]

RS485 это просто помехоустойчивый интерфейс. Он не может ничего регламентировать. Это бред.
Вы можете по нему пустить весь набор сигналов RS232.

[/q]

Класс!


top написал:

[q]

USB модемы очень даже "знают" сигналы RTS|CTS

[/q]

Супер!


top написал:

[q]

Это просто некультурно.

[/q]

Буду учиться культуре у Вас.

top написал:

[q]

2 штуки MAX488 и витая пара реализуют Rx, Tx,RTS,CTS в 485 интерфейсе.

[/q]

Повторю, что RS485 - это стандарт (RS = Recommended Standard), регламентирующий электрические хар-ки приемников и передатчиков в многоточечных линиях связи (системах передачи данных). Собственно, он именно так и называется: Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint Systems. Устройства с интерфейсом, выполненным по стандарту RS-485, подключаются к общей шине "двумя проводами". Устройств в сети может быть до 256 штук. Все устройства с т.з. передачи данных "равноправны". Эти две причины (множество взаимодействующих устройств + их "равноправие") делают бессмысленным и затруднительным использование каких бы то ни было дополнительных сигнальных линий: для этого мы должны были бы от каждого устройства к каждому другому устройству протянуть еще по два провода. Т.е. каждое устройство должно было бы быть подключено парой проводов к общей шине данных, плюс от него должно было бы отходить до 255 пар проводов к "соседям".

Конечно, для двухточечного соединения "модем с RS-485 - вычислитель с RS-485", являющегося частным случаем соединения многоточечного, можно реализовать любые дополнительные линии. Но называть получившийся интерфейс интерфейсом RS-485 будет нельзя. Кроме того, RS-485 в наших применениях ценен тем, что позволяет использовать один модем на группу вычислителей. И, что, мы тогда от каждого вычислителя протянем к этому модему свои RTS / CTS?


top написал:

[q]

Вы сомневаетесь, что в USB есть flowcontrol потока данных?

[/q]

Ни капли не сомневаюсь, потому что точно знаю: USB (2.0) - это две пары проводов, одна из которых используется для передачи данных, вторая - для питания хостом периферийных устройств. Никаких дополнительных линий в USB нет. Возможно, Вы путаете аппаратное управление потоком с программным. Но программное управление не зависит от типа интерфейса, осуществляется по линиям данных и не требует дополнительных линий RTS / CTS.

top написал:

[q]

всё это понятно, а обсуждаем мы сейчас сферического коня

[/q]

К обсуждению этого коня перешли Вы. Я в этой теме спокойно рассказывал о своем опыте работы с коммуникаторами КАРАТ. Напомню, у меня их оказалось 39 штук, с ходу нормально заработали только 19, остальные зависали, не выходили на связь или выходили, но не отвечали на запросы сервера (вообще не отвечали, ни байта). Последнее, кстати, теоретически может быть проблемой не (или не только) коммуникатора, но и самого вычислителя. Несколько коммуникаторов начали работать после того, как я свозил их в "КАРАТ", хотя в "КАРАТе" говорят, что ничего с ними не делали. Остальные коммуникаторы заработали после замены антенн или изменения положения штатных антенн. Модем Robustel, поставленный вместо одного из коммуникаторов, при неизменных внешних условиях сразу вышел на связь и с тех пор выходит по расписанию, без сбоев. В итоге на сегодня у меня только один неопрашиваемый узел - на нем мне ПОКА не удалось добиться приемлемого уровня сигнала. Плюс на одном узле не работает порт КАРАТа-307, это выявлено точно.

Так вот, не обвиняя разработчиков ни в жадности, ни в глупости, и не претендуя на раскрытие истинных причин проблем с коммуникаторами, я сделал простой практический вывод:

"Так вот, теперь опыт есть (гоняю коммуникаторы с августа), и я честно говорю: если вам нужно "диспетчеризировать" КАРАТ-307, не покупайте коммуникатор, купите Robustel. С сопряжением - никаких проблем, все настройки - через удобную и понятную программку. Единственное, что потеряете - это возможность видеть на дисплее 307го информацию об операторе, балансе и уровне сигнала. Но диспетчеризацию мы делаем не для того, чтобы приходить и смотреть на дисплей теплосчетчика, не правда ли?

А коммуникатор, я думаю, будет иметь смысл брать, если будет доработано его резидентное ПО (обеспечена эффективная защита от зависаний и "невыходов" на связь) и раза хотя бы в 2 снижена цена."

На этом я свой рассказ закончил. Но пришли Вы и со всей пролетарской прямотой заявили: ПО модулей пишут "индийские программеры", КАРАТовцы зажали пару баксов, и именно поэтому, а также потому, что мал буфер и не используются (в интерфейсе RS-485) линии RTS / CTS, коммуникаторы и "виснут". Ну, и не преминули вставить пару добрых слов о своих устройствах, всегда передающих данные без потерь. Это ведь так и было? - или это вновь мои домыслы, а Вы ничего такого не писали?

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

Поэтому данную тему я закрываю - она себя исчерпала, т.к. непосредственно про коммуникаторы КАРАТ ни Вы, ни я ничего нового добавить здесь пока не сможем, а других лиц, желающих рассказать о своем опыте работы с данными коммуникаторами, за три месяца существования темы так и не обнаружилось.

Если Вы желаете поделиться своим опытом обнаружения линий CTS и RTS в USB или поведать о том, как добавить эти линии к интерфейсу RS-485 - откройте отдельную тему или темы. А относительно тона Ваших высказываний я уже предупреждал Вас выше. Предупреждал не как участник обсуждений, а как администратор этого форума.