И тем не менее она продолжает прекрасно РАБОТАТЬ, сколько ее не критикуй
Равно как и дешевые китайские модули

Так никто и не спорит что не будет работать. Будет По той же причине завсегда на рынке найдется место и китайцам и европейцам

"Первый класс, вторая четверть!"

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


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


Какая связь между скоростью реакции на предложение и общей длительностью реализации проекта?
Но, кстати, это реально круто, за неделю внести изменение в уже выпускающееся массово изделие, выпустить всю внутреннюю нормативную документацию (по какому ISO компания сертифицирована?), обновить внешнюю документацию, провести испытания. Уважаю. Для меня недостижимая скорость. Если только фирмварю проапдейтить, при этом ридми файл обновить и на багтрекере проекта все описать, то можно и быстрее недели, но это внутрипроектные отладки, не более того.

Вот поэтому и круто, что лишним не заморачиваются. Просто сделали: фирмарю проапдейтили, при этом даже ридми никто не обновлял: скинули на С файлик даже без коментов по функции, этого достаточно. В этом и особенность этого "другого" подхода: сделать БЫСТРО. Кому-то так не нравится, а мне нравится.
Ладно, давайте закончим, а то опять офтоп пошел. Сорри, если кому на мозоль наступил, ненарошно: наболело

Именно! На уровне 90% потребителей всех модулей, нужна поддержка стандартных АТ команд и спеков GSM, а вот в плане реализации встроенного TCP стека и прочих проприетарных вещей производитель, по моему мнению, должен максимально идти на встречу разработчикам. И здесь нет равных(ИМХО) Qectel. При этом Cadilo очень старается оказать максимальную поддержку пользователям как представитель Simcom, но сколько дракона не дергай за хвост, до головы это доходит очень долго. Вот потому и имеем 900R и конкурентную цену когда, как у нас говорят, жареный петух...

Как по мне, то очень приятно работать с фирмой, с которой есть глубокая обратная связь не только на уровне техподдержки регионального представителя, но и вплоть до первых лиц.

И по поводу долгосрочности. Модели телевизоров в СССР выпускали подолгу(берёзка, весна), но они были хуже любой импортной модели, которая выпускалась не более 2 лет.

Оно-то можно, а зачем? Собственными GPIO МК рулит куда быстрее.
Разве что модуль управляется какой-то 10-ножкой...

А разве решения этого плана принимают разработчики, а не их начальство? Порой там антагонизм полнейший.

Например, если модулем управляет ПК через USB конвертер (FT232R).

...и не хватает собственных "верёвок" FT232R. Согласен!

Вот сейчас проект - модулем рулит АРМ стоногий. Нехватает! Так что халявные пины не помешают. Тем более что в модуле это просто дорожка к чипсету - если выкинуть то никакой экономии не будет.

Чем, однако, понравился SIM800 - так двусторонней распиновкой и отсутствием "лишнего". Хотя, конечно, не на все случаи жизни такой форм-фактор.

Без элементарной защиты от ESD производитель модуля вешает на себя некоторые дополнительные риски. А с ней - слегка растет себестоимость. Так что не совсем бесплатно это.

Зачем защита, если сигнал по плате дальше 5см не уходит? Или обратный варинт - что дасть защита от статики если я воткну пин в 12В? А если в 220? Так что ставить нужную защиту исходя из требований - это на совести разработчика, производитель модуля тут не при чем.

В общем чем дольше я пытаюсь запустить прототип на телите, тем глубже убеждаюсь, что для использования с UDP и datagram-oriented протоколами телит с его нынешним интерфейсом TCP/IP стека просто непригоден. Да и "проблески разума" появившиеся в последней прошивке использовать по сути невозможно.

Прямой и недвусмысленный вопрос к представителям Телита - насколько реально в обозримом будущем (т.е. не годы, не месяцы а недели) добиться от разработчиков хоть какого то юзабельного способа приема UDP датаграмм, который не будет смешивать их (в том числе пришедшее с разных IP) и валить в буфер без разбора? То что есть сейчас - это реплика того что сделано для TCP (где имеет право на жизнь), но для нормальной работы с UDP датаграммами (а не потоком данных) попросту непригодно.

