[MIkler 0]

Вашей информации как минимум год.

Потому как 5.0 уже проехали и примерно с августа используют 5.1

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

[Alechek 0]

Я полностью поддерживаю Эдуарда - в версиях 5.0 и 5.1 проблем не замечено, суточные логи дают одно-два события "невалидные координаты" по одной секунде.

На сегодня самая свежая из официальных версия MT3333_AXN5.1.1_FW_General(Official)_GNSS

Владимир, это, конечно, хорошо, что на 5.1 проблем не наблюдается...

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

 

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

 

 

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

 

 

[MIkler 0]

Владимир, это, конечно, хорошо, что на 5.1 проблем не наблюдается...

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

 

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

 

 

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

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

 

[Alechek 0]

Вы не можете обновить девайсы по воздуху?

Обновить СВОЙ девайс по воздуху не проблема. Проблема обновить фирмварь стороннего МОДУЛЯ!

Таких задач не ставилось. Загрузчик такого не знает. А писать фирмарь, который обновит модуль..... Ну как бэ.. Через Ж можно сделать все.

 

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

 

PS:

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

[MIkler 0]

PS:

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

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

 

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

[artemkad 51]

PS:

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

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

Такими темпами и до унитазов докатимся.

[wwo55 0]

По утверждению Медитека, проблема решена в прошивках 3.8 моложе 18 апреля 2016, а также всех 5.х.

К сожалению, тут ничего не попишешь - потребители хотят зафиксировать прошивки, а порой получается зафиксировать баги...

[Telit 0]

По утверждению Медитека, проблема решена в прошивках 3.8 моложе 18 апреля 2016, а также всех 5.х.

К сожалению, тут ничего не попишешь - потребители хотят зафиксировать прошивки, а порой получается зафиксировать баги...

 

Володя,

 

кстати FYI,

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

[batuev.b 0]

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

 

- Решение №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 часа.

 

 

[alex2103 0]

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

[molecul 0]

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

 

- Решение №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 часа.

Батор,

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

[Alechek 0]

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

Ну, так скажем, не во всех.

К примеру, у u-blox

2.31 PMTK352 API SET STOP QZSS

Command purpose:

Since QZSS is a regional positioning service, the command allows the user to enable or disable the QZSS

function.

Default is to disable the QZSS function.

Command number: 352

DataField:

PMTK352,Enabled

Enabled: ‘0’: Enable

‘1’: Disable

Example:

$PMTK352,0*2A : Enable QZSS

$PMTK352,1*2B : Disable QZSS

 

Reply:

$PMTK001,352,3*34<CR><LF>

This message applies only for MT333X based receivers IT530, IT530M, UC530 and UC530M.

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

 

Если не читать секцию "Example" у SIMCOM, то все остальное там верно:

команда называется PMTK_API_SET_STOP_QZSS,

при параметре TRUE (1), QZSS вполне логично будет отключаться.

 

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

 

 

 

- Решение №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 все время запитан.

К сожалению. это решение - тоже не решение.... Модуль живет своей жизнью...

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

Алгоритм вроде верный:

 

вкл. питания модуля.
ждем 2200 мс
ищем NMEA (определяем скорость)
while (инициализация)
{
посылаем следующую команду инициализации
ждем ответ "$PMTK001,..." 3000 мс
}
горячий рестарт
прием координат

 

Таким образом, понять, выполнена ли инициализация модуля - невозможно!

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

Ответа по этому поводу жду 2 недели....

 

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

[wwo55 0]

Добрый день!

 

Если нужно - информация от первоисточника.

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 не видны (как, например, в Питере), то проблему выявить невозможно.

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

Минимальная потеря времени из-за отсутствия навигации.

 

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

[desh 0]

Медиатек сам в шоке.

 

Многие в шоке от этой ситуации, но медиатек больше всех. Настолько в шоке, что потерял дар речи.

Если оставить в стороне эмоции, то о проблеме известно почти полтора месяца. Как минимум

с 13.10 стало известно о связи сбоев с QZSS. По состоянию на 27.10 ни от медиатека ни от производителя модулей

по-прежнему нет официального репорта по данной проблеме.

[Alechek 0]

Добрый день!

 

Если нужно - информация от первоисточника.

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

 

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

 

2016/4/21 Fixed Sky plot would not update issue by PMTK command disable QZSS issue

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

 

 

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

 

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