softdevice affecting the IR pulse timing

[yafis]

Hello devzone... My setup: nRF51422 and S110 peripheral My setup transmits IR data on reception of Bluetooth data from a central device. I have used PWM for generating IR pulses. It is configured as GPIOTE, the timer compare event toggles the pin. This works fine without the softdevice enabled. If the softdevice is enabled, it blocks the CPU for sometime to serve the radio events which mess up the IR mark and space timings. I have to start and stop the timer tasks and events at proper intervals. Since softdevice blocks the CPU there is delay which increases the IR data timings. The IR is an integral part of my application, so i would like to avoid ble events till the application sends IR data. Any suggestions and design improvements where in i can have a sync between IR and ble? Can i disable the events from sd for the time IR data is being sent?

Thanks..:-)

[RK]

This is discussed here very often, you should search for similar questions, there's lots of good discussion and suggestions out there.

You can't stop the softdevice or disable it or block it from working and it will absolutely affect anything interrupt-based.

You can use the Multiprotocol Timeslot API to request a limited sized window where you have control of the chip, you'll get called back when your window starts. The max size of the window isn't that long, 100ms, and you have to wait for the softdevice to call you to tell you it's ready. is 100ms at random times enough for you?

You can use PPI (there are libraries available) to generate PWMs of different duty cycles, but you still have the problem of turning it on and off or changing the duty cycle which again usually requires interrupts. If you have some flexibility in turning the PWM on and off/changing the duty cycle, you may be able to use PPI for the generation and interrupts for control, if your timing is precise on that too, you won't be able to do what you want.

The latest revisions of the chip do allow the CPU to work when the radio is on, but the softdevice still will mess up any precise interrupt-based timing.

You can also buy an IR chip which does all the IR generation for you and talks serial or SPI and use that instead. A quick google and I found 3, sure there are more, that may be a better way to do what you want because generating precise waveforms with the softdevice running is .. not really possible.

[victor]

Maybe you could send the data via SPI back to an GPIO that controls the PWM using PPI. If you use the SPIS then you can use the DMA but then you need to generate the clock that is feed in to the SPIS.

[yafis]

I would give the Multiprotocol timeslot API solution a try...but i guess 100ms would not be sufficient enough...will have to look into it..!!Thanks for that...!! Lets consider that i dont want the bluetooth connection with the central after i receive the data to be sent over IR, then can i disconnect from the central and disable the sd , sent my IR thing and then enable the sd to start advertising. will that be doable?? Then the sd wont interrupt the IR operation i guess??

[RK]

I doubted that 100ms would be enough for an IR blast. You can request the slot is extended up to a number of seconds but you can get denied so it's not guaranteed. You can try tweaking down the connection parameters so packets are sent less-frequently but I'm not sure I could engineer it to guarantee the multiprotocol slot will end up being extendable for the time needed for an IR communication.

You can certainly disable BTLE entirely - which will disconnect - shut down the softdevice and do what you like then turn it all back on again. Can't say I love that plan, feels a bit heavy-handed and I don't know how well the central is going to like devices going away and coming back a fraction of a second later.

[yafis]

sorry for the late response....!! I too am not very happy with the above plan, but hey it works...!!! I was wondering, what if i increase the connSlaveLatency....?? wouldn't that help..???