Wialon Combine

Пока в протоколе не предусмотрена возможность передачи сообщений от сервера к прибору. Будет что то меняться в этом направлении или останется только односторонний обмен?

По сути нужен контейнер произвольного размера, В IPS, аналог сообщения для водителя. Дальше разбор на уровне железа. Для отдельных форматов слишком много вариантов  сообщений. Это и настройки оборудования и передача настроек, управляющих команд, и сообщений внешним устройствам... и много чего еще не придумали но кому нибудь очень нужно

Правильно ли я понимаю из формата протокола, что все подпакеты для пакета дата равноправны и могут содержаться в любой комбинации? Как сервер будет поступать с данными без подпакета gps к какому времени и координатам привязывать значения датчиков?

На сколько понимаю, у Вас в протоколе время является уникальным идентификатором события?
И в протоколе не указано как время из 4 байт вычислять, видимо точность регистрации событий 1 сек, считая от ???, но не суть.

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

Давайте рассмотрим две реальные ситуации, одна из них совсем жизненная.

1.

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

2.

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

Новый протокол бинарный уже поддерживается в предыдущих сборках локальных? С чем связан вопрос - устройство для работы с Wialon, сейчас занимаемся ним, можно ли в устройстве реализовывать один бинарный протокол? Ну, чтобы завтра устройство вышло на связь на сборку например 1401 Pro?

yavi
only IPS v2.0 )
спасибо.

Описание протокола по ссылке не доступно - https://docs.gurtam.net/index.php/s/MYUbNnL497vg0m1

Хочу в свое устройство добавить бинарный протокол для Wialon. Куда можно подключиться для тестов?
Текстовый протокол пытался отлаживать на orange - получалось.

Здравствуйте, коллеги. В процессе просмотра спецификации на протокол, появился вопрос по расширяемым полям. Указано, что поля могут расширяться с 1 до 2х байт и с 2х до 4х. При этом, указателем на необходимость дочитать нужное количество данных, является старший бит. Но старший бит уже будет выставлен для значений байта, больших 127. В таком случае, как выравнивать биты для значений, не требующих установленного старшего бита?
Возьмем для примера поле Type (расширяемое, 1 - 2 байта).  Допустим мне необходимо записать в него значение 256 (0x100). Как будет выглядеть правильно выравненное значение в бинарном представлении?

Как правильно передать на сервер накопившиеся данные при отсутствии связи?
Если передавать по одному пакету и ожидать подтверждение его регистрации, то все работает, но получается достаточно долго т.к. по GPRS пакет из 50 байт идет столько же времени что и 500 байт.
Если в одном TCP пакете отослать пачку сообщений, то сервер подтверждает только первое из них. Если отослать еще одну пачку, то подтверждает второе сообщение из первой пачки и т.д.

Обычная регулярная передача выглядит так:
head type seq len data crc16 , где в data в минимальном варианте есть время и подзапись POSITION_DATA
seq - инкрементируется при создании каждого нового сообщения. Seq уникальна и сохраняется между сессиями и/или выключениями питания.
Т.е. внутри устройства (да и сервера думаю тоже) уникальный ключ это seq + time.
Если передавать пачку сообщений, то получается последовательность:
head type seq len data_1 data_2 data_3 data_n crc16
Получается к одному seq привязана уже кучка сообщений что противоречит самой задумке уникальной seq.
Или я неправильно понял и надо так:
head type seq_1 len_1 data_1 seq_2 len_2 data_2 seq_n len_n data_n crc16

Я передавал так:
head type seq len data crc16 head type seq1 len1 data1 crc16 head type seq2 len2 data2 crc16