пока однозначно ясно стало то, что этот 1/2 треллис превращает исходный массив дибитов в массив дибитов в два раза большего размера, вот почему я увидел размер в два раза больше ожидемого. Остаётся только неясным, как осуществляется это треллис кодирование и как обратно всё это раскодировать. Вот только после этого и можно будет получить блоки исходного размера и тогда уже смотреть октеты, показанные здесь

Увеличить

а на данный момент имеем в два раза большее количество октетов, да ещё и обработанныхх по какому-то непонятному на данный момент алгоритму

killer258, читаю с интересом. Продолжайте пожалуйста.

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

Да, действительно, 1/2 треллис кодирование. А для его декодирования вроде как применяется декодер Витерби, который и превращает последовательность дибитов в последовательность битов.
Так что получается, хорошо, что я всё же не поспешил все принятые дибиты соединить в байты. Тут видимо не просто так было задумано оперирование дибитами. Теперь применительно к каждому блоку из 96 дибитов , который у меня получился (см. пост 11 Апр 2021 00:32:35) , надо применить декодер Витерби, и он из 96 дибитов сделает 96 битов, то есть те самые 12 по 8 битов, то бишь 12 октетов, нарисованных на картинке.

Кто бы мог подумать, что изучение темы "Декодирование АПКО-25 Фаза1" заведёт в изучение декодирования Витерби... Я что-то смутно помню об этом из институтского курса, когда был студентом и голова работала в разы быстрее, но это было лет тридцать уже назад, очень давно.

Короче, придётся пока взять тайм-аут , чтобы разобраться в решетчатом кодировании и алгоритме Витерби.
В общих чертах идея кодера и принцип декодера Витерби мне , как мне кажется, понятны, но надо ещё и процедуру написать для компа, так как вручную сравнивать метрики ошибок всех возможных путей по решетке на протяжении 96 шагов вряд ли хватит терпения

Если я правильно понял, то поскольку исходное состояние конечного автомата треллис кодера нулевое, а с него возможны только два возможных перехода (на "00" при 0 на входе и на "10" при 1 на входе ), то согласно диаграмме кодера, самый первый дибит , который выйдет с кодера,может быть только 00 или 11, а у моих 96-битовых блоков у двух из них так оно и есть, у первого 00, последний блок начинается на 11 , но вот средний блок начинается на 10, а этого быть не должно . Надеюсь, что я всё же на верном пути, а этот дибит просто оказался искажён эфиром. (в этом случае Витерби его исправит)

