Позволю себе вынести и сюда проблему:

с 15.09.2017 на некоторых местностях у модулей на MT3333 стала пропадать навигация. Выгдядит как плавная потеря всех спутников, и GPS, и ГЛОНАСС.
Через некоторое время (5-30 минут) все восстанавливается, опять начинаем видеть спутники по-максимуму.

На форуме Гуртама создана по этому поводу тема

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

Как стоит устройство какой версии чипы и прошивка. Тут много если. Пока тех подробностей вашей проблемы никаких. На форуме Гуртама вы говорите о паре спутников.

На форуме Гуртама я ничего не говорю. И там речь вообще не про наши устройства.
А прошивка в модуле, если кому интересно: AXN_3.60_3333_14042516,0000,B04V60SIM33ELA9,1.0

Старовато фирмваре.

Крайняя версия
B06V10SIM33ELA1 and B06V10SIM33ELA9
Based on AXN5.1_C33_SDK_00

vs
AXN_3.60_3333_14042516,0000,B04V60SIM33ELA9,1.0

Т.е. в более свежих версиях откатились назад? Интересно узнать, почему.

ядро AXN5.1 как-то свежее чем AXN3.6 - где тут откат назад?

CADiLO, глаз замылился, увидел только 60 и 51...

Предварительные итоги изысканий совместно с MT:

* FACTORY RESET помогает. (даже однократная посылка)
* работа только на ГЛОНАСС тоже помогает (работает отлично, кстати)
* работа только на GPS НЕ помогает.
* отключение AIC НЕ помогает.
* отключение QZSS НЕ помогает.
* отключение EASY НЕ помогает.

а теперь фишка:
* после FACTORY RESET невозможно инициализировать модуль! Хотя при инициализации отключаются дифпоправки (SBAS), модуль так и прололжает их использовать
(проверялось прошивкой на прежнюю "боевую" версию, где они всегда отключаются, устройство после этого перезагружалось)

Ведется проверка на воздействие PMTK_CMD_CLEAR_FLASH_AID. Посмотрим, поможет ли...

Сколько собирается таблица EASY? Сколько дней она действует, если обновлять ее не получается?

at least 5 minutes full operation
at least 6 satellites in view
at least a carrier-to-noise ratio (C/N) of 40 [dB Hz] for each satellite in view
3 дня может предсказывать.

Mihail Gluhowchenko, это официальная информация? Тогда еще один повод не доверять MTK.
- эфемериды спутник передает каждый исключительно свою.
- альманах передается 12.5 минут

Как можно предсказать орбиты ВСЕХ спутников на 3-е суток вперед, вычитав только 6 из них, и даже не прочтав альманах? Магия?
Есть тут одна тема, где обсуждалось предсказание у SiRF...


PS:
Тут попутно вычитал, что у MTK есть еще некая HotStill™, а как с ней дела? И имеется ли она в ядре AXN3.60? Как ее отключить?

PPS:
А HotStill™ и EASY™ к каким группировкам спутников (навигационным системам) применимы?

Добавлю
* PMTK_CMD_CLEAR_FLASH_AID тоже НЕ помогает.

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

Да возможно рассчитать траектории относительно позиции.

Mihail Gluhowchenko,
с МТ-Systems сейчас плотно общаемся, Mediatek в курсе проблемы и сама чешет репу!
Просто на форумах иногда ответы появляются раньше, чем сработает техподдержка.
Да и N голов лучше чем 1-2-4 головы.

Добавление:

* FACTORY RESET помогает до поры - до времени. Т.е. тоже не панацея.
Сегодня, 29.09.1017 около 04:00 UTC опять начались проблемы.

Добрый день!

Я полностью поддерживаю Эдуарда - в версиях 5.0 и 5.1 проблем не замечено, суточные логи дают одно-два события "невалидные координаты" по одной секунде.
На сегодня самая свежая из официальных версия MT3333_AXN5.1.1_FW_General(Official)_GNSS
Кстати, она нормально поддерживает Галилео.
Есть возможность поставить ограничение на минимальный уровень сигнала, принимаемого в решение. Это здорово помогает тем, кто хочет увидеть, в какой именно гараж въехала машина...

Добрый день
У меня информация по поводу версий вот такая
AXN3.8 latest version of firmware.
Next release under test AXN5.0 version.

Собственно 5 как бы не стабильна. Или я что то путаю?

Вашей информации как минимум год.
Потому как 5.0 уже проехали и примерно с августа используют 5.1

Мы купили GTOP вот разбираюсь чего они там натворили и куда идут. Спасибо.

