Forums - Tx Queue Characterization

8 posts / 0 new
Last post
Tx Queue Characterization
karthikeyan.t
Join Date: 3 May 15
Posts: 27
Posted: Wed, 2016-07-13 19:54

 

Hi,

Messages send by the device get queued in the Tx Queue. Has anyone characterized this queue to answer the questions -

1. What is the queue length?

2. How will advertisment time and advertisement interval affect the message transmission? Suppose the advertisement time is 600ms and there are two messages in the queue, will each message be sent 600ms apart, or will they be sent simultaneously in an interleaved manner.

3. Is there any way to flush the queue?

4. What is the behaviour when the queue is full?

Regards,

Karthik

 

 

  • Up0
  • Down0
Dr. Nissim Zur
Profile picture
Join Date: 6 Jun 16
Location: Skype: nissim.test CSR1010 External design house
Posts: 235
Posted: Wed, 2016-07-13 20:59

1. What is the queue length?

probably ~31 bytes. No documentation. Use 21 bytes to be on safe side.

2. How will advertisement time and advertisement interval affect the message transmission? Suppose the advertisement time is 600ms and there are two messages in the queue, will each message be sent 600ms apart, or will they be sent simultaneously in an interleaved manner. Messages are sent ASAP. So if you fill the buffer,All will be send immediately.

3. Is there any way to flush the queue?

There is a command to clear. But it useless, since once you add data to buffer, it RF TX already.

4. What is the behaviour when the queue is full?

Lost data if you add more than the queue space.

  • Up0
  • Down0
karthikeyan.t
Join Date: 3 May 15
Posts: 27
Posted: Thu, 2016-07-14 00:59

 

I hope my understanding is not wrong.

I believe the Tx queue is for messages (or) is it a byte queue as Dr Nissim mentioned?

When a message sending API is called, the message is sent over a time period, it will not be instantenous. i.e. each message is retransmitted over a period of time based on the advertisement interval and advertisement time.

Eg. -

Consider the advertisement interval = 90, advertisement time = 600. Each message sent will be sent around 6 times.

Now, if our program is sending two messages Msg1 and Msg2 90ms apart only once, then what will be the beaviour?

1. Msg1----90ms----Msg1----90ms----Msg1----90ms----Msg1----90ms----Msg1----Msg2----90ms----Msg2----90ms----Msg2----90ms----Msg2----90ms----Msg2

or

2. Msg1----90ms----Msg1Msg2----90ms----Msg1Msg2----90msMsg2----Msg1Msg2----90ms----Msg1Msg2----90ms----Msg2

 

 

 

  • Up0
  • Down0
Dr. Nissim Zur
Profile picture
Join Date: 6 Jun 16
Location: Skype: nissim.test CSR1010 External design house
Posts: 235
Posted: Thu, 2016-07-14 04:45

You have only one buffer, so any new data will replace old data on same buffer. 

and yes, it bytes size... 

  • Up0
  • Down0
karthikeyan.t
Join Date: 3 May 15
Posts: 27
Posted: Thu, 2016-07-14 20:27

 

Ok, I have checked the current consumption using oscilloscope and am pretty sure the data is being sent in an interleaved manner. But not sure of the sequence.

Image 1 - Using Data Model, Data is sent once, advertisement interval - 90ms, advertisement time - 600ms

 

Image 2 - Using Data Model, Data is sent twice 50ms apart, advertisement interval - 90ms, advertisement time - 600ms

Image 3 - Using Data Model, Data is sent 10 times 10ms apart, advertisement interval - 90ms, advertisement time - 600ms

Can CSR Comment on the Tx Queue size and behaviour?

 

 

  • Up0
  • Down0
Jesse Tsai Moderator
Join Date: 5 Apr 16
Posts: 12
Posted: Wed, 2016-08-03 01:43

Hi Karthik,

Please refer to my comments below:

1. The default size is 8 and it is maximum. You can set and get the size by API:

CSRSchedSetConfigParams/CSRSchedGetConfigParams (le_params -> mesh_le_param -> tx_param -> tx_queue_size)

2. The message are sent by turns not simultaneously.

3. Currently no API to do that.

4. It takes the slot which transmitted the most messages.

 

Thanks.

  • Up0
  • Down0
aircable
Join Date: 8 Jun 16
Location: San Jose
Posts: 25
Posted: Sat, 2016-08-20 14:12

Jesse,

I cannot confirm your 4th point: 4. It takes the slot which transmitted the most messages.

After lots of tests and trying to send as many messages as possible, I have to say that the CSRmesh library locks up, when you send messages too quickly. First messages are sent out ok, then the buffers reduce to only about 1 message per default_adv_time and then to nothing. All calls succeed and there are no error messages. But the transmitter just stops transmitting. This is clearly visible when using the DEBUG_RADIO_TX pin configuration. 

When shortening the default_adv_window, you can send out more message, but it will lock up eventually too.

There must be a bug in the library buffer management. Interesting enough, the diagnostic counters are still working and shows that messages are being sent, but they are not.

If the rate of messages sent is kept at a low pace, the library will work fine. It's only when you send messages out faster than the adv_interval and adv_time when it happens.

Can you guys please check it or give us some hints how fast we can post messages to the library for transmitting?

Thanks

  • Up0
  • Down0
karthikeyan.t
Join Date: 3 May 15
Posts: 27
Posted: Wed, 2016-10-05 22:38

 

Hi CSR,

Please comment on how to recover from a lock up when sending too many messages.

If we have some API to detect the lockup of Tx, then atleast we can reboot the board.

I am using Stream Data Block on CSR Mesh 1.3 library. My application can only use this.

 

 

 

 

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.