Тут я почитал, оказывается, в блоках помимо треллис кодирования применен ещё и интерливинг. Это не страшно, потому что таблица перестановок приведена, но вот из текста на вражеском языке я так и не уловил, этот интерливинг делается после декодирования треллиса или до того. А то опять два варианта получается надо проверять :-(

killer258
для сравнения дайте , если не трудно, тот же файл, но теперь без этой поправки. Хочу посмотреть, на чём это отразится при декодировании, насколько хуже будет ситуация с ошибками
Ок, вот без символьной коррекции файлик.
Для наглядности, вид уровней в демодуляторе SA.

А, ну теперь мне понятно. Значит, без символьной коррекции с течением временем найденный момент "правильного" взятия семплов начнёт постепенно сьезжать с середин символьных интервалов и перестанет быть правильным, начнётся размытие уровней и ошибки (я это уже проверял экспериментально, если отступление больше или равно на 1/10 интервала в любую сторону от центра символа, то ошибки сразу же появляются) потом этот сдвиг будет расти, момент считывания дойдёт до границ символьных интервалов, там будет вообще полная лажа, потом постепеннно опять будет приближаться к центрам интервалов и тд. То есть в этом случае мне не удалось бы правильно продекодировать весь файл на одном дыхании, без пересинхронизаций заново на каждом встретившемся синхропакете

killer258
Посмотрите внимательно в описании стандарта какое помехоустойчивое кодирование используется.
В одном из описаний (не стандарт) увидел, что Header Data Unit кодируется (36,20,17) Reed-Solomon code, а
Voice Code Word (23,12,7) Standard Golay Code и (15,11,3) Standard Hamming Code.
Ну и судя по описанию перемежение (interleave) идет после помехоустойчивого кодера, перед модулятором.
Как говорит теория для устранения пакетов ошибок, которые может создать кодер.
Это описано в файле который есть на просторах интернета apco-25_training_guide.pdf
+ там есть "интересные картинки" описывающие структуру кадров.

надо будет поискать apco-25_training_guide.pdf , в данный момент у меня этого документа нет среди того, что я скачал по данной теме.

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

Тогда получается, чисто логически если рассуждать, что если на передающей стороне после треллис-кодера шёл интерливинг, то при декодировании в приёмном устройстве операции над TSBK блоками необходимо сделать как я понимаю, в обратном порядке -сначала произвести обратное перемежение, поставив все дибиты на свои места, а уже потом заниматься решетчатым декодированием по Витерби?


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

Я из чего исходил. Кодер начинает свою работу всегда из одного и того же начального состояния. С учётом диаграммы возможных состояний кодера это значит, что первый дибит, который выйдет из кодера, может быть только двух видов - или это 00, если входной бит был 0, или 11, если входной бит был 1
На первом шаге мы видим, что из эфира пришёл дибит 00, значит, первый бит был нулевым.
Дальше из этого состояния опять возможны только два дибита, 00 или 11, но с эфира пришёл дибит 10, который не является ни 00, ни 11, и метрика ошибки составляет в обоих случаях 1. Я понимаю, если бы сигнал был зашумлённым, но сигнал то можно сказать, чистый, отношение сигнал/шум было несколько баллов. Так что пожалуй, наверное, и правда, надо вначале попробовать произвести деперемежение, а потом снова попытаться реконструировать тот путь, который прошёл по решётке кодер. на передающей стороне.

Для начала видимо необходимо определиться с кадровой структурой apco25.
в файле на который я указал в картинках она показана. видимо надо сначала найти
синхропоследовательсность кадра FS равную 48 бит, она там приведена и от нее
плясать по структуре кадра, т.к. в нем разные блоки кодируются разными кодами,
там и Голей и Рида-Соломона.
Если выложите демодулированный файл может местные гуру по анализу сигналов и помогут с битами.
И надо посмотреть теорию кодов, если они блоковые, то смотреть алгоритм декодирования.
Решетчатая диаграмма может здесь и неподойти.

надо сначала найти
синхропоследовательсность кадра FS равную 48 бит, она там приведена и от нее
плясать по структуре кадра

я именно так и сделал. Синхропакеты находил, 48 бит (01 01 01 01 01 11 01 01 11 11 01 01 11 11 11 11 01 11 01 11 11 11 11 11, если выражать в дибитах, или, если в уровнях, то "+3,+3,+3,+3,+3,-3,+3,+3,-3,-3,+3,+3,-3,-3,-3,-3,+3,-3,+3,-3,-3,-3,-3,-3" ( после обьединения дибитов в шестнадцатиричку это 0х5575F5FF77FF), потом за ними дальше был NID 64 бита (из них 12 бит был NAC, 4 бита DUID и остальное проверочные бчх биты), далее, судя по тому, какие были DUID, вот эти самые блоки TDU, PDU и TSBK

я именно так и сделалПочитал тему "назад", увидел.
но дальше об этом "by a rate 1/2 trellis code" нигде ни слова
Посмотрите TIA-102-BAAA-A-Project_25-FDMA-Common_Air_Interface
там вроде приведена схема декодера.

нашел этот документ. да, действительно на блок-схеме после кодера идёт интерливер, значит , при приёме всё в обратной последовательности надо делать. сначала интерливинг, потом декодинг

Перенесу табличку сюда, чтоб была:

Увеличить

Кстати, тут говорится о 98 дибитах, а не о 96. А я всё думал, откуда у меня взялись "лишние" 6 дибитов на три блока. (см. пост от 11 Апр 2021 00:32:35). Там как раз этот момент вызывал у меня вопрос. Теперь с ним ясно, они не лишние. Так что я не совсем правильно блоки сформировал .Правильно будет их по 98 , а не по 96 дибитов. и будет всё ровно, без довеска, в точности как по протоколу. Завтра исправлю.

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

Увеличить.
Всё, на сегодня хватит.

однако вернёмся к разбору блоков первого из трёх TSBK фреймов. Меня несколько дней назад удивляло, что на картинке блоки содержат по 196 битов (98 дибитов), в то время как вроде в структуре блоков рисуют 12 октетов (96 бит). В связи с вновь открывшимися обстоятельствами, стало понятно, что там применено треллис-кодирование, превратившее каждый массив из 98 битов в массив из 98 дибитов (те самые 196 бит), и надо бы исправить пост от 11.04.2021 00:32:35 в связи с этим, чтоб не путать тех, кому интересна тема, но поскольку спустя сутки там уже невозможно ничего отредактировать, то приведу этот кусок здесь. Это тело фрейма без синхропакета FS и без NID , и статусные символы из него убраны. Оставшееся разбито для наглядности на 3 куска по 98 дибит. (подлежащие процедуре обратного интерливинга, которая восстановит первоначальный порядок следования дибитов в них) :

Короче, блоки первого TSBK фрейма правильно изобразить так (по 98 дибит в каждом), для последующего деинтерливинга:



// 0..97 первый

....0...1...2..3...4..5...6...7..8..9
-------------------------------
0! 00 10 00 10 11 00 11 10 00 10
1! 00 10 10 01 00 11 10 01 01 00
2! 11 00 11 11 01 01 11 11 00 10
3! 11 10 11 00 00 10 11 11 00 10
4! 01 10 11 00 10 00 11 01 01 10
5! 10 11 00 10 11 00 11 10 00 10
6! 01 01 00 10 10 10 11 10 10 00
7! 01 11 01 00 11 10 00 10 00 00
8! 00 10 00 10 00 01 11 00 10 10
9! 00 01 01 01 11 10 10 00


//0..97 второй
....0...1...2..3...4..5...6...7..8..9
-------------------------------
0! 00 10 11 01 00 10 00 10 00 10
1! 00 10 00 10 00 10 00 10 00 10
2! 11 11 00 11 01 01 00 10 01 11
3! 00 10 00 10 00 10 00 10 00 10
4! 00 10 00 10 00 10 10 11 01 01
5! 11 00 11 10 00 10 00 10 00 10
6! 00 10 00 10 00 10 00 10 00 10
7! 11 10 00 10 00 00 00 10 00 10
8! 00 10 00 10 00 10 00 10 00 10
9! 00 10 00 10 11 00 11 11


//0..97 третий
....0...1...2..3...4..5...6...7..8..9
-------------------------------
0! 00 01 00 10 00 10 11 10 00 10
1! 00 10 10 01 11 10 01 00 10 01
2! 00 01 11 01 10 01 01 00 00 10
3! 00 01 11 00 00 10 11 11 00 10
4! 11 11 01 01 00 10 10 01 01 00
5! 10 11 00 10 01 11 11 10 00 10
6! 01 01 11 00 10 00 11 00 00 10
7! 00 01 10 11 11 10 00 10 00 00
8! 00 10 00 10 00 01 00 00 01 10
9! 11 01 00 10 01 11 11 01

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


....0...1...2..3...4..5...6...7..8..9
--------------------------------
0! 00 10 11 11 10 11 11 10 00 10
1! 00 10 00 10 00 10 11 00 11 10
2! 11 00 00 00 11 10 11 00 11 10
3! 00 10 00 10 00 10 00 10 00 10
4! 00 10 11 11 01 01 00 01 10 01
5! 11 00 00 10 11 00 00 11 01 10
6! 10 10 10 10 10 01 11 00 11 10
7! 00 01 01 00 10 00 10 00 01 01
8! 11 00 11 01 01 11 11 10 11 11
9! 01 10 01 00 10 00 01 01

// что любопытно - интерливер не меняет местоположение первых двух дибитов, они остаются там, где и были


(Второй и третий блоки пока деинтерливить не стал, потом вернусь и их тоже "переведу").

Теперь надо попытаться декодировать треллис.

Сдаётся мне, что тут диаграмма треллис-кодера не такая, как я думал. Может быть, треллисы разные могут быть? Попробуем разобраться.

для декодирования треллиса нам потребуется вот это

Увеличить

и вот это
Увеличить

Обратил внимание, что похожие процедуры (треллис 3/4, перемежение) применяются в ETSI TS 102 361-1 V1.4.5 (2007-12). есть на русском - СТБ ETSI TS 102 361-1/ОР.

Да, похоже, что это часто используемый приём приём при передаче данных через радиоканалы.

Продолжим грызть гранит науки :-)
Для начала перепишу матрицу финит стейт машины (Transition State Table) , упомянутую в той блок-схеме в Figure 7.2 "Trellis Encoder State Diagram"
вот эту вот :


Увеличить

c учётом вот этих вот указанных там же вещей:

Увеличить

в вид, более удобный мне для работы:

.................00........01.......10........11.....(input)
-------------------------------------------
S 00..|.....0010....1100....0001...1111
T 01..|.....1110....0000....1101...0011
A 10..|.....1001....0111....1010...0100
T 11..|.....0101....1011....0110...1000
E

надеюсь, что я тут в циферках не ошибся нигде и что я понимаю идею блок-схемы из того документа правильно. (то есть тут текущий входной дибит , сдвигаемый через ячейку задержки( в которой перед началом работы находится дибит 00), используется как следующее состояние машины, во всяком случае я именно так понял фразу " FSM used in this particular implementation has the special property of having the current input as a next state ")

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

Теперь, если я правильно понял их идею, надо будет , начав с начального значения state =00 в элементе памяти (как я понимаю, оно вначале находится в линии задержки на 1 такт , если это она- "Current State Storage") подобрать такую последовательность input-ов, при которой финит-машина будет выдавать на выходе тот же поток, что мы имеем в деинтерливленном недавно блоке. Правда, не знаю, что делать в случае если наши принятые из эфира дибиты окажутся искаженными помехами и в кодере не будут подбираться. Не знаю, какие здесь возможны переходы по решётке , чтоб можно было строить пути и искать путь с наименьшей суммарной метрикой ошибок.

А если всё получится, тогда эта подобранная последовательность input-ов и будет раскодированным потоком, который останется разбить на октеты (по сути , байты. (не знаю, почему их в описании назвали октетами)) и посмотреть, похоже ли содержимое полей октетов на то, что там должно быть по описанию. то есть бит LB (который равен нулю у всех блоков кроме последнего) , бит P=0 если not protected, биты Opcode, Manufacturer ID (который можно посмотреть по логам DSD) и тд и в конце 16 бит CRC

Да, похоже, что это часто используемый приём приём при передаче данных через радиоканалы.
Я про то, что там точно такие же треллис 3/4 и перемежитель 0..97 и описание немного дополнено, ну и + описание на русском.

Продолжаю заниматься ковырянием первого TSBK блока (а до этого из него еще вдобавок были выдернуты статусные биты). Хочется посмотреть, получится у меня раскодировка в итоге или же я ошибся или сбился где-нибудь.


Как уже говорилось, блок получен в результате проведения деинтерливинга. Кстати, надо наверное привести здесь таблицу, которую я составил для обратной процедуры , потому что в документе была проведена только прямая, которая проводилась на передающей стороне. а обратная таблица преобразования индексов входного массива [0..97] в индексы выходного массива такой же размерности получилась такая (может, она кому - нибудь тоже пригодится) :

out...in .out.....in out.....in ...out.....in...out...in
0 <-- 0 22 <-- 78 44 <-- 60 66 <-- 42 88 <-- 22
1 <-- 1 23 <-- 79 45 <-- 61 67 <-- 43 89 <-- 23
2 <-- 26 24 <-- 6 46 <-- 84 68 <-- 66 90 <-- 48
3 <-- 27 25 <-- 7 47 <-- 85 69 <-- 67 91 <-- 49
4 <-- 50 26 <-- 32 48 <-- 12 70 <-- 90 92 <-- 72
5 <-- 51 27 <-- 33 49 <-- 13 71 <-- 91 93 <-- 73
6 <-- 74 28 <-- 56 50 <-- 38 72 <-- 18 94 <-- 96
7 <-- 75 29 <-- 57 51 <-- 39 73 <-- 19 95 <-- 97
8 <-- 2 30 <-- 80 52 <-- 62 74 <-- 44 96 <-- 24
9 <-- 3 31 <-- 81 53 <-- 63 75 <-- 45 97 <-- 25
10 <-- 28 32 <-- 8 54 <-- 86 76 <-- 68
11 <-- 29 33 <-- 9 55 <-- 87 77 <-- 69
12 <-- 52 34 <-- 34 56 <-- 14 78 <-- 92
13 <-- 53 35 <-- 35 57 <-- 15 79 <-- 93
14 <-- 76 36 <-- 58 58 <-- 40 80 <-- 20
15 <-- 77 37 <-- 59 59 <-- 41 81 <-- 21
16 <-- 4 38 <-- 82 60 <-- 64 82 <-- 46
17 <-- 5 39 <-- 83 61 <-- 65 83 <-- 47
18 <-- 30 40 <-- 10 62 <-- 88 84 <-- 70
19 <-- 31 41 <-- 11 63 <-- 89 85 <-- 71
20 <-- 54 42 <-- 36 64 <-- 16 86 <-- 94
21 <-- 55 43 <-- 37 65 <-- 17 87 <-- 95

(как я уже заметил ранее, 0-й и 1-ый элементы массива перемежение почему-то не затрагивает)
(впрочем, 34й и 35й -тоже. мне это как-бы по барабану, но видимо, это всё чем-то обосновано)


Я сразу как-то не догадался, что удобнее было после деинтерливинга разбить блок на строчки так, чтоб в каждой строчке было бы 4 группы по 2 дибита, потому что далее после декодирования треллиса из них потом получится в каждой строке 4 группы по 2 бита = 8 бит в строке, что как раз удобно будет октеты анализировать построчно.

В общем, после деинтерливинга по приведённой выше таблице и разбивки на строчки
по 4 квадрибита я получил такой результат:

----1----2----3----4---
0| 0010 1111 1011 1110
1| 0010 0010 0010 0010
2| 1100 1110 1100 0000
3| 1110 1100 1110 0010
4| 0010 0010 0010 0010
5| 0010 1111 0101 0001
6| 1001 1100 0010 1100
7| 0011 0110 1010 1010
8| 1001 1100 1110 0001
9| 0100 1000 1000 0101
A| 1100 1101 0111 1110
B| 1111 0110 0100 1000
?|0101

// 196 бит, всё как и в описании

собственно, теперь процедура декодирования треллиса.
Процедуру провожу с помощью конечного автомата того же самого треллис-кодера, матрицу которого
я тут ранее составлял, вот она, эта матрица:


.................00........01.......10........11.....(input)
-------------------------------------------
S 00..|.....0010....1100....0001...1111
T 01..|.....1110....0000....1101...0011
A 10..|.....1001....0111....1010...0100
T 11..|.....0101....1011....0110...1000
E

Исходя из блок-схемы кодера , цель состоит в подборе такой входной последовательности дибитов, чтоб выдаваемые матрицей квадробиты выходили бы в такой же последовательности, как и имеющиеся в нашем раскодируемом сейчас блоке "четвёрки" битов.
Если квадробиты в том блоке прошли через радиоканал без искажений, то там всё подбирается довольно быстро:

берём самый первый квадробит блока, приведённого выше. Это 0010. По правилам, начальное состояние state всегда установлено =00, поэтому всё начинается с него. То есть, в данный момент мы смотрим строчку матрицы, которая соответствует state=00, то есть самую верхнюю. Ищем, какой из квадробитов матрицы совпадает с нашим "0010". В данном случае это самый первый, тот, который , как видим, соответствует input=00.
И так, это значение input= 00 - наш первый раскодированный дибит(именно при нём кодер выдает тот же квадробит, что и тот, который находится в начале раскодируемого блока.

Теперь какое у нас значение input (оно могло оказаться любым из четырёх возможных, не обязательно это будет 00), в той строчке матрицы дальше и смотрим. В данном случае снова в строчке state00, то есть самой верхней, берём из блока следующий квадробит , это 1111, находим такой же в конце этой строчки, под input11,
Значит, наш второй результирующий дибит будет 11,
дальше в матрице смотрим строку state11 , ищем в строке квадробит 1011, находим его соответствующим input=01. Значит, третий наш дибит =01, а следующая строчка в матрице будет соответствовать state01.
Ну и так далее.
В итоге потихоньку набирается цепочка выходных результатов процедуры декодинга : 00, 11, 01, .... и так далее.
Это всё так легко в случае, если приходящие из эфира квадробиты не повреждены, и в матрице находятся такие же, тогда всё просто как сейчас, потому что запись с демодулятора была хорошего качества.

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

Продолжение следует ;-)

и вот наконец долгожданный результат раскодирования треллиса 1/2 - наш многострадальный TSBK блок
в его исходном (то есть до вставки статусных битов, треллис-кодирования и интерливинга) виде :)

