Декодировать двоичный протокол в Python

Question

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

Протокол описан здесь (для удобства скопирован ниже). Насколько я понимаю, первые 42 байта должны содержать метафрейм, который я думал читать / декодировать с помощью модуля python struct.

Я начал с чего-то очень простого.

import select, socket
from struct import *

port = 19090
bufferSize = 512

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(('localhost', port))
s.setblocking(0)

i=0
while i<10:
  result = select.select([s],[],[])
  msg = result[0][0].recv(bufferSize)
  # The meta section?
  msg = msg[:42]

  # Log raw bytes
  #print ' '.join('{0:08b}'.format(ord(x), 'b') for x in msg)

  print unpack(">QIxBHIHIIIQ", msg)  # big endian
  i += 1

Однако я не достаточно знаком с такими вещами, чтобы понять, как я буду синхронизировать, поэтому я декодирую нужные разделы. Приведенное ниже описание указывает на КПР, но я не уверен, как это сделать. Немного руководства было бы здорово. Проблема GitHub не получила ответа.

Полное объяснение протокола дано здесь, но также скопировано ниже:

упаковка

Блок данных, полученных с аппаратного устройства, разбивается на блоки с размером полезной нагрузки UDP. Эта последовательность блоков называется "кадром" в следующем. Специальный блок, называемый мета-блоком, отправляется перед кадром. Он используется для передачи "мета-данных" о фрейме и его последующих данных. CRC на 64 бита рассчитывается на основе этих "мета-данных" и добавляется к ним. Он служит для проверки, а также для распознавания "мета" блока из блоков данных, таким образом, достигая синхронизации. Фактически существует очень низкая вероятность смешать его с блоком данных.

Сжатый поток может упаковать несколько блоков данных, извлеченных из аппаратных средств, в один кадр, чтобы повысить эффективность сжатия. Таким образом, может возникнуть ситуация, когда происходит изменение метаданных с одного "аппаратного" блока на следующий в том же кадре. В этом случае кадр разделяется и создается новый кадр с начальным "мета-блоком" из блока, в котором метаданные изменились. Первая часть исходного кадра отправляется сразу по UDP. Это гарантирует, что фрейм данных и его "мета" блок всегда согласованы.

Блок метаданных

Блок мета-данных состоит из следующего (значения выражены в байтах):

Общий размер составляет 42 байта, включая CRC 8 байтов.

Блоки данных

Когда поток является несжатым, блоки UDP с размером полезной нагрузки заполняются полными выборками I/Q, оставляя возможный неиспользованный промежуток меньше, чем выборка I/Q в конце блока. Последний блок заполняется только оставшимися выборками. Количество максимально заполненных блоков и оставшихся отсчетов в последнем блоке указано в "метаданных". Конечно, поскольку поток данных является несжатым, эти значения также могут быть рассчитаны из общего количества выборок и размера полезной нагрузки.

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

Сводная диаграмма

Несжатый поток

аппаратный блок (2 байта I или Q сэмплов):
|I/Q I/Q I/Q I/Q I/Q I/Q I/Q I/Q I/Q I/Q I/Q I/Q: Я /Q|

Блок UDP (22 байта):
| Xxxxxxxxxxxxxxxxxxxxxx|

Рамка:
|Meta:xxxxxxxxxxxxxxxxx|I/Q I/Q I/Q I/Q:I/Q: хх | I/Q I/Q I/Q I/Q:I/Q: хх | Я /Q:I/Q:I/Q: XXXXXXXXXX |

Количество сэмплов в аппаратном блоке: 13
Количество блоков в кадре..........:  1 (всегда, если не сжато)
Количество байтов в кадре...........: 52 (4 * 13)
Завершенные блоки......................:  2 (рассчитано)
Остальные образцы....................:  3 (рассчитано)

Edit:: Я закончил тем, что отказался от этого подхода (в пользу SoapySDR) вскоре после публикации, поэтому больше не могу комментировать.

Answer 1

У меня нет никакого примера, но у меня была похожая проблема в последние дни, и поэтому я нашел эту библиотеку. Но вот пример: https://github.com/construct/construct/tree/master/construct/examples/protocols

Если это не хорошо, я также могу удалить свои ответы.