• State Verified Answer
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 765 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 252279
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

When the timeslot extension could be failed?

eleven-x_devteam

Hello,

My project is using Lora + radar + ble so I am trying to let 1 radio tx at a time for FCC and power.

For this, I found time slot API and extension at the links.

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/setting-up-the-timeslot-api

https://devzone.nordicsemi.com/f/nordic-q-a/19200/timeslot-extension/74379#74379

I need to secure the timeslot up to around 400ms per timeslot session and It seems works usually.

But my question is how the extended timeslot mode is reliable. Once the other radio get a timeslot session and while they transmit their signal with keeping timeslot extended, if extension get failed in the middle of tx then multiple radios would work at the same time so I want to avoid that situation.

When could the extension get failed? what kind of conditions? Or how to minimize the fails?

One example I've seen fails is when I enabled radio notifications and the notification event trigger a job for printing debug messages the radio notification status(very frequently with ble connected).

too many interrupts of higher priority can affect?

Thank you.

Parents
  • 0

    Hello,

    The softdevice will always have first priorit. This means that if you request an extension, the softdevice will grant this if it doesn't need the radio for anything else. 

     

    One example I've seen fails is when I enabled radio notifications and the notification event trigger a job for printing debug messages the radio notification status(very frequently with ble connected).

     What does it print?

    What is the length of the timeslot you have requested? Is this requested as an extension?

    What is your connection interval?

  • 0 in reply to Edvin

    Thank you for your answer.

    Edvin said:
    The softdevice will always have first priorit. This means that if you request an extension, the softdevice will grant this if it doesn't need the radio for anything else. 

    Yeah, it makes sense and it's clear to me now.

    Edvin said:
     What does it print?

    it prints radio activity status whenever it gets radio notification from softdevice.

    I guess this print stuff is not so related to this issue, never mind.

    Edvin said:
    What is the length of the timeslot you have requested? Is this requested as an extension?

    Every time it sets 200us and try to extend it to 120 seconds but Lora or radar will close the session in 3~400ms.

    Edvin said:
    What is your connection interval?

    min 20ms max 75ms

    eleven-x_devteam said:
    It seems works usually.

    I was wrong. As you explained, softdevice has the first priority so it looks like the extension can get failed whenever softdevice needs to do something for ble.

    In my understanding, to secure only one radio at a time 100%, it needs to block Lora and Radar when ble is connected and also and stop ble advertising befroe  lora and radar need to start. (maybe timeslot is not so meaningful in this case)

    Or would there be any other idea with not stopping each other?

  • +1 in reply to eleven-x_devteam

    It is correct as you say. If you are in a connection, then the softdevice will need the radio either every advertising interval or every connection interval (decided by central/client in the connection), or both. So if your LoRa requires the (external) radio for longer than the connection/advertising interval, then you can't get that during the connection/advertising. You can try to increase the connection interval, but remember that it is always the central that has the final saying in the connection parameters. The peripheral/slave can only come with requests, and disconnect if these are not met. 

    So if you want to make sure the radios are not working at the same time, timeslots are a very safe way to do so. You know 100% sure that the softdevice doesn't use the radio as long as you have been granted a timeslot. If the timeslots are too short to work with the softdevice, you must disconnect and stop advertising to make sure that the timeslots are granted, although timeslots are not really necessary when you are not in a connection and not advertising nor scanning. The softdevice doesn't use the radio for anything else.

    Best regards,

    Edvin

Reply
  • +1 in reply to eleven-x_devteam

    It is correct as you say. If you are in a connection, then the softdevice will need the radio either every advertising interval or every connection interval (decided by central/client in the connection), or both. So if your LoRa requires the (external) radio for longer than the connection/advertising interval, then you can't get that during the connection/advertising. You can try to increase the connection interval, but remember that it is always the central that has the final saying in the connection parameters. The peripheral/slave can only come with requests, and disconnect if these are not met. 

    So if you want to make sure the radios are not working at the same time, timeslots are a very safe way to do so. You know 100% sure that the softdevice doesn't use the radio as long as you have been granted a timeslot. If the timeslots are too short to work with the softdevice, you must disconnect and stop advertising to make sure that the timeslots are granted, although timeslots are not really necessary when you are not in a connection and not advertising nor scanning. The softdevice doesn't use the radio for anything else.

    Best regards,

    Edvin

Children
Related
Terms of service