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 - контрольная сумма - гонять файлы без нее ну скажем несколько рисковано....