Сообщений в теме: 11

[Андрей Мартыненко]

Всем привет!!!
Можно ли заменить  null modem кабель GPRS модемом

[Sergiy Lapin]

Немного подробнее пожалуйста. Можно заменить городской телефон на спутниковый. Технически никаких проблем нет.

[Андрей Мартыненко]

GPRS телеметрия и удаленного устройства есть только COM. Могу ли я управлять и получать данные скажем с АЦП подключив его по RS-232 к GPRS модему. Максимальныя скорость данных 19200.

[Dmitri Kazakov]

Андрей Мартыненко сказал:

GPRS телеметрия и удаленного устройства есть только COM. Могу ли я управлять и получать данные скажем с АЦП подключив его по RS-232 к GPRS модему. Максимальныя скорость данных 19200.

Теоретически можно. Практически - думаю что не получится.
Практический путь что я могу предолжить для поверхостных экспериментов. В интернете я пару раз видел прогу com via IP - можно погуглить. Провести експеримент - поставить комп с этой прогой, к нему подключить GPRS модем и АЦП. на другом компе поставить прогу и подключить дата анализирующий софт. Поиграться.
Потом программу с com-IP можно убрать и попытаться установить связь между модемами непосредственно. (я не работал с GPRS модемами но я уверен что у них стандартная AT система команд с расширениями)

Проблема может возникнуть в том что АЦП ето, вероятно, не просто АЦП - ето целое устройство с АЦП, микропроцессором и контроллером и сом интерфейсом. Для процессора написан софт с учетом serial communication (скорее всего RS232) специфики. Там очень поверхостно могут обрабатывабтся задержки потому что больших задержек не ожидается и обмен может происходить в виде диалога побайтово. В реальной GPRS или интернет коммуникации могут быть относительно больше задержки и выпадения (потери). Это требует принятия особенных мер.

Это все мое личное мнение (IMHO).

[Sergiy Lapin]

Ну не вижу противопоказаний. Мы таким способом опрашиваем удаленные терминалы. Исползуется Soekris SBC + EVDO PC-Card. На борде бежит мааааленький Linux собственного розлива

[Dmitri Kazakov]

Sergiy Lapin сказал:

мааааленький Linux собственного розлива

Я упустил ето решение из виду. Согласен с предидушим оратором. Перепишите код на АЦП модуле и будет вам шастье

[Sergiy Lapin]

Ничего переписывать не нужно, Этот Линух выступает в роли терминального адаптора, как раз и занимается вопросами буферизации, побайтового обмена и восстановлением потеряных пакетов. Подклучен к COM порту оборудования которое мы мониторим. Цена решения около $120 + $15 абонплата за телеметрический план от мобильного оператора

[Dmitri Kazakov]

Sergiy Lapin сказал:

Ничего переписывать не нужно, Этот Линух выступает в роли терминального адаптора, как раз и занимается вопросами буферизации, побайтового обмена и восстановлением потеряных пакетов. Подклучен к COM порту оборудования которое мы мониторим. Цена решения около $120 + $15 абонплата за телеметрический план от мобильного оператора

Постейший сценарий. Протокол работает с эхом. При етом клиент ожидает эхо от АЦП. Время ожидания эха перед выдачей ошибки ограничено АЦП софтом (и, вполне вероятно, АЦП - от клиента). А тут потеря пакета или задержка. Перезапрос туда-сюда линуксом. Время вышло - АЦП выдает Timeout ERROR.
Или заменим эхо CRC. Сценарий тот-же. Хотим рассчитать и сравнить CRC а последний байтик задержался долше ожидаемого. Опять ERROR. Никакой линух не поможет. Все определяется допустимым временем ожидания ответа. Если система заточена под нуль-модем где ожидание в расчет не принимается так как задержки обычно определяются миллисекундами - будет ошибка. Хорошо если она обрабатывается встроенным протоколом. А если нет - тогда ничего не получится.

Следуя вашей логике и линукс не нужен - современные модемные протоколы имеют встроенную корекцию. Только вот не в ней дело а в возможных задержках...

Я вроде об этом писал выше...

Однозначного ответа нет - надо либо читать документацию либо экспериментировать. Все зависит от конкретного дизайна пары АЦП-клиент.

Впрочем, чем мог - я помог. Вступать в полемику нет времени и желания. Наличие потенциальной проблемы для меня очевидно. Удачи в экспериментах.

[Sergiy Lapin]

А я бы не стал искать проблему там где ее может и не быть. Будет проблема, будем решать. К примеру можно часть клиента вынести на Линукс (будем называть его так), который будет реализовывать критическую ко времени часть протокола. Конечно закладываться на самый худший вариант это хорошо, но если в 98% случаев задачу можно решить за $100 и оставшиеся 2% за 1,000,000 это не значит что нужно строить решение за 1,000,000 для всех 100%

[Андрей Мартыненко]

Спасибо, за ответы.
Пробовал АЦП с SBC ELF3 (Linux) и парой радио модемов - проблем нет. При обрыве связи просто теряются данные, при восстановлении эта штука работает дальше. Шастье уже почти наступило, но осталось разобраться как Linux ELFa будет управлять GPRS модем и где вообще потом искать данные.
Ессли кто сталкивался – какие реальные скорости UP LOAD GPRS??? Данные собираются с небольшой скоростью но постоянно.
И еще немного не по теме, что такое Power Consumption As low as? Например на сайте http://www.inhand.com/elf.asp написано, что ELF3 жрет as low as 350mW. Я меряю с их предустановленным Linux, ничего не запускаю и ничего не вставляю – получаю 1,2W. Может кто встречал SBC с реальным потреблением меньше 0,5W. Минимальная конфигурация – CF или SD card socket, 3 COM, USB. Буду очень благодарен за любую информацию.

[Sergiy Lapin]

Ну as low значит как мининум, а максимум никто не обозначил Кроме того они не указали условия измерения, так что спрашивать не с кого. В нашем случае усползуется стандартный драйвер PC карточек, а дальше ppp скрипт и потом получаем IP от провайдера, поднимаем IPSEC, и делаем что хотим. В случае потери связи данные буферизируются в RAM самого SBC в tmpfs, если переполняется, то данные теряются, но в наших условиях такого небыло, запас хода на пару дней.

[Sergiy Lapin]

Да, мы имеем стационарное питание, так что даже не меряли