-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seg Fault in Receiver on Ubuntu 17 #4
Comments
Fixed that part by blacklisting the kernel modules and adding rtl=0 to the receive.py. Now the decode process is crashing.... String length 99: ----------------__--------__----------------------------------------__-------_--_ |
That was fixed by adding a devices file.... now I get some stuff then FIFO closed and the decoder stops. |
If the FIFO closes that sounds like an issue is happening in the gnuradio flowchart. (The FIFO closing causing the decoder to stop is expected behavior). I'd suggest opening receive345.grc in GNU Radio Companion, disabling the FIFO output, enabling some of the visual sinks, and confirming that everything runs as expected without the decoder running at all. |
@efaden - were you able to resolve your seg faults? I just set all this up for the first time (on Ubuntu 16) and am having the same issue (I did not see seg faults on the receiver though - seems to be working fine). As a reference, here is what I'm seeing:
decode output with no data:
Once I move a magnet to a sensor:
From that point, decode345 (c version) will continue to output the same data until the receiver is restarted. I'm going to work on troubleshooting, but I'm new to radios and have never used gnuradio, but I'm expecting progress to be slow... Edit: So I think this is an issue with the C version of decode345. I'd really like to use that version, but I'm going to work with the Python version for now to get a proof-of-concept working here, then I'll try to troubleshoot the C version once I better understand the entire system. Side note: |
The segfault I was receiving was due to line 194 of decode345.c. If you haven't specified a devices file, when it reaches this line: I haven't really dug into the code yet, and C is not a strength of mine, but I'm guessing that either DeviceIDs is null or DeviceIDs[0] is undefined.. |
Thanks for all the notes @kevinfealey re: different status codes, the ones that are listed as just the bit number (e.g. Bit5-0) were never generated by my sensors, so I had no idea what they did. My guess was that for they are used for sensors that have multiple trigger mechanisms. A google search for your sensor seems to confirm this is likely what's going on, as yours has "two zones" -- a reed switch + a contact loop (ref). Mine only have one zone. So, bit 5 is probably the status of the additional zone. re: Seg Fault --- yes, it looks like there's an off-by-one issue in the code that checks against the device list. When I have an opportunity I'll add a fix. |
Where in receive.py did you put the rtl=0? I need to specify rtl=1 but i am not a python programmer so uncertain as to where to place it. Thanks. |
So I have a fresh install of Ubuntu 17. Plugged the USB sdr in. Installed python, etc and then tried to run receive.py and I get
linux; GNU C++ version 6.2.0 20161027; Boost_106200; UHD_003.009.005-0-unknown
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy soapy redpitaya
Segmentation fault (core dumped)
Thoughts?
The text was updated successfully, but these errors were encountered: