Вопрос аналогичный предыдущему. Приёмник на каком чипсете, на ваш взгляд, будет лучше? При условии что будет использоваться, в основном, в режиме, когда получение координат нужно редко. Либо раз в несколько дней (раз в неделю), либо раз в пол-часа.

Для примера рассмотрим SIM18 и EB570. Другие приёмники на этих же чипсетах не отличаются слишком сильно.

SIM18 -- ~45мА в режиме захвата, -147dBm, 1.8в, 48 каналов... режим работы sirfaware, технология CGEE, другие режимы сбережения энергии.

EB570 -- ~30мАв режиме захвата, -148dBm, 3.0в, 66 каналов. sirfaware нет, CGEE нет.

Больше существенных отличий не наблюдается.

SIM18 потребляет по-мощности меньше. Но реализовать это преимущество без импульсного DC-DC нельзя. А если прибор миниатюрный и с батарейным питанием и там уже 2шт. DC-DC (4.5 для GSM и 3.0 для остального), то добавление третьего преобразователя слишком сильно затрагивает бюджет и площадь ПП, по сравнению с первыми двумя. А при 3-вольтовом питании приёмника (через LDO) начинает выигрывать EB570. Да и потребление от шины VRTC -- меньше.

Чувствительность в режиме слежения скорей не имеет существенного значения, если речь идёт только об однократном определении координат.

Технология sirfaware не даёт возможности реализовать своё преимущество при включении раз в несколько суток точно. При включении раз в, примерно, пол-часа тоже (в таких условиях и старые приёмники на SIRF-III отрабатывают типично менее чем за 18 секунд...) Не совсем понятен смысл её существования. Понятно, что она сокращает задержку до получения координат. Но даёт ли она экономию энергии? При какой периодичности включения? При более чем получасовой, думается, мало чем будет отличаться от обычного GPS-приёмника.

Другие режимы сбережения энергии приёмников SIRF мало чем будут отключаться от управления на уровне включил-выключил для не-SIRF приёмников. Из опыта -- даже хуже, потому, что при "ручном" управлении можно хоть задать адекватные критерии выключения.

Технология CGEE позволяет сократить 35-секундный интервал. В ней видимо есть преимущество, но только при периодичности включения от нескольких часов до трёх суток. Экономия при интервале включения раз в пол-часа и чаще, скорей, не будет замечена (эфемериды успевают обновляться). Раз в несколько суток -- тоже (всё равно загружать заново). При наличии всё равно включаемого GSM и GPRS лучше было бы думать о работающем A-GPS.

Единственный вопрос, насколько SIRFstar-IV работает быстрей, в режиме захвата, по-сравнению с MTK3329. Источников этой информации нет.

Да и с документацией на приёмники Transystem ситуация непонятная. Для SIM18 есть хоть что-то. Для Transystem непонятно, например, как указать приёмнику текущие примерные координаты и время (для ускорения поиска спутников, при наличии альманаха). В SIRFstar для этого используется vendor-specific NMEA команды. Ситуация с A-GPS, который заявлен там и там вовсе непонятная. Публично доступной документации нет (а есть ли она вообще -- скрывается, обычно, известно что...)

Просьба высказать свои мнения по данному вопросу.

Попробую ответить на некоторые вопросы:
1. По поводу холодного старта - он будет практически одинаков для любых GPS модулей, и определяется в основном очень низкой скоростью передачи данных в канале (речь об эфемеридах).
2. Фирменный протокол МТК является конфиденциальным и давать его производитель разрешил только под NDA. Однако, как это часто бывает, сей секретный документ есть и в открытом доступе здесь.
3. Аналог SGEE у МТК тоже есть, документ тоже конфиденциальный и его тоже можно найти, как ни странно, у Leadtek
4. МТК ведет разработку нового GPS чипсета 3339. Модуль Transystem EB-700, выпускаемый на этом чипсете, будет повыводно совместим с EB-570. Образцы обещали к концу года. Среди прочего, там будет и аналог CGEE.

Вопрос - GPS будет только с контроллером или GSM модуль тоже предполагается в системе ?
Если предполагается - посмотрите в сторону SIM908

