Протокол KT-LCD

[13_chip_13]

Зачем этот изврат если и  B1^B2^B3^B4^B5^B7^B8^B9^B10^B11 отлично работает....

А точно,  не досмотрел что изначально СRC неправильно считал paha(старт кадра не входит в расчёт) . Ну а такой изврат с массивов вполне себе использую на других протоколах( там для декодировки/кодировки значений некоторых) ,  потому что не удалось понять зависимость этого ключа.

[p-a-h-a]

Приветствую. Blik86, 13_chip_13 спасибо за ответы. Проблема с последнем байтом ответа контроллера пока открыта. Тут вот в чем дело - этот байт содержит информацию о каденсе.  И когда датчик PAS не установлен, последний байт вроде как и не учитывается в контрольной сумме. Но стоит начать вращать педали и наша модель CRC рушиться.
Про каденс никто не писал в найденных мною расшифровках протокола. Дисплей LCD-6U показывает каденс. Пруф на стр. 10 в разделе "Cadence Display" Инструкция KT-LCD6.pdf
Я выводил этот байт, но там была несуразица. Попробую настройками PAS в С1 поиграть. Дисплей показывает каденс от 0 до 99. После настройки С1 просит ввести количество магнитов.

[13_chip_13]

.  И когда датчик PAS не установлен, последний байт вроде как и не учитывается в контрольной сумме. Но стоит начать вращать педали и наша модель CRC рушиться. 

Логи бы увидеть...  Если это те что выше,  определились же что crc считать по другой формуле надо. А "каденс" - ритм это похоже просто частота вращения педалей в некоторых относительных единицах (вполне возможно и не все 8 бит,  но тут только опытным путем педали разгонять на подвесе и смотреть)

[Blik86]

Проблема с последнем байтом ответа контроллера пока открыта.

В чем проблема?  B0 замените на  B11!!! B1^B2^B3^B4^B5^B7^B8^B9^B10^B11  считает в соответствии с теми данными что вы прислали.

[Калин]

Получения множителя по байтовым данным. https://www.onlinegdb.com/fork/Bk9HMKP3I  В результате первая колонка - множитель, вторая и третья должны быть равны

[Blik86]

Получения множителя по байтовым данным

Что это и зачем нужно?

В результате первая колонка - множитель, вторая и третья должны быть равны

Что я делаю не так?

-

Hello World
0, 3d, 33
1, 3c, 33
2, 3f, 33
3, 3e, 33
4, 39, 33
5, 38, 33
6, 3b, 33
7, 3a, 33
8, 35, 33
9, 34, 33
10, 37, 33
11, 36, 33
12, 31, 33
13, 30, 33
14, 33, 33
15, 32, 33
16, 2d, 33
17, 2c, 33
18, 2f, 33
19, 2e, 33
20, 29, 33
21, 28, 33
22, 2b, 33
23, 2a, 33
24, 25, 33
25, 24, 33
26, 27, 33
27, 26, 33
28, 21, 33
29, 20, 33
30, 23, 33

[Калин]

Что это и зачем нужно?Что я делаю не так?

-

Hello World
0, 3d, 33
1, 3c, 33
2, 3f, 33
3, 3e, 33
4, 39, 33
5, 38, 33
6, 3b, 33
7, 3a, 33
8, 35, 33
9, 34, 33
10, 37, 33
11, 36, 33
12, 31, 33
13, 30, 33
14, 33, 33
15, 32, 33
16, 2d, 33
17, 2c, 33
18, 2f, 33
19, 2e, 33
20, 29, 33
21, 28, 33
22, 2b, 33
23, 2a, 33
24, 25, 33
25, 24, 33
26, 27, 33
27, 26, 33
28, 21, 33
29, 20, 33
30, 23, 33

  14, 33, 33   - Множитель 14

 BYTE[5] = XOR(transferBuffer, TRANSFER_BUFFER_SIZE, 5)^14;
        bitWrite(BYTE[5], 0, true);

[Blik86]

14, 33, 33   - Множитель 14

Суть понял, не понял зачем подбирать множитель если можно сразу считать правильно CRC без костылей в виде множителя.
И если уж считать этот множитель, то добавить одну строчку сравнения и сразу выводить нужный множитель, без кучи бесполезных строк.

ui8_crc = 0;
      for (ui8_j = 1; ui8_j <= 11; ui8_j++) {
         
         if (ui8_j == 5) continue; // don't xor B5
         ui8_crc ^= ui8_rx_buffer[ui8_j];
      }
Дает верный результат, без всяких ui8_crc^ui8_j

[13_chip_13]

