Мы купили 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?