Вариант выглядящий наиболее простым и не мешающим совместимости со старыми делами (для тех кто работает с URC) - добавить новый режим выдачи в SRING который будет подобен моторольскому URC MIPRUDP. Что можно придумать для тех кто работает по опросу - даже и в голову не приходит (так, чтобы и совместимость сохранить с теми кто уже использует телит).

PS: Волей-неволей понадобится и поддержка hardware flow control в коммандном режиме.

И все же не могу понять, зачем постоянно так мужественно преодолевать трудности... Ведь есть в сотню раз проще подход - взять Quectel ОЦПУ, написать 10-20 строчек обработки в callback-функции чтения (доступны и айпи-порт отправителя, и длина датаграммы, и сама датаграмма в ОТДЕЛЬНЫХ переменных), чтобы необходимые данные в УДОБНОМ для Вас формате выдавались в нужный UART на ваш внешний контроллер.
Легко можно и формат телита сэмулировать, и нужные АТ-команды САМОМУ дописать в ЛЮБОМ формате...
Вобще, в оцпу в паре с внешним процом несоизмеримо уменьшит затраты на разработку софта.

— …предлагаю вам взять несколько журналов — в пользу детей Германии! По полтиннику штука!
— Нет, не возьму.
— Но почему вы отказываетесь?
— Не хочу.
— Вы не сочувствуете детям Германии?
— Сочувствую.
— А, полтинника жалко?!
— Нет.
— Так почему же?
— Не хочу.

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

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

Хехе. Опередили

Симкомовцы предложили в связи с уменьшением выводов сделать "only gprs" модуль в маленьком форм факторе с выводами по двум сторонам как в 800E. Сказали что МТК чипсет даже и не будут рассматривать для европейского региона и им проще сделать новый модуль в цену 800Е, чем потом отбиваться от того что он прожил пару тройку лет. Поэтому вместо поставок 800й серии будет еще один модуль в 900-й.
Кстати еще один из вариантов который они рассматривают, сделать пин-то-пин с М72, только добавить вход зарядного на место зарезервированых контактов.

Так что на рассмотрении сейчас три варианта.
пин-то-пин SIM900R, но с кучей пустых ножек
пин-то-пин М72 + зарядное
двустороннее расположение в максимально малом корпусе

если быстро закончим согласование, то увидим модули еще в этом году.

Не пора ли Симкому уже отказаться от идеи слепить нормальное зарядное? Всё равно все ставят внешнее... так хоть не пришлось бы платить дважды.

Могу сказать что по отзывам в SIM908 (тот же чипсет) зарядное работает очень даже неплохо. Говорят поднимает аккумулятор даже из полностью просаженого состояния. Сам не проверял, но отзыв был уже не один. Да и не лепит Симком внутрь зарядное - оно уже готовое в чипсете имеется - нужно только ножку вывести. В чипсете от АД (как тогда оказалось с SIM300) было неудачное. Здесь вроде все в порядке. Так что тут вопрос не к Симкому, а к производителям чипсетов.

Хотелось бы вот это

Мы тоже к этому склоняемся - это решение будет и максимально дешевым.
Примерно так как на рисунке. Если есть предложения по перестановке выводов - тоже говорите.
Да, кстати - VRTC в этом варианте убран, а конденсатор внутри модуля.

Однако Симком просил вынести на обсуждение все варианты.

Ну и прочие предложения вносите - будем рассматривать.

Пайка дешевле будет. Меньше размеры - развести на месте любого бОльшего модуля не проблема.

Близко к идеальному варианту! Особенно удобно, что по разные стороны разнесены питание/радиочасть и цифровые выводы.

Я вечером хочу положить рядом типовой симдержатель и посмотреть как он разводится с внешними элементами чтобы если что переставить ноги которые для симки. Тогда на плате в большинстве случаев можно будет без переходных делать.