Чудовищное потребление, сопоставимое с советскими ГЛОНАСС приёмниками. Из-за более высоковольтного (GSM) питания, да и само по-себе.

Это совместное потребление обоих модулей, так как GPS часть не имеет собственного процессора.
Задача для него проста - включился, запросил, передал, уснул. Тем более что под него планируется EAT, так что можно будет вообще без внешнего проца.

Ну а если GSM часть не нужна, то конечно смысла в нем нет.

Если действительно интересуют совмещенные модули и не пугает BGA, можно рассмотреть GE864-GPS. GPS там Sirf IV. В отличие от упомянутого SIM908 - GPS там полностью выделенный. Не буду спорить, лучше это или хуже, но подход несколько иной.

кстати в планах Telit на следующий год есть еще комбинированный модуль GE865-GPS на 5-м поколении сирфов, который будет уже с ГЛОНАСС/ГАЛИЛЕО поддержкой, и в таком же формфакторе, как и GE864-GPS, который выпускается сейчас. Чтобы безболезненно перейти можно было в будущем... ну и само собой с поддержкойeCall и все такое.







ну ну... EAT, да с малым энергопотреблением... Я что то не слышал, что ST-Ericcson, вместо АРМа перешли на кортэксы.
Не думаю, не думаю, а по сему жрать будет как паровоз.

Да, еще уснул-проснулся или НЕ проснулся! та еще тема монстры вроде вейвкома-сиерры на этом МАРКЕТИНГОВОМ пути споткнулись и "завалились"... а тут вообще смех один. Тем более ценник за кортэксы да армы совсем уже ниже плинтуса стали. А будут еще дешевле.

Все равно люди внешний процессор будут ставить всегда, как ни крути. там хоть контроль свой какой-то есть.

Да и по поводу производительности тоже вопросы будут. Я еще мог бы представить, если бы внутрь модуля добавили ОТДЕЛЬНЫЙ ARM9, как это сделали мы, в модуле GE863PRO3, добавив отдельно ARM9 - Atmel AT91SAM9260 с линухом.

на фоне того сколько сожрет приемопередатчик за время регистрации в сети и потом обмена данными, говорить о токе потребления процессора просто смешно.
ну добавили и что, цена какая получилась? а 908-й уже ниже 30 баксов, и будет снижаться цена.... и монтировать проще чем BGA.

так что вам своя ниша, а нам своя.....

Вы не поняли. Разговор не о цене. Хотя Telit GE864-GPS вплотную приближается к озвученной вами цене на SIM908 на больших проектах.
По поводу BGA, так если пропустить сложность монтажа пяти изделий в кухонных условиях, то в BGA выводится на порядок больше земляных пинов, что позволяет в целом поднять помехоустойчивость модуля.
Кстати а что там за GPS в 908-м? Дешевка от MTK очередная? У GE864-GPS там SirfStarIV...

И еще, я лишь хотел довести мысль про бесперспективность! использования в нормальных изделиях так называемых "внутренних ресурсов модуля", и мы оба знаем (да и не только мы), что это лишь маркетинговая уловка, вводящая в заблуждение кучу народа, который в конце концов все равно ставит внешний проц.

Почему MTK дешёвка? Я вот вижу -- потребление меньше.
Чем SIRF лучше, кроме модного слова?

>>>вплотную приближается к озвученной вами цене на SIM908 на больших проектах.

Но я то озвучил - розничную цену, а на больших проектах GE864-GPS будет далеко позади.

>>>Кстати а что там за GPS в 908-м? Дешевка от MTK очередная? У GE864-GPS там SirfStarIV

чипсет STE

•Receiver type 42-channel GPS L1 C/A code,High-performance STE engine
•Max. update rate 1 Hz
•Sensitivity Tracking: -161 dBm Reacquisition: -151 dBm Cold starts : -144 dBm
•Time-To-First-Fix Cold starts: 35s (typ.) Hot starts: 3s (typ.)
•Accuracy Horizontal position: <2.5m CEP
•Operation temperature: -40°C to +85 °CElectrical
•Power consumption - Acquisition 43mA Tracking 41mA
•Antenna type Active and passive
•Antenna power External or internal VANT_OUT 2.8V

