Урок 2. CRC8: приёмник узнаёт испорченный байт

Паспорт урока

Параметр	Значение
Место в модуле	BeaconRadio, модуль 1 «Информатика», урок 2 из 7
Длительность	45 мин
Возраст	12–16
Оборудование	Бумага, компьютер (для проверки расчётов)
Предварительные знания	Урок 1: формат пакета, байты, hex
Предмет	Информатика, математика (двоичная арифметика)

Образовательные цели

№	Цель	Блум	Миллер	Чем доказывается
2.1	Вычислять CRC8 и объяснять обнаружение повреждения	применять	знает как	Расчёт CRC для пакета
2.2	Различать диагнозы «битый пакет» и «потерянный пакет»	анализировать	знает как	Разбор: CRC-fail против дыры в `seq`
2.3	Объяснять, почему CRC не включает сам себя	понимать	знает как	Ответ на вопрос о байте [11]
2.4	Различать защиту от ошибок и защиту от подделки	анализировать	знает как	Сравнение CRC и подписи

Сценарий занятия (45 минут)

Время	Блок	Что делает педагог	Что делают ученики
0–5	Retrieval	Мини-квиз по уроку 1	Пишут, разбор
5–12	Проблема	«Радио — ненадёжный канал. Что если байт исказился?»	Осознают проблему
12–25	Теория	Идея контрольной суммы, полином	Разбирают алгоритм
25–35	Практика	Считают CRC, ломают байт	Решают задачи
35–42	Два диагноза	Мусор против тишины	Разбирают таблицу
42–45	Итог и ДЗ	Фиксация	Записывают

Блок 1. Проблема (5–12 мин)

Постановка

«Мы упаковали данные в 12 байт и отправили по радио. Но радио — среда ненадёжная: помехи, слабый сигнал, чужие передатчики. Что если по дороге один бит перевернулся — был 0, стал 1?»

Демонстрация опасности

Взять пакет из урока 1 и изменить один байт координаты:

	Байты широты	Значение	Место на карте
Было	`50 8E 28 21`	55,6306°	нужный город
Стало (один бит)	`50 8E 28 A1`	отрицательное огромное	середина океана

«Один перевёрнутый бит — и диспетчер отправляет помощь в другое полушарие. Приёмник при этом не видит ошибки: байты как байты, число как число. Нужен способ проверить целостность.»

Ключевой вопрос

«Как приёмник может понять, что данные испортились, если он не знает, какими они были?»

Дать классу подумать. Ожидаемые идеи:

Идея ученика	Комментарий
«Послать дважды и сравнить»	Работает, но удваивает эфир — дорого
«Послать сумму всех байтов»	Верное направление! Это и есть контрольная сумма
«Проверить, похоже ли на координату»	Не универсально: испорченный байт заряда так не поймать

Блок 2. Теория (12–25 мин)

2.1. Базовый уровень (12–14 лет)

Идея контрольной суммы.

Представь, что диктуешь другу список чисел по телефону. В конце говоришь: «а их сумма — 100». Друг складывает записанное: если у него получилось 100 — записал верно, если 97 — где-то ошибся.
Контрольная сумма работает так же: отправитель считает по данным некоторое число и приписывает его в конец. Получатель считает заново и сравнивает.

Почему не просто сумма.

Обычная сумма ловит не всё. Если два числа поменялись местами — сумма та же, а данные другие. Поэтому используют более хитрое правило, которое реагирует и на порядок, и на каждый бит. Оно называется CRC.

2.2. Углублённый уровень (14–16 лет)

Шаг 1. Идея полиномиального деления.

CRC (Cyclic Redundancy Check) трактует данные как большое двоичное число и делит его на заранее выбранный полином. Остаток от деления и есть контрольная сумма.

Ключевое свойство: изменение любого бита данных с высокой вероятностью меняет остаток. Полином подбирается так, чтобы гарантированно ловить типичные ошибки — одиночные биты, пакетные искажения.

Шаг 2. Наш полином — 0x07.

Это x⁸ + x² + x + 1 — стандартный полином CRC-8. Алгоритм:

crc = 0
для каждого байта данных:
    crc = crc XOR байт
    повторить 8 раз:
        если старший бит crc = 1:
            crc = (crc << 1) XOR 0x07
        иначе:
            crc = crc << 1

Всё вычисление — восемь строк кода, никакой сложной математики: сдвиги и XOR.

Шаг 3. Что именно защищается.

В нашем пакете CRC занимает байт [11] и считается по байтам [0…10]:

