How to implement a Packet Sink Block as simple as possible

GNU Radio
1

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: IEEE 802.15.4 packet sink · GitHub - 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

2

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.

You may want to take a look at my GrExtras project. See readme for more
details: GitHub - guruofquality/grextras: Advanced GNU Radio Blocks

This gives you the ability to write blocks in python like any other
gnuradio block with a work function and all. Its probably a better way
to get access to streams in gnuradio rather than these hacky message
queues and python threads. Its using the schedulers own threads to call
into your implementation.

Also, it implements a message passing framework on top of the existing
stream tags interface. Again, no hack-around, its using the schedulers
own threads to call into your implementation.

I want to give this project a wiki page with a coding guide and a formal
announcement. In the meantime, take a look at some of the blocks in the
project as an example. I think the work in this project address some of
your issues from a framework perspective. Obviously, you still probably
have blocks to implement that are not part of GR.

or I’m just peddling my own crap :slight_smile:

-josh