Значи постановката е следната - отварям един сокет и ескейп излизам и отварям втори сокет и след това повече не мога да изляза в команден режим. Плюсовете дето подавам за ескейпване се получават на сървъра

За съжаление ми се налага да държа повече от един отворен сокет. Знам че решението е CMUX ама не ми се пренаписва всичко сега.

Иначе проблемите всъшност са повече (но ги заобикалям при 1 сокет)
1) AT&D1 и след това клатене на DTR - не бачка избщо... нито на един, нито при два сокета. Нямам идея защо не бачка, но затова ползвам "+++".
2) Всъщност ползвам "+++\r\n" защото "+++" не бачка, въпреки че спазвам времената и го пращам след няколко секунди тишина и след това чакам, ама колкото и да чакам не излиза от оналайн режим докато не пратя enter, или поне не излизаше всеки път.

При мен на 862 работят всичките тези неща без никакъв проблем, точно както са си описани в дейташита. Явно нещо не правиш както трябва или пък ако е на друг модул може и да имат разлики .
Аз обаче имам само един сокет в даден момент.

Пробвам на:


утре мога да изпробвам и други модификации на 864, ама то така или иначе ми трябва код за всички *864ххх


Иначе не знам какво пропускам, но логът ми е следия:




Нищо особено... отварям един сокет, прекъсвам го, отварям втори (към същото IP&port) и до там.
бтв, в лога се вижда още един проблем - при отворяне на сокета първо виждам промяна на DCD пина и после CONNECT-а, т.е. лъже ме че са данни. Това не е проблем, щото аз не очаквам данни и мога лесно да го "флъшна". А още по-странно е че понякога (макар и рядко) тоя конект го получавам едва след като се върна в АТ-командите, явно не винаги успява да го изпрати.

Аз слушам за "NO CARRIER" и "+++" и в данните и в АТ командите, т.е независимо от състоянието на DCD линията. Иначе преди и при мен ставаше прекъсването с +++ от 2-я - 3-я път, но сега няма грижи. При мен последователността на командите е следната:
AT+CGDCONТ
AT#USERID
AT#PASSW
AT&D2
AT&K3
AT#GPRS=1
AT#SKTD
Като при последните две чакам за тайм аут по 10 сек., а на всички останали по 5 сек. На края си пускам +++ без никакви ентери на края и тайм-аута е пак 5 сек. И работят няколко хиляди вече повече от 6 месеца без никакви грижи, а 3 сме ги оставили на един сървър дето им върти вскакви комбинации от дропвания и грешни данни вече повече от година и те също си работят и възстановяват връзката без грижи. Единственото, което съм забелязъл, е че понякога след като AT#GPRS=1 даде грешка и не се върже към мрежата трябва първо да пратя AT#GPRS=0 и чак после пак да пробвам и затова за всеки случай съм го сложил това AT#GPRS=0 винаги да го праща след грешка за да не рестартирам модема след определен брой грешки.

Сега го видях това - при мен се получаваше нещо такова в началото когато не чаках определено време след всяка команда, а веднага след отговора от модема пращах следващата команда. Сега пращам следващата команда след 0.1 сек., а за някои команди стигам и до 2 сек. Командата за кънектване към сървъра чакам 1 сек преди да я пратя а GPRS=0 след 2 сек. иначе модема се побърква и чак по някое си време изплюва всички отговори наведнъж или нещо подобно беше. Та погледни колко чакаш преди да пратиш следваща команда след като си получил отговора на предишната и ако не чакаш трябва да сложиш един таймер за тая цел и да експериментираш .

сложих паузи и то големи между командите, със сигурност не помага за излизане от сокет

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

В момента включвам GSM-а, отварям сокет, пращам малко данни и чакам отговор. Отговор няма, щото сървърът не е направен още да отгаваря на тази заявка. И така след 30 секунди приемам, че съм чакал достатъчно и искам да затворя сокета. Пращам 3-те плюса (само тях) и пак чакам. В случая чакането е безсмислено, защото 3-те плюса си се предават към сървъра и ги виждам че пристигат.

Както и да го гледам това не би трябвало да се получава - имам по 30 секунди преди и след плюсовете, като пращането винаги ми е на ДМА, т.е. няма откъде да влезе пауза между самите плюсове. По-чисто от тоя ескейп няма как да направя. Просто явно телето не детектва ескейп по някаква причина. Може би е свързано с това че сървъра не отговаря нищо.

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

AT#SKTD
[=<socket type>,
<remote port>,
<remote addr>,
[<closure type>],
[<local port>]]

<closure type> - socket closure behaviour for TCP
0 - local host closes immediately when remote host has closed (default)
255 - local host closes after an escape sequence (+++)

мамка му и прасе не ще! Явно при #SD не може да се затваря сокета.

Значи аз нещо съм се подлъгал, че +++ действа. Всъщност никога не е действало, просто по подразбиране AT#SKIPESC е 0 и така +++ ВИНАГИ се праща и в нормална ситуацуя, моя сървър като не го очаква затваря сокета изритвайки ме...

@bateAz, AT#SKTD наистина бачка, в зависимост от #SKIPESC първо праща или не праща +++ към сървъра и след това виждам TCP/IP пакет с FIN флаг, демек буквално затваря сокета и ме връща в команден режим.