Не вдаваясь в детали,  вывод такой : сократить число команд на несколько исключающих или (опяже смотреть лень,  но скорее всего после 5-го байта идут постоянные данные настройки которые не меняются от команды к команде,  поэтому xor для них можно предварительно посчитать и...). В общем смысл это имело лет 20 назад когда была эпоха авр тини, мега, pic12 и т.п. когда экономили  на всём даже в простых проектах. Сейчас этот подход вызывает улыбку только.

[Blik86]

Сейчас этот подход вызывает улыбку только.

Нет у них такого подхода. Вместо того что бы включить мозг и подобрать правильную формулу расчета CRC, народ пытаясь подогнать CRC добавляет дополнительный множитель...
Ииии о нежданность!!! Вместе с изменением слов которых не хватает или недолжно быть в формуле CRC - множитель меняется))))

[Калин]

Получаю такие данные от контроллера [65, 16, 0, 27, 10, 0, 184, 0, 0, 0, 128, 57]  Не совсем вяжется с описанием.  Контроллер КТ36/48.  Причем такие данные идут и при подключенном дисплея на него.

[Blik86]

Не совсем вяжется с описанием.  Контроллер КТ36/48.  Причем такие данные идут и при подключенном дисплея на него.

Что в них странного? Страницу назад у p-a-h-a  были почти такие же данные.
Меняйте настройки дисплея и смотрите меняется ли что то в ответах. Учтите, там есть скрытые настройки доступ к которым появляется при определенных настойках.

[Калин]

Получаю такие данные от контроллера [65, 16, 0, 27, 10, 0, 184, 0, 0, 0, 128, 57]  Не совсем вяжется с описанием.  Контроллер КТ36/48.  Причем такие данные идут и при подключенном дисплея на него.

Получаю такие данные от контроллера [65, 16, 0, 27, 10, 0, 184, 0, 0, 0, 128, 57]  Не совсем вяжется с описанием.  Контроллер КТ36/48.  Причем такие данные идут и при подключенном дисплея на него.

В B2, по описанию,должно поступать напряжение от аккумулятора из контроллера. Оказалось все нее так. LCD сам измеряет это напряжение аккумулятора по входу своего питания. Это видно, если запитать отдельно дисплей без контроллера.
Пример расчета контрольной суммы от контроллера к дисплею
to_disp=[65, 10, 0, 27, 10, 0, 184, 0, 0, 0, 128, 57]
xor_result = 0
for i,b in enumerate(to_disp):
    if i>0 and i!=6:
       xor_result ^= b
Игнорируется 0 байт и 6 байт
В 6 байте содержится контрольная сумма
Эта формула тогда должна начинаться от 1
   uint8_t XOR(uint8_t *buffer, size_t bufferSize, uint8_t placeXor)
    {
        uint8_t XOR = 0;
        for (uint8_t i = 1; i < bufferSize; i++)
        {
            if (i == placeXor)
                continue;
            XOR ^= buffer;
        }
        return XOR;
    }
А так, в принципе, рассчет скорости считается верно.
 ReceiveData.speedPeriod = BYTE[3] * 256 + BYTE[4];
        ReceiveData.speed = settings.speedDivided / ReceiveData.speedPeriod;

[Blik86]

В B2, по описанию,должно поступать напряжение от аккумулятора из контроллера. Оказалось все нее так. LCD сам измеряет это напряжение аккумулятора по входу своего питания. Это видно, если запитать отдельно дисплей без контроллера.

Я особо не разбирался с пакетами от контроллера. Но я нигде не встречал информации о том что контроллер передает информацию о напряжении, то что оно целочисленное как бы уже намекает...
Я запомнил что В2 это режим работы контроллера 24в,36в,42в возможно бывает 60в, 72в.
Вероятно при нештатном подключении инициализируясь контроллер не смог определить режим, так как напряжение было низким или отсутствовало на силовых цепях. Так же возможно он определяет режим из L или P параметров, там что то такое было.

[edw123]

Я запомнил что В2 это режим работы контроллера 24в,36в,42в возможно бывает 60в, 72в.

да, я тоже именно это встречал. Хотя перевод практически одинаков.

[Калин]

да, я тоже именно это встречал. Хотя перевод практически одинаков.

Дисплей показывет всегда напряжение (которое цифровое) сам, без контроллера. Из контроллера получает только его уровень (0,4,8 ... ).

[Blik86]

Из контроллера получает только его уровень (0,4,8 ... )

Так что стало причиной 0? Низкое напряжение?

[Калин]

Так что стало причиной 0? Низкое напряжение?

В B2 всегда 0 .  Дисплей не анализирует эти данные.