АвтоГРАФ GSM

Когда я собираюсь потратить несколько миллионов - я всегда сомневаюсь. )))
В адаптивном режиме получена следующая последовательность точек:

Время Дистанция Скорость
6:47:05    94,8   26,2
6:47:15    74,6   26,8
6:47:49   167,7   17,8
6:48:11   187,0   30,6
6:48:12     6,4   23,0
6:48:22    75,7   27,3

Скорость рассчитана диспетчерским ПО АвтоГРАФ, т.е. это средняя скорость по участкам между точками. Максимальная скорость на участке длиной 187 метров, возможно, была больше 30,6 км/ч. Вопрос: при каком характере движения на данном участке терминал обязательно поставил бы дополнительную точку между 6:47:49 и 6:48:11? Т.е., например, можно ли утверждать, что скорость 40 км/ч не была достигнута?
Направление движения не менялось.

Получается, что на каждом участке между записанными точками максимальная скорость не более чем на 1 секунду превышала среднюю? Оригинально! А минимальная скорость на этом же участке учитывается?
Если исходить только из этого условия записи точек, то при чередовании плавных разгонов и торможений терминал в зависимости от порядка обработки начального (единственного) значения скорости или будет писать точки каждую секунду, или не будет писать их вообще. Но этого не происходит - фиксируются начало и конец разгона.
А настройка минимального интервала записи точек от 1 метра - это, как выясняется, лукавство. Если терминал может определять скорость только 1 раз в секунду, а машина движется не со скоростью пешехода, то реальный минимум - 5-20 метров. Согласно документации - это рекомендуемые значения.

Почему ? Я не знаю, рассчитанная это скорость или измеренная. Если у Вас включена запись вектора скорости в терминале, то измеренная в точке записи координат, если не включена, то рассчитанная ПО.
И, кстати, какова дистанция нечувствительности у данного терминала в адаптивном режиме ?

Added after    3 minuts  1 seconds:

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

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

Вот именно ! Что бы Вам ни написали "конкуренты" или даже я - это не есть повод успокоиться. Ну если уж пошел задушевынй разговор - что мешает мне тут Вам наврать с три короба ? Проверить мои слова в плане кода прошивки Вы никак не сможете.
Самое правильное - когда устраиваются ходовые испытания, потому что даже если производитель заложил в прошивку некий озвученный алгоритм, не факт, что он на самом деле работает именно так, как задумано. Это же программа... которая может содержать пусть не прямые ошибки, но... скажем так - неучтенности, а-ля по алгоритму надо точку записать, но некое прерывание забирает управление на себя и т.п.
Рекомендую провести такие испытания - это несложно.
А выкладывать здесь алгоритмы, на отладку которых потрачены годы, на блюдечке для начинающих производителей железок - увольте.

P.S.: Omnicomm никто не просил дать полный алгоритм обработки показаний их LLS ? Ссылаясь, что иначе LLS работает непредсказуемо для пользователя... Многим было бы интересно его получить...

Есть ещё один источник данных о движении - акселерометр.

Из моего письма дилеру: "При анализе аварии / ДТП важно выяснить характер движения транспортного средства непосредственно перед местом события: какая была скорость и в какой момент началось торможение - за 100 метров, за 10 или вообще не начиналось". Также был пример трека от другого терминала с недостаточным для анализа количеством точек и вопрос о том, сколько точек записал бы АвтоГРАФ. Дилер предложил мне почитать руководство к конфигуратору. Там я ответа не нашёл и написал в Техноком (на адрес, указанный в руководстве). Ответа нет, поэтому я здесь. "Домысливаю" и "додумываю", пытаясь исходный вопрос разложить на более простые.

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

Не передергивайте. В предыдущем посте речь шла о непредсказуемости для пользователя, а не для специалистов по распознаванию лиц. Кстати, если Вы знаете кодирование JPEG, Ваш вопрос про кол-во оттенков красного - лишен смысла.

Смешно. Тогда надо вернуться к паровозам, а лучше - к лошадному способу передвижения.
Зачем мы делаем все эти анализы, фильтрации выбросов, уникальные, годами полируемые алгоритмы и многое другое - самое простое - тупо выводить все как есть. Проще некуда... )))))))))))
Есть один достаточно известный производитель, у него сливы топлива долгое время детектировались как порог в литрах "на 10 предыдущих точек трека". Просто, понятно, но... хреново.

Added after    7 minuts  18 seconds:

А кто его знает ? Для этого надо воссоздать точный профиль движения транспортного средства (вектор скорости, 3D-вектор ускорения) и прогнать его через алгоритм.
На основании КАКИХ данных дилер мог сказать Вам количество точек ? На основании нескольких "недостаточных" точек чужого терминала, который непонятно по какому принципу он записал ?
Вы задали дилеру изначально некорректный вопрос.

Added after    9 minuts  22 seconds:

Это прямо иллюстрация к известному высказыванию: У любой сложной проблемы есть ясное, простое и неправильное решение.

А драйвера устанавливали?

http://www.tk-chel.ru/zagruzka-fajlov/index.php
в самом низу...
И для терминалов не последних серий - отключите в драйвере виртуальный ком-порт.

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

А может, и не надо ничего делать? У меня на таком же трамвае Телтоника ездила, треки показывала не хуже. Правда, событий было намного больше.
Проблема не в том, что в АвтоГРАФе реализован некий ценный алгоритм. Проблема в том, что это единственный алгоритм работы. Пользователь должен или верить, что "всё будет хорошо", или обходиться записью по времени.
При этом некое подобие критикуемого упрощённого подхода конкурентов у АвтоГРАФа тоже есть (вкладка "События" в конфигураторе). Но из параметров движения там только скорость и ускорение. Были бы ещё изменение скорости и изменение курса (как у конкурентов) - мой вопрос вообще не возник бы.

Вы же верите в различные системы курсовой устойчивости и алгоритмы функционирования ABS, которые весьма разные у каждого автопроизводителя. Или пользователи тоже где-то запрашивают и изучают эти алгоритмы ? )))
Или там алгоритм работы распознавания лица в фотокамере. Тоже не припомню, чтоб выкладывали фотопроизводители...
Бесполезно дилера Canon спрашивать, что дескать "вот мой сосед с такой вот ряхой, так никон его лицо распознает в 7 случаях из 12, а Ваш Canon  в скольки его случаях распознает ?" - не даст Вам дилер ответ или даст чисто "от фонаря".

Всё это многофакторные алгоритмы. Вы когда-нибудь банально расписывали, как в школьно-институтские годы на уроках физики - какие силы / ускорения действуют на автомобиль ? Или Вы думаете, что есть только вектор ускорения, направленный вдоль оси движения автомобиля ? На авто, особенно при маневрировании, действует целая куча сил / ускорений, суперпозицию которых отлавливает акселерометр, а микропрограмма процессора анализирует её, сопоставляет с координатно-скоростными данными с навигационного приемника и принимает решение: записывать или не записывать точку трека.
Банально значения скорости, вычисленные по  координатам, по доплеру с приемника и по данным акселерометра - могут иногда сильно отличаться в силу разных причин...

А что касается "У меня на таком же трамвае Телтоника ездила, треки показывала не хуже" - так есть, к примеру, люди, которые не видят разницу между Full HD BD-RIP фильмом в 15 Гб и сильно зажатым MPEG в 600 Мб с DVD... Ну или, что чаще встречается, не чувствуют разницу между звуком с 2-раз переписанной кассеты и DVD-Audio на аппаратуре за тысячи евро...
Или возьмите такую известную программу просмотрщик картинок ACDSee, там есть выбор алгоритма увеличения/уменьшения изображения: биквадратный, бикубический, по соседним пикселам, Bell, B-Spline, Lanczos, Mitchell, ClearIQZ... Что толку спрашивать, какой будет лучше для "съёмки вышеуказанного красного пиджака на закате пасмурного летнего дня" ? Никто Вам этого не скажет с такими невнятными условиями задачи.
Проводя аналогию, люди пишут сложные и умные алгоритмы увеличения / уменьшения фото, принятия решения о цвете той или иной точки, а для Вас и по соседним пикселам хорошо. Каждуй точку превратил в квадратик 4х4 точки - вот и увеличение картинки в 4 раза... Пусть жестко ступеньками, зато просто и понятно )

С другой стороны - я же не знаю алгоритмов телтоники, и Вы не знаете. Может они дают Вам покрутить пару параметров, но решение реально принимается на основании еще десятка факторов, которые Вам недоступны для регулировки... Или данные крутилочки влияют с сильным коэффицентом ослабления, к примеру, чтоб свести к минимум вмешательство пользователя.
Или они Вам выложили свой программный алгоритм ?

Added after    4 minuts  47 seconds:

Это вообще другой функционал и он не имеет никакого отношения к рассматриваемому вопросу.