Колеги,направихме едно устройство, което предава данни през GPRS, чрез TCP към WEB базирана услуга при възникване на определени събития .Използвали сме GSM модул на SIMCOM SIM900.
Имам следните въпроси:
1.Нужно ли е да създавам връзка през APN с User name и password ,след като модула се конектва и без APN и работи по същия начин .
2.Таксува ли се създаването на нова връзка,тъй като по необясними причини през МТЕЛ ми се затваря връзката след определено време ако не е изпращана информация.С карта на Vivatel този проблем със затваряне на връзката го няма,но пък там ми замотва пакетите и някой път времето за изпращане през което модула не реагира на никакви команди от контролера ми превишават таймаутите които са 20sec и това ми създава допълнителни проблеми.Това нормално ли е .С карта на Globul още не съм пробвал.Все пак става въпрос за предаване на 9 байта информация,а аз искам един път създадена връзка да не се затваря и времето за пращане на такава информация ,да не е толкова много, че понякога да ми превишава 20 секунди.Има ли някакви особености при използването на GPRS,които да избягват тези проблеми?
Предварително благодаря!

Не познавам модулите на SIMCOM и съответно стека им, но...

1. Щом работи еднакво, значи това става автоматично.
2. Доколкото знам - таксува се и то солено в сравнение с трафика от твоите 9 байта.
Виж си настройките на стека за ТСР. При ТСР, пакет се изпраща или когато размера на данните превиши определен обем или при изтичане на определен тайм-аут. Например, при дифолтните настройки на модулите на Телит, пакет ще се изпрати при натрупване на 300 байта. Ако изпратиш повече, те се цепят на пакети по 300.
Аз се отказах от TCP и преминах към UDP - пакета се изпраща веднага независимо от обема на данните.
Няма разкъсване на връзката, дори след спящ режим (без прекъсване на регистрацията в мрежата).
При по-дълга пауза, при следващ пакет се сменя само номера на порта.

При UDP нали пък доставката на пакета не е гарантирана, или аз греша нещо ??

UDP и TCP минават по един канал. Просто TCP праща непрекъснато, докато някой пакет не мине и след това отсрешното устройство почва да праща пакети докато някой отговор не мине. С UDP можеш да си емулираш TCP.

Точно това имахме за цел с TCP.Да има сигурно предаване на пакети,въпреки че трафика се редуцира при UDP.Aко наистина го има този проблем при ТCP с разкачането,ще трябва да се преориентираме към UDP,но трябва да се изисква отговор от сървъра ,че пакета е стигнал както казва ike.Но ако не стигне и отговора от сървъра ще се получи ,много лош омагьосан кръг и трябва firmware да се поизпипа доста .

Да, при UDP доставката не е гарантирана. Защото стека изпраща пакета и не чака потвърждение (на практика, не се губят пакети толкова често). При TCP, ако няма "ack" ще има "push" ...
А обвивката на пакет е 54 байта.
При UDP потвърждението ми е в протокола и не давам на стека да си прави каквото си иска (42 байта обвивка по жицата).

Ugeen, колко често се случват събитията, за които трябва да се уведомява.

Събитията може да са с през 1секунда до няколко или по-вече минути.Става дума за брояч на преминавания през входовете и изходите на търговски обекти.

Не мога точно даси го представя твоето приложение, но то май се е утепало за UDP. Предаваш периодично ( напр. 10 мин ), като предаваш освен текущите данни, и тези за по-стари периоди. От време на време сървърът ти връща пакет какво е чул, да не му повтаряш постоянно, щото е обидно.

Това със "замотването" на пакети заради карта на vivatel нещо не ми се вярва, защото ползвам точно такива карти и вградения TCP на модула, а не ми се набива на очи подобно държание. Има връзки продължаващи със седмици. След приключване на предаване, ако известно време (10-15 сек. примерно) нямам нови данни за предаване, питам модула има ли предадени данни за които не е получен acknowledge. Ползвам синтерион и куектел, но сигурно и симкома си има такава команда. Освен това ако дълго време няма данни за предаване пращам съобщение до нашия сървър да знае че съм жив и едновременно оператора да не ме разпада. Макар че vivatel не разпадат - утре може и да почне. В какво точно се състои 'замотването' - не получаваш отговор на няква АТ команда за определен период или нямаш acknowledge за изпратените данни? Замотаните данни всъщнос получени ли са отсреща?

