[Le Fou 0]

Есть железка, от нее хочется получать много логов. Канал коммуникации -- последовательный порт, 115200. Логи типа "dd-mm-h:m:s параметр А принял значение Б" и "dd-mm-h:m:s Начали процедуру С по команде оператора".

 

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

 

И задумался я про какую-нибудь упаковку или сжатие. Количество собственно типов сообщений конечно -- образовать из них словарь. Ну, будут еще параметры -- данные с разных датчиков (real, 4 байта), и timestamp (тоже 4 байта). Это в первом приближении можно слать как есть бинаркой. а можно тоже чего-нибудь наэкономить, свести real к диапазону разумных значений например и втолкать в два байта. (доступа к сырым данным АЦП нет)

 

При том не покидает ощущение, что это какая-то ерунда :01:

 

Дайте совет)

[aaarrr 63]

Есть железка, от нее хочется получать много логов. Канал коммуникации -- последовательный порт, 115200. Логи типа "dd-mm-h:m:s параметр А принял значение Б" и "dd-mm-h:m:s Начали процедуру С по команде оператора".

 

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

Этого времени как раз на две строки и хватит - 115-230 байт получается.

 

При том не покидает ощущение, что это какая-то ерунда :01:

Бинарные логи - ерунда и неудобство сплошное. Нужно иметь очень веские основания для внедрения.

[VCucumber 0]

"dd-mm-h:m:s Начали процедуру С по команде оператора"

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

или в три раза в абсолютных

и коды архиваторов есть в свободном доступе - текст жмётся тоже раз в десять

 

 

 

Нужно иметь очень веские основания для внедрения

таки сабж - важное основание

 

 

[ViKo 1]

Английскими словами короче будет. И сократить слова можно. А больше ничего делать не надо.

[Le Fou 0]

Всем спасибо.

1) Я в прикидках ошибся на порядок)), а получается и правда 11 байт за 1 мс. Не так и страшно, вроде.

2) Логи конечно английские

3) Архиваторы-то да, но заголовки там, фигня всякая -- на коротких посылках оверхед большой. Да и в принципе, словарь-то одинаковый на всю жизнь, не надо его каждый раз составлять. Уж тогда и правда каждому типу сообщения придать номер -- их не сильно больше ста разных планируется.

Месяц опустить, отладка хоть и будет долгой, но не настолько) И слать всё текстом, чтобы с написанием парсера не морочиться.

 

[_4afc_ 24]

Месяц опустить, отладка хоть и будет долгой, но не настолько) И слать всё текстом, чтобы с написанием парсера не морочиться.

Вообще опустить всё кроме секунд/миллисекунд. А полную дату постить в сообщении, только если в ней что-то изменилось кроме секунд.

[zltigo 0]

Бинарные логи - ерунда и неудобство сплошное. Нужно иметь очень веские основания для внедрения.

Могу только сказать, что паковка текстовых логов с целью сократить объем передаваемых данных, еще большая ерунда :(

 

 

и коды архиваторов есть в свободном доступе - текст жмётся тоже раз в десять

КОРОТКИЕ фрагменты ни в какие разы НЕ жмутся. Нифига Вы даже не представляете, как работают архиваторы которые "раз в десять" жмут.

А когда, как пишет Автор - "железка чахлая", то тем более.

[VCucumber 0]

даже не представляете, как работают архиваторы

ну почему же, представляю vxl.gzip.encode(byte[] asource; int acount);

 

 

[zltigo 0]

ну почему же, представляю vxl.gzip.encode(byte[] asource; int acount);

Точно!

Как работает трансформатор? Уууууу....

 

 

[psL 0]

можно попробовать вот такое использовать https://github.com/nanopb/nanopb