Если коротко то SIM900 + SIM08 в одном флаконе при цене меньшей чем на модули раздельно.

Ну, не смог удержаться...
Это все от кривых рук (или мозгов) программистов, которые только понты умеют гонять и лапшу вешать (а сегодня, к сожалению, много "профессионалов" именно такие). Если грамотно написать внутренний софт и учесть все возможные ситуации, то дополнительный внешний проц только снизит общую отказостойкость устройства. Ведь внутренний проц Вы никуда не дели - он параллельно работает.

Это точно. А если учесть что на "сыром" ЕАТ работает уже достаточное количество проектов....

Открою "страшную тайну" ЕАТ был еще на SIM300D, у меня вся документация есть на это.
Но там это было под очень большие проекты, зато оттестировали сам принцип.....

Открою тайну еще страшнее. Один из из нескольких разработчиков этого EAT еще на сим 300 Mr. Zhang - теперь ведущий инженер тех. поддержки Quectel. Ну это длинная история.

Я знаю. И не только его - если интересно выложу фотку, ткнете пальцем в перебежчиков ))))
Впрочем мы отошли от темы топика.

Если честно то когда у нас берут модуль на МТК, как известно это L10, L10-C и на Сирфе L20 или L30. то я тоже потом перезваниваю и интересуюсь как ведет себя модуль что лучше. Так большинство разработчиков склоняется к МТК, а СИРФ берут в основном из-за габаритов.

Вот это бред так бред. Вы бы не позорились перед обществом с такими постами... - "дополнительный внешний проц только снизит общую отказостойкость устройства". Кстати технически правильно будет - отказоустойчивость.
"Стойкость" - фраза хорошая для дуболомов в армии.

И по вашему, одна из задач внутренней ЗАКРЫТОЙ OS модуля, читай приложение EAT или OpenAT (!!! с наинизшим приоритетом по отношению к обработке GSM дел) будет быстрая и отказоустойчивая ???
Какие же варианты у вас есть по контролю этой вашей задачи если КОД OS ИЗНАЧАЛЬНО ЗАКРЫТ!!!. Даже производители модулей ничего гарантировать не могут... Вспомним историю с OpenAT. а EAT это то же самое ...

Я конечно рад за вас, как за менеджера, поддерживающего здесь некоторых продавцов, но хоть какой то этикет соблюдать нужно.

И еще, уточните только, какой это такой внутренний процессор параллельно в модуле работает? Но это так вопрос, для смеха уже ...

Че за бред ты несеш вообще башню снесло? Это кто здесь менеджер я или Gegel? Ты если не знаешь так молчи лучше пиарщик мля.

Без эмоций, ок?

А модераторы есть в Этой ветке вообще?

Ну это традиционно. "В мировом финансовом экономическом кризисе виноваты программисты" © rbc.ru



А внутри SIM900, например, софт достаточно грамотный? А как быть с зависаниями и пересбросами, а? А то вон соседние темы смотрим -- у кого завис, у кого сбросился, у кого на NRESET не реагирует.

И вы предлагаете внутри этого ещё и свой софт запускать? И потом объяснять почему он то завис, то пересбросился, то просто глючит? Без внешнего процессора (чтоб регулярно отключать питание) это просто не работает.

А можно я вопросов наводящих позадаю сразу? А предусматривается (например, Cortex-M3 предусматривает и это реализовано в LPC17xx, в STM32xxx) ли изоляция разных задач в этих ОС, встроенных в модем? Они работают в разных адресных пространствах, есть защита памяти? Скорей нет. Любые ошибки в ПО самого модема могут вести к сбоям в прикладном ПО. Так и наоборот. Количество сбоев растёт лавинообразно...

На вопрос как реализовать голосовое меню в Embedded AT ответ отрицательный. Никак. Что-то изменилось? Опять внешний процессор, внешняя память, внешний DAC (при том, что всё есть внутри модема, казалось бы) и двойное преобразование цифра-аналог-цифра (хоть бы PCM уж вывели, если так).