И аз съм срещал проблем със "замотаване"

Ситуацията беше следната - при интензивна комуникация, някой пакет който виждам че се праща навреме от сървъра се "мота" някъде и се получава след около 20-на секунди от модема. От сървърната страна няма видим проблем, няма retry или друго. От страна на модема също не съм забелязал проблеми, поне съдейки по консумацията пакета се получава наистина след закъснението...

Изобщо по всичко изглеждаше, че мотането е в мрежата на самия оператор и няма нищо общо нито със сървъра нито с модема.

Решението беше да намаля скоростта. При някои модеми има възможност да се контролира GPRS класа (т.е. броя на слотовете). При телит това зависеше от скоростта с която се отваря UART-a. При скорост до 28400 няма проблем, т.е. прехвърлям стотици мегабайти без никакъв таймоут. И общо взето си поддържа скоростта.
Надхвърля ли я тая скорост обаче, може след 10к, може след 100к, но в рамките на един мегабайт задължително един пакет някъде се забавяше...

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

Миро, каква е тази скорост 28400 ? Да не е 38400 ?

аъъ... сега погледнах сорса - 19,200 е

Но по спомени го тествахме на всякакви стандартни и нестандартни стойности. И бачкаше до 28 и нещо си, най-вероятно ша да е било 28800 (=14,400 * 2). Но може и да бъркам (тва беше преди 2 години)

Замотването се състои в следното:В началото конектвам към сървъра докато модула върне CONNECT OK.След това преди всяко пращане проверявам статуса на връзката с командата AT+CIPSTATUS.Ако модула отговори че е свързан ,изпращам данните.Това което ми прави впечатление е ,че в началото си праща безпроблемно към минута и от там нататък започва да се мота.Контролера му подава данните
за изпращане,модула започва да изпраща ,но отговора SEND OK идва след много време .Примерно след 20сек.През времето когато праща ,модула е абсолютно,неадекватен .Не приема нищо през UART-а.Понякога SEND OK не идва изобщо.Тогава се налага да рестартирам и пак отначало.Когато го оставя без да праща ,няколко минути,при чекване на статуса показва CLOSED.А след още 10-тина минути ,показва +PDP DEACT(изключва се GPRS). В документацията пише ако е CLOSED или PDP DEACT ,да се отваря отново connection с командата AT+CHIPSTART.Това изобщо не ми изнася,или пък да пращам постоянно ,за да не умира връзката.Пробвах и с UDP.Там проблема с пращането ,го няма(винаги си дава SEND OK на момента,което в документацията за разлика от ТСР пише ,че съвсем не значи ,че пакета е стигнал) но след определено време се деактивира GPRS-a,както и при TCP връзката.Много ненадежден ми се вижда този GPRS. Заради тези неща 70% от firmware са само проверки за различните статуси на модула и вземане на решения как да се постъпи.И въпреки това все ,нови и нови изненади.

Проблемът не е в GPRS или в нашите оператори.
Най-вероятно е в модула или неговите настройки или ниво на сигнала или натоварване на мрежата.
Не забравяй, че GPRS е трети по приоритет след Voice и SMS.

Пробвай UDP но с потвърждение от Сървъра.
При мен работи перфектно.

Здравей,
Виждам, че симком е доста подобен на куектел. Пишеш, че при пращане получаваш "SEND OK", но не споменаваш нищо за "SEND FAIL".
Чакаш ли такъв стринг за неуспех и въобще имаш ли видимост какво точно и кога пристига от модула. Да не би модула да ти казва "SEND FAIL", а твоя софт да не обработва тази ситуация? С куектела при по активен обмен, на всеки 5-6 "SEND OK" се появява "SEND FAIL", чакам няколко стотин милисекунди и пробвам пак. Освен това през USB мога (ако го разреша) да наблюдавам цялата комуникация за/от GSM и там разни други неща. По този начин хаванах много непредвидени предварително ситуации със модула.