This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF51822 with TV-IR - how to hold block ble radio Softdevice interrupting

we builded " BLE to IR " using nRF51822 , it was working fine with out the softdevice. problem start when we integrated with the SoftDevice .

1.the problem that we need that for 40 - 60 ms the softdevice / radio will not make any use or interrupt

since it making 560us pulse to 1700us randomly

  1. we must find a simple way to make the mcu doing only the IR transmitting this task .

2.1 we don't want to close the communication with the user or that the user will have to reconnect.

  1. please help , and tells us what command and syntax should be use if it possible
Parents
  • You really can't. Are you generating the IR pulse using timers and interrupts, because you really cannot do accurate timing while the softdevice is running. This is discussed her many times a week. The softdevice has the highest priority interrupt and it needs it because BLE has very critical timing requirements.

    You can try using the timeslot API. This will give you a window of up to 100ms during which time you can do whatever you like. However, and this is a BIG however, the softdevice gets to tell you when you can have the slot, you may wait for a long time before it's able to schedule it. If you are in connection and the connection interval is low enough, you may not even be able to get a slot of that length, at all. I'm sure you're not able to wait a random time before delivering your IR command, so the timeslot API, especially for slots of that long length, probably won't help you.

    So no what you need to do is find a way to make your IR pulse train without the MCU's involvement. Using TIMERs and IRQs is not going to work. You need to use PPI or other hardware to generate it. How complicated is the pulse train? If it's simple the nrf51 series has a PWM driver you can try, if it's complicated then that chip may not be good enough for you.

    You can also just interface the thing to an IR pulse generator where you send commands out over another transport and the generator generates them for you.

Reply
  • You really can't. Are you generating the IR pulse using timers and interrupts, because you really cannot do accurate timing while the softdevice is running. This is discussed her many times a week. The softdevice has the highest priority interrupt and it needs it because BLE has very critical timing requirements.

    You can try using the timeslot API. This will give you a window of up to 100ms during which time you can do whatever you like. However, and this is a BIG however, the softdevice gets to tell you when you can have the slot, you may wait for a long time before it's able to schedule it. If you are in connection and the connection interval is low enough, you may not even be able to get a slot of that length, at all. I'm sure you're not able to wait a random time before delivering your IR command, so the timeslot API, especially for slots of that long length, probably won't help you.

    So no what you need to do is find a way to make your IR pulse train without the MCU's involvement. Using TIMERs and IRQs is not going to work. You need to use PPI or other hardware to generate it. How complicated is the pulse train? If it's simple the nrf51 series has a PWM driver you can try, if it's complicated then that chip may not be good enough for you.

    You can also just interface the thing to an IR pulse generator where you send commands out over another transport and the generator generates them for you.

Children
  • I agree in general with what RK posted here.

    Just want to add that it shouldn't be too hard to get a 40-60ms timeslot within a reasonable amount of time. I don't have any calculation, but I would assume it should be less than 100ms delay. And for this application, an IR remote for TV, a 100ms lag is hard to notice. The softdevice scheduler should be able to skip several BLE events to give enough time for the timeslot, as long as the connection won't be terminated because of the skipping.

    Also if we can select not too short connection interval, says 100ms interval, then it's pretty easy to fit a 40-60ms timeslot in.

Related