Может ли Embedded AT обрабатывать данные поступающие с частотой ~300 выборок в секунду (аналоговый акселерометр, например) ? Ответ скорей отрицательный. В теории может, на практике упрётся в ПО и недостаточно реактивную ОС. То же касается DTMF-декодера, только там уже 8000/сек.

PIC-контроллер может выполнять массу задач при потребляемом токе в ~3мА с частотой ~8МГц, наконец. И засыпать снижая потребление до десятков мкА. Для модема было сказано -- 600мкА. Разница на порядок в рабочем режиме и режиме сна.

И ещё очень много ньюансов. Сейчас Embedded AT применима лишь для узкого ряда ограниченных задач, на самом-то деле. Будь там качественная RTOS внутри, сфера применения была бы шире. Но не для микропотребляющих приборов в любом случае.

Сказано верно. Где EAT или OCPU справятся, а где уже и что посерьезнее нужно.
Так что под каждую задачу надо просто выбрать инструмент обладающий разумной достаточностью. Или я не прав ?

Ну, я привык к таким эмоциям... Но этим ничего не изменишь ведь
Кстати, я к менеджменту не имею отношения, и от Quectel ни копейки никогда не получал, просто мне сразу понравилось оцпу. В виде "эльфов" на сименсы это решение уже было лет 7 назад, но "крутые профессионалы" врядли этим интересовались.
А что касается технических деталей, то у вас, как на мой взгляд, немного неверные стереотипы, что, впрочем, очень характерно для профи. Я не профи, и никогда им не был, поэтому разрабатываю, как мне хочется, и как я считаю нужным, а не как учили - и в этом вижу некоторые преимущества

По существу: проц внутри - это проц модуля (АРМ). Он работает паралельно внешнему процу, в который Вы пишите пользовательский код. Причем мотивируете это необходимостью контроля за внутренним процом модуля. Для этого нужен внешний проц под линуксом??? Абсурд... А его кто дергать будет, если что? Если хотите сделать контроль, поставьте PIC10 как вотчдог и подстрахуйте внутренним его вотчдогом, чтобы управлял стабилизатором модуля. Чем проще, тем оно надежнее, знаете ли...
Конечно, если надо спецпериферию, это другое дело. Но для обычных задач вполне достаточно ресурсов внутреннего АРМ.
Я прикручивал в оцпу tDES, AES, математику с плавающей точкой и т.д., это не те задачи, о которых стоит волноваться. Опять же, надо грамотно писать код, тогда рационально используются ресурсы. И если Вы ставите внешний проц с линукс-системой и пишите туда охранную сигнализацию или жпс-трекер, то сколько бы вы не пыжылись, кроме улыбки, это ничего не вызовет.

Скажите, а что делает охранная система внутри модуля когда исчезает GSM-регистрация в сети? А сколько проработает GPS-треккер работающий как закладка от автономного питания? Скажите, если требуется контролировать аналоговый 3-х координатный акселерометр с частотой хотя-бы по сотне выборок в секунду на канал плюс 2-3 аналоговых величины - и как Ваш внутренний АРМ с этим справится?

ЗЫ. Это ведь простые задачи - 3-5 аналоговых входа, потребление на уровне десятка и меньше микроампер, независимая работа от наличия связи. Есть еще такая обычная задача для систем защиты - реакция на событие за единицы мкс.

ЗЗЫ. Что касается Линукс-системы во внешнем проце, такое решение принимают тогда, когда нужен пользовательский интерфейс и работа с дисками и сетевыми устройствами. Т.е. когда очередной раз повторять интерфейсы к типовым устройствам нет времени и желания.

Эту уже у нас офтоп пошел, модераторы нас точно отшлепают Но рискну ответить.

Только давайте отдельно - стационарные системы охраны и энергосбережение автономной закладки.

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

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

