Hi, All!

Столкнулся со странным глюком SIM300D. Использую GPRS для получения данных по HTTP. Алгоритм простейший - один GET, запрашивающий файл, и прием этого файла. На файлах, не превышающих несколько кб все хорошо, но когда получаю файл большего размера, то в принятом файле оказываются пропущенные куски по несколько сот байт на каждые несколько принятых килобайт. Пропуски в разных местах, но первый всегда примерно на одном и том же месте, после пятого принятого килобайта.

Чтобы исключить собственные ошибки, продублировал прием внешней терминальной программой - тоже самое, a принятом файле, в сравнении с исходным, есть пропуски. Почему так? Сеанс связи завершается нормально, никаких разрывов связи или ошибок нет.

Возникла версия, что размер буфера в TCP стеке SIM300 слишком мал, и он захлебывается принимаемым файлом. А выбирать данные быстрее я не могу, ибо данные - это прошивка, и во время приема она пишется в память программ (AVR). Поэтому прием данных в МК все время тормозится с помощью RTS, чтобы успевать записывать. Сомнительная версия, но другой у меня нет... Еще версия, что в принимаемых данных (они двоичные) встречается какая-то неудачная комбинация, от которой SIM300 дуреет. Но тогда ошибка была всегда точно в одном и том же месте, а она немного плавает.

В чем может быть дело, кто-нибудь сталкивался с подобным? Есть ли у SIM300D возможность посмотреть состояние TCP стека, или отрегулировать какие-нибудь параметры (размер буфера, и др)?

так а зачем сразу всю прошивку ему слать?
Думаю нужно делать это постранично, отослать страницу, дождаться ответа от сима, если гуд слать следующую, если не гуд повторить.
И ничего переполняться не будет и ртс не нужен будет.

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

если например у вас отключено аппаратное управление потоком. или включено программное. то 100% h17 непройдет и куча всего другого что лежит вне зоны аски кодов тоже может тормозить и глючить...
на аппаратном управлении в прозрачном режиме все четко.. ниодного байта не пропадает.

Версия подтвердилась: попробовал пропускать дешифрование и запись, чтобы успевать выбирать данные из модема - все ништяк, файл считывается целиком без ошибок. Вопрос - что теперь с этим делать? Сдается мне, что это баг реализации TCP стека SIM300. Было бы интересно услышать мнение коллеги CADiLO, имеющего, как я понимаю, к ним некоторое отношение.



Аппаратное управление потоком включено (AT+IFC=2,2), режим данных - прозрачный (AT+CIPMODE=1).

Версию прошивки вашего модема огласите.
Может китайцы это уже успели исправить

AT+GMR
Revision:1008B14SIM300D32_SST34HF3284

Оно? Насколько она отстала от жизни?


Дай Бог. Я пока пытаюсь реализовать загрузку файла кусочками, используя Range, но это такой геморрой...

Довольно сильно, это релиз от января 2008. Посмотрите на нашем фтр в папке ГСМ. Там есть все Release notes.

Кстати, возникла еще одна идея:
у вас на другом конце канала, откуда передается прошивка, hardware flow control включен и работает?
А то, если нет, то модем тут не причем.
И то, что вы видите, и должно происходить...

+1 на этой жк прошивке стабильно мегабайты проганялись. думаю передатчик виноват. или канал.

И причем тут другой конец канала? На другом конце канала стоит Апач, версию не помню, но, в принципе, там может быть любой другой Web сервер. В TCP flow control обеспечивается ACK'ами, и не может быть отключен. А модем не обеспечивает синхронизацию контроля потока между TCP каналом и COM портом, во всяком случае, на прием. Видимо, это фича, в даташите есть упоминание о контроле переполнения только передающего буфера.

Я, в принципе, проблему решил - забираю файл кусками, через Content-Range, чтобы каждый кусок не превыщал 2кб. Дольше, конечно, зато работает. Но осадочек остался. Сильно упрощенная реализация TCP-стека у SimCom'а.


Откуда гонялись, из Web'а или с FTP одним файлом? И выходной поток притормаживался? Не верю. Проблема не в том, чтобы прогнать мегабайт, а чтобы принять его с необходимой скоростью. Для этого модем ACK серверу не должен слать, пока я не заберу у него данные, а он на это не обращает внимания.

>>>> И выходной поток притормаживался? Не верю. Проблема не в том, чтобы прогнать мегабайт, а чтобы принять его с необходимой скоростью.