Что-то это мне напоминает
Может, пусть уже подстраиваюся, чтобы pin-to-pin совместимость была?
А там, гляди, Quectel умрет - и легко перейдем на Simcom

Беру M72 и накладываю поверх SIM900. М72-й больше по размерам. А новый модуль хотят сделать меньше 900го.

Внутри М72 четыре "кирпича", внутри SIM900 - три и меньшие по размеру. Память так точно в более мелком корпусе.
Поэтому есть куда ужаться. А это минус на стоимость платы как модуля так и устройства на нем. Ну и так далее....

Но как уже говорил выше - идея такая была озвучена.

Предлагаю первые 12 выводов перевернуть в обратный порядок(1,2,3,4-sim, 5-GND, 6-12-ком порт), тогда дорожки, идущие на контроллер, при разводке, не будут пересекаться с дорожками симки. Как считаете?

Это уже как располагать - если симка с этой стороны то ее как не крути она не попадет в зону антенны.
А если поменять как предлагается, то найдутся умельцы которые довернут ее к антенному выводу.
И как назло там окажется несогласованная антенна.

Или как вариант, делать свое зарядное. Как это делали мы.
Кстати Симком мы тоже проверяли на температурный режим в морозилке в составе нашего устройства. Он прекрасно работал (даже связь GPRS) не терял при -20. В течение пары часов.

Эдуард, подскажите: ADC как то связано с цепями голосового тракта? Я к тому спрашиваю, можно ли вывести вход ADC в урезанном модуле вместо, скажем DCD?

Вот стандартные линии последовательного порта порт лучше не трогать (IMHO).

На прямой вопрос могу сказать следующее:
1. За недели сделать новую стандартную прошивку для всех модулей нереально. Напомню, что прошивки всех GSM модулей Telit совместимы между собою, поэтому при добавлении любого, даже самого минимального, функционала, необходим достаточно длительный процесс тестирования на всех модулях, внесение изменений в внутреннюю и внешнюю документацию и пр. Поэтому стандартная прошивка появляется раз полгода или даже реже. Этим Telit и отличается от того же Quectel, где разработчик может запросто изменить прошивку по просьбе потребителя, не оставив никаких следов этого изменения (недавно это тут уже обсуждалось). В итоге если разработчик покинет компанию по какой-либо причине, разгребать завалы таких изменений будет просто некому.
2. Возможна кастомизированная прошивка, под конкретный проект. Но поскольку Telit - коммерческая компания, проект должен быть достаточно серьезным. Примеры кастомизации имеются, в том числе и в России.
3. В любом случае лучше обращаться непосредственно к дистрибьютору по вопросу внесения изменений в прошивки.

HW flow control вполне достаточно RTS + CTS. Пускай DSR используется для входа в Sleep
Но как можно использовать DCD, ума не приложу...

А RI кто-нибудь когда-нибудь использовал?

Мне кажется, если Stanley покинет Quectel, то у Quectel шансы 0, т.к. он там, по моему, практически все сам делает
Вот в этом прелесть маленьких компаний - все делается одним продвинутым человеком, под которого, собственно, и сделана компания. В отличие от штата нахлебников с кучей понтов, притирающих стулья и регулярно требующих прибавки (за счет конечного потребителя, разумеется).

>>>Эдуард, подскажите: ADC как то связано с цепями голосового тракта? Я к тому спрашиваю, можно ли вывести вход ADC в урезанном модуле вместо, скажем DCD?

Последовательный порт трогать не будем. Ну и учитывая что ADC из модуля мало кто использует - убираем.
Все равно для этого модуля нужен внешний контролллер.
А даже в том же PIC который 1-2 бакса стоит, несколько каналов 10-ти разрядного АЦП. Что уже лучше встроенного в модуль.
Так что нет смысла оставлять этот вывод.

>>>А RI кто-нибудь когда-нибудь использовал?

Используют как выход прерывания чтобы не читать URC RING.
И по нему же определяют что свалилось на модуль - входящий, SMS или CSD.....

>>>>Но как можно использовать DCD, ума не приложу...

When set ”AT&C=1”, DCD line is ON (low) only in the presence of data carrier.

