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

А пък аз такова ъпдеътване искам, но нещо не мога да го активирам ...

Идеята за АТ команди и като цяло текстов протокол не е толкова лоша. Проблемът е че имплементацията е кофти и има много недомислици.

Най-интересна е реакцията на телетата. Примерно решили да добавят команди за пращане и получаване от сокет без да се излиза от команден режим. Аз като последния идиот, седнах, пренаписах си кода и се оказа че за моя модел фирмуера не го поддържа. Ти мани това ама чета по форумите дето се оплакват други. Значи при пращане пускаш командата (#SSEND), чакаш промпт, подаваш данните и накрая CTRL-Z за край на данните.
Готина идея, само че хората питат кво да правят ако в данните има ctrl-z (0x1B). Отговорът на телит - ми така е, с тая команда не може да предаваш 1В. Ебахти и сокета, дето определени байтове не могат да се пращат. После питат и кога ще го оправите, отгоорът е "ами не е планирано да се оправя"...

Аз за това се интересувам вече, щото ако ми остане време ще вкарам CMUX, ама ме е страх да няма и там някакви недомислици, че ще затрия пак 10-на дена труд за тоя дето духа...

Появи се в последните фърмуери и засега бачка стабилно, като изключим че го праща когато и както си поиска...
Разрешавам го преди регистрация с "AT#NITZ=7,1".

Значи бих могъл и да не го разреша, както вероятно мога да изключа всякакви нотификаци... Но това някак си не ми изглежда като решение. Ако беше някакъв супер ефтин и жълт модул да кажеш "това не работи, ама ще го преживея"... В края на краищата, след като се предлага дадена възможност, тя трябва и да може да се използва.

Няма как Миро - или трябва да парсваш all unsolicited message - или да ги забраниш.

И не надценявай възможностите независимо от цената.
Преди да използвам някоя възможност на модула - тествам задължително.

Кривата имплементация е свързана с концепцията с AT команди според мен. Май всички GSM модеми страдат от тия болести. Аз колко нерви съм изпотрошил с Wavecom..... Нищо лошо в текстовия протокол. CMUX е някакъв опит да се пооправи положението но си е просто кръпка.
Как на един производител не му хрумна да направи възможност за някакъв читав протокол за управление. Да си има възможност за работа с ATкоманди но и да може да се превключи на другия протокол. Така и изперкалите дъртофелници които не искат да учат нещо ново ще са доволни а останалите ще имат възможност да работят по човешки с модема.

не виждам как би го направил без CMUX... и пак няма гранции, щото ще си тясно свързан с конкретен фърмуер.
телит на колко дена правят нов фърмуер?

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

е, няма да стане и за 20 дена...

напоследък нещо спряха (може би заради кризата)...


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

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

Едва ли ще е от мрежата, след като се случва и у наше и у ваше село

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

Още нещо много странно, значи аз файлчетата ги дърпам с HTTP, т.е. пращам заявка и на екрана вместо progrress bar пускам секундарник. Времето от изпращането на заявката докато почна да получавам данни варира доста - да кажем най-често между 2 и 8 секунди. Това го намирам за нормално - и с обикновен телефон като браузвам времената са в тоя интервал, т.е. Телит не са по-бавни или по-бързи при нормална ситуация. Странното е като се получи таймоут, тогава трансфера се възобновява точно на 30-тата секунда. В това не мога да намеря никаква логика.

Реално трансферът е един пакет заявка и няколко пакета отговор. И тъй като таймоута е винаги някъде по средата на данните, т.е. получил съм поне един пакет съвсем нормално е да очаквам възстановяването на трансфера да става на фиксирано време след последния пакет, който съм получил.
Демек ако да кажем таймоута е 25 секунди и първия пакет го получа на 3-тата секунда, след това трансфера ще се възстанови на 28-та секунда. Ако първия пакет го получа на 7-та секунда, трябва да се възстанови на 32-та. А то винаги възстановява точно на 30-тата секунда

едит: за протокола само... снифнах от страна на сървъра и всичко е чисто. Получава се заявка, сървърът автоматично изстрелва целия файла в рамките на 3 пакета, потвържденията идват след около 1,5 секунди. С това за сървъра комуникацията е приключена съвсем нормално. Няма препредавания или загубени пакети. Ако има нещо нередно, то е явано между телето и оператора, който всъщност е proxy...

И Сименс го има това нещо като поведение. Че и по повече от 25 секунди е откарвал.
Проблемът е операторски, не можеш да го пребориш. Засичал съм го с WireShark + подслушване на RF комуникацията на модула - бави се операторът. Явно има някакво ограничение колко буквички за колко часа може да прехвърлиш и ако минеш границата, ставаш с мнооого нисък приоритет. Между другото, това го има само с натоварените часова. За София де. За други места нямам наблюдения.
А по закон GPRS е с най-нисък приоритет в мрежата.

Тъй явно това със "замислянките" при получаване ще се наложи да го преживия... Няма видими проблеми и от двете страни на тръбата и каквото става - става между модула и оператора.... Но поне освен забавяне няма друг страничен ефект.


Лошото е че изкочи друг проблем. Решихме да го изтормозим на тема пращане и заливам модула с данни. Но от другата страна от време на време липсват байтчета - лошо!
Така на първо четене изглежда като проблем с хендшейка на UART-a. За съжаление в момента ще ми е зор да го подслушам, че цялата работа е в кутия и трябва да си поиграя доста, за да го подкарам разфасовано. Аз всъщност се сещам от какво може да е... има една възможност да пращам 1-2 байта след сваляне на разрешението. Макар че понякога ми се губят и повечко байтове и това ме хвърля в размисъл.
Някой има ли идея колко е чувствителен хендшейка на телит? Все си мисля че не би трябвало да очаква че аз ще спра по средата на байта като ми каже да не пращам повече ... Би трябвало да позволява още 2-3 байта или греша?

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

E тва със "замислянките" не можах да го преживея... твърде гадничко си е да браузваш и да чакаш по 30 секунди да ти зареди страничка от 1-2К

Няма да казвам колко време ми отне да го излекувам мамка му Опитвах какво ли не - всякакви комбинации за размер на пакети, таймоути... но накрая се оказа че е свързано с баудрейта на UART-a.
Нали си говорим за "многозадачност" в една друга тема, ей на типичен бъг - явно синхронизацията на Телит им куца между нишката дето получава/потвърждава пакетите и пращането на данните по UART-a.


Та с две думи не ползвате байдрейт над 19200. На тая скорост трансфера пада на 2КВ/s но поне работи надеждно. Аз го бях пуснал на по-височка скорост и получавах с около 3KB/s ама 10-15 пакета средно потъва в мнооооого дълбок размисъл, което смъква скоростта много повече.

Това да не би да е заради мрежата нещо ? Аз работя на 57600 и си прехвърлям едни файлове от по 150кБ и не съм забелязъл да се замисля въобще. Единствено, когато съм ползвал FTP (и то на 9600) и получавам файл е имало такова замисляне, ама не чак 30 сек.

Няма как със сигурност да знам от какво е... Знам само че сървърът праща данните към оператора без паузи - и аз като bateAz пусках Wireshark. От друга страна на тръбата обаче данните излизат понякога със зверски закъснения.
От към контролера съм с DMA и съм сигурен че хендшейка не блокира модула. Очевидно данните се бавят или от оператора или стоят вътре в модула и не излизат.

Възможно е както казва батето операторът да има огранияение "колко буквички" да ми праща за единица време и при скорости над 19200 аз да настъпвам защитата.

Възможно е, но се съмнявам.

Първо ТСР-стека на телето ползва прозорец от 10-11к демек трябва да има място да вкара поне 10-на пакета преди да даде "заето". А пък аз съм го виждал да гърми още на втори пакет от комуникацията.
Второ ако оператора ще налага ограничение, то най-логично да бави всеки пакет по малко. А не един куп пакети да се получават без никакво бавене и после един единствен да увисва за цели 30 секунди...
Трето същите операции ги правя с моето устройство и с моилен телефон. Мобилния никога, ама никога не съм го виждал да се замисля 30 секунди.

Така или иначе след като го свалих от 38400 на 19200 замислянките изчезнаха и не ме интересува много къде е бил проблема

Миро, доколкото разбирам, твоята постановка е проц + теле и вероятно предаваш данните през първия сериен порт (ASC0). (То и през втория да беше - все тая)
Ако е така, да не би да препълваш буфера на този порт, който в зависимаст от телето е от 2 или 4кВ.
Това, добавено към таймингите и буферирането по-нататък може да доведе до описания проблем - и забавяне и загуба на байтове.

Едит: Всъщност не е много ясно отвън как е буферирането, но в откъм питонските модули е така.