[0] [1 2 3 4] [5 6 7 8] [9]    [10]  | [11]
 id    lat       lon    status  batt  |  CRC
└──────── защищаемые данные ─────────┘

Почему CRC не включает сам себя: это невозможно логически. Чтобы посчитать CRC, нужны все байты; если бы CRC входил в расчёт, он зависел бы от себя самого — уравнение без решения. Приёмник поступает так же: считает CRC по первым 11 байтам и сравнивает с двенадцатым.

Шаг 4. Где ещё применяется.

Технология	Роль CRC
Ethernet	контроль кадра
USB	контроль пакета
ZIP, RAR	контроль целостности архива
Прошивки	проверка перед записью
Жёсткие диски	контроль сектора

Шаг 5. Зачем свой CRC, если у LoRa есть аппаратный.

У радиомодуля есть собственный CRC на физическом уровне. Наш проектный CRC8 в полезной нагрузке добавлен по двум причинам:

Учебная — восемь строк кода наглядно показывают, как приёмник узнаёт о повреждении;
Практическая — он защищает данные на всём пути, включая обработку на сервере: Node-RED проверяет CRC заново перед записью в базу. Радийный CRC заканчивается на приёмнике, наш — доходит до хранилища.

Блок 3. Практикум (25–35 мин)

Расчёт вместе с классом

Пакет из урока 1 (SOS, GPS работает, seq = 3, заряд 100%):

01 50 8E 28 21 E8 CE 69 16 69 64

CRC8 = 0x1B

Полный пакет в эфире: 01 50 8E 28 21 E8 CE 69 16 69 64 1B

Опыт «сломай байт»

Ученики портят один бит и пересчитывают:

Что испортили	Новый CRC	Обнаружено?
Ничего (эталон)	`0x1B`	—
Бит в байте [0] (id)	`0x04`	да
Бит в байте [5] (долгота)	`0x32`	да
Бит в байте [9] (статус)	`0x0E`	да

«Любое изменение — и остаток другой. Приёмник сравнивает и отбрасывает пакет.»

Короткие примеры для тренировки

Данные	CRC8
`01 02`	`0x1B`
`01 03`	`0x1C`
`FF`	`0xF3`

Обратить внимание: 01 02 и 01 03 отличаются одним битом, а CRC — разный.

Блок 4. Два диагноза: мусор и тишина (35–42 мин)

Это методически важный блок — он вводит различение, которое проходит через весь курс.

Постановка

«Пакет не дошёл до базы данных. Что случилось?»

Возможны две принципиально разные причины:

Диагноз	Что произошло	Как обнаруживается	Что чинить
Мусор	Пакет пришёл, но повреждён	CRC не сошёлся → `CRC-fail` в логе	помехи, слабый сигнал, антенна
Тишина	Пакет не пришёл вовсе	дыра в счётчике `seq`	питание, дальность, шлюз

Ключевая мысль: «мусор» и «тишина» — разные диагнозы с разным лечением. Система, которая их путает, бесполезна для отладки. Именно поэтому в пакете есть и CRC (ловит мусор), и seq (ловит тишину).

Это первое появление принципа, который дальше встретится в каждом модуле: отсутствие данных — тоже данные.

Пример из реальной отладки

На сервере видны кадры с номерами 48, 49, 51, 52 — пакет 50 потерян в эфире (тишина). А кадр 52 пришёл, но Node-RED написал CRC! и не записал его в базу — это мусор. Две разные проблемы, обнаруженные двумя разными механизмами.

Блок 5. Практические задачи

Уровень A (12–14 лет)

A1. Зачем к пакету добавляют контрольную сумму?

Ответ

Чтобы приёмник мог проверить, не исказились ли данные по дороге. Он считает сумму заново по полученным данным и сравнивает с присланной: не сошлось — пакет повреждён и его надо отбросить.

A2. Почему нельзя доверять пакету, у которого CRC не сошёлся?

Ответ

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

A3. CRC занимает байт [11], а считается по байтам [0…10]. Почему он не включает сам себя?

Ответ

Это невозможно: чтобы посчитать CRC, нужно знать все байты. Если бы CRC входил в собственный расчёт, получилось бы, что он зависит от себя самого — такое уравнение не имеет решения.

Уровень B (14–15 лет)

B1. Посчитайте CRC8 (полином 0x07) для двух байт: 01 02.

Решение

Пошагово по алгоритму:

crc = 0, XOR с 0x01 → 0x01. Восемь сдвигов влево с условным XOR 0x07: результат 0x07.
XOR с 0x02 → 0x05. Восемь сдвигов: результат 0x1B.