вот они, долгожданные октеты:


00| 00 11 01 00
01| 00 00 00 00
02| 01 00 01 01
03| 00 01 00 00
04| 00 00 00 00
05| 00 11 00 10
06| 00 01 (11 или 01, но скорее всего 00) 01? // есть два спорных дибита :-(
07| 11 10 10 10
08| 00 01 00 10
09| 11 11 11 00
10| 01 10 01 00
12| 11 10 11 11
?! | 00 (это наверное те самые NULL биты в конце, которые не несут информационной нагрузки, судя по документу)


Ну, или лучше для удобства представим теперь это
как октеты (байты), ведь дальше предстоит оперировать с ними:

00| 0011 0100
01| 0000 0000
02| 0100 0101
03| 0001 0000
04| 0000 0000
05| 0011 0010
06| 0001 ????
07| 1110 1010
08| 0001 0010
09| 1111 1100
10| 0110 0100
12| 1110 1111

рассматриваем самую первую строчку (октет 0): видим там 0 0 110100 (я её разделил на поля, так как уже есть предположения, которые сейчас надо проверить)

Если получившийся набор октетов - то самое, о чём я и предполагал, то
тогда в первой строчке первый бит -это бит LastBit, он равен нулю, если блок не последний (так и есть).
Второй бит- он равняется 0 , если not protected (в данном случае это так)

