Swig error with add_item_tag

GNU Radio
1

Hello,

I am working with some code from Jared B. who did some work with
gnuradio looking at Tire Pressure Sensor Modules (tpms). See the repo
here: GitHub - jboone/tpms: Tire Pressure Monitoring System decoding tools.. I am having a hell of a time
getting
my setup to run his code. I get the following error:

jay@ironfist:~/tpms-master/src$ …/src/extract_bursts.py
~jay/ping_903.020m_0.400m_20140403_000000z_rtlsdr.cfile
19.6 ********************
T: -256, 0
handler caught exception: Wrong number or type of arguments for
overloaded
function ‘block_gateway_sptr_block__add_item_tag’.
Possible C/C++ prototypes are:
gr::block_gateway::block__add_item_tag(unsigned int,gr::tag_t const
&)
gr::block_gateway::block__add_item_tag(unsigned
int,uint64_t,pmt::pmt_t
const &,pmt::pmt_t const &,pmt::pmt_t const &)

Traceback (most recent call last):
File “/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py”,
line 55, in eval
try: self._callback()
File “/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py”,
line 144, in __gr_block_handle
) for i in self.__out_indexes],
File “/home/jay/tpms-master/src/burst_detector.py”, line 100, in
general_work
self.add_item_tag(0, nitems_written + index_start - self.block_size,
self._burst_tag_symbol, gr.pmt.PMT_T, gr.pmt.PMT_F)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py”,
line
5172, in block__add_item_tag
return _runtime_swig.block_gateway_sptr_block__add_item_tag(self,
*args)
NotImplementedError: Wrong number or type of arguments for overloaded
function ‘block_gateway_sptr_block__add_item_tag’.
Possible C/C++ prototypes are:
gr::block_gateway::block__add_item_tag(unsigned int,gr::tag_t const
&)
gr::block_gateway::block__add_item_tag(unsigned
int,uint64_t,pmt::pmt_t
const &,pmt::pmt_t const &,pmt::pmt_t const &)

thread[thread-per-block[1]: <block Burst Detector (2)>]: caught
unrecognized exception
^Cjay@ironfist:~/tpms-master/src$

Jared and I made an adjustment to the add_item_tag call in the
burst_detection.py code (to make sure the number of arguments passed is
right) but still get the same error. I am not sharp enough in python to
see what I am doing wrong, nor do I know if there have been changes made
to
the swig code that impacts the burst_detection code.

Any help would be appreciated.

Thanks,

Jay

Jay R.
Twitter: @jradcliffe02
E-Mail: [email protected]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

2

Hey Jay,

please make sure to provide GR version number for questions like this,
and point us to the exact source file and line number that’s causing the
trouble.

As for your error:

On 04/09/2014 08:34 PM, Jay R. wrote:

gr::block_gateway::block__add_item_tag(unsigned

int,uint64_t,pmt::pmt_t const &,pmt::pmt_t const &,pmt::pmt_t const &)

Python/SWIG is picky with overloading and types.
You could try adding a tag_t instead:
t = gr.tag_t()
t.offset = tag_sample_index
t.key = self._burst_tag_symbol

etc…

self.add_item_tag(0, t)

That said, your code should work. tag_sample_index isn’t a double, by
any chance?

M

3

On Wed, Apr 09, 2014 at 12:34:59PM -0600, Jay R. wrote:

jay@ironfist:~/tpms-master/src$ …/src/extract_bursts.py
~jay/ping_903.020m_0.400m_20140403_000000z_rtlsdr.cfile
19.6 ********************
T: -256, 0
handler caught exception: Wrong number or type of arguments for overloaded
function ‘block_gateway_sptr_block__add_item_tag’.

Short answer: It’s a bug in TPMS’s extract_bursts.py. Try this diff:

  • block_abs = numpy.abs(block_spectrum)
  • block_abs = numpy.abs(block_spectrum[2:-1])

Long answer: There are two problems, and the change above is a
workaround for both.

The first problem is that the burst detection algorithm fails on your
particular capture file because the DC offset in your file is high. So
instead of detecting six separate bursts within your file, it detects
one long burst consisting of the entire file. The change above causes
the algorithm to completely ignore narrow signals (narrower than 3/256
of your capture bandwidth) centered at 0 Hz.

I’m going to suggest this change to Jared because DC offset is a very
common defect in SDR captures. However, it is a trade-off. In cases
where a capture file does not suffer from DC offset, this change could
cause the algorithm to overlook narrow, well-centered signals.

The second problem is that there is a bug that causes a negative number
to be passed as an argument that is supposed to be an unsigned integer.
I think this only happens when a burst is detected right at the start of
the input file, so the above change avoids the problem. It’s just a
workaround, not a bug fix.

Mike

4

Much appreciated. Jared and I caught the negative number last night.
It
then did exactly what you described, finding one huge burst. I am
working
with him on some of the fsk demod tools he is working on.

As far as your other message: I would love to take your course. I know
you
are giving it at Black Hat, but I am also teaching a class those four
days
there. Are there any other times you are giving it? One of the
frustrations I am having is there is very little out there on
demodulation.
You can find lots of stuff on finding signals and identifying them.
That
part I have a decent grip on. post-demodulation I fail at. Much of it is
I
know what I need to do, but don’t know how to make the blocks/write the
code to do it. How much of your course focuses on the demodulation side
of
things? My fear is that 80% of the courses are on the parts I am
comfortable with. My co-worker (Don Weber) took the course, and he is
just
as lost as I am on this.

Thanks,

Jay

Jay R.
Twitter: @jradcliffe02
E-Mail: [email protected]
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02