Владимир, это, конечно, хорошо, что на 5.1 проблем не наблюдается...
Но, что делать, если N тысяч катаются с прошивкой 3.6? И 5-10% ведут себя неадекватно (зависит от региона)?

Думал, прошивка навигационных модулей по причине их кривого п/о прошла вместе с модой на ГЛОНАСС (последний раз прошивали SKYTAQ и ГЕОС)...


И где гарантия, что у МТК это снова не повторится, когда опять скорректируются/поменяются орбиты Navstar спутников?

Вы не можете обновить девайсы по воздуху? Сеть GSM то они не потеряли, в чем проблема?

Обновить СВОЙ девайс по воздуху не проблема. Проблема обновить фирмварь стороннего МОДУЛЯ!
Таких задач не ставилось. Загрузчик такого не знает. А писать фирмарь, который обновит модуль..... Ну как бэ.. Через Ж можно сделать все.

(Фирмварь устройства 100 кб размером, флеши в контроллере 128 кб. Фирмварь модуля - 500 кб!!! Ж большая!)

PS:
Хорошо что унитазы не надо пока перепрошивать, прежде чем сходить.....

Это до нас ещё не докатилась мода на уровень сахара и прочих сопутствующих.

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

Попалась тут мне в руки зубная щетка, так там как раз содержимое EEPROM улетело, вот и перестала нормально зубы чистить....
Такими темпами и до унитазов докатимся.

По утверждению Медитека, проблема решена в прошивках 3.8 моложе 18 апреля 2016, а также всех 5.х.
К сожалению, тут ничего не попишешь - потребители хотят зафиксировать прошивки, а порой получается зафиксировать баги...

Володя,

кстати FYI,
на гуртамовском форуме народ трет что весь юблокс начал сыпаться, после того как 15 сентября вступил в работу новый спутник QZSS #194

Коллеги, друзья! После всех проверок с МТК было зафиксировано решение(я):

- Решение №1: обновить ПО приемника (версию ПО - уточнять у дистри или ко мне в ящик batuevточкаbatorсобакаsim.com);

- Решение №2: ввести алгоритм отключения QZSS в навигационных рассчетах.
Нужно подать команду $PMTK352,1*2B (не 2A!!!) при старте. Перезагружать модуль не нужно. Эта команда сохраняется в VRTC RAM, если ножка vbackup все время запитана. Если vbackup не запитана, то команду надо подавать при каждом включении приемника. Ответ модуля на команду «$PMTK001,352,3*34» говорит об успешном отключении QZSS. Способа проверки включен ли QZSS в навигационных рассчетах или нет не существует.
Перед тем как подать команду $PMTK352,1*2B важно удалить старый альманах из памяти приемника. Удаление альманаха достаточно провести один раз, далее – подаем только $PMTK352,1*2B. Альманах хранится в VRTC RAM, поэтому его можно удалить, сняв питание с ножки vbackup или подав команду $PMTK104*37, если vbackup все время запитан.

Решение №3: перезагружать приемник каждые 2 часа.

За $PMTK352,1*2B - браво. Во всех даташитах CRC в примерах PMTK352 указана неверно.

Батор,
А диод между VCC и V_BACKUP часом не установлен? Если установлен, то отключение V_BACKUP ничего не даст.

Ну, так скажем, не во всех.
К примеру, у u-blox

У меня, вобщем то, NMEA CRC считается автоматом, поэтому мне до лампочки, что там по даташиту.

Если не читать секцию "Example" у SIMCOM, то все остальное там верно:
команда называется PMTK_API_SET_STOP_QZSS,
при параметре TRUE (1), QZSS вполне логично будет отключаться.

Я до этого додумался еще до рекомендаций MTK и SIMCOM.... Вот только модуль, видать, упорно не хотел отрубать QZSS!




К сожалению. это решение - тоже не решение.... Модуль живет своей жизнью...
Замечено, что модуль не всегда отрабатывает команды инициализации.
Алгоритм вроде верный:



Таким образом, понять, выполнена ли инициализация модуля - невозможно!
Возможно, модуль в каких-то случаях отвечает ""$PMTK001,Cmd,2" (2= Valid command / packet, but action failed), состояние не контролируется...
Ответа по этому поводу жду 2 недели....

Плясать с бубном больше не могу - бубен сломался!

Добрый день!