а последние 6 битов 110100 в этой первой строчке - это по идее, должен быть OPCODE. Ищем в документации описание блока с таким же точно OPCODE, и очень надеемся, что такой существует (иначе получится, что я или где-то сбился в нумерации битов на предыдущих этапах или неправильно интерпретирую этот блок). Если этот OPCODE существует, то можно с облегчением вздохнуть и начать тогда сверять остальные поля на правдоподобность.

Ура!! OPCODE "110100" существует:-)

Встречайте - это он :

Увеличить

"Identifier Update (IDEN_UP_VU) for VHF/UHF band" - так он называется в описании.

И так, очередной этап этого научного исследования по ковырянию декодированных пакетов протокола APCO-25, продолжается.


Смотрим октет1 - там у нас должен (см. картинку) находиться manufacturers ID (MFID)

видим в нём 00000000, в шестнадцатиричке это $00. Проверяем : в документе написано , что "As of 2004/2/25, an
MFID of $00 or $01 indicates a Standard Project 25 message." . Да. Значение валидное.


Смотрим октет2. видим там 0100 0101

Первые 4 бита здесь 0100 это =4 в десятичке - трактуется как идентификатор IDEN_UP_VU .
DSD подтверждает, что в исходной wav записи действительно имеется такой IDEN_UP_VU с №4)

Последние 4 бита здесь -это BWVU (value for receiver bandwidth), они у нас равняются 0101. Читаем в описании про этот параметр.
он может быть 0101, тогда это означает bandwidth=12.5 kHz . Правдоподобно, раз совпало. Значение валидное.
(Другое его возможное значение по документации - это 0100, тогда это было бы 6.25 кгц)

Ещё возьмём для проверки например , октет 5.

Читаем : 0011 0010. Это должен быть Channel Spacing. Значение этого поля умножается по документу на 0.125.
У нас тут в двоичке 0011 0010, это в десятичке =50
50 х 0.125==6.25 кГц Это тоже подтверждается DSD. Значение валидное. Как произнёс один из героев фильма "Газонокосильщик" - разум торжествует над материей! :-)


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


Короче, получается, что раз исследование дошло до подтверждённого результата, значит, последовательность действий , необходимых для раскодирования фрейма APCO25 фазы 1 , была понята верно и все действия были проведены правильно. Теперь ясно, как всё это делать.

собственно, оставшиеся ещё два TSBK блока нет пока особого желания рассматривать, там наверняка что-то аналогичное, потом можно будет и их раздербанить при желании.
А вот ещё остался неисследованным PDU фрейм, надо бы посмотреть, что окажется там. Он поменьше, видимо, в нём внутри не три, а два блока.

Собственно, вот он:

//синхропакет :
01 01 01 01 01 11 01 01 11 11 01 01 11 11 11 11 01 11 01 11 11 11 11 11
// и далее идёт содержимое фрейма :
00 10 11 00 00 01 11 00 00 10 00 10 11 01 00 10 10 10 01 10 01 10 11 10 01 10 00 00 10 01 10 01 10 00 10 10 00 11 10 00 10 00 10 01 00 10 10 10 11 10 10 01 00 10 11 00 10 00 01 01 11 11 10 00 00 10 00 10 11 00 01 01 10 01 11 11 00 10 00 10 11 10 10 10 11 10 11 10 00 00 10 00 10 11 10 00 10 00 10 01 10 00 10 00 10 00 01 11 10 00 11 10 11 00 10 00 10 00 01 11 00 01 11 00 10 10 00 10 00 10 01 00 11 11 00 10 11 10 11 10 01 11 00 10 11 11 01 11 00 10 11 11 00 00 10 10 11 11 10 11 10 00 10 00 10 00 01 00 00 00 01 01 10 00 11 00 10 01 01 11 01 11 10 11 11 00 10 00 10 01 11 10 00 00 01 00 01 00 01 01 00 10 00 01 10 10 11 11 01 01 11 00 11 00 11 01 11 10 01 01 01 10 00 10 00 10 01 10 11 01 00 10 11 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10

Привычным уже приёмом разбиваем эту хрень на микрослоты по 70 бит (35 дибитов), пишем по 7 дибитов в строчку, чтобы выделить и затем отбросить статусные дибиты (в конце каждой пятой строчки показаны торчащими сбоку) :



01 01 01 01 01 11 01 // (начало синхропакета +3+3+3+3+3-3+3... )
01 11 11 01 01 11 11
11 11 01 11 01 11 11
11 11 11>00 10 11 00 // после знака > начинается NID, из которого следует, что это Packet Data Unit
00 01 11 00 00 10 00 10
11 01 00 10 10 10 01
10 01 10 11 10 01 10
00 00 10 01 10 01 10 // конец NID

00 10 10 00 11 10 00 //начало . это 196 дибитов (2х98) плюс куча нулей последних строчек
10 00 10 01 00 10 10 10
11 10 10 01 00 10 11
00 10 00 01 01 11 11
10 00 00 10 00 10 11
00 01 01 10 01 11 11
00 10 00 10 11 10 10 10
11 10 11 10 00 00 10
00 10 11 10 00 10 00
10 01 10 00 10 00 10
00 01 11 10 00 11 10
11 00 10 00 10 00 01 11
00 01 11 00 10 10 00
10 00 10 01 00 11 11
00 10 11 10 11 10 01
11 00 10 11 11 01 11
00 10 11 11 00 00 10 10
11 11 10 11 10 00 10
00 10 00 01 00 00 00
01 01 10 00 11 00 10
01 01 11 01 11 10 11
11 00 10 00 10 01 11
10 00 00 01 00 01 00 01
01 00 10 00 01 10 10
11 11 01 01 11 00 11
00 11 01 11 10 01 01
01 10 00 10 00 10 01
10 11 01 00 10 11 11 00
00 00 00 00 00 00 00
00 00 00 00 00 00 00
00 00 00 00 00 00 00
00 00 00 00 00 00 00
10


Отбрасываем статусные дибиты. Для интерливера нужно делить на части по 98 дибитов. Получится 2 блока по 98 дибитов

Перепишем всё это дело без статусных дибитов , разобьём на две кучки по 98 дибитов и выстроим их в ряд по 10:


......0. 1.. 2. .3.. 4...5...6....7..8...9
-------------------------------- ----- //1й - cкорее всего это окажется Header Block
0| 00 10 10 00 11 10 00 10 00 10
1| 01 00 10 10 11 10 10 01 00 10
2| 11 00 10 00 01 01 11 11 10 00
3| 00 10 00 10 11 00 01 01 10 01
4| 11 11 00 10 00 10 11 10 10 11
5| 10 11 10 00 00 10 00 10 11 10
6| 00 10 00 10 01 10 00 10 00 10
7| 00 01 11 10 00 11 10 11 00 10
8| 00 10 00 01 00 01 11 00 10 10
9| 00 10 00 10 01 00 11 11

0| 00 10 11 10 11 10 01 11 00 10 //2й - скорее всего окажется, что это будет DATA Block
1| 11 11 01 11 00 10 11 11 00 00
2| 10 11 11 10 11 10 00 10 00 10
3| 00 01 00 00 00 01 01 10 00 11
4| 00 10 01 01 11 01 11 10 11 11
5| 00 10 00 10 01 11 10 00 00 01
6| 00 01 00 01 00 10 00 01 10 10
7| 11 11 01 01 11 00 11 00 11 01
8| 11 10 01 01 01 10 00 10 00 10
9| 01 10 11 01 00 10 11 11

00 00 00 00 00 00 00 00 00 00 // это видимо , пустые NULL биты , которыми добивают конец
00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 10
------------------------------------------------------------




Итак, интерливим 1й блок :, получаем это:

