sdrdaemonというプログラムから生成されたバイナリストリームをデコードする単純な python クライアントを作成しようとしています。
プロトコルはここで説明されています(便宜上、以下にコピーされています)。私の理解では、最初の 42 バイトには、python構造体モジュールで読み取り/デコードすると考えていたメタ フレームが含まれている必要があります。
私は非常に単純なことから始めました。
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
ただし、この種のことについては、同期する方法を理解するのに十分なほど慣れていないため、正しいセクションをデコードしています。以下の説明はCRCを指していますが、どうすればよいかわかりません。少しのガイダンスは素晴らしいでしょう。github の問題に応答がありませんでした。
プロトコルの完全な説明はここにありますが、以下にもコピーされています。
包装
ハードウェア デバイスから取得されたデータのブロックは、UDP ペイロード サイズのブロックにスライスされます。以下、この一連のブロックを「フレーム」と呼びます。「メタ」ブロックと呼ばれる特別なブロックがフレームの前に送信されます。フレームとそれに続くデータに関する「メタ」データを伝達するために使用されます。この「メタ」データに対して 64 ビットの CRC が計算され、追加されます。これは検証として機能し、データ ブロックから「メタ」ブロックを認識して同期を実現します。それをデータブロックと混同する可能性は事実上非常に低いです。
圧縮ストリームは、圧縮効率を向上させるために、ハードウェアから取得した複数のデータ ブロックを 1 つのフレームにパックする場合があります。そのため、メタデータの変更が同じフレーム内の 1 つの「ハードウェア」ブロックから次のブロックに発生する場合があります。この場合、フレームが分割され、メタデータが変更されたブロックの開始「メタ」ブロックで新しいフレームが構築されます。元のフレームの最初の部分が UDP 経由ですぐに送信されます。これにより、データ フレームとその「メタ」ブロックが常に一貫していることが保証されます。
メタデータ ブロック
「メタ」データのブロックは、次のもので構成されます (値はバイト単位で表されます)。
合計サイズは、8 バイトの CRC を含めて 42 バイトです。
データブロック
ストリームが圧縮されていない場合、ペイロード サイズの UDP ブロックに完全な I/Q サンプルが詰め込まれ、ブロックの最後に I/Q サンプル未満の未使用のギャップが残る可能性があります。最後のブロックは、残りのサンプルのみで埋められます。最後のブロックで最大に満たされたブロックと残りのサンプルの数は、「メタ」データで指定されます。もちろん、データ ストリームは圧縮されていないため、これらの値はサンプルの総数とペイロード サイズから計算することもできます。
ストリームが圧縮されると、UDP ブロックは圧縮ストリームのバイトで完全に詰め込まれます。最後のブロックは、残りのバイトのみで満たされています。完全なブロック数と残りのバイト数は「メタ」ブロックで指定され、これらの値はそれ以外では計算できません。
まとめ図
非圧縮ストリーム
ハードウェア ブロック (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:I /Q| UDP ブロック (22 バイト): |xxxxxxxxxxxxxxxxxxxxxxxx| フレーム: |メタ:xxxxxxxxxxxxxxxxx|I/Q:I/Q:I/Q:I/Q:I/Q:xx|I/Q:I/Q:I/Q:I/Q:I/Q:xx|I /Q:I/Q:I/Q:xxxxxxxxxx| ハードウェア ブロックのサンプル数: 13 フレーム内のブロック数..........: 1 (圧縮されていない場合は常に) フレーム内のバイト数........: 52 (4 * 13) 完全なブロック................................................: 2 (計算) 残りのサンプル.................................: 3 (計算)
編集::投稿後すぐにこのアプローチを (SoapySDR を支持して) 放棄することになるため、関連するコメントはもうできません。