Это вам не проводные сети точка-точка. Тут все от оператора зависит. Вы примете свой мегабайт или сколько там, с той скоростью, которую посчитает нужным предоставить оператор. И если в некий момент будет перегруз канала по разговорам, то будете сидеть и ждать с нулевой скоростью. Данные в сотовых сетях передаются по остаточному принципу, приоритет отдается разговорам.
Поэтому используем RTS-CTS чтобы видеть что сота не отдает данные или не принимает их от вас.

Так что принимать и писать "на лету" есть глупость. Принимаем в буфер, желательно с КС, а потом только обновляемся.

Э-э-э, Вы это зачем написали? Какое отношение написанное имеет к означенной проблеме? В данной дискуссии Вы вообще какую точку зрения отстаиваете?

Что описанного явления не существует? Так Ваша позиция тогда, мягко говоря, весьма шаткая. Ибо явление элементарно воспроизводится. Берем SIM300 с любой терминальной программой. Настраиваем: включаем аппаратное управление потоком, прозрачный режим данных и все что нужно. Через CIPSTART подключаемся к любому Web-серверу на 80 порту. Набираем команду GET и запрашиваемм какой-нибудь файл подлиннее, лучше текстовой. Например Анну Каренину, не забыв добавить Keep-Alive. Предварительно в свойствах терминала ставим CR+LF как конец строки. После двойного нажатия Enter по экрану побегут бессмертные строки. Пока все очень хорошо. Включаем сохранение лога в файл. И затем снимаем RTS. Строчки на экране остановились, это тоже правильно. Подождав секунд 30 снова включаем RTS, строчки вновь побежали. На первый взгляд все замечательно, но если теперь не полениться и сравнить текст, оставшийся в логе, с каноническим, то мы обнаружем в нем лакуну, чуть позже того места, где мы снимали RTS.
Ваше объяснение полученных результатов?

А может Вы полагаете, что описанное явление не баг, а фича? Что ж, это вопрос диалектический. Лично я полагаю, что баг, но готов допустить, что Вы считаете по другому. Я бы согласился, что фича, если модем хотя бы сообщение об ошибке (переполнение буфера) выдавал, а то ведь нет, он считает что все в порядке - что принял, то и отдал! А ведт TCP обязан гарантировать целостность принятых данных. Или, если бы он, не обращая внимания на RTS, все равно бы данные выплевывал, дескать девать некуда. А молча глотать - это все-таки баг. Или, как минимум, ограничение данной реализации TCP стека. Собс-но, совершенно не важно как явление квалифицирую я или Вы, гораздо интереснее, знают ли о таком поведении в SimCom, и как явление квалифицируют там. Не исключено, что проблема уже пофиксена, мне проверять лень, ибо для себя я вопрос решил описанным выше способом, а что там думает SimCom меня мало волнует на данном отрезке времени. И вообще, по моему скромному мнению, повышение юзабельности SIM300 и расширение его области применения много больше должно волновать его изготовителя и дистрибьютеров, нежели меня. Я то, если будет совсем плохо, могу и другие модемы использовать.

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

Странные люди... Казалось бы, проблема - выявлена, исследована, локализована. Найдено обходное решение (устраивающее, по крайней мере, меня). Так нет - несут какую-то ахинею... питание... мегабайты принимал... глупость писать на лету... И уж полным откровением для меня было, что КС надо к файлу добавлять, оказывается! Дескать, тогда в модеме переполнения буфера не случается! Я, например, считаю глупостью помещение подобного рода сообщений на форум.

- подозреваю КиевСтар. (самый "рульный" пока) на нем проблемы такой нет. (десяток устройств с обновлениями через инет) ниодного! , за сотни раз, несовпадения CRC . лог ошибок тупо пустой. ( по этой ошибке)

Аналогично. Объём передаваемых данных - несколько больше сотни кБ. Полученные данные грузятся в dataflash, проверяются CRC блоков, глобальная CRC - если всё ОК, перепрограммируем МК, если нет - перезапрос.
Впрочем, стоп... файл именно кусками и принимается .

Да о чем и речь, теперь и у меня кусками по 1-2кб, и все ништяк.

Объясняю.