Что значит как .... В ДШ всё писано... Подключение к серверу я например ловлю. Ловить эти CONNECT, CONNECT OK не комильфо если есть аппаратный выход.

Ну это для любителей 100-ногих контроллеров.
А бывают и другие подходы. Кому-то не влом написать 10 строк, чтоб избавиться от 1 проводника. Хотя тут мож и 1 строки достаточно.

А про ADC - если модуль не будет поддерживать EAT, то не нужен скорее всего. А если будет - то я бы предпочел его иметь. Тем более его можно тупо соединить внутри модуля с тем же RI.
Если мне потребуется ADC , я запрограмирую RI как GPIO input, и он мешать не будет.

>>>Ну это для любителей 100-ногих контроллеров.

Для тех кому попроще

PIC16F1823 14 Pin, 3.5KB Flash, 128 RAM, 256 EEPROM розничная цена $1.03
• Analog-to-Digital Converter (ADC) module:
- 10-bit resolution, up to 8 channels
• Enhanced Universal Synchronous Asynchronous
Receiver Transmitter (EUSART) module:
- RS-232, RS-485 and LIN compatible
- Auto-Baud Detect

А чо вам не нравятся 100 ногие... Какая собсно разница?
У меня есть возможность обрыва соединения с серваком.Гораздо проще завести на прерывание или хотябы на опрос ноги перед передачей, чем гонять парсер даже из 3 строчек.

Так вот и я к тому веду, что если в качестве ADC используется борт ARM, то есть смысл объединить с любой ногой, где есть возможность отключить pull up. Оно, конечно, не совсем по правилам - подавать аналоговые уровни на цифровой вход, но и тем не менее функционал этот не помешает: все ж я уверен, что внутренний код будет популярен в таких бюджетных решениях, т.к. 2$ на контроллер - это уже существенно на фоне предполагаемой цены модуля. Просто народ еще не раскачался из-за консервативности.
А так, смотри, и мы начнем эл.розетки и градусники модулями комплектовать, не только китайцы

Да, кстати, а будет ли модуль поддерживать ЕАТ? Или, если зайти с другого конца, если это урезанный по железу sim900, то, по идее, в него можно будет тупо влить прошивку для последнего.

если цифровой вход не страдает от уровней напряжения, близких к трешхолду, а большинство современных контроллеров как раз не страдают, то кто мешает подавать?
Я не стану ставить контроллер с АЦП, если в модуле уже есть один, и он меня устраивает. Кроме того, никто не мешает на этот АЦП повесить аналоговый коммутатор, а на GPIO в режиме пусть даже софтового SPI - пару сдвиговых регистров.

Мешает политика максимальной бюджетности данного модуля И, наверное, это оправдано - раз решили заполнить эту нишу, то надо максимально удешевить все, но также сделать по максимуму все, что повышает функционал, не требуя при этом дополнительного железа. Отсюда острая необходимость в EAT - тут она даже более актуальна, чем в полноприводном SIM900, тем более что это не потребует ни цента лишнего на производстве.

я имел ввиду снаружи повесить.

Может не стоит убирать ADC в модуле, который с ЕАТ??!!!
Сейчас начал искать аналоговый мультиплексор, чтоб 8 аналоговых каналов мерять одним симовским АЦП из ЕАТ....
Если его уберут, скажите зараннее, а то потом проблема будет...снова переделывать проект.

74НС4051 и его аналоги. По цене ведро за доллар.

>>>Да, кстати, а будет ли модуль поддерживать ЕАТ? Или, если зайти с другого конца, если это урезанный по железу sim900, то, по идее, в него можно будет тупо влить прошивку для последнего

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

Есть уже предварительная информация по модулю, сейчас осталось утрясти еще несколько моментов и выложу небольшой анонс.
Мы еще хотим чтобы пользователю сделали доступным для АТ команд DBG порт и сделали его с переменной скоростью.
Тогда управлять модулем можно будет не мешая данным. Но пока думают делать или нет.
Ну и еще пару мелочей не договорились.....

Я использовал. И продолжаю это делать.