.....0...1.. 2....3...4...5...6...7...8....9
------------------------------------------
0| 00 10 11 11 10 11 00 11 10 00
1| 10 00 10 00 10 11 11 10 00 10
2| 00 10 00 10 00 10 00 10 00 10
3| 00 10 00 10 11 00 11 10 00 01
4| 01 00 01 01 00 10 00 01 10 10
5| 10 01 00 10 11 00 11 10 11 11
6| 01 10 10 10 10 01 00 10 00 10
7| 00 10 00 10 00 10 00 10 00 10
8| 11 00 11 10 00 01 01 00 10 00
9| 10 11 11 10 11 11 01 01

(вторым блоком займёмся несколько позже, так как сейчас не терпится посмотреть, что окажется в первом)
Перепишем результат интерливинга в виде , разбитом на квадробиты ,чтоб было 12 строк по 16 бит в строке:

-----------------------------
0| 0010 1111 1011 0011
1| 1000 1000 1000 1011
2| 1110 0010 0010 0010
3| 0010 0010 0010 0010
4| 0010 1100 1110 0001
5| 0100 0101 0010 0001
6| 1010 1001 0010 1100
7| 1110 1111 0110 1010
8| 1001 0010 0010 0010
9| 0010 0010 0010 0010
A| 1100 1110 0001 0100
B| 1000 1011 1110 1111
?| 0101

декодируем 1й блок по треллису 1/2 (точно так же, как и TSBK блоки) :
теперь у нас 12 строк по 8 бит в строке, то есть 12 октетов

Смотрим результат- наши октеты.

0| 00 11 01 11
1| 11 11 11 01 // бррр.. manufacturer не нули! зато следующий октет нули
2| 00 00 00 00 //значит, это наверное расширенный формат и надо подходить с другими мерками
3| 00 00 00 00
4| 00 01 00 10
5| 11 00 00 10
6| 10 00 00 01
7| 00 11 10 10
8| 00 00 00 00
9| 00 00 00 00
A| 01 00 10 11
B| 11 01 00 11
? 00

Судя по ненулевым значениям в том поле, в котором я ожидал увидеть manufacturer ID (октет1) с кучей нулей, и наличии её зато в октете2, у этого блока не обычный , а расширенный формат, и его надо интерпретировать по иному, а именно, как вот это:

Увеличить

потому что для расширенного формата характерно обычно, что -
октет 0: 7бит=0, 5й бит=1 если osp (так и есть)последние 5(формат)=10111 всегда(как я понял)
октет1: 7,6 биты =1
октет 2 мануфактурер (00000000) здесь а не в 1-ом октете, как в обычном формате, а во 2-ом
октет 6 бит7=1
октет 7 биты 7 и 6=0

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

Тогда рассмотрим первый блок именно как хэдер расширенного формата:

0| 00 11 01 11 //10111 --это format
1| 11 11 11 01 // здесь 11+SAP identifier (sap 111101=61 По докам он может быть 61 или 63. Верно.)
2| 00 00 00 00 //manufacturer, ноль, правдоподобно
3| 00 00 00 00 // LRA=0 (верно. DSD подтверждает это)
4| 00 01 00 10 //
5| 11 00 00 10 //(и младшие 4 бита предыдущего октета) -вместе это system id=%001011000010=0х2c2 (это правда)
6| 10 00 00 01
7| 00 11 10 10 //opcode 111010 . Это означает, что нам попался RFSS_STS_BCST (RFSS Status Broadcast)
8| 00 00 00 00 //reserved
9| 00 00 00 00 //reserved
A| 01 00 10 11 //это CRC хэдера
B| 11 01 00 11 //это CRC хэдера
? 00

==============================================================
короче говоря, в этом фрейме мне попалась широковещательная информация управляющего канала.

Также теперь стало ясно, что московский апкотранк использует оба формата блоков данных - как простой, так и расширенный. Определить, какой именно попался, можно, как мне представляется, по последним пяти битам нулевого октета. У расширенного они будут равны 10111. (и вроде бы 10101 ещё бывает ) Если здесь что-то другое, то значит, формат простой и тогда эти биты и ещё один слева будут означать opcode, а в случае расширенного формата opcode надо искать в октете7 (последние 5 битов)


Собственно , неплохо бы ещё продекодить следующий за этим хэдером дата блок
там , судя по картинке выше, в нём должны находиться : Site ID(октет1), channel R,(октет 4 и 5), Channel T (октет 2 и 3),
Интересно, в каком виде там представлены каналы Rx и Tx ? - в мегагерцах они окажутся или в условных циферках, кратных 6.25 кГц плюс какое-то базовое смещение?

В общем-то, программа DSD конкретно по данному изучаемому фрейму показывает следующее:



Скрин подтверждает , что LRA=0 и SysID=2C2 в первом блоке фрейма , который хэдер.
Тем временем я продекодировал и второй блок этого фрейма (шедший после хэдер-блока)
Не буду здесь приводить промежуточные результаты (всё делалось точно так же), только приведу конечный результат:

октеты 0-11:

