Интернет+AVR Опции

[Alex_1811]

Есть такая задача: нужно контролировать удаленное устройсто через интернет.
Планирую использовать в качестве модема GPRS Siemens 35 серии + AVR.
Вопрос такой, в каком направленни мне двигаться (протокол по проще, пример
сайта для контроля и т. д.)

[Glupen']

Не понятно, что подразумевается под словом "контролировать"?
Вы хотите управлять устройством? Или читать с него значения измерений? Какие задержки вас устраивают? Будете держать все время канал? Или поднимать только в случае необходимоти связи?

Техническое задание давайте. Тогда и поговорим.

[Alex_1811]

Не понятно, что подразумевается под словом "контролировать"?
Вы хотите управлять устройством? Или читать с него значения измерений? Какие задержки вас устраивают? Будете держать все время канал? Или поднимать только в случае необходимоти связи?

Техническое задание давайте. Тогда и поговорим.

Нужно читать и при необходимости управлять. Задержка не важна.
Связь будет в случаи необходимости.

[Glupen']

Варианты:
1. Прямой телефонный звонок, далее скрипучее модемное соединение и "говорите, что устройству делать, или сколько там на входе?"

2. SMS "Вкл. реле", AVR его разбирает/понимает, и делает "вкл. реле", и тут же в ответ дает SMS "реле есть вкл".
Или "Сколько на входе?", AVR думает, и отсылает "На входе 300".

3. Удаленное устройство держит поднятой GPRS-сессию, если валится, то тут же заново поднимает.
Тогда устройство имеет свой "адрес, порт" в сети Internet, и вы можете слать команды/запросы в этот порт.

Протокол... А что протокол... Шифрование от постороннего управления? Размер передаваемых данных в одну сторону, в другую... Тут я вообще ничего не знаю.

[Непомнящий Евген...]

3. Удаленное устройство держит поднятой GPRS-сессию, если валится, то тут же заново поднимает.
Тогда устройство имеет свой "адрес, порт" в сети Internet, и вы можете слать команды/запросы в этот порт.

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

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

Что касается протокола - то в простейшем случае можно просто пихать в tcp\ip свои собственные структуры, предваряя их полем типа и дополняя CRC.

[Glupen']

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

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

А я и не говорил, что это будет статический адрес.
У нас есть система телеметрии удаленных объектов на базе собственного сервера. По причине уменьшения задержек (например, авария на удаленном объекте) удаленный модуль держит все время поднятой GPRS-сессию. Как только она валится, модуль опять ее поднимает и стучится на сервер "вот он я, мой номер такой-то", сервер сидит новый "адрес" модуля с номером такой-то, и тут они начинают общаться.

[Alex_1811]

3. Удаленное устройство держит поднятой GPRS-сессию, если валится, то тут же заново поднимает.
Тогда устройство имеет свой "адрес, порт" в сети Internet, и вы можете слать команды/запросы в этот порт.

Надо этот вариант.

Алгоритм подключения такой:
1. Я звоню на номер удаленного устройства.
2. Устройство определит мой номер и сбросит вызов.
3. Через пару секунд оно подкючается к нету и далее обмен данными.

А управление надо сделать через сайт.

[Непомнящий Евген...]

Алгоритм подключения такой:
1. Я звоню на номер удаленного устройства.
2. Устройство определит мой номер и сбросит вызов.
3. Через пару секунд оно подкючается к нету и далее обмен данными.

А ваш номер ему зачем?

[Glupen']

Надо этот вариант.

Алгоритм подключения такой:
1. Я звоню на номер удаленного устройства.
2. Устройство определит мой номер и сбросит вызов.
3. Через пару секунд оно подкючается к нету и далее обмен данными.

А управление надо сделать через сайт.

Ну вот вы сами и ответили себе на все вопросы.

Мы так делали: кидали смс в модуль "забери прошивку", модуль лез на наш сервер, забирал файлик для него, сам перепрошивался, сбрасывался и работал с новой прошивкой.

А номер телефона, чтоб отсечь ложные звонки.

Сообщение отредактировал Glupen' - Jul 4 2008, 10:51

[_Ivan_33]

простите что вмешиваюсь:
а откуда у сименса 35 серии жопорез??? если использовать CSD - соединение то это дорого обойдется ... и мне кажется что оно уже отошло...

[AntonKr]

Я делал проще, но при этом использовал Siemens TC65 (писал на Java, но можно управлять и через AVR) :
1. Пользователь звонит на номер, модем его определяет и сбрасывает звонок
2. Поднимается соединение через GPRS и поднимается HTTP сервер
3. На телефон пользователя пересылает полученный IP и порт, который открыл. (необходимо включить услугу "IP адрес" иначе адреса будут недоступны, т.к. будут за NATом)
4. Пользователь заходит через инет по данному адресу и порту через браузер и работает с устройством.

[chds]

а откуда у сименса 35 серии жопорез??? если использовать CSD - соединение то это дорого обойдется ... и мне кажется что оно уже отошло...

Видимо имеется в виду модем MC35(i), там что то под названием GPRS есть

2 Alex_1811:
Как по мне на AVR поднимать TCP/IP соединение самостоятельно очень проблемная вещь, а проблемы использования встроенных в модемы стеков TCP/IP в этом форуме уже обсуждалось не раз.
Может проще (и как раз по силам AVR) обмениваться sms. Пмоему по 160 символов можно передавать запросто. Взять пакет с шаровыми sms и наслаждаться простотой и работающим устройством.

[defunct]

Как по мне на AVR поднимать TCP/IP соединение самостоятельно очень проблемная вещь,

Зато UDP/IP можно поднять хоть в секции бутлоадера. Чем недостаточно для обмена?

[Alex_1811]

Зато UDP/IP можно поднять хоть в секции бутлоадера. Чем недостаточно для обмена?

А можно про него подробнее.
Может есть пример реализации обмена?

[defunct]

А можно про него подробнее.

http://www.rfc.net/rfc768.html

Может есть пример реализации обмена?

тут есть пошаговый пример того что нужно сделать, правда для ethernet
http://www.astrosurf.com/cavadore/Ethernet...er/sources.html

[fmdost]

Зато UDP/IP можно поднять хоть в секции бутлоадера. Чем недостаточно для обмена?

А разве для GPRS он подойдёт?

[defunct]

А разве для GPRS он подойдёт?

А почему нет? Все что over IP подойдет.

Насчет "не гарантированности" доставки почитайте вторую ссылку. Гарантированность доставки (подтверждения и ретрансмиты) реализуется вручную и занимает гораздо меньше места чем реализация TCP.

[Rst7]

А почему нет? Все что over IP подойдет.

Ох не факт. Потому как неизвестно, есть ли NAT и, если есть, как он настроен.

[defunct]

Ох не факт. Потому как неизвестно, есть ли NAT и, если есть, как он настроен.

Какая разница есть NAT или нет.
1. NAT прозрачен.
2. NAT роутит IP.

UDP firewall'ом закрывать никто не будет, т.к. сильно много служб over UDP.

К тому же есть еще одна простая альтернатива - ICMP.

[Rst7]

NAT роутит IP.

Не совсем так. NAT меняет данные не только в IP-заголовке, но и в TCP, и в UDP (порты переставляет). Вот и не факт, включена ли работа с UDP, потому как, по большому счету, для банального www достаточно обработать UDP в виде DNR прямо на первом гейте, а пакеты UDP на другие порты сдропать для уменьшения траффика

Да и вообще, забобоны опсосов непредсказуемы. Например мой опсос закрыл стандартный порт FTP.

[defunct]

Вот и не факт, включена ли работа с UDP, потому как, по большому счету, для банального www

Обязана быть включенной, иначе как у вас будет работать DNS и соответственно весь www?

PS: из личного опыта - провайдеры UDP и ICMP пропускают.

[Rst7]

Обязана быть включенной, иначе как у вас будет работать DNS и соответственно весь www?

Я же объяснил, что из UDP обрабатывается только DNS, и то, прямо на гейте. Обычный случай:

MS(192.168.1.x)<->NAT_GATE(192.168.1.1)<->Internet

MS имеет (назначен ему при соединении к NAT_GATE) адрес DNS-сервера 192.168.1.1. Обычно в таком виде DNS транслируется отдельным каналом, не используя собственно NAT.

PS: из личного опыта - провайдеры UDP и ICMP пропускают.

Да спору нет. Хорошо, что пропускают. А могут и дропать, и претензий не предъявишь.

[defunct]

А могут и дропать, и претензий не предъявишь.

Если так рассуждать то и TCP могут дропать. И претензий не предъявишь.

У них нет причин дропать udp, т.к. VOIP не будет работать.

[Rst7]

У них нет причин дропать udp, т.к. VOIP не будет работать.

Ага, а с другой стороны, например, Лайф на Украине не за NAT'ом тебя держит, а дает адрес из пула нормальных белых IP. Вот только порт FTP зафайерволен. А так - все классно, DynDNS - и ты сервер

Но я же не кричу о том утверждаю, что NAT невозможен Возможен, но могут и дропать UDP не к DNS, поэтому я бы пользовал исключительно TCP.

[Kovrov]

Ребят сорри немного не в тему
а тут W5100 чето подешевели брал недавно ~140 руб/шт
кстати неплохая тема... и парится совсем не надо..

[Rst7]

кстати неплохая тема... и парится совсем не надо..

А нафига оно автору темы? Лишний камень?

[Alex_1811]

А реально ли реализовать обмен с помощью ICQ сервер, срузу бы отпала проблема с опредилением IP адреса.

[zltigo]

Ага, а с другой стороны, например, Лайф на Украине не за NAT'ом тебя держит...

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

[Rst7]

нехай всякий мусорный трафик сыпется извне на пользователя

Да сколько его там, фигня... Зато белый IP.

А реально ли реализовать обмен с помощью ICQ сервер, срузу бы отпала проблема с опредилением IP адреса.

Можно, но геморойно. И есть еще одна проблема - если поменяют протокол, то Вам все девайсы перешивать надо будет. Так что это плохой план. Лучше уж жабер тогда. А еще лучше свой собственный сервер, сейчас VDS копейки стоит...