А вот по поводу акселерометра - это идея супер, я смотрел эти трекера. Так понял, что речь идет о режиме сна и активации в рабочий режим по движению. Обязательно реализую в своем трекере (автономном варианте). Только вот ума не приложу, зачем трехканальный акселерометр с 300 семплов/сек??? Текст вводить жестами?
Я бы не так сделаю - использую максимально дешевый магнитный или пьезо датчик и максимально дешевый пик с компаратором и программой отработки интервалов включения - отключения, управляющий основным питанием модуля. Результат будет тот же, наверное, но цена...

Диски и сетевые устройства - не спорю, но при чем тут охрана и трекер? Мне кажется, что на рынке выиграет тот, кто демпингует его ценой и возмет массовостью.

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

Это если совсем чистая закладка.... Но и так потребление обычно выше чем с внешним камнем.

Нет, это вариант для GSM сигналки со встроенным датчиком наклона/перемещения/удара организованного на акселерометре. Для отслеживания наклона/перемещения много выборок не надо, а вот для того, что-бы не пропустить удар - вот те самые минимум 300 семплов/сек.

...тот еще...

Треккеры могут ведь писать не только координаты, но и картинки. Да и вспоминаем классические навигаторы...

Просто из любопытства, чем обоснована цифра 300 семплов/сек? Если стукнуть по машине, кузов наверняка будет вибрировать ещё пару секунд.

А от мимо проезжающего камаза - еще дольше. Но нам-то надо удар т.е. пиковое воздействие...

Тем, что пик-контроллер 1.5мА будет потреблять в рабочем режиме, например. А не все 30. И просыпаться будет за микросекунды. А не загружаться как windows, то-есть, хотел сказать, OpenCpu, по несколько секунд. А это всё ватт-часы.

Будильник... А что если в момент от срабатывания будильника до его перепрограммирования на следующий интервал произойдёт сбой внутри OpenCPU -- больше вооще никогда не проснётся? Аппаратный watchdog так и напрашивается (да всё равно нужен). Значит перезагружаться будет часто и съедать батарейку.



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





В OpenCPU же даётся пользователю перезаписываемый flash? Зачем EEPROM?
И в EmbeddedAT тоже. Другое дело, поверх flash напрашивается адекватная файловая система или что-то в этом роде.




Датчик "удара" строится так: фильтр ВЧ, амплитудный детектор. Частота с которой будет вибрировать -- десятки герц, а то и больше сотни. Кроме того, скорей важна даже не вибрация, а скорость нарастания сигнала.

Другое дело что... для аналогового акселерометра и обработку можно сделать аналоговую (на АЦП попадает после амплитудного детектора). У кого-то application note был на эту тему. Экономит и ватты и такты MCU. События же типа "наклон", "движение" получаются путём обсчёта данных после фильтра НЧ, это всё медленно и CPU не нагружает (кроме самого фильтра, тоже аналогового). Но по нынешним временам, при наличии достаточно быстрых и малопотребляющих MCU, проще всё программно.

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

Ну, так а в чем сложность для оцпу по п.1? Посмотрите мою схему, там вобще это на логике сделано.
При работе оцпу выходит меандр, поддерживающий мультивибратор в включеном состоянии. Если оцпу виснет, он исчезает и идет включение-отключение с периодом
7-8 сек до запуска оцпу. Если не виснет, то все под его контролем: и регистрация, и макс-тайм на запуск жпрс, подключение к серверу и т.п.
Можно было и на PIC10 сделать, но не хотелось лишний софт лить.
Может, это и не модно, но ведь цена....

А по поводу еепром и т.п. - просто, наверное, Вы не совсем в курсе возможностей оцпу Quectel. Там полноценная файловая система, причем достаточно солидного размера (на модуле Т128 - до 9М, если память не изменяет).
На модуле N32 - 500К точно. Ну и остальное - проигрывание мп3 с возможностью вывода в любом направлении, декодирование дтмф, и т.п.
Если заинтересуетесь, я скину доку с API.

На счет акселерометра: да уж... Опять же, может, я старомоден, но все ж обычный аналоговый датчик удара чем плох?
Хотя, конечно, согласен - при хорошем алго можно добиться лучшей надежности и помехоустойчивости, но стоит ли оно того?
Метать бисер, а юзер оценит?