Дома подключаю Samsung 900E (телефон жены), ставлю карточку Life, так как на ней активирован интернет.
Для тех кто не знает, это "оператор для студентов" - весь приоритет на разговоры по дофига минут - остальные сервисы побоку. Славится он еще и рассыланием SMS в самый неподходящий момент и навязыванием мелодий и акций.... Вобщем если говорят Life, то лучше позвонить по городскому телефону.
Ну так вот, подключился, тяну драйвера - связь то приостановится, то дальше пойдет....
Файл скачан - не хватает 40 килобайт на 15 мегабайтах.
Вторая попытка - не хватает почти мегабайта.
Третья попытка..... Связь оборвалась и 2 часа интернета не было.
Скачал я только после полуночи когда активность поупала немного.
Так что гарантированую прокачку файла вы можете получить только если купите у оператора служебный канал под данные - например как под банкоматы, где никто не влезет с приоритетами и не оборвет соединение. В противном случае - лотерея.
Один из наших клиентов приобрел себе такой канал - у них несколько сотен точек по Украине с модемами на SIM300D - ни разу не было ни одной жалобы что потерялись данные.

КС - она же CRC - контрольная сумма - гонять файлы без нее ну скажем несколько рисковано....

Насколько я знаю таких контрольных сумм в самом TCP\IP несколько - на каждом уровне протоколов. Повышает ли надежность передачи добавление еще и своей CRC? По-моему, нет, при условии, что стек протоколов на самом модеме реализован корректно. 

Ключевая фраза "при условии"
А вы уверены, что стек в модеме не имеет ошибок?
А вы уверены, что у ОпСоса при передаче пакетов ничего не может выкинуться (именно намеренно удалится, а не пропасть) при полной загруженности конкретной соты голосовыми данными?

Я вот не уверен. Хотя допускаю, что те TCP сегменты, которые добираются до места назначения, не имеют ошибок.
Но при передаче больших объемов данных происходит фрагментация. И, видимо, часть сегментов пропадает по пути из-за кривости какой-то части оборудования...

>>>>Повышает ли надежность передачи добавление еще и своей CRC? По-моему, нет, при условии, что стек протоколов на самом модеме реализован корректно.

Ходжа Насреддин говаривал - на Аллаха надейся, а осла привязывай.....

Дело в том, что если не дошел хотя бы один фрагмент из пакета, то этот пакет будет невозможно собрать, и, по сути, весь пакет будет считаться недошедшим. Cмысл-то TCP как раз в этом - создать иллюзию передачи всего пакета, сколь угодно большого, а внутри себя нарезать его удобным образом. Вопрос к CADiLO - замечались ли частичные приходы пакета, без части сегментов? 


Спасибо.

Я, конечно, не уважаемый CADiLO, но замечу примерно следующее: потеря части пакетов - дело абсолютно нормальное. И бороться с этим посредством заклинания "Оборудование оператора сети должно передавать всё в целости и сохранности", думаю, вряд ли удастся. Посему советую сделать так: разбить прошивку (а речь ведь идёт именно о ней) на пакеты по 1 кБайт и передавать их один за другим. При этом, во-первых, можно полностью задействовать буфер SIM300, во-вторых, в случае порчи части посылки придётся пересылать не всю прошивку, а лишь её небольшую часть. Обязательно следует использовать квитирование (дошла посылка в целости - отвечаем о готовности принять следующий кусок, нет - запрос на повторную пересылку).

Кстати, что касается самого процесса перепрошивки. Сильно сомневаюсь, что нужно заливать прошивку "на лету" по приёму из модема. Во-первых, тогда сам bootloader займёт очень много места (в него будет входить программный драйвер SIM300), а во-вторых, этот самый драйвер может содержать программные ошибки, и исправить его удалённо уже не удастся. Это, конечно, в том случае, если не перепрошивать и bootloader, что считается дурным тоном... Для хранения прошивки на плату удобнее всего ставить SRAM. Залитую прошивку можно проверить после сборки на целостность при помощи всё той же пресловутой CRC, да и управление памятью не в пример проще, стало быть, драйвер SRAM займёт немного места. Для экономии места на плате можно применить SRAM в BGA (AS6UA25616) или, к примеру, KM68V1000B в TSOP.

SRAM много "лап" контроллера займёт. AT45-е вполне рулят, т.к. спешить особо не требуется.
Самый стрёмный момент: пропадание питания в процессе прошивки.

Поддерживаю. Тоже использую АТ45. Пропадание питания в процессе прошивки вроде не боюсь, т.к. после восстановления питания программа стартует с бутлоадера и заново прошьет программу сначала. А потом уж удалит спецсимвол из 45-й, приказывающий эту прошивку осуществить.