Може би ще се задоволя с това, макар че исках да имам повече от един отворен сокет. А с тая команда няма как да стане това... Но очевадно #SD не бачка, иначе идеята ми беше с нея да отворя един сокет, после с +++ да изляза в команден режим (БЕЗ ДА ЗАТВАРЯМ сокета) и да дам #SD за втори сокет.... после евентуално да изляза и да се върна на първия.... Само че, при #SD, +++ не затваря сокета (то не би и трябвало да го затваря), но за съжаление и не излиза в команден режим. И по никакъв начин не мога нито да затворя, нито да изляза. Очевидно разпознава плюсовете, защото като включа AT#SKIPESC - ги отфилтрирва. Но само толкова, стои си в оналайн режим и няма мърдане, докато сокета не се разпадне отвън

Изобщо някой пускал ли е повече от 1 сокет на телит?

Аз засега само чрез CMUX-а не съм пробвал, но все повече се съмнявам, защото ваианта #SD с 1 за комманд моде не бачка, т.е. не мога да ползвам #SSEND /#SRCV, другия вариант на #SD дето мъчих досега с излизане с +++, т.е. suspend/resume на socket също очевидно не бачка, поне не и на GE864 и GC864... Сега остана да пробвам CMUX и там да изям дърво...

Ние ползваме само един сокет а и при нас сървъра е нагласен като получи трите плюса да дропва връзката .

Телит твърдят, че може да се дефинират до 2 контекста и до 5 или 6 бяха сокета общо, но аз не съм го правил.
Лошо са документирани нещата и от това идва най-големия проблем. После, естествено следват бъговете.
Аз не съм и опитвал повече от един сокет, а и вече преминавам към FTP.

Уфф... май разбрах какво става

Аз ползвам DCD като критерий дали получавам данни или съм в режим на АТ команди. Затова и ме беше яд че CONNECT понякога идва след DCD.... Но него го ловя на по-високо ниво, щото ползвам HTTP протокол. Та целият проблем е, че очаквам след +++ DCD да се вдигне, да ама не! То не се променя щото явно сокета оставя отворен. А пък аз докато е активно буферирам всичко което получа без да го трейсвам и затова не виждам ОК-ито.

Гадното е, че цялата ми логика е навързана с това DCD и го проверявам на 100 места, че даже и на интеръпт е закачено да сменям по-бързо буфера за АТ команди и за сокетни данни... Сигурно ще го измисля ама ме е яд, че за не знам кой път вече обръщам целия код с краката нагоре... Тия жабари да бяха си написали малко по-добре документацията, сега нямаше да си губя времето (-:

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

DCD (без да съм чел документацията) бих го свързал с изградена връзка (транспорт).
в твоя случай, изграден GPRS. не би трябвало стандартно да има някакво отношение със сокети, а още по-малко с данни. в общия случай трябва да следва логиката на CONNECT.
не изключвам възможността с някоя команда да можеш да му сменяш поведението, ама трябва да си наясно какво си пипал в тоя случай.

Ех, то целият проблем е в транспорта и то транспорта по серийната връзка с модула. Мога да направя връзка със сървъри по цял свят, но тънкото място си остава една отсечка от 2 см на мойта платка

Голяма боза е. Първо на серийна връзка от 9600 ми капризничат и искат да има паузи като говориш на модула, иначе му се променя поведението. То хубаво, айде нека паузите да са част от протокола, ама защо само при предаване.... При приемане нямам никаква гаранция за нищо. Пращам команда и трябва да чакам 180 секунди без да знам дори дали командата е получена изобщо.
А за разпознаване на отговорите си трябва изкуствен интелект. Когато пращам аз, то си прави ехо, което се мъча да използвам като критерий че отсреща има някой и ме чува. Да ообаче, ехото на моменти закъснява със секунди, а пък като включа да ми праща нотификации и ги вмъква където му падне.

Примерно аз пращам: AT#SD=?
а получавам: AT#SD=?> AT# #NITZ: 09/04/29,09:56:58+12 SD=? #SD: (1-6),(0,1),(1-65535),,(0,255),(1-65535),(0,1) OK

С просто око, особено ако е оцветен текста лесно вижда кое какво е, ама докато се парсне софтуерно... Сега и тая боза, дето след отваряне или suspend на сокет нямам никаква сигурна индикация къде съвршват/почват данните и къде АТ командите. Трябва да анализирам и да гадая, което не е толкова лесно щото данните са през HTTP и само един нов ред да не разпозная кой го е казал и картинката се променя.
Май ще трябва да мина на CMUX ама имам много код вече, цял веб браузър търкалям отгоре с многонишкова комуникация и кашата е пълна както се казва

Аз съм на мнение че тоз кретен дето му е дошло на ум тая малоумна система с AT команди да се прилага към GSM модеми трябва да се набучи на кол. Или поне да се изпече жив.
Загубих маса време да пиша парсер че интерфейса да се облече в някакво човешко API. Сега е над 2500 реда C код чисто като ползва и разни други мои библиотеки. И ми гълта маса ресурс на процесора. С WaveCom го напаснах да работи долу горе стабилно. Но ако река да мина на Телета или SimCom епопеята ще започне наново.