По поводу картинок и классических навигаторов - вот тут без вопросов: снимаю шляпу! И я бы предпочел линукс. Но пока до этого не дошел.


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

Вопрос "засыпания" не раскрыт. При засыпании мультивибратор некому будет сбрасывать. Значит будет функция его выключения... Может PIC10 не такая уж и плохая идея. Ещё следует учитывать, что площадь печатной платы тоже критична.

И самый главный вопрос -- сколько потребляет модем, в среднем, ток какой?
OpenCPU может при такой вот работе "засыпать" с потреблением на уровне 2мА,
в промежутках между вычислениями? Мне думается, что нет (вспоминаю, что SIMCOM, например теряет первый байт в режиме +CSCLK=2 -- следовательно перифирия контроллера там не работает полноценно в режиме сна, только прерывания). То-есть к потреблению GPS-приёмника на уровне 40mA нужно добавить потребление модема на уровне ~30мА. А если без GPS -- будет засыпать? Наверное, тоже нет, из-за watchdog.



Интересуюсь.



Непредсказуемостью его характеристик. Сложностью приобретения готовых датчиков с известными характеристиками. Наверное не секрет, что сейчас болтики с пружинками массово у всех заменяются на MEMS-акселерометры. Кроме, может быть, самых дешёвых решений. К слову, чаще, вполне себе аналоговых.



"Обычный" датчик не умеет классифицировать события (отличать удар и движение, например). Слишком резко реагирует на резонансной частоте и в одних плоскостях и недостаточно хорошо на других частотах и в других плоскостях. Настроить тяжело. Много ложных срабатываний. "Датчик наклона" же вовсе не сделать.





Ситуация, на мой взгляд, как раз обратная. В маленькие приборы, с маленькими батарейками и ограниченным функционалом, OpenCPU плохо вписывается. Из-за потребления энергии, в основном. Да и pic-контроллер неплохо справляется.

В случае же "большого" прибора потребление волнует уже меньше, а возможностей микроконтроллера не хватает и он быстро обрастает внешней памятью, например, и много чем ещё. И тут OpenCPU очень даже интересна, тем, что позволяет экономить на собственном уже относительно дорогом микроконтроллере (современные кортексы, да ещё память -- по цене больше половина модуля уже), если переносить "тяжёлые" вычисления и коммуникацию внутрь OpenCPU, оставляя на долю маленького внешнего микроконтроллера только наоболее критические функции.

ФС это круто! Только не забудьте в свою программу добавить Norton Disk Doctor - для восстановления той самой ФС после очередной не законченной записи. FAT это ведь не просто в EEPROM восстановить значение по КС. Я уже предостаточно насмотрелся на перепрошивку навигаторов с разрушенной файловой системой...

Это как раз и меня волнует. В трекере пишу файл архива по получению каждой точки (200K, fopen-fseek-fwrite-fclose), а также в файл счетчика пройденного пути (8 байт), и в файл конфигурации (124 байта, единожды при конфигурировании). Вроде китайцы успокоили, сказали, что используются внутренние механизмы, гарантирующие сохранность (дублирование фат и предотвращение постоянной записи в одни физические адреса флеш - общаюсь непосредственно с разработчиком оцпу , в этом плане у них саппорт супер!), но как оно в реале будет - посмотрю, отпишу. В тестах пока не глючило

FAT и так всегда дублируется (начиная с FAT12 на флопи-дисках) Вот только это мало помогает т.к. нельзя сразу однозначно сказать какая из таблиц правильная. Так, что просто дублирование мало помогает. А если учесть, что обычно корректность (идентичность) таблиц при старте не проверяют и работают до сбоя только с первой...
Что касается второго - это стандартная работа форточек - любое изменение файла по сути убивает старый и в новом месте создает полностью новый.

Ага, а ниче что первые сектора при этом фиксированные и постоянно перезаписываются? Если флэш без wear-leveling то убьется очень быстро.

Этот вопрос как раз ставил перед разработчиками. Сказали, что wear-leveling касается как секторов, ток и FAT-таблицы. Итого вопрос ставился так: необходимость постоянной каждые 10 сек перезаписи файла 8 байт в режиме open-write-close.
Подтвердили, что даный режим допустим и не повлияет на долговечность. А как там на самом деле - жизнь покажет (как Вы верно заметили ранее - ОС то закрыта).
Но в любом случае использование оцпу в целом подкупает минимальностью затрат, как бы там ни было.

