Skip to content
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

Open
efaden opened this issue Aug 18, 2017 · 7 comments
Open

Seg Fault in Receiver on Ubuntu 17 #4

efaden opened this issue Aug 18, 2017 · 7 comments

Comments

@efaden
Copy link

efaden commented Aug 18, 2017

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?

@efaden
Copy link
Author

efaden commented Aug 18, 2017

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: ----------------__--------__----------------------------------------__-------_--_
String length a1: ----------------__------__-------------------------_--------_-------_------------------
String length a0: --------------_--
----------------------------_--------------------__-------__--------_
String length 8c: ----------------__------__-----------------__-------_---------------____________
String length a0: ----------------__------__-------------------------_--------_-------_-----------------
String length 86: --------------_--
---------------------------------------_---
len 80: ----------------__----__--------------_------------------------------_
Packet Received: 0xfffe8e1fe888aa8c
DeviceID: 0x8e1fe8
Status: 0x88
CRC: 0xaa8c
Segmentation fault (core dumped)

@efaden
Copy link
Author

efaden commented Aug 18, 2017

That was fixed by adding a devices file.... now I get some stuff then FIFO closed and the decoder stops.

@denglend
Copy link
Owner

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.

@kevinfealey
Copy link
Contributor

kevinfealey commented Nov 24, 2017

@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:
receiver output:

linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown

gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Exact sample rate is: 1000000.026491 Hz
[R82XX] PLL not locked!
Using Volk machine: sse4_1_64_orc

decode output with no data:

# of Devices: 0
Waiting for FIFO data...
Receiving data...
FIFO Closed

Once I move a magnet to a sensor:

# of Devices: 0
Waiting for FIFO data...
Receiving data...
len 80: _-_-_-_-_-_-_-_-_-_-_-_-_-_-_--__--_-_-__-_-_-_--__--__--_-__-_--_-_-_-_-_-__--__-_--_-_-_-_-_-__-_--_-_-__-_--__-_--_-_-_-_-_-_
Packet Received: 0xfffe<redacted>
 DeviceID: <redacted>
 Status: 0xc0
 CRC: <redacted>
Segmentation fault (core dumped)

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:
decode345.py seems to be working fine too.. I've been able to get output like:
Deck Door Open []

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:
I really appreciate how easy it's been to start getting some output @denglend! I'm not sure my sensors use the same status codes as yours though. I'm still working through it, but it looks like what you have as "Open Bit5-0" means "Closed" for me (ADEMCO Model No 5816) - seems like others, like pulse check, open, and tamper-sensor are the same. If I make any changes for my setup, I'll definitely contribute back.

@kevinfealey
Copy link
Contributor

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:
for (i=NumDevices;i>=0;i--) if (DeviceIDs[i] == DeviceID) break;
it crashes.

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..

@denglend
Copy link
Owner

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.

@jsunwalters
Copy link

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: ----------------__--------__----------------------------------------__-------_--_
String length a1: ----------------__------__-------------------------_--------_-------_------------------ String length a0: --------------_------------------------------_--------------------__-------__--------_
String length 8c: ----------------__------__-----------------__-------_---------------____________ String length a0: ----------------__------__-------------------------_--------_-------_----------------- String length 86: --------------_-----------------------------****-----------__--****--
len 80: --
-------------------------**---------------------------------**----_
Packet Received: 0xfffe8e1fe888aa8c
DeviceID: 0x8e1fe8
Status: 0x88
CRC: 0xaa8c
Segmentation fault (core dumped)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants