Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
vad_98 приветсвую! Проблему TK-SK увидел, отразил это в посте #73, я так понял, что пока какогото конкретного решения не принято, идет процесс анализа. Ждем результаты от TK-SK .
OPL,
Прочтите https://docs.wialon.com/ru/hosting/limits/limits
Цитирую:
Ограничения по сообщениям:
Не более 1 сообщения должно приходить от объекта за 1 секунду.
1) ......
3) Не существует 100% правильного алгоритма работы с сообщениями из будущего на стороне платформ. Ни фильтрация, ни ожидание наступления нужного времени в будущем, ни регистрация с текущим временем сервера не может являться 100% правильным, т.к. сама по себе ситуация с сообщениями из будущего не нормальная.
Единственно правильным решением данной проблемы является решение проблемы времени сообщения от прибора. Большинство терминалов позволяет синхронизировать время со спутниками GPS или операторами связи.
Это цитата сотрудника гуртам
Пост номер 68 в этой теме
В моем случае задействована цепочка: терминал-основной сервер-сервер виалон-сервер АвтоГРАФ. .
Из перечисленных серверов в цепочке ---- исключите Виалон (в обсуждаемом случае это решит проблему)
Из перечисленных серверов в цепочке ---- исключите Виалон (в обсуждаемом случае это решит проблему)
Если бы была такая возможность, я бы отключил. Еще раз поясню, завтра от других пользователей отправилась ретрансляция в АфтоГРАФ, с аналогичной проблемой, или я приборы например Навтелекома заведу на сервер конвертации АвтоГРАФа, которые тоже "умеют" иногда слать пакеты с одинаковым временм до секунд , далее в отчеты опять выпадет не верно рассчитанная скорость, и клиенту выпишут не обоснованный штраф за превышение, дальше что??
autokirov@gmail.com, не надо больше комментариев в пустоту, не пишите если глубоко не вникли в проблему. Вопрос не почему превышения, а в том , что выписываются штрафы денежные , на основании отчетов из АвтоГРАФа, которые являются отчетами с ошибочно рассчитанной скоростью. Именно про это я говорю. Требуется исключить формирование отчетов с ошибкой.
Уважаемый TK-SK уже пояснил, что увидели проблему, анализируют. Ждем решения.
OPL,
Ваш трекер "забегает в будущее" но не генерирует по несколько записей с одинаковым timestamp
Одинаковый timestamp генерирует Виалон в рассматриваемом случае
Пересылку на сервер АвтоГРАФ с виалона замените пересылкой с Вашего невиалон-сервера если не имеете желания обновить firmware трекеру
Или воспользуйтесь пересылкой на второй сервер с трекера
Или замените трекер
И мне рот не затыкайте, я называю пути реально решающие Вашу проблему
, или я приборы например Навтелекома заведу на сервер конвертации АвтоГРАФа, которые
OPL
Прибор напрямую на сервер конвертации АвтоГРАФа
Не равен пересылке с виалона
Потому что именно виалон изменил timestamp из будущего времени в серверное время
Породив Вашу ситуацию
Исключите из цепочки виалон либо обновите трекер
Ваш сервер обязан уметь пересылать более чем на один сервер, добавьте пересылку с Вашего сервера на сервер конвертации АвтоГРАФа
Естественно пересылку с виалона придётся отключить чтобы не задвоить
И мне рот не затыкайте, я называю пути реально решающие Вашу проблему
Спасибо именно ваша помощь мне пока не требуется, все что вы написали я уже давно отразил в своем посте #50.
Я 15 лет занимаюсь мониторингом транспорта, с различными платформами и железом, ваши предложения уже в первых страницах темы обсудили, и еще раз дублировать повторно это не требуются.
Воспользуйтесь поиском , прежде чем по 10 раз написать одно и то же. Пожалуйста, не засоряйте тему одной и той же информацией.
надо работать не 12 часов а головой / стив джобс
Не стоит прогибаться под изменчивый мир – Пусть лучше он прогнется под нас ....
А зачем "сыпать" сообщения чаще 1 сек ? Приемник "писать" координаты чаще секунды не умеет, переферии опрос куда реже, а если приходит событие в сообщении со "старыми координатами", или "сверхновым временем" так может и "автографа связка запутатся"......
Я встречал сравнительно недавно случай в ПО автограф когда ТС со скорости около 90 за три секунды скакануло до 160 и обратно. Прям "топфюэл" класс какой то.
Оставлю пару своих слов. По мне тут проблема с блоком, в его настройке. Что бы не так часто отправлял точки и проблем с превышением. Как я вижу Автограф суммирует скорости за 1 сек.
Удивительная ветка, тут тебе и недоделанные отчеты от интегратора, выдающие нереальные данные на основе которых клиент выставляет не глядя счета и кривейшие сообщения от нонейм терминалов... Мда.
Оставлю пару своих слов. По мне тут проблема с блоком, в его настройке. Что бы не так часто отправлял точки и проблем с превышением. Как я вижу Автограф суммирует скорости за 1 сек.
сам блок ничего не суммирует да и по тоже скорее всего
....Потому что именно виалон изменил timestamp из будущего времени в серверное время
Породив Вашу ситуацию. Исключите из цепочки виалон либо обновите трекер
Сегодня я просто для примера взял в виалоне прибор СМАРТ-2333, открыл сообщения от прибора, и что, картина маслом, пожалуйста , прибор шлет кучу сообщений с одинаковым timestamp. (образец на приложенных скринах).
Тут врядли виалон менял чтото от прибора, как прислал, так и записал.
Заметте, повлиять в данной ситуации ни на виалон ни на прибор я не могу.
Если я начну это прибор ретранслировать в АвтоГРАФ, подозреваю, что там опять возникнет в отчетах выдуманная скорость, с превышениями.
И этот клиент легко нарвется на не обоснованный штраф за превышение.
А ретранслировать например надо и вариантов других нет.
Хорошо, даже если я на прямую заведу в АвтоГРАФ этот прибор, через транскодер, так он туда же, таких же сообщений нашлет, с одинаковым timestamp ну и далее в отчеты опять скорость с превышениями.
Вот вам и пример, что дело не в виалоне. В отчетах просто не надо обрабатывать эти ошибки с одинаковым timestamp, чтобы не искажать реальную скорость объекта, вот и все что требуется от ПО АвтоГРАФ.
Ждем от TK-SK информацию по обработке этой ситуации.
Несчитаное множество 2333 сквозь конвертер техноком в софте АвтоГРАФ с достоверной скоростью имею (без посредника виалон)
Описанный выше случай - объясняется игнорированием рекомендаций обновлять firmware после ролловера GPS
Заметте, повлиять в данной ситуации ни на виалон ни на прибор я не могу.
Если я начну это прибор ретранслировать в АвтоГРАФ, подозреваю, что там опять
именно что можете повлиять , обновите firmware
и попробуйте а не поливайте грязью качественный софт основываясь на подозрениях вместо опыта проверки
opl по скриншоту (пример ситуации со временем 08.15.20) видно, что приходят сообщения об ударе (event_code 4513 -- датчик слабого удара, event_code 4529 -- датчик сильного удара). Поэтому зарегистрировалось сперва 2 сообщения в одной секунде. Это событийные сообщения с высоким приоритетом, поэтому есть вероятность что более чем одно сообщение попадет в одну секунду.
Также по msg_type A и T мы видим что одни и те же сообщения приходят как рядовые (тип А) и внеочередные (тип Т). Такова логика прибора, заложенная производителем намеренно. При желании можно отключить данную функцию (внеочередной отправки Т сообщений, в разделе Передача данных - отключить передачу внеочередных сообщений), и будет приходить только тип А.
Что касается сообщений с кодом event_code=5893 означает что сообщение сформировано изменением по курсу. Т.е. скорее всего в настройках прибора установлена слишком большая чувствительность изменения курса.
Вероятность того, что 2 (и более) сообщения в одной секунде исказят трек Wialon и уйдут в неправильном порядке через ретранслятор есть. Это справедливо для всех типов устройств.
Но говоря о навтелеком на примерре ваших сообщений, если отключить внеочередную регистрацию T сообщений скачки на треке будут либо минимальными, либо вообще будут отсутствовать. Также возможно стОит пересмотреть настройки регистрации событий, возможно чувствительность тех же ударов и другие датчики на стороне железа настроены на слишком большую чувствительность.
opl по скриншоту (пример ситуации со временем 08.15.20) видно, что приходят сообщения об ударе (event_code 4513 -- датчик слабого удара, event_code 4529 -- датчик сильного удара). Поэтому зарегистрировалось сперва 2 сообщения в одной секунде. Это событийные сообщения с высоким приоритетом, поэтому есть вероятность что более чем одно сообщение попадет в одну секунду.
Также по msg_type A и T мы видим что одни и те же сообщения приходят как рядовые (тип А) и внеочередные (тип Т). Такова логика прибора, заложенная производителем намеренно. При желании можно отключить данную функцию (внеочередной отправки Т сообщений, в разделе Передача данных - отключить передачу внеочередных сообщений), и будет приходить только тип А.
Что касается сообщений с кодом event_code=5893 означает что сообщение сформировано изменением по курсу. Т.е. скорее всего в настройках прибора установлена слишком большая чувствительность изменения курса.Вероятность того, что 2 (и более) сообщения в одной секунде исказят трек Wialon и уйдут в неправильном порядке через ретранслятор есть. Это справедливо для всех типов устройств.
Но говоря о навтелеком на примерре ваших сообщений, если отключить внеочередную регистрацию T сообщений скачки на треке будут либо минимальными, либо вообще будут отсутствовать. Также возможно стОит пересмотреть настройки регистрации событий, возможно чувствительность тех же ударов и другие датчики на стороне железа настроены на слишком большую чувствительность.
согласен с ним
yavi благодарю вас за комментарий, я думаю autokirov@gmail.com прочитал ваш пост и понял, что про ролловер GPS, он как обычно пустил воздух.
Я знаю про эти особенности приборов Навтелеком, прибор настроен именно так как нам нужно, с высокой чувствительностью и на передачу внеочередных сообщений. Все что вы описали, это все необходимо и прекрасно обрабатывается виалоном. Прибор работает исправно, в соответствии с заложенными в него алгоритмами. Это не проблема, а нормальная работа прибора с учетом формата FLEX 2.0 Навтелеком в виалоне.
Еще раз повторяю, для тех, кто в танке не смог прочитать всю ветку, и пытается привязаться к прибору, дело не в приборе, а в дальнейшей обработке в ПО АвтоГРАФ этих сообщений с одинаковым timestamp, как результат формирование отчета в ПО АвтоГРАФ с ВЫДУМАННЫМ превышением скорости.
Вероятность того, что 2 (и более) сообщения в одной секунде исказят трек Wialon и уйдут в неправильном порядке через ретранслятор есть. Это справедливо для всех типов устройств.
Спасибо, это и пытаюсь донести до TK-SK, и то что далее, когда ПО АвтогГРАФ получив такие сообщения, формирует в отчетах не корректнно рассчитанную скорость.
можно ли считать нормальной работой то, что противоречит рекомендации разработчиков платформы?
https://docs.wialon.com/ru/hosting/limits/limits
Фактически нарушено требование обоих платформ по частоте сообщений.
yavi благодарю вас за комментарий, я думаю autokirov@gmail.com прочитал ваш пост и понял, что про ролловер GPS, он как обычно пустил воздух.
Я знаю про эти особенности приборов Навтелеком, прибор настроен именно так как нам нужно, с высокой чувствительностью и на передачу внеочередных сообщений. Все что вы описали, это все необходимо и прекрасно обрабатывается виалоном. Прибор работает исправно, в соответствии с заложенными в него алгоритмами. Это не проблема, а нормальная работа прибора с учетом формата FLEX 2.0 Навтелеком в виалоне.
Еще раз повторяю, для тех, кто
в танкене смог прочитать всю ветку, и пытается привязаться к прибору, дело не в приборе, а в дальнейшей обработке в ПО АвтоГРАФ этих сообщений с одинаковым timestamp, как результат формирование отчета в ПО АвтоГРАФ с ВЫДУМАННЫМ превышением скорости.
У нас тоже всё обрабатывается, когда данные идут с самих приборов как есть, а не какие-то склеенные пачки с Виалона к тому же с искаженным временем по часам сервера с Виалоном.
У Вас там уже однозначно недостоверные данные, раз время искажено на серверное, да еще и куче точек поставлено одно и то же.
Задача софта не красивую картинку получить искусственными методами, а достоверно отобразить то, что пришло. Есть соответствующие ГОСТы.
Целостность навигационно-информационной системы: Способность системы выдавать своевременные и достоверные сообщения о возникающих отказах и сбоях ее элементов.
Примечание: А не вуалировать отказы и кривую работу её элементов.
В случае обнаружения нарушений нормального функционирования навигационно-информационной системы, влияющих на качество системной навигационной информации, должны формироваться сообщения, содержащие признаки неисправностей, которые должны учитываться при управлении режимами работы навигационно-информационной системы.
Примечание: А не вуалировать отказы и кривую работу её элементов.
При таких искажениях вообще нельзя говорить ни о какой о достоверности навигационной информации и тем более о "правильной скорости", которая "как-то" берется из целой пачки значений непонятным методом (в пачке из постов выше крайние значения скорости у входящих в пачку точек с одинаковым временем отличаются аж в 3 раза от 17 до 51 км/ч) в которой у каждой точки одно и то же время и к тому же это время приема сервером, а не с навигационного приемника.
yavi пишет:Вероятность того, что 2 (и более) сообщения в одной секунде исказят трек Wialon и уйдут в неправильном порядке через ретранслятор есть. Это справедливо для всех типов устройств.
Спасибо, это и пытаюсь донести до TK-SK, и то что далее, когда ПО АвтогГРАФ получив такие сообщения, формирует в отчетах не корректнно рассчитанную скорость.
Я уже спрашивал Вас, что такое "корректно рассчитанная скорость" для секунды в которой содержатся несколько навигационных точек с одинаковым временем у которых крайние показания скорости отличаются аж в 3 раза от 17 до 51 км/ч ?
Вот Вам точки:
17:51:23 - 34 км/ч
17:51:23 - 47 км/ч
17:51:23 - 17 км/ч
17:51:23 - 25 км/ч
17:51:23 - 51 км/ч
17:51:23 - 18 км/ч
Какая же в этой точке "корректно рассчитанная скорость" и как она получается из этих значений ? Можно "корректный и правильный алгоритм" в студию ?
О том, что между этими точками на самом деле еще и расстояния от единиц до десятков и может даже сотен метров, хоть они все и спрессованы в 1 мгновение, мы пока даже и вспоминать не будем.
можно ли считать нормальной работой то, что противоречит рекомендации разработчиков платформы?
https://docs.wialon.com/ru/hosting/limits/limits
Фактически нарушено требование обоих платформ по частоте сообщений.
Там вообще не в частоте сообщений дело (прибор не слал такие пачки с одинаковым временем), а в том, что пересылающий софт спрессовывает точки с разным временем (хоть оно и в будущем идет с прибора, но хотя бы может кол-во секунд между точками соответствует скорости и расстоянию в этих отрезках) в пачки, ставя все этим точкам одно и то же время, равное времени приема этих точек от терминала сервером, хоть эти точки и были приняты терминалом в совершенно другое время, которое непонятно на сколько отстоит от времени их приема сервером.