Какую материальную ответственность несут консультанты за свои рекомендации? И каковы гарантии того, что в процессе развития firmware разработчикам не понадобятся дополнительные ресурсы, которые будут тихой сапой "заимствованы" из того пула, который используется для wear leveling сейчас?



Часто демонтаж дефектного или намертво зависшего устройства на объекте и монтаж нового по затратам (транспорт, рабочее время) может быть сопоставим со стоимостью устройства. И где в случае вылезших массовых отказов будет экономика этого дела? И какие гарантии лично вы можете иметь в случае закрытой OS?

Да почти такие же от закрытой ОС, как и от открытой
Я не раз убеждался, что едино практика и эксперимент решает вопрос, а не абстрактные рассуждения.
Сделаем 5-10 трекеров (по $30-35 за штуку), поставим на такси, покатаются месяц по городу - а там оно покажет.
Если будет нормально, то демпингуем рынок ценой (и убедите потом юзера в преимуществе открытой ОС ) ), а если нет - ну что ж, пойдем другим путем

Три раза "гы". Если выкинуть из комплектующих процессор и память 4$ ценой, то себестоимость конечного изделия от этого в разы не снизится. Так что никаких особенных преимуществ в демпинге не будет. Даже если использовать бесплатный рабский труд на сборке

с моей точки зрения - от демпинга нет ползу...
это плохо для компании, потому что есть очень маленький доход.
это плохо для клиента, потому что нет приемлемого качества (в большинстве случаев). Также, когда цена низкая - обслуживание не может быть хорошим.
... и не забывайте - вы должны зарабатывать достаточно для хорошего R&D.. :-)

На вейвкомовских модулях в OpenAT похожая технология записи во флэш. Пишем туда постоянно и ниче пока не отвалилось.

Износоустойчивость файловой системы это конечно хорошо. Но как технично умалчивается про журналируемость (как в NTFS). Т.е. если в самый непохходящий момент отключить питание - полетит все к чертям, или нет.

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

Небольшая резервная батарея спасет Правда добавляются затраты на контроль обоих напряжений питания.

Ну а где тогда вся простота и дешевизна то будет?

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

Вернемся к теме топика.
Компания Transystem сообщает о подготовке к производству нового GPS модуля EB-870 на базе чипсета MTK 3339.

Благодаря использованию новейшего чипсета, модуль EB-870 обладает лучшими в мире на сегодняшний день характеристиками:

- чувствительность -165 dBm

- потребление тока менее 15 мА в активном режиме (слежение)

- пиковый ток до 18 мА

- ряд эффективных режимов энергосбережения

- предвычисление эфемерид без использования внешних серверов

- фильтрация до 15 источников внешних помех

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

Размеры модуля 10х10 мм. Модуль повыводно совместим с уже выпускающимся модулем EB-570, что позволит кардинальго улучшить характеристики уже выпускаемых изделий без какой-либо аппаратной доработки.



Начало производства ожидается в декабре 2011 года.

15-18 mA - весьма неплохо. А питание V сколько? Поддержка активной антенны? Наличие на борту пассивной?

2.8 - 4.2 В. Работает и с активными, и с пассивными антеннами. На борту антенны нет. Как показывает опыт, подавляющее большинство производителей не использует модули с антеннами, а ее наличие существенно удорожает модуль.

Предварительный даташит:

Standby Current -?
И что он в этом режиме делает: отключен или слушает эфемериды?
Время от Standby до фиксации?

Я же написал, документ предварительный. Про standby пока что известно что:
1. Это режим пониженного энергопотребления
2. Вход в режим по проприетарной команде MTK
3. Выход из режима посылкой любого байта.
Предполагаю, что по выходу из режима будет горячий старт.

Нестыковочка сведений. У 570го спячка управляется отдельным пином. Да и в доке пин указан, так что скорее всего такая функция будет.