Segmentation fault 11 & overrun with HackRF One

[tstilwell]

Hey there, been following your awesome work on trunk-recorder for quite some time, took a hiatus and came back. Here are the specs I'm working with: os: osx 10.11.6 gnuradio: 3.7.10.1 (macports) device: HackRF One

Background: With a fresh install of your 1.x branch, everything runs perfectly out of the box, I adjusted config.json with proper error, etc. With current master, as soon as recorder starts, I'm getting 0000s (overrun?) immediately followed by a "Segmentation fault: 11" which terminates the recording. Also noticed that error "[error] Size of LPF: 24243"

I tried looking for other similar issues, or adjusting the buffer with "device": "buffers=64". Also noticed if I set Sample to 16M instead of 8M it hangs on for a few secs longer with more overruns but still dies. I'm not really sure how to troubleshoot from here. The only other thing I found was my console report for the crashed thread:

Any ideas?

p.s. Thanks again for all the work you've put into this!

[robotastic]

I actually ran into the same crash. I am not really sure causes it. I have it with the Jawbone and the HackRF One.

Try adding: "device": "hackrf=0", to the config.json file. I think that ended up fixing if I remember right.

[tstilwell]

Hmm still not doing it. Out of curiosity which version of gnuradio have you tested the most with? Also what version of hackrf firmware have you used? I noticed when I just re-installed macports that it's pulling a fairly recent one: https://github.com/mossmann/hackrf/tree/c4a820ef34d064c351d6e35348bb427cc9dbb12d

Just trying to deduce if it's a problem with hackrf/gr-osmosdr or setup error on my part with macports.

EDIT: I should add it seems that the smartnet mode with fsk4 modulation seems to work. Granted I only have the one SDR right now which can't cover the smartnet TGs, but it seems no seg fault at least:

Just to make sure, with DC's WMATA, I'd need at least 2 SDRs for smartnet right? One listens to control channel ~ 496 MHz and other tunes to the conversations ~ 850 MHz?

[robotastic]

Hmm… I just tried it with my Jawbone and I wasn’t getting a crash. I just updated my MacPorts, so I wonder if there was an update? I am using Gnuradio 3.7.10.1. It does look like there a lot commits. It might be worth doing a port update and pulling down the late version of everything. My guess is that the problem is with the hackrf drivers, since the crash came from inside that code.

On Feb 7, 2017, at 8:06 PM, tstilwell notifications@github.com wrote:

Hmm still not doing it. Out of curiosity which version of gnuradio have you tested the most with? Also what version of hackrf firmware have you used? I noticed when I just re-installed macports that it's pulling a fairly recent one: https://github.com/mossmann/hackrf/tree/c4a820ef34d064c351d6e35348bb427cc9dbb12d https://github.com/mossmann/hackrf/tree/c4a820ef34d064c351d6e35348bb427cc9dbb12d Just trying to deduce if it's a problem with hackrf/gr-osmosdr or setup error on my part with macports.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robotastic/trunk-recorder/issues/97#issuecomment-278197025, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG53EInSP-AJblbun9-70txB9jL8OCzks5raRUggaJpZM4L3pbb.

[tstilwell]

man tried clearing out all and re-installing gnuradio, gr-osmosdr, hackrf, didn't work :/

I thought I was narrowing it down..but..

Do you recall if you've ever flashed the hackrf firmware and/or CPLD controller, or still using what was stock on it? I was messing with it other day and during CPLD write, it failed. Gqrx was showing crazy freqs way off. Since then I've corrected that and next day I ran spiflash and CPLD it worked, so now it all is back to normal. Fairly certain it's not hackrf.

Other major culprit I thought it could be was libusb, since it looked like some issues with wakeups/pointer references were resolved with libusb-devel vs. libusb..but just started from scratch with -devel and same issue there.

I do see some console messages that have to do with recorder requesting too many wakeups.

Anddd last possible thing was this message (I cleared out my ~/.gnuradio folder before reinstalling all):

darn. lol.

[robotastic]

I did update the firmware, but it was a couple months ago. Here is the config file that I am using right now, that works for me. Give this a try and see if it still crashes:

{ "sources": [ { "center": 496000000.0, "rate": 8000000.0, "error": -8000, "gain": 24, "ifGain": 24, "bbGain": 32, "digitalRecorders": 3, "analogRecorders": 1, "modulation": "fsk4", "debugRecorders": 0, "driver": "osmosdr" } ], "systems": [{ "control_channels": [496537500, 496437500], "type": "smartnet", "talkgroupsFile": "wmata.csv", "shortName": "fake", "apiKey": "9ebbff72254582631a5128da36740c3a4f898abf3c888d226b55d81f10807685" }], "uploadServer": "http://localhost:3005" }

[tstilwell]

