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: [email protected] LinkedIn + Resume: http://www.linkedin.com/in/jradcliffe02 On Thu, Apr 10, 2014 at 4:50 PM, Michael Ossmann <[email protected]> wrote: > On Wed, Apr 09, 2014 at 12:34:59PM -0600, Jay Radcliffe 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 >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
