1

Is it possible to implement IR receiver on android-things?

1st idea:
Use GPIO as input and try to buffer changes and then parse the buffer to decode a message.
findings:
GPIO listener mechanism is too slow to observe IR signal.
Another way is to read GPIO infinite loop. But all IR protocols strongly depend on time and java(dalvik) in this case is to less accurate.

2nd idea
Use UART findings:
It seems to be possible to adjust baud rate to observe all bits of a message but UART API require to setup quantity of start bits etc. and this is a problem because IR protocols do not fit that schema.

IMHO at the moment, UART is the only path but it would be a huge workaround.

Vincent D.
  • 977
  • 7
  • 20
Paweł Byszewski
  • 390
  • 1
  • 5
  • 11
  • can you elaborate on how slow the GPIO listener is and what is the requirement? – spitfire88 Feb 02 '17 at 18:33
  • I do not know exactly how slow but I checked that is too slow to read IR message. Please check out for example NEC protocol http://www.sbprojects.com/knowledge/ir/nec.php so we need to check state each 560µs – Paweł Byszewski Feb 02 '17 at 20:19

2 Answers2

3

The overarching problem (as you've discovered) is that any non-realtime system will have difficulty parsing this input directly because of the timing constraints. This is a job best suited to a microcontroller where you can access a timer interrupt. Grab an inexpensive tinyAVR or PIC to manage the sensor for you.

You will also want to use a dedicated receiver sensor (you might already be doing this) to simplify parsing the signal. These sensors include a demodulator, which means you don't have to deal with 38kHz pulse signal and the input is converted into a more standard PWM wave.

devunwired
  • 62,780
  • 12
  • 127
  • 139
  • IMHO dedicated receiver sensor does not resolve the problem. The signal from the receiver is still too fast for standard GPIO(two state changes per 1ms) and does not fit to (android things)UART package scheme. What would you suggest to try? – Paweł Byszewski Feb 03 '17 at 06:56
  • Indeed, it sounds like you read the second half of the recommendation without the first. The sensor helps parsing, but what you need is an MCU to capture the input and resolve the pulse widths in a deterministic manner. – devunwired Feb 06 '17 at 16:15
  • @Devunwired are you saying adding this mcu..basically in between the other components? – sirvon Feb 07 '17 at 11:49
0

I believe you can't process the IR signal in Java because the reading pulses would be quicker than the reading resolution-at least in a raspberry pi. To get faster gpio readings I'm confident you can do in c++ with ndk with the raspberry. Though it's not officially supported there's some tricks to enable it. See How to do GPIO on Android Things bypassing Java on how to write to gpio in c. From there it should be trivial to read in a tight loop. Though I would still try to hook the trigger from Java since so far I have no clear easy idea on how to write/install interrupts in c.

Community
  • 1
  • 1
Fabio
  • 2,654
  • 16
  • 31
  • This is unlikely to provide much benefit. The primary issue is not the Java-Native Interface boundary but rather that without direct access to a hardware timer you cannot reliably compute the pulse width, which is necessary for proper IR capture. – devunwired Feb 06 '17 at 16:18
  • 1
    You can still run a tight loop and over sample by 50x, annotate transition times and correct for jitter. Cumbersome, but can be improved. – Fabio Feb 06 '17 at 21:34