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

Notification timing not correct.

Hello Devzone,

I've been working on a system to set notifications on time ready for transmission.

The client sends a WWR package to my peripheral and I want my peripheral to send a notification back in the same connection interval.

The client and peripheral both have a 7.5ms min and max connection interval.

To my knowledge a notification has to be set before the transmission moment occurs.

My approach is to have one free running timer captured as soon as I get the WWR message, I'll add that captured value with x (roughly 6ms in timer ticks) to a new compare register to create an event to set a notification ready for the next connection interval.

When the compare event strikes I do a sd_ble_gatts_hvx(....) and set my notification ready.

I've added a picture to help understand what I'm trying to achieve. 

The problem I'm having is that the notification is not send as I pictured here.

Instead the notification is set at the right time but instead of being transmitted in the following connection interval, it is being transmitted in the connection interval after the intended interval.

I've tried changing the time for when the notification is set ready for transmission but this either resulted in ERROR_NO_RESOURCES or in the same behavior.

When I change the WWR and notification time so it is transmitted every 15ms instead of 7.5ms I get the following behavior.

This is really bugging me and I cannot find what I'm doing wrong here.  

Can anyone help me with my struggles?

Kind regards

Parents
  • Hello,

    Remember that you can queue packets at any time. If they are queued enough time before the next connection event, it will be transmitted that event. If it is queued too late, the softdevice doesn't have time to process the packet, and it will be sent the next event instead.

    Have you tried queuing the packet directly after the previous notification was sent (and you get the TX_COMPLETE event). In that case it should be sent the very next connection event.

    An alternative is to use something called radio notifications, whic is a module that makes it possible to get events a given amount of time before the next connection event. 

    Please check out this guide for how to setup and use radio notifications:

    https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/radio-notification

    What you are probably seeing is that you start an app_timer right after a connection event. This timer will not be started until the softdevice is done, so perhaps you queue it too late? How much data do you send before you start the timer? If you have enabled data length extension and event length this may actually take a lot of time.

    I suggest either using the TX_COMPLETE event (called BLE_GATTS_EVT_HVN_TX_COMPLETE. Add this to your ble_evt_handler) to queue the next notification, or look into using the radio notifications, and experiment with different timings (NRF_RADIO_NOTIFICATION_DISTANCE_800US). Depending on how much data you queue, you need a different amount of time.

    Best regards,

    Edvin

  • Hello Edvin,

    Even if I queue my notification right after it is being sent I still get the the same problem. I have changed the wait value from 1ms to 6ms with 500us increments but it didnt help at all.

    I do not use an app_timer, I have configured NRF_TIMER2 to be free running from the start. I use PPI and the EGU to trigger my events and tasks. 

    The data length of my notification is 100 bytes and I have set data length extension correctly.

    I use the BLE_GATTS_EVT_HVN_TX_COMPLETE event in addition to my timers (logical OR from events) to trigger writing the notification.

    The thing is that I cannot explain what is going on in picture 2 and 3 in my original post.

  • Ive made an Excel sheet with some information about the timing if that helps.

  • After doing some more testing I've found out that the HVX complete event is set after the connection interval. Please correct me if I'm wrong.

    By trying to set a new notification before this event happened I probably got the message NO_RESOURCES. So does this mean I am unable to send a WWR + notification every connection interval?

  • You don't need to wait for a notification to send a WWR. But of course, if your WWR depends on the content of the notification, you need to do so. As I mentioned in the beginning of this post, I tested this using the ble_app_uart and ble_app_uart_c together, and then I send some data (WWR) in the notification event directly. This was sent the very next connection interval. Have you tried this?

  • I do have tried this and I've seen this happen, but I don't know if this app is scalable to multiple peripherals.

    I'm using a timer to send out WWR's at a fixed interval.

    My WWR contains data that must be set as late as possible, this I am getting to work, its just that on the peripheral side things are not working correctly.

  • I am not sure where to go from here. Is there some way for me to reproduce what you are seeing? 

    You would need to zip your project. Due to limited staffing I don't have time to develop this myself based on a description. I need to see exactly what you are seeing. So if you zip the central and the peripheral project, and attach it here, together with a short description on how to reproduce it and what to look for, then I can have a look.

    If that is not possible, the only thing I can say is that if you queue a packet too late, then the softdevice will not have time to set it up before the next connection interval, and it will be sent the one after that.

    BR,

    Edvin

Reply
  • I am not sure where to go from here. Is there some way for me to reproduce what you are seeing? 

    You would need to zip your project. Due to limited staffing I don't have time to develop this myself based on a description. I need to see exactly what you are seeing. So if you zip the central and the peripheral project, and attach it here, together with a short description on how to reproduce it and what to look for, then I can have a look.

    If that is not possible, the only thing I can say is that if you queue a packet too late, then the softdevice will not have time to set it up before the next connection interval, and it will be sent the one after that.

    BR,

    Edvin

Children
No Data
Related