Infrared send driver time length is not correct sometimes, why ?

RE: Infrared send driver time length is not correct sometimes, why ?

ovrebekk — Tue, 15 Oct 2019 11:27:50 GMT

Thanks a lot Peter, I will try to keep your repo in mind for future IR request 🙂

RE: Infrared send driver time length is not correct sometimes, why ?

Peter Hinson — Fri, 11 Oct 2019 17:26:39 GMT

Thanks for sharing this example, Torbjørn. I've migrated the code to SDK 15.3.0 and posted it to Github for posterity: https://github.com/peterhinson/nrf_uart_ir_example

RE: Infrared send driver time length is not correct sometimes, why ?

kattaliraees — Thu, 05 Sep 2019 00:30:24 GMT

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

RE: Infrared send driver time length is not correct sometimes, why ?

joeyh — Thu, 18 Jul 2019 06:55:45 GMT

That's very helpful.

Thanks again.

RE: Infrared send driver time length is not correct sometimes, why ?

ovrebekk — Thu, 11 Jul 2019 11:08:40 GMT

Good to hear that you found the issue 🙂

One thing worth noting is that the PPI controller is actually not protected by the SoftDevice for direct access. This means it is possible to bypass the sd_ppi API and simply access the hardware registers in the NRF_PPI module directly.

Then there is no limit on what interrupt level you have to be in, and you can easily enable or disable groups from anywhere in the code.

The only thing to keep in mind when using the NRF_PPI registers is to stay away from PPI channels used by the SoftDevice, since there is nothing stopping you from interfering with the SoftDevice PPI configuration (PPI channels 16 and up).

To disable a PPI group using hardware registers simply run the following code line:

NRF_PPI->TASKS_CHG[IR_PPI_GROUP].DIS = 1;

And enable:

NRF_PPI->TASKS_CHG[IR_PPI_GROUP].EN = 1;

For more information about the PPI hardware please refer to the PPI chapter in the product specification.

Best regards
Torbjørn

RE: Infrared send driver time length is not correct sometimes, why ?

joeyh — Wed, 10 Jul 2019 17:13:14 GMT

I think you are correct that it is an IRQ priority issue. Just quickly tried using a flag in the main loop, the code runs fine without crashing. It looks kind of ugly though to have things in separate c files. I will try to app_scheduler way later.

Anyway, Thanks!

RE: Infrared send driver time length is not correct sometimes, why ?

ovrebekk — Tue, 09 Jul 2019 08:15:21 GMT

It sounds like a interrupt priority issue.

On the nRF52 series you have to be in IRQ priority 6 or 7 to be able to call into the SoftDevice, any higher priority (lower number) and you will get an assert.

Alternatively you would have to defer the SoftDevice calls to the main context, by setting a flag in the interrupt that you later check in your main loop, or by using the app_scheduler module.

If you have more questions on this please open a new devzone ticket, the system is not really set up to handle multiple different questions in each case. You can refer to this case and mention my name if you want, and it will assigned to me if I'm available.

Best regards
Torbjørn

RE: Infrared send driver time length is not correct sometimes, why ?

joeyh — Mon, 08 Jul 2019 18:35:51 GMT

Thanks for the example code. It helps our project tremendously.

As a followup to your example project, we are trying stop all gpiote, timers and PPIs after we sent the IR signal. We do such cleanup inside the interrupt function IR_CARRIER_COUNTER_IRQHandler() when m_bits_remaining==0. With PPIs, the code is crashing in some assembly code whenever I try to call either of the following functions:

    sd_ppi_group_task_disable(IR_PPI_GROUP);
    sd_ppi_channel_enable_clr(1 << IR_PPI_CH_A | 1 << IR_PPI_CH_B | 1 << IR_PPI_CH_C | 1 << IR_PPI_CH_D | 1 << IR_PPI_CH_E);

Is it because I can't do this inside a IRQ? How can we solve this?

RE: Infrared send driver time length is not correct sometimes, why ?

ovrebekk — Mon, 27 Aug 2018 10:56:21 GMT

In this case the IR example is overkill, and it's probably easier to implement this functionality from the ground up rather than using the IR example.

If you don't need a carrier pulse you can set up everything with a single timer. Use 4 of the compare registers of the timer to toggle the GPIOTE at different points in time, and update the compare registers as you go along. Each compare event must be connected to the GPIOTE toggle task over PPI, and the GPIOTE must be configured to set the pin you want.

If you set the timer prescaler to 4 then it will run at a 1MHz frequency, which means you can set the compare registers based on how many microseconds of delay you need.

Best regards
Torbjørn

RE: Infrared send driver time length is not correct sometimes, why ?

mdevil39 — Sun, 26 Aug 2018 02:07:25 GMT

I want the output to be on for 12us, off for 5076us, on for 12us, off for 7204us and so forth, the last off time can

ignore(because at the end the driver is off, it takes no effect) .

It is this IR code feature. Can you tell me how to change the driver code ?

