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

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

kattaliraees — Thu, 05 Sep 2019 00:32:21 GMT

https://github.com/kattaliraees/nrf52-IR/

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

Martin Sivertsen — Wed, 13 Jul 2016 11:03:03 GMT

Thanks for the feedback!

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

Ole Bauck — Wed, 13 Jul 2016 10:24:24 GMT

"Lowerstack" is the "SoftDevice timing critical" according to the figure, "upperstack" is the "SoftDevice API calls and deferrable handling".

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

Ole Bauck — Wed, 13 Jul 2016 10:21:26 GMT

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.

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

Martin Sivertsen — Mon, 04 Jul 2016 09:14:40 GMT

Having commented out the app_pwm-parts of the code, I have got the IR-code to send signals in the NEC-protocol standard. The next challenge is to create code that registers the different intervals of the IR-signal (and compares them to pre-existing intervals). I haven't found any good examples of how to solve this on the nRF52 (just this), and I'm a bit stumped on where to start.

As it is now, we use the pin_event_handler to see if there is a change on the pins connected to the IR-receivers, and then register a hit. But I have understood that the pin_event_handler might not be able to register the time intervals of when the pin is low or high, but just register a change on the pins, or am I mistaken?

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

Martin Sivertsen — Mon, 04 Jul 2016 09:11:33 GMT

Hello, and sorry for the late feedback. I am not that well versed in C-programming and have spent the last few weeks reading up and trying to implement an IR-protocol. I had read a bit about different IR-protocols before, but hadn't decided on a particular one before embarking on this project. The NEC-protocol seemed like a very robust and simple protocol though. Luckily, I found this example that Torbjørn Øvrebekk had made (although for nRF51). I managed to port it to nRF52 and integrate it with our existing code.

I had trouble getting the IR-signal emitting to work together with other functions, and Torbjørn was nice enough to join me and debug the code. He found out that there was a conflict with the app_pwm that was used in our project and the PPI used for the IR-emitting.

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

Ole Bauck — Fri, 17 Jun 2016 11:43:28 GMT

Interrupt latency due to forwarding alone is given here. Latency due to processor usage pattern of the SoftDevice have to be calculated from the information given here.

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

SRA — Thu, 16 Jun 2016 17:11:08 GMT

Are there average and worst case scenarios listed for the the time on the SoftDevice? Like what we can reasonably expect for how long each event might take?

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

Ole Bauck — Thu, 16 Jun 2016 10:30:25 GMT

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.