Ответ: 0x1B. Проверить можно программно.

B2. В пакете испортился один бит. Гарантированно ли CRC8 это обнаружит?

Разбор

Одиночную ошибку бита CRC8 обнаруживает гарантированно — это свойство корректно выбранного полинома.

Но CRC8 даёт всего 256 возможных значений. При множественных искажениях есть вероятность примерно 1/256 (≈ 0,4%), что повреждённые данные случайно дадут тот же остаток и ошибка пройдёт незамеченной.

Вывод: CRC — не абсолютная гарантия, а очень дешёвое и очень эффективное средство. Для критичных применений берут CRC16 или CRC32 с существенно меньшей вероятностью пропуска.

B3. Чем CRC отличается от подписи (которую вы изучите в FoxHunter)?

Ответ

	CRC	Подпись
От чего защищает	случайных искажений	намеренной подделки
Нужен ли секрет	нет	да, ключ
Может ли злоумышленник подделать	да, легко	нет без ключа

CRC защищает от природы (шум, помехи). Подпись защищает от человека. Природа не хитрит — человек хитрит, поэтому против него нужен секрет.

Уровень C (15–16 лет)

C1. Оцените вероятность того, что повреждённый пакет пройдёт проверку CRC8 незамеченным. Достаточно ли этого для маячка безопасности?

Разбор

CRC8 даёт 2⁸ = 256 возможных остатков. При случайном искажении вероятность совпадения ≈ 1/256 ≈ 0,39%.

Маячок шлёт телеметрию раз в 10 минут — 144 пакета в сутки. Если бы искажался каждый пакет (крайне пессимистично), незамеченным прошёл бы примерно один пакет за двое суток.

Реально искажается малая доля пакетов, поэтому событие редкое. Но для устройства, от которого зависит жизнь, стоит учитывать:

у LoRa есть свой аппаратный CRC — две независимые проверки;
тревожные пакеты повторяются каждые 60 секунд, одиночный сбой не критичен;
координата дополнительно проверяется на правдоподобие (резкие скачки).

Вывод: CRC8 достаточно в сочетании с другими механизмами. Полагаться только на него в критичной системе было бы неверно — и в нашей системе на него и не полагаются в одиночку.

C2. Почему CRC вычисляют и на устройстве, и на сервере, если у LoRa уже есть аппаратный CRC?

Разбор

Аппаратный CRC LoRa защищает радиоучасток: от передатчика до приёмника шлюза. Дальше пакет проходит: шлюз → сетевой сервер → брокер MQTT → обработчик → база данных.

На этом пути возможны искажения другой природы: ошибка декодирования, сбой в обработке, неверная сборка байтов, ошибка в коде декодера.

Наш CRC8 в полезной нагрузке защищает данные сквозным образом (end-to-end): он вычислен на устройстве и проверяется прямо перед записью в базу. Если между ними что-то исказило данные — это будет обнаружено.

Общий принцип, применимый шире: проверка целостности должна покрывать весь путь данных, а не отдельный его участок. Это называется сквозной принцип (end-to-end argument) и является одним из фундаментальных в проектировании систем.

C3. Предложите, как отличить редкие случайные искажения от систематической проблемы, используя счётчики CRC-ошибок.

Разбор

Вести на приёмнике два счётчика: принятых пакетов и пакетов с CRC-ошибкой. Вычислять долю:

P_{err} = \frac{N_{CRC-fail}}{N_{\text{всего}}}

Наблюдение	Диагноз
`P_err` < 1%, случайно во времени	норма, естественный шум эфира
`P_err` резко вырос	появилась помеха, ухудшился линк, села батарея
`P_err` ≈ 0, но растут дыры в `seq`	пакеты не доходят вовсе — проблема дальности или шлюза
`P_err` близка к 100%	грубое рассогласование: не тот формат, не та версия декодера

Ключевая идея: одиночная ошибка ничего не говорит, а статистика ошибок — мощный диагностический инструмент. Этот же приём применяется в WarWalk (метрика PDR) и в PowerSentry.

Ответы на вопросы, которые прозвучат

