HDL

Ровно так и делается в моем проекте, но: - точность никакая (200-300м в лучшем случае, а обычно - хорошо, если 500м), - от RxLVL пользы чуть менее, чем никакой, по 2 причинам: 1) у сот разная мощность излучения, 2) на пути могут стоять ЭМ препятствия. Это можно попробовать, спасибо за идею. Речь о E-OTD, а не о AT+CNETSCAN. Про RxLVL - не фантазия, а реально у нас самая "мощная" сота географически дальше всех от нас. Горе тем, кто использует RxLVL для рассчета геолокации.

Вопрос: какие GSM модули поддерживают технологию OTD/E-OTD. Еще ссылка по теме. Насколько я понял - SIMCOM не поддерживают? Спасибо.

CADiLO, еще раз с Днем Рождения!!! :rolleyes: Спасибо за инфу. Есть сведения о сертификации данных модулей Verizon-ом?

sash.1212, спасибо!

Ищется модуль для CDMA 4G, который бы работал с Verizon-ом в США. Задача - передавать данные, по объему сравнимые с GPRS, т.е. не шибко много и быстро. У SIMCOM есть, что предложить? Большое спасибо!

Модули имеют различное расположение площадки Area A, под SIM800 придется делать новый дизайн платы.

Call ready появляется когда модуль закончил инициализацию и прошел регистрацию в сети (симка вставлена и работает). Без симки либо при проблемах с ней это сообщение не появится.

UPDATE: обнаружил, что AT+CIPCLOSE=1 вырубает модем из сессии в 100% случаев, но именно тот раз 1 из 100 оставляет сессию незакрытой - сервер не получает фин-пакета. Ну и пофиг. Все же вопрос: насколько опасно рубать питание модулю, когда нет другого выхода, и происходит ли апдейт инфы во флэше при включении?

Несколько раз встречал здесь предупреждение о том, что бездумно дергать модуль нельзя, ибо апдейт ЕЕПРОМа рано или поздно приведет к его истиранию. Вопрос: модем записывает параметры в ЕЕПРОМ (флэш) при включении или при выключении? (Совершенно ясно, что AT+IPR=115200 например апдейтит ЕЕПРОМ.) Происходит ли запись при таком сценарии: - включили - поработал - вырубили питание (не посылая AT+CPOWD=1 / не прижимая поверкей)? Вопрос связан с тем, что накнулся на море ситуаций, когда модуль ожидает чего-либо от оператора во время GPRS сессии, по таймауту не вываливается, на инпут не реагирует. Конкретный пример: закрываем сессию через AT+CIPCLOSE, висит. Слышно, что по GSM пинает соту. Один раз из 100 может провисеть и 15 минут - дольше не ждал. Что посоветуете?

Да, собсно в коде инициализации я ниче такого и не увидел. Поздравляю! )

А покажи пожалуйста свой код - соберу и проверю у себя.

Нене, про диоды я конечно не забываю - схема IO Atmel перед глазами. Даже если МК питается от 2.85-3В (чтоб избежать согласования уровней), нога сим900 же подтянута внутри на 2.8В. Меньше 2.85В напряжение питания IO MCU в принципе маловероятно. Если я правильно понял многабукаф обсуждения, корень зла в том, что МК не может выдать лог.0 как 0В, а вместо этого выдает 0.3-0.7В (в атмеле так и указано - 0.7В макс). Но даже если и так, ну включили питание СИМ900, поверкей все время в Z - ток ведь никакой не течет. Подождали, перевели поверкей в лог.0 (0.5В допустим), сим900 воспринял это как 0 и включился. Где подвох?

Окей, пасиба. Еще вопрос: насколько я понял, требование к ОК для паверкея обязательно. Все равно, не понимаю почему. У меня в схеме МК включается первым, при этом на всех портах тристейт. Почему я не могу включать поверкей через ио контроллера, обеспечивая там импульс 0 на заданное время, а потом снова переводя его в Z? И еще один :) Можно ли сделать согласование выхода уарта МК на вход RXD сим900 таким образом: диод катодом на МК, подтяжка резистором к VDD_EXT со стороны RXD? Т.е. заменить транзистор на диод. А TXD подать на вход МК как есть, он его воспримет нормально. UPDATE Для паверкея нашел в форуме. Понял, что 10мкА достаточно для выведения сабжа из спячки. Тогда тот же вопрос: достаточно ли диода катодом к МК или обязательно ставить транзистор?

Скачать увы не нашел, а почитать: http://www.docin.com/p-54136233.html

Спасибо за ответы! Посмотрел на китайцах, MIC29302WU стоят меньше бакса. Почему-то не додумался сделать это сразу, испугался местных цен - 4-5 баксов за юнит. И кстати, у этого девайса есть полезная лапа EN, которой вероятно можно управлять с внешнего контроллера - как раз для контроля питания SIM900. Еще вопрос - можно ли на схеме закоротить POWERKEY на GND? Идея такая: питание сим900 разрешается выходом внешнего контроллера. Этот выход притянут к земле резистором. Первым стартует МК, выставляет 1, включая питание модулю. POWERKEY, притянутый к земле автоматически включает модуль. Отключается модуль через CPOWD=1 с МК. Любая нештатка, вызванная неадекватным поведением модуля приводит к передергиванию по питанию со стороны МК. Это нормально или нет?

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

О, спасибо, почитаю.

UPDATE Иногда (редко, но факт) все-таки происходят прерывания работы юзер-приложения основным функционалом модема, что выражается в заметных растягиваниях задержек. Прошу прощения за неточную информацию. Следовательно, такие протоколы как 1-wire реализовать нельзя в принципе.

Насколько я понимаю, рандомность программной задержки обусловлена тем, что внезапно приходит прерывание на ядро в процессе выполнения пользовательской процедуры. А вызывать оно их может только прерываниями. Провел некоторые эксперименты. Задача: сформировать сигналы на ГПИО из пользовательской процедуры с заданными программными задержками, определить: - факт вклинивания в процедуру вызовов ядра (по изменению задержек), - кол-во тактов проца на одну итерацию цикла задержки. В качестве измерителя использовал альтерный ТАР с частотой сэмплирования 3,125МГц. Код рабочей процедуры: ebdat6_04WriteGpio(PIN, TRUE); fl_wait(1); ebdat6_04WriteGpio(PIN, FALSE); fl_wait(1); ebdat6_04WriteGpio(PIN, TRUE); fl_wait(10); ebdat6_04WriteGpio(PIN, FALSE); fl_wait(10); ebdat6_04WriteGpio(PIN, TRUE); fl_wait(100); ebdat6_04WriteGpio(PIN, FALSE); fl_wait(100); ebdat6_04WriteGpio(PIN, TRUE); fl_wait(1000); ebdat6_04WriteGpio(PIN, FALSE); fl_wait(1000); ebdat6_04WriteGpio(PIN, TRUE); Код задержкера: С: void fl_wait(int n) { volatile v; while (n--) v; } Дизасм: ROM:904005C4 fl_wait ; CODE XREF: fl_entry+112j ROM:904005C4 SUBS R0, R0, #1 ROM:904005C6 BCS fl_wait ROM:904005C8 BX LR Снятый график: http://i.snag.gy/QvNTY.jpg Актуален сигнал SDA (названия сигналов остались от предыдущих экспериментов). Картинку наблюдал визуально в режиме Autorun analysis в течение примерно 5 минут. При этом звонил на модем, принимал и отправлял СМС. Резалты: Кол-во итераций: 1, 10, 100, 1000 Задержка в отсчетах 3,125МГц: 16, 39, 256, 2416. Средняя задержка на итерацию в отсчетах 3,125МГц: 2.4 Средняя задержка на итерацию в тактах 156МГц: 120 (!!!) Выводы: - все задержки имеют постоянную величину и не прыгают рандомно, - количество тактов на 2 команды тхумба 120, что зашкаливает мое понимание этой жизни, если конечно ядро не сбрасывает частоту АРМа при входе в ЕАТ процедуры (как раз для экономии батарейки). Еще поснимал логи работы китайского встроенного I2C: работает чотко по двум сценариям: ebdat15_07I2C_GET_DATA(): START SLA-W Send DATA (pTransfer->txDataSize bytes) RSTART SLA-R Receive DATA (pTransfer->rxDataSize bytes) STOP Ну и ebdat15_07I2C_PUT_DATA() - наоборот. Т.е. для кастомного сценария обмена по шине не пригодно.

Bit-banging? А если выключать инты на время лоу-левельных процедур на гпио?

Печально, но %сабж%. Вызов транзакции по I2C шине, например такой (взят из примера): ebdat15_07I2C_PUT_DATA(pTransfer); из обработчика событий в EAT приложении зависает, если устройство с заданным I2C адресом не ответило ACK-ом на SLA-R/W. Модем висит несколько секунд до самого ребута по вотчдогу. Зависание происходит на втором по счету обращении, если на первое получен NACK, причем наличие ACK на втором обращении ни на что не влияет. Прошивку дизасмил, нашел и рассмотрел почти все процедуры и2ц, но патч придумать сходу не удалось. Скажите, насколько реально добиться от китайцев соответствующего фикса? Как и куда обращаться? Может кто-нибудь сталкивался с этой проблемой? На форуме ничего такого не обсуждалось? (Поиском не нашел.) Спасибо.