Контроль топлива на бензовозе/топливозаправщике; УСС

Сообщение удалено модератором.
Причина: публикация личной переписки в публичном доступе.

Надеюсь совместными усилиями победим данную проблему.

Видимо моих доводов, примеров, споров с участниками форума для определения истины, рейтинга (плюсиков) в ветке, плюсов в карму за посты недостаточно аналитикам для принятия данной задачи в разработку.

alek Наверное модератор удалил мою переписку с саппортом GURTAM до того как Вы увидели.
Так вот суть:
Суть проблемы такова:
Создается датчик счетчик в объекте с таблицой преобразования:
X=0 Y=0
X=200 Y=1
Где X это количество импульсов а Y это литры.
Тип счетчика мнгновенный или дифференциальный.
Когда значения X приходят менее 200 в отчете в результирующей таблице
"Датчики счетчиков" возникаю строки со значением счетчика ноль или какое-то
мелкое добрное число например 0.01. И из-за дребезга и паразитных импульсов
данных строк возникает огромное количество. Даже если на аппаратном уровне
отсеять дребезг УСС, данный сигнал аналоговый и подвержен электро-магнитным
помехам и 100% мы не исключим паразитные импульсы, мы их просто минимизируем.

Вторая ситуация в том, что на некоторых терминала счетчик дифференциальный
и количество импульсов постоянно накапливается.
В один прекрасный момент параметр у трекера переполняется и сбрасывается в
ноль, из-за этого в результирущую таблицу попадает значение счетчика со
знаком минус. Тип датчика дифференциальный с переполнением (2 байта) не
всегда подходит, так как я понимаю что в 2 байта можно уложить число 65535, а
некоторые терминалы превышают данное значение до огромных значений и
потом сбрасывают в ноль.

Проблема в том, что текущими возможностями ПО Wialon отфильтровать данные
случае невозможно.
Использовать нижнюю границу X в датчике нельзя, так как мы отфильтровываем нули в сообщениях и строки слипатся в одну. (Почему описывал в посте 6 в этом топике:http://forum.gurtam.com/viewtopic.php?id=9539).

Хотелось бы что-бы была некая нижняя граница и верхняя граница которая
применяется уже к результирующиму значению в столбце "Счетчик" в таблице "Датчики счетчиков".
Если значение не укладывается в эти границы, то строка не выводится в отчет.

В идеальном варианте если этот фильтр будет указываться в настройках объекта в датчике
с типом "Счетчик", что бы регулировать данные для каждого объекта
индивидуально. (Это было бы более правильно как например у решений Fort Telecom, данное их решение я описывал выше в посте №77)

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

на вторую половину года

Мельком прочитал тему, пока не нашел для себя проблемы с УСС. Привожу пример, стоит УСС 10 импульсов на литр с обнулением. Во вложении график расчета, все что меньше 0,5 литра считается нулем, проблем нет, большинство нулевых значений в отчете исчезает.

Ну во первых, если идет поток топлива из бензовоза и я примерно знаю периодичность записи пакетов (что в принципе настраивается под определенные цели), я могу определить минимально возможное количество импульсов на отрезке времени, тем самым я максимум откину суммарно литр с первого и последнего сообщения раздачи. Да и раздачи обычно на несколько порядков больше.

Согласен, для каждой задачи необходимо подбирать решение индивидуально, но например 20 раздач по 200 литров, итого 4000 литров, 20 из которых отсеялись (причем не факт что отсеятся, так как мы не можем утверждать что до первой записанной точки в раздаче нальется менее 0,5 литра топлива) составит 0,5 процента. А смотреть портянки из нулей в таблице это явно не выход. Клиентские бензовозы разливают и 500 и 1000 и 5000 литров за раз, так что эти 1-2 литра роли не сыграют.

Всем привет. Подскажите как крепить ДУТ внутри цистерны чтоб его не поломало? Спасибо

Добрый день.
Кто-то сталкивался с мелкими выдачами по счетчику, 0.1 - 1 литр, как их можно отфильтровать?

вторая половина года, ну ок, потерпим.