So that runs without crash. Same as the pic I added in 2nd post, just doesn't record anything: "no TG covering ~ 851 MHz" etc. repeated. Should it be recording/tuning to these freqs even with just one device staying on the control channels ~ 496 MHz? I assumed I'd need 2nd SDR for that. But regardless yea, so it appears the crash is solely when using type: p25.

[Treehouseman]

No, the center frequency stated in the config file is the center frequency the radio will always have, to cover more bandwidth you have to add radios.

And fair warning, I have found that 1 radio with large bandwidth takes a lot more cpu than many radios with small bandwidth due to how the recorders work.

[robotastic]

Interesting... I just checked and it looks like it works with Smartnet and P25... which is weird. I will look at the graph for P25 and see if there is anything that would cause it. I am sort of shocked that it worked for the system I sent out. Are you in the DC region? If you want to decode, just download the wmata branch of the code and it will correctly parse the freq.

[tstilwell]

Ah so strange. And yes I am in DC ha. Oh interesting I'll try that branch. I'm actually starting fresh on new machine, Sierra. I'm fairly certain I had some odd permissions set from years of backups, at least it appeared so when I compared vs default new. Aside from the above things I noted, permissions were the last thing I thought it could be. I'll let you know how that goes.

[robotastic]

So I think I fixed it. It was the weirdest thing. I was using an FIR filter for SmartNet and a FFT filter for P25. For some reason, if I only turn on the P25 flow after I connect things, it all works fine. The latest version of the Master branch should fix it. Also, I have a bunch of DC systems up here: http://openmhz.com

[tstilwell]

Wow yea I think that did it. No more seg fault on p25. Continues on and records now. Thanks so much for looking into it. Yea I've been using your DC Scanner iOS app now ever since you put it up. That and openmhz are awesome, so useful for figuring out what's going on. I was just particularly interested in the science behind it; doing somewhat related spectrum management/analysis for work-related project.

On a separate note, I noticed on the new machine there was more verbose debugging during the make process that pointed this out from boost: [ 65%] Building CXX object CMakeFiles/recorder.dir/trunk-recorder/main.cc.o In file included from /Users/tstilwell/radio/trunk-recorder/trunk-recorder/main.cc:31: In file included from /Users/tstilwell/radio/trunk-recorder/trunk-recorder/source.h:10: In file included from /Users/tstilwell/radio/trunk-recorder/trunk-recorder/recorders/recorder.h:43: In file included from /Users/tstilwell/radio/trunk-recorder/trunk-recorder/recorders/../../gr_blocks/nonstop_wavfile_sink.h:26: In file included from /Users/tstilwell/radio/trunk-recorder/trunk-recorder/recorders/../../gr_blocks/../trunk-recorder/call.h:21: In file included from /Users/tstilwell/radio/trunk-recorder/trunk-recorder/uploaders/call_uploader.h:4: In file included from /Users/tstilwell/radio/trunk-recorder/trunk-recorder/uploaders/uploader.h:8: In file included from /opt/local/include/boost/asio.hpp:21: In file included from /opt/local/include/boost/asio/basic_datagram_socket.hpp:20: In file included from /opt/local/include/boost/asio/basic_socket.hpp:20: In file included from /opt/local/include/boost/asio/basic_io_object.hpp:19: In file included from /opt/local/include/boost/asio/io_service.hpp:767: In file included from /opt/local/include/boost/asio/impl/io_service.hpp:71: In file included from /opt/local/include/boost/asio/detail/task_io_service.hpp:196: In file included from /opt/local/include/boost/asio/detail/impl/task_io_service.hpp:19: In file included from /opt/local/include/boost/asio/detail/completion_handler.hpp:20: In file included from /opt/local/include/boost/asio/detail/fenced_block.hpp:24: /opt/local/include/boost/asio/detail/macos_fenced_block.hpp:45:5: warning: 'OSMemoryBarrier' is deprecated: first deprecated in macOS 10.12 - Use std::atomic_thread_fence() from instead [-Wdeprecated-declarations] OSMemoryBarrier(); ^ /usr/include/libkern/OSAtomicDeprecated.h:749:9: note: 'OSMemoryBarrier' has been explicitly marked deprecated here void OSMemoryBarrier( void ); ^

repeated for each of the recorder components. But maybe that's unrelated/trivial. Regardless I think you fixed the original problem, so feel free to close.

[robotastic]

Yea - I have been stuck with those OSMemoryBarrier messages. It has something to do with the Boost libraries on Sierra. Not sure how to fix that.

Good to hear it is working!

Let me know if there are any features that would help spectrum analysis. I used to work a bit with the NTIA guys out in Boulder doing some of that stuff. I was thinking of adding some better logging features and could support for things like that.

[robotastic]

I just updated the code with better low pass filters... it should solve the root problem.