0| 00 00 00 01 //RF Subsystem ID=1 (dsd это подтверждает, что RFSS=1 , как видно из скрина)
1| 00 00 00 01 //Site ID =1 (dsd это тоже подтверждает )

2| 00 10 01 10 // ССтх=2-1620 по dsd , в двоичке будет 0010-011001010100 (так оно и есть) это означает 450.125 мгц
3| 01 01 01 00

4| 00 10 11 00 // ССrx=2-3310 по dsd, в двоичке будет 0010-110011101110 (так оно и есть) это означает 460.6875 мгц
5| 11 10 11 10

6| 01 11 00 00 // это какой-то там Service Class. SC=70 по dsd, в двоичке= 01110000=0x70 (так оно и есть)

7| 00 00 00 00 reserved

8| 11 00 10 10 //Packet CRC
9| 01 10 10 10 //Packet CRC
10| 01 00 11 00 //Packet crc
11| 00 11 00 11 //Packet crc

Видно из скрина , что DSD делает точно так же , как и я, идёт по очереди по полям, читает их и пишет их содержимое в таком же точно порядке.

Теперь собственно, про каналы. Они тут не в мегагерцах, а в циферках 2-1620 и 2-3310
Черточка в октетах отсутствует, она видимо рисуется DSD для наглядности. (возможно, что двойка перед черточкой означает UHF,а 1 -VHF, это предположение надо будет проверить)
Сами эти циферки , такие как 1620 и 3310 (dsd отображает их в десятичном виде) , как я ранее выяснил, представляют собой некие целочисленные числа, помноженные на шаг 6.25 кгц и плюс прибавлена какая-то начальная константа. (такая вот линейная функция) Если эти десятичные обозначения перевести в двоичку, и не писать чёрточку, соединив обе части вместе, то так же и будет, как выглядит двоичка в полях октетов 2,3 и 4, 5

Эти фреймы я продекодил чисто для того, чтоб убедиться, что смогу находить в потоке нужные блоки данных и где там в них что передаётся, и в каком виде. Основной же интерес представляют вот эти два блока :

GRP _V_CH_GRANT (это Group voice channel grant , у него opcode=%000000)
GRP _V_CH_GRANT_UPDT (это Group voice channel grant update, у него opcode=%000010)

в которых содержится информация о том, какому TGID какой разговорный канал предоставляется. Полагаю, что каналы там тоже представлены в таком же представлении, как и здесь. Прочитав их, можно будет перевести их в мегагерцы и дать команду например, для приёмника PCR-1000 или для SDR-свистка , чтоб он быстренько встал по приёму в нужный речевой канал.

То есть тут схема действий достаточно ясна. Все эти действия с дибитами нетрудно реализовать в "железе" на каком-нибудь микроконтроллере типа атмеги или sтм32, сделав таким образом микросхемную реализацию декодера протокола Р25 , ничего сверхсложного тут нет.
Вот только есть одно очень серьёзное "но" : всё это декодирование возможно только лишь в том случае, если перед этим удастся произвести качественную демодуляцию C4FM сигнала.

А вот собственно , тот самый транкинговый сигнальный блок, по информации , извлечённой из которого можно быстро настроить приёмник на ту частоту, которую управляющий канал выделил конкретному TGID в данный момент времени:


Увеличить

opcode у него = 000010. Находим в битовом потоке блок с таким opcode. Поскольку процесс декодирования теперь выполняется не вручную, а уже автоматизирован с помощью небольшой программы, то теперь без промежуточных результатов виден сразу конечный результат - вот он , раскодированный блок:

(DUID=0111, то есть это у нас не что иное как TSBK)

0) 00000010
1) 00000000
2) 00100111
3) 00001110
4) 00000101
5) 01101111
6) 00100111
7)00010010
8) 00000101
9) 00011110
10)...
11)..

Прокомментирую его октеты:

0) 00000010 // opcode=000010, то есть это мне попался Group voice channel grant update (GRP_V_CH_GRANT_UPDT)
1) 00000000 // код производителя оборудования (обычно нули всегда)

2) 00100111
3) 00001110 // эти две строчки -номер речевого канала. В переводе из двоички в десятичку это канал 2-1806 (то бишь 451.2875 мГц)

4) 00000101
5) 01101111 // эти две строчки это TGID, которому предоставлен канал. Два байта.В переводе в десятичку этот TGID=1391

6) 001001 11
7) 00010010 //эти две строчки - номер канала для ещё одного TGID, В переводе это канал 2-1810 (то бишь 451.3125 мГц)

8) 00000101
9) 00011110 // а это тот самый второй TGID, которому давали канал 2-1810. В переводе в десятичку будет TGID=1310

дальше идут две строчки с CRC

А вот что показывает DSD по данному фрейму:

Увеличить

Информация совпадает.

В общем-то, вот и всё, что мне хотелось выяснить. Особая благодарность участнику KarapuZ за проведённую им демодуляцию моей I/Q записи средствами программы SA , цифровую фильтрацию и коррекцию символьного битрейта демодулированного сигнала, что собственно и сделало возможными эти эксперименты по декодированию и анализу содержимого различных пакетов управляющего канала московского апкотранка , записанных из эфира