Segmentation error during irrecord when recording non-numeric buttons during...

What hardware did you use?

To my knowledge, Barco uses non-modulated IR signals, while Lirc sort-of implicitly assumes everything is (close to) 38kHz.

You may like to try a non-demodulating receiver. Or look at the (not demodulated) signal with an oscilloscope.

Thanks! I'll ask around (I'm currently working at Barco). I do remember getting a 38kHZ reading while using the oscilloscope but I'll check again.

The hardware I'm using is an Odroid c2 with a kernel my collegues built using buildroot.

Okay, used the oscilloscope and the signal is indeed not modulated (just bits)(EDIT Ignore this, I'm an idiot, it's modulated at 36 kHz for RC5 and 38 kHz for NEC). LIRC does seem capable of reading this though, but it's very unstable. When I started using it, there were never any segmentation faults, and now, even after flashing my SD card with the original image and replacing my odroid C2, it continually gives segmentation faults, which I really don't understand.

You need to take the (hardware) demodulation out, nothing more, nothing less. It is basically a brutal high-pass filter. It has nothing to do with Lirc proper, or kernels or such.

Replace the demodulating receiver of your receiver with a non-demodulating one (a photo diode or -transisor may do, better is TSMP58000 or similar). No idea if this can be done on the odroid, or if it can be re-done.

It certainly can be done on the odroid (replacing the hardware part on the odroid with a software-only reciever is kind of the point of this project).

However, I was using the oscilloscope incorrectly: (Sorry for the confusion)

The Barco signal DOES get modulated (at least according to the guy who designed the remote control) with 36 kHZ for the RC5 (which is probably what gets me into trouble with the 38 kHz demodulation) and 38 kHZ for NEC (this should work but it still results in segmentation faults).

Besides, it must have something to do with Lirc, because while I'm undoubtedly doing something wrong with the signals I'm sending to Lirc, I don't understand how I can cause segmentation errors by doing this. I didn't just get segmentation errors with the 36 kHZ RC5 demodulated with 38 kHz (which is obviously wrong), but also with the NEC, which according to the specs is 38 kHz

Ok. RC5 is a well known protocol, but since the letters "RC" are so "canonical" (for example, Canon makes a remotecontrol called RC5, and it is definitely not using the RC5 protocol...) I did not conclude that it was in use. There at least has been Barco products using non-modulated IR control.

36 vs 38 kHz is NOT a big issue, unless you are after maximal range.

Assuming that /dev/lirc is in order, I suggest that you use IrScrutinizer, with capturing hardware /dev/lirc, instead of irrecoded.

Okay, after some more testing, I'm unable to reproduce the segmentation fault with NEC. Maybe I accidently switched back to RC5 when recieving my segmentation fault, so I'll consider NEC working.

That means the segmentation fault must be, as you suggested, caused by a demodulation problem. My reciever demodulates 37.9 kHz, while in RC5 mode, my remote transmits on a 36 kHz carrier frequency.

Thanks for helping me, and if you wish, you can close this ticket, my problem has been fixed. I'll just have to remember that lirc will throw segmentation faults if I feed it garbage.

EDIt: I wrote this message before you posted your last one, I'll check it with IrScrutinizer

Ok, but there seems to be a misunderstanding: Please read for example http://www.vishay.com/docs/82489/tsop322.pdf . A demodulating receiver filters out the modulation in hardware, for the "sharpness", see Figure 5, which says that the relative sensitivity drops to 0.7 when the frequency is 5% off. Morover, the software never sees the modulation, since the chip has killed it.
So,

lirc will throw segmentation faults if I feed it garbage.

"this cannot happen".

See if you can reproduce with mode2.

EDIT: I can't use IrScrutinizer right now because I have no access to the tools necessary to recompile the kernel with IrScrutinzer added.

Ran mode2 while still in NEC mode (facepalm) let me try with RC5.

EDIT2: Ran mode2 in RC5, cannot reproduce, gives pulses and spaces length for both numeric and non-numeric keys.

With irrecord, it seems to recognize buttons being send, and doesn't crash it immediately, it's only if you send it 2 full lines of keys in irrecord that it crashes with a segmentation fault, but it only crashes if at least one of the keys pressed during the production of those 2 lines was a non-numeric key.

That is good news. The system, including /dev/lirc, is working properly, and the problem has been located to irrecord. IrScrutinizer should work ok.

ok, thanks! What should I do to reduce the possibillities further?

EDIT: To make sure it's perfectly clear for other people, here is what you need to do to reproduce:

1) Get an Odroid C2 (not sure if hardware effects this) and a Barco RC5 remote (R8769195)
2) "modprobe ir-meson"
3) "irrecord"
4) follow the instruction and during the part of random button presses, press at least one key that is not 0-9
5) This should create a segmentation fault after 2 lines have been created.

EDIT2: I'm hunting for as many remote controls as possible to verify it's this specific remote that's causing the issue

Okay, was able to reproduce with a R724075 but not with a RM368701 nor a TSFP-IR01 (R724075 has the same output as my R8769195 when using mode 2, so it likely uses RC5, while if I switch the R8769195 to NEC, it returns the same mode2 values as the RM358801.)

So TL,DR: if you use a (Barco?) RC5 controller, you can reproduce.

EDIT: Samsung TM1781A works, but I think this is not 36 kHz (cannot reproduce seg fault)

Just a small comment: I personally do not think it is a good idea to try to fix irrecord. We simply do not need it --- there are a number of alternative sources to get IR data. At the mailing list and/or the tickets, the last few years there have been several occastions when irrecord has been shown not to do its task --- and no-one seems to care to fix it.

If you do not agree, please ignore!

Ok, then consider it closed. I personally no longer have a problem since I now have a plethora of controllers that actually do work, thanks to some scavenging around the company. Thanks for helping me! It got me a lot of information that I would have otherwise probably missed.