Вопрос ученика	Как отвечать
«Почему не просто сложить все байты?»	Простая сумма не ловит перестановку байтов и часть парных ошибок. CRC устроен так, что реагирует и на значения, и на их порядок
«А можно исправить ошибку, а не только обнаружить?»	Да, есть коды с исправлением (например, Хэмминга, Рида — Соломона). Но они требуют больше избыточных байт. У LoRa есть своё исправление — параметр CR
«Если CRC не сошёлся, можно попросить переслать?»	В двусторонней связи — да, так работает Wi-Fi и TCP. Наш маячок шлёт в одну сторону и экономит энергию: проще дождаться следующего пакета
«Что если испортится сам байт CRC?»	Тогда проверка не сойдётся, и пакет будет отброшен — хотя данные целы. Это ложное срабатывание, но безопасное: лучше отбросить хороший пакет, чем принять плохой
«Почему полином именно 0x07?»	Это стандартный полином CRC-8, подобранный математически так, чтобы ловить типичные ошибки передачи. Выбор полинома — отдельная область теории кодирования

Раздаточный лист (для печати)

Урок 2. CRC8 — контроль целостности
Зачем: приёмник должен узнать, что данные испортились по дороге.
Что защищается:
[0] [1 2 3 4] [5 6 7 8] [9]    [10]  | [11]
 id    lat       lon    status  batt  |  CRC8
└─────── считаем CRC по этим байтам ──┘
Алгоритм (полином 0x07):
crc = 0
для каждого байта:
    crc = crc XOR байт
    8 раз: если старший бит = 1: crc = (crc<<1) XOR 0x07
           иначе:                crc = crc<<1
Тренировка. Проверьте расчёты:
Данные CRC8
01 02
01 03
FF
Опыт «сломай байт». Эталон: 01 50 8E 28 21 E8 CE 69 16 69 64 → CRC = 0x1B
Что испортил Новый CRC Обнаружено?
байт [0]
байт [5]
байт [9]
Два диагноза — заполните:
Мусор Тишина
Что произошло
Как обнаружить
Что чинить

Данные	CRC8
`01 02`
`01 03`
`FF`

Домашнее задание

Обязательная часть

Врайтап по рубрике А. Обязательный пункт: объясните разницу между «пакет пришёл битый» и «пакет не пришёл» — почему это разные проблемы.

Уровень A

Придумать свою простую контрольную сумму для списка из пяти чисел (например, «сумма по модулю 10»). Проверить: обнаружит ли она изменение одного числа? А перестановку двух чисел местами?

Уровень B

Посчитать CRC8 для трёх коротких наборов байт и проверить программой или калькулятором CRC. Испортить по одному биту и убедиться, что CRC меняется.

Уровень C

Изучить, чем CRC16 и CRC32 отличаются от CRC8 по надёжности. Рассчитать вероятность пропуска ошибки для каждого. Обосновать, для какого класса задач какой вариант выбирают.

Ориентир для педагога

Вероятность пропуска ≈ 1/2ⁿ: CRC8 — 0,39%; CRC16 — 0,0015%; CRC32 — 2,3·10⁻⁸ %.

Выбор: CRC8 — короткие пакеты, где важен каждый байт (наш случай, промышленные шины); CRC16 — протоколы средней ответственности (Modbus); CRC32 — файлы, архивы, Ethernet, где объём данных велик и цена ошибки высока.

Ключевой вывод: длина CRC выбирается по соотношению «цена ошибки против стоимости байтов», ровно как длина ключа в FoxHunter.

Итог урока: что записать в журнал

Вывод урока 2

Радио — ненадёжный канал: биты могут искажаться, и приёмник сам этого не увидит.
CRC — остаток от деления данных на полином; отправитель приписывает его, получатель пересчитывает и сравнивает.
Наш полином 0x07, восемь строк кода. CRC считается по байтам [0…10] и не может включать сам себя.
Мусор (CRC не сошёлся) и тишина (дыра в seq) — разные диагнозы с разным лечением.
CRC защищает от случайных ошибок, но не от намеренной подделки — для неё нужна подпись с секретом.
Сквозная проверка (на устройстве и перед базой) надёжнее проверки одного участка.

Связь с курсом

Что родилось на этом уроке	Где станет инструментом
Контрольная сумма	RFCurtain (CRC в пакете занавеса), PowerSentry
«Мусор и тишина — разные диагнозы»	Все модули, лестница диагностики
Сквозная проверка целостности	PowerSentry (проверка перед записью в базу)
CRC против подписи	FoxHunter урок 4

Чек-лист педагога перед уроком

Проверены эталонные значения: пакет → CRC 0x1B
Готов калькулятор CRC (онлайн или скрипт) для быстрой проверки
На доске заготовлен алгоритм из восьми строк
Раздаточный лист распечатан
Готов пример из лога с CRC-ошибкой и с дырой в seq

Урок 1. 12 байт, каждый с работой Урок 3. NMEA: градусы, минуты и почему нельзя делить на 100

	Мусор	Тишина
Что произошло
Как обнаружить
Что чинить