Re: [Discuss-gnuradio] Swig error with add_item_tag

[Jay Radcliffe]

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 Radcliffe
Twitter: @jradcliffe02
E-Mail: address@hidden
LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02

On Thu, Apr 10, 2014 at 4:50 PM, Michael Ossmann <address@hidden> wrote:

On Wed, Apr 09, 2014 at 12:34:59PM -0600, Jay Radcliffe wrote:
>
> address@hidden:~/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