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

Usage of schedule_first_time and setup_next_timeout in advertiser.c

Hi,

I've been experimenting with the Mesh SDK (v3.2) on nRF52832 boards. After doing some end-to-end latency experiments, I've come up with some questions associated with broadcast behavior. First, I'll try to summarize how I understand the behavior up until now:

In advertiser.c, the method advertiser_packet_send is called when an upper layer wants to broadcast something. Upon checking the advertiser being enabled and non-active, the method schedule_first_time is called. This method will reschedule the transmission after a random BACKOFF between 0 and the advertisement interval associated with the advertiser instance, is called.

Upon timeout, the method timeout_event is called, which checks if the radio is busy transmitting. If not, it checks if a packet is available for transmission and starts the transmission. Also, if the radio was busy transmitting or has now started the transmission of the next available packet, the method setup_next_timeout is called. This method reschedules the timer to timeout after the advertisement INTERVAL + a standardized random backoff between 0 - 10 ms. Upon timeout, the method timeout_event is called again and process repeats itself, until no packets are available anymore in the buffer.

However, the packet buffer is filled by calling advertiser_packet_send. In some cases, the method schedule_first_time is also called again in that method, even though an interval was already scheduled in setup_next_timeout. This happens for example, when relaying a packet. The method schedule_first_time then reschedules the timeout after the random BACKOFF and removes the scheduled interval timeout. In other cases, the method schedule_first_time is not called within advertiser_packet_send, because of the check for the advertiser being enabled and non-active fails. This is the case for example when scheduling retransmission's because of the configured retransmission count state in the transmitting model. This retransmission then does happen, but only after the previous configured INTERVAL.

Now for the questions:

- Does each advertiser have a separate packet buffer or queue? In other words, are relay packets queued separately opposed to originator packets?

- In what cases does calling advertiser_packet_send also mean that a previous configured INTERVAL by setup_next_timeout will be overwritten by novel RANDOM backoff configured by schedule_first_time being called again. In other words, when does the check for the advertiser being enabled and non-active, succeed?

Thanks!

Kind regards,

Mathias

  • Some follow-up to my questions: I saw that the retransmission interval of the transmitting model was 0, so the retransmission is scheduled instantly. When I change the interval to 20 (which means 1 sec.), the BACKOFF does overwrite the interval. So could it be that advertiser being non-active mean that is it not busy sending a packet via broadcast.c? And thus if a novel packet arrives via advertiser_packet_send, it is scheduled via BACKOFF if the advertiser is currently not (attempting to) transmit(ting) another packet?

    And what does this mean for separate advertiser instances? If an originator is busy transmitting a packet and at that moment the relay's advertiser instance also calls advertiser_packet_send to relay a packet, does schedule_first_time get called then? Because then another advertiser instance (the originator's) is busy transmitting but the relay's advertiser instance is not busy transmitting yet, so it will return non-active, or not?

  • Hi. 

    Thank you for the detailed description and questions. 

    Just as a sidenote, I would like to mention that we have released a newer version of the nRF5 SDK for Mesh (nRF5 SDK for Mesh v4.0.0). 

    1. 

    - Does each advertiser have a separate packet buffer or queue? In other words, are relay packets queued separately opposed to originator packets?

    Yes, packet buffers for originator and relay roles are different. Their sizes can be controlled by these settings: `CORE_TX_QUEUE_BUFFER_SIZE_ORIGINATOR`,  `CORE_TX_QUEUE_BUFFER_SIZE_RELAY`. 

    2. 

    - In what cases does calling advertiser_packet_send also mean that a previous configured INTERVAL by setup_next_timeout will be overwritten by novel RANDOM backoff configured by schedule_first_time being called again. In other words, when does the check for the advertiser being enabled and non-active, succeed?

     I'll need to look into this a bit closer. Will update the answer when I have more information. 

    Best regards, 
    Joakim Jakobsen

Related