Decoding infrared signals with nRF52 Development Kit, is it possible?

[Martin Sivertsen]

Hello, we have made cars that play laser tag against eachother using infrared emitters and receivers. The problem is that the infrared radiation bounces off the surroundings, and the cars end up getting hit by themselves.

The way it is set up now is that the nRF52 DK sends a 38kHz carrier signal for about 32 milliseconds to the infrared emitter.

What I would like to do is have the DK send modulated signals with several differently timed pulses in specific intervals, and that these specific interval pulses are registered in a library. This way the DK can compare the intervalled pulses and ignore its own signal.

But I read that having crucially timed tasks like this would not be possible due to the SoftDevice interrupting the timing. (link text).

Is this correct, and should I start looking for other solutions?

[Ole Bauck]

Yes, doing bit-banging while the SoftDevice is running will lead to some problems where the SoftDevice will interfere with the timing. I think you should be able to do this, but of course it depends on what protocol you are using (how the timing is), how often the SoftDevice interrupts your code (advertising interval or connection interval) and how many other processes your application is doing. If you are check if the data received is corrupt (f.ex. with CRC) and can accept to drop packets I believe this is plausible. You should run the IR code in APP_PRIORITY_HIGH interrupt and consider using capture task together with interrupt to catch the timing.

Which protocol do you intend to use? I remember using this protocol a while back on an AVR chip to receive data from an IR remote. This does not have very strict timing so it should be possible to use together with the SoftDevice.

[Ole Bauck]

You can start a timer when the pin goes low (falling edge) and capture, stop and clear the timer when the pin goes high (rising edge). If the capture value is 2.25ms - 0.56ms = 1.69ms, then the value is a logical "1". If the capture value is 1.12ms - 0.56ms = 0.56ms, then the value is a logical "0". If the captured value is 4.5ms, then it is the start of the frame.

To get exact timing you should use PPI to trigger the start task when the pin goes low and the capture, stop and clear task when the pin goes high. You can then retrieve the captured value in the interrupt. The interrupt should run at priority between lowerstack and upperstack to guarantee that the interrupt will be executed before the next capture task (at earliest 1.12ms after the last capture task). If only the lowerstack runs at higher priority, the maximum delay should be 230us + 4us (interrupt latency) if you are in a peripheral connection according to the SoftDevice documentation, see here.