Если нужно - информация от первоисточника.
2014/1/22 Add "MTK_Set_CustomizationStn_Output" to config "GPTXT" and "PMTK010".
2014/4/10 Add "MTK_Set_PMTK_CMD" to input PMTK command through SDK.
2014/5/12 Support PMTK299 on/off debug mode.
2014/4/18 Support 1PPS sync NMEA feature.
2014/7/28 PMTK886 support aviation and balloon
0 : normal mode
1 : fitness mode
2 : aviation mode
3 : balloon mode
2014/10/22 Fix Glonass issue.
2014/10/26 Add xPPS feature.
2016/1/21 Support GNSS Jamming Scan
2016/3/1 Support PMTK306/308/406/408
2016/3/7 GLP official release. Support GLP LNA control pin configuration by SDK API.
2016/4/21 Fixed Sky plot would not update issue by PMTK command disable QZSS issue
2016/5/5 New Jamming Scan
2017/2/18 GLP LNA control pin can be configured by Core Builder, but this feature is disabled by default,

Сейчас для МТ3333 наиболее рекомендуемая версия AXN5.1.1.

Это по версиям и их возможностям.

Теперь о самой проблеме.
This issue caused by QZSS #194 that is new operation at 9/15 this year. Before it, all update procedure are correct.
So, this issue happened after 9/15.
Let me explain it more detail. After implement the solution, MTK can guarantee this issue will not happen again.

Issue Symptom:
The receiver reported sky view do not change. After long operation duration (>2 hours) without power off, hot start, hardware reset, the unchanged sky view cause the receiver only track few satellites and result in positioning drift or no fix.
Sample for Sky view no change.
<image003.jpg>

Root Cause:
The elevation angle update mechanism is designed to update single satellites at 1 second. When the valid QZSS #194 almanac is received, it is the high priority SV that need to update its elevation angle. However, the elevation angle update function doesn’t recognize #194 SV. It returns a failure and the updated loop is end in this second. The next second, the #194 almanac is still keep in the high priory list that need to update its elevation angle. So the continued failure update of #194 elevation angle caused all GNSS elevation update mechanism stuck.

Solution:
1. Fix the elevation update function do not accept QZSS #194 almanac problem.
2. New monitor mechanism to detect the stuck elevation angle update problem and force update all GNSS’s elevation angle

И еще вдогонку.
Если в данной местности спутники QZSS не видны (как, например, в Питере), то проблему выявить невозможно.
Если спутники видны, то самое простое и безобидное - рестарт горячий каждые полчаса-час.
Минимальная потеря времени из-за отсутствия навигации.

Медиатек сам в шоке, что такая мелкая деталь вызвала столь крупные проблемы.

Многие в шоке от этой ситуации, но медиатек больше всех. Настолько в шоке, что потерял дар речи.
Если оставить в стороне эмоции, то о проблеме известно почти полтора месяца. Как минимум
с 13.10 стало известно о связи сбоев с QZSS. По состоянию на 27.10 ни от медиатека ни от производителя модулей
по-прежнему нет официального репорта по данной проблеме.

Владимир, спасибо за исчерпывающую информацию!

Вот только осталось пара непоняток:


Все в кучу свалили... Тут что FIXED, ошибка обновления неба или невозможность отключить QZSS через PMTK command?




А тут возникает вопрос, в ANX5.1 оба пункта пофиксены или только один из них? Или ждем новой прошивки от MEDAITEK?

По результатам личной встречи с "contact window" Медиатек:
1. В новых версиях ПО поддерживаются спутники QZSS №194 и #195 (выйдет через пару лет), 196 и выше пока не поддерживаются, но до них ждать еще лет шесть.
2. Отключение QZSS работало и работает во всех прошивках, просто была "грамматическая" ошибка в подсчете контрольной суммы, тиражируемая в большинстве документов.
Программы, самостоятельно вычисляющие контрольные суммы, передают корректную посылку.
3. Механизм обновления данных работает по принципу "сначала фикс, потом не менее 10 спутников GPS+GLONASS, потом BEIDOU, потом SBAS и QZSS". По этой причине модуль всегда получает решение независимо от QZSS.
4. Если в старой программе виден спутник QZSS #194 - будет клинч, обновление данных спутников прекратится. Видимые спутники зайдут за горизонт, а новые не будут обработаны. Эфемериды устареют и решение потеряется.
5. ЛЮБОЙ старт (холодный, теплый, горячий, резет) заставляет модуль заново обновить информацию по основным спутникам.
6. Повторение горячего старта каждые полчаса позволяют полностью исключить проблему старой программы.
7. Перед командой выключения спутников QZSS (если это не первое включение питания и в памяти модуля что-то есть) надо стереть RAM модуля командой Полного Холодного Старта
Packet Type: 104 PMTK_CMD_FULL_COLD_START
Packet Meaning:
Full Cold Restart: It’s essentially a Cold Restart, but additionally clear system/user configurations at re-start. That is, reset the receiver to the factory status.
DataField: None
Example:
$PMTK104*37<CR><LF>
8. Механизм обновления "появляющихся из-за горизонта" спутников действительно обновлен, обещают отсутствие ступора.
9. Заменены симуляторы сигналов, на которых проверяются программы. Теперь они могут имитировать не только существующие спутники, но и перспективные.

Владимир, тут как бы противоречие:

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

Как я понимаю, данная настройка сохраняется в RAM, то есть при снятии VBAT она сбрасывается. Таким образом необходимость в подаче команды Полного Холодного Старта отпадает.
А если VBAT присутствует, то разрешение работы QZSS неизвестно (и узнать нельзя!). Но, мы можем иметь необходимые данные для горячего старта, которые стирать каждый раз крайне нежелательно!

То есть, при питании VBAT от ионистора
1. Запретить однократно работу QZSS нельзя, это делать надо каждый раз.
2. Стирать RAM при включении нелельзя, иначе потеряем горячий старт.

Иными словами, ОТКЛЮЧИТЬ QZSS НЕЛЬЗЯ! Косяк....


PS: Владимир, Что за проблемы с производством ML8088? Из-за задержек с поставкой придется, похоже, ставить аналоги в таком же корпусе.

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

Далее:
Как я понимаю, данная настройка сохраняется в RAM, то есть при снятии VBAT она сбрасывается. Таким образом необходимость в подаче команды Полного Холодного Старта отпадает.
А если VBAT присутствует, то разрешение работы QZSS неизвестно (и узнать нельзя!). Но, мы можем иметь необходимые данные для горячего старта, которые стирать каждый раз крайне нежелательно!

То есть, при питании VBAT от ионистора
1. Запретить однократно работу QZSS нельзя, это делать надо каждый раз.
2. Стирать RAM при включении нелельзя, иначе потеряем горячий старт.

Иными словами, ОТКЛЮЧИТЬ QZSS НЕЛЬЗЯ! Косяк....

Не понял.
Если при включении питания произвести корректную процедуру (полный холодный старт, а затем выключение QZSS), то далее все будет корректно работать. И в ОЗУ приемника будут сохраняться требуемые установки.
А уж отследить разряд ионистора несложно - время с приемника пойдет "по умолчанию" до получения данных от спутников. Программным путем "ловится" элементарно.
Добавим, что опять же речь идет о манипуляции со старыми версиями программы.

PS: Владимир, Что за проблемы с производством ML8088? Из-за задержек с поставкой придется, похоже, ставить аналоги в таком же корпусе.
По поставкам ML8088 - регулярно вижу письма о поступлении модулей на склад.
Вы заказывали их?
Основная проблема - крайне длительные сроки поставки навигационного чипа STA8088CFG, превышающие 20 недель. ST теперь держит такие сроки...

>>>ST теперь держит такие сроки...

согласно Commercial_Newsletter_November_2017 уже от 26 до 30 недель.

Я добавлю 5 копеек. Важно, дождаться чтобы RAM полностью очистилась и после подачи $PMTK104 надо выждать 5-10 сек до того как подать $PMTK352.
"before disable QZSS we must clear all RAM data using 104, so when customer send PMTK104 please wait 5-10 seconds".

И еще, чтобы не путаться, решение с отключением QZSS надо разделить на два случая:
1. Vbackup запитан
2. Vbackup не запитан

В первом случае RAM не сбросить отключением основного питания, и сбросится RAM только по команде полного холодного рестарта. Что же тогда с настройкой 352, если она хранится в ней же, в RAM? Ответ - подавать ее ПОСЛЕ холодного рестарта. Проблема уйдет, пока будет живо питание на vbackup.

Во втором случае RAM можно сбросить отключив питание, команда холодного рестарта не нужна. А как же 352, если она хранится в RAM? Ответ - подавать ее при каждом включении.

(Ну, есть и другие решения - горячий рестарт каждые 2 часа или обновление ПО, как тут уже было сказано)

Отлично! В документации этого нет, поэтому - БАГ!

И что так долго ОЗУ стирается? Там гномики перемычки перставляют что-ли?

Вопрос: в новых прошивках исправлено? Или также QZSS можно считать практически неотключаемым?


Вариант
3. Vbackup запитан от ионистора.

Полагаться на предположение, что если сбросились часы, то и RAM сбросилась, особенно зная МТК - нельзя.

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

Коллеги,

а что слышно про наших коллег и их конкурирующий продукт ublox M8 (дешевая rom версия),
они в шоколаде, или тихо помалкивают про перепайку миллионов трэкеров ?

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

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

Еще, до кучи, добавлю, что в AXN5.1.1 можно включить прием сообщений Galileo RLS (Return Link Service) или RLM (Return Link Message).
Это делается через SDK.