RE: Infrared send driver time length is not correct sometimes, why ?

ovrebekk — Thu, 23 Aug 2018 14:50:57 GMT

Are you saying you are not going to use any carrier at all?

In other words, you just want the output to be off for 12us, on for 5076us, off for 12us, on for 7204us and so forth?

Best regards
Torbjørn

RE: Infrared send driver time length is not correct sometimes, why ?

mdevil39 — Tue, 21 Aug 2018 09:59:37 GMT

Hi , thanks for the IR driver and it helps a lot . But now I have a question , how can I send out the IR data without IR carrier , like the data below :

12,5076,12,7204,12,5076,12,7204,12,5076,12,5076,12,7204,12,14716

The 'mark' data is small , so it has no carrier , but I don't know how to change the driver .

RE: Infrared send driver time length is not correct sometimes, why ?

ovrebekk — Mon, 16 Apr 2018 13:19:17 GMT

The example was written for the nRF51x22 only, but the ir_lib.c/h files should work fine on the nRF52832 as well (they just haven't been tested).

If you want to try the code out on the nRF52 I suggest you start out with an example written for the nRF52832, and add the ir_lib.c and ir_lib.h files afterwards. Trying to migrate the entire example to the nRF52 is likely to be more work.

Best regards
Torbjørn

RE: Infrared send driver time length is not correct sometimes, why ?

Nijat — Wed, 04 Apr 2018 01:31:26 GMT

Hi Ovrebekk, can I run this example on nrf52832 ? I have a PCA10040 development board.

RE: Infrared send driver time length is not correct sometimes, why ?

pallavi — Wed, 05 Apr 2017 07:39:30 GMT

hello qoboty,can you please tell me the concept of code i am not getting how can i send my data to ir pin of controller.the zip file includes the function void ir_lib_send(uint16_t *time_us, uint32_t length); but i am not getting what data i should pass here. i want to impliment ir function for nrf51822 microcontroller.in zip file it is mentioned that static void nus_data_handler(ble_nus_t * p_nus, uint8_t * p_data, uint16_t length) function and in this function nec protocol is implimented.but exactly i am not getting what are you doing here.can you please explain me how should i make ir code for rc5

RE: Infrared send driver time length is not correct sometimes, why ?

Tushar — Fri, 23 Sep 2016 10:21:59 GMT

Hi Torbjørn Øvrebekk, I successfully managed to affect remote device. But looks its not stable. Sometime it successfully switch on device & sometime not. Any suggestion ?

RE: Infrared send driver time length is not correct sometimes, why ?

Tushar — Sun, 11 Sep 2016 02:06:26 GMT

Hi Torbjørn Øvrebekk, I have tried to implement ble_app_uart_IR.zip successfully. Is it running to 38Khz frequency ? Because data I am getting is correct, still I am not able to act on IR device correctly.Please help me out. Also please tell how to change frequency with change of prescaler with IR_CARRIER_LOW_US & IR_CARRIER_HIGH_US value.Thanks.

RE: Infrared send driver time length is not correct sometimes, why ?

qoboty — Thu, 19 Nov 2015 05:16:54 GMT

Thank you very much! According to your approach I got the wave that I expect.

RE: Infrared send driver time length is not correct sometimes, why ?

ovrebekk — Wed, 18 Nov 2015 09:21:50 GMT

The problem is that you are being interrupted by the BLE stack in your while loop (when waiting for the TIMER2 event). In general it is not a good idea to base the system on while loops like this, it would be better to use the PPI to have TIMER2 turn on and off the carrier (TIMER1) in the background, so that BLE interrupts will not affect you.

I decided to make a small example of my own to demonstrate this:
ble_app_uart_IR.zip

I chose to use a slightly different approach. Instead of using TIMER2 as a timer, I use it as a counter, and count the number of pulses from the carrier before turning it on and off.

The API is comparable to yours I believe. You just provide the library a list of 16-bit values, each storing the number of microseconds the carrier should be on and off. To implement specific IR protocols you have to fill in the buffer correctly.

The example is based off of ble_app_uart, and will output an IR version of the first UART byte sent to the nRF51 on P0.04
The GPIO used is configured when calling the init function. All other parameters are configured in the ir_lib.h file (such as the frequency of the carrier).

Best regards
Torbjørn

RE: Infrared send driver time length is not correct sometimes, why ?

qoboty — Mon, 16 Nov 2015 09:41:11 GMT

when I adjust parameter MAX_CONN_INTERVAL or MIN_CONN_INTERVAL to different value, the error result will be different, Is the connect interval impacts on timer delay ?

RE: Infrared send driver time length is not correct sometimes, why ?

qoboty — Mon, 16 Nov 2015 08:22:34 GMT

advertise parameter is:

  #define APP_ADV_INTERVAL                256
#define APP_ADV_TIMEOUT_IN_SECONDS      180  
#define MIN_CONN_INTERVAL               32
#define MAX_CONN_INTERVAL               120