discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] How to implement a Packet Sink Block as simple as pos


From: Marius
Subject: [Discuss-gnuradio] How to implement a Packet Sink Block as simple as possible
Date: Mon, 21 May 2012 21:17:24 +0200

Hi!

I have some questions regarding the implementation of Packet Sinks
with GNU Radio in general.

Since GNU Radio 3.6 there are some new blocks available like the
Packet Encoder and the Packet Decoder. Also the Simple Framer Block. I
haven't had success in utilizing them. I wonder whether there is an
example available since it seems that mapping the Payload data is a
larger issue. Especially together with a WX/QT Terminal Sink from GRC.

My initial try (for which I tried to find a workaround without
success) is as follows: https://gist.github.com/2763957 - this defines
my Python block, that acts as a Sink. It uses a watcher thread to pull
the PHY packets from the queue. And the bit-processing is within a C++
sink block.
My problem is, that my module (cogra) cannot be imported due to the
error, that I put in the comments. I don't understand why that is, but
my C++ Sink implements the State Machine to check for Synchronization
and Header Fields according to the IEEE 802.15.4 standard in this
case. The linked Python class belongs to that module, too. - Which
makes the import issue somewhat strange. I need to get access to the
C++ block via Swig, and the C++ class is available already, after
successful compilation. What is impossible is to import the module in
Python to connect some Python frontend block with its C++ backend
block. At least that is idea here.

I wonder whether there is a simpler way - without the need of a
state-machine, queue and watcher thread. The only thing I practically
need is to map the demodulated bits into frames (of variable length).
I don't think a full blown packet stack should be necessary or a queue
data structure.

I'd be happy if someone had a fix or a workaround. I'm not sure
whether there is a simpler solution though.

Best,
Marius



reply via email to

[Prev in Thread] Current Thread [Next in Thread]