• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 52 subscribers
  • Views 887 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bluetophia Increase transmit throughput

Elliott Gurrola
Prodigy 90 points
Other Parts Discussed in Thread: MSP430BT5190

Dear all,

I am currently developing a sensor station looking to provide a client device with readings from several sensors.

I have created a GATT Server and a corresponding set of Services which contain the characteristics with the sensor data.

My idea is that whenever the client connects, the station will start transmitting the sensor data to the client (I am using BLE configurations) However, I have run into an issue with the actual throughout.

Currently for testing purposes I am sending 6 bytes of data at a frequency of ~50 Hz. Unfortunately, increasing the frequency will cause the buffers to fill. I am sure I am not doing something right since I am barely transmitting 300bytes/sec!

I am using the ez430-rf256x development board which contains a PAN1323 BL module and a MSP430BT5190 MCU.

This is a rough outline of what I am doing:

I have created a BTPS Scheduler function that is called every 20 msec.

In the function I perform the sensor measurements and put the data into an array to be transmitted.

The device then checks if there is an active BLE connection. If there is one, I use the GATT_Handle_Value_Notification to transmit the data to the connected client.

However,, If I decrease the function's period, say to 10 ms, I get the BL stack giving an "Alloc Failed: 29".and the data transmission stops.

I am not very familiar with BL transmission practices but the throughput Im getting seems ridiculously small so I'm sure I am doing something wrong. I was thinking maybe I should rather create a bigger data buffer that contains multiple sensor readings this way I could send a bigger packet with a single call to the Notification function. However, it seems that the Notification function can only transmit up to a certain number of bytes.

Any pointers on this would really be appreciated! Maybe having my client do a GATT Read Request would be a better option instead of the server sending notifications? On a rough estimate I need around 1.5kbps which I think it should be very doable.

Thanks for the help!

  • 0
    Mastermind 7225 points

    Hi,

    The Alloc fails can be fixed by increasing the memory size. I have attached a document that explains increasing the memory size here. 4331.Changing RAM Size for CCS and IAR.PDF You should also look at the GATT_Set_Queuing_Parameters function.  This function can Set a limit on the number of packets that we will queue internally. This mechanism allows for the flexibility to limit the amount of RAM that is used for streaming type applications that are using un-acknowledged transactions. The SPPLE demo uses this. 

    Regards,

    Stonestreet One.

  • 0 in reply to Stonestreet One Support
    Prodigy 90 points

    Thank you for the reply!

    Increasing the RAM size would delay the Alloc message but if the output rate is less than the input rate the buffer would eventually fill up as well.

    I am guessing that storing data on a buffer and then transmitting it using bigger packets is more efficient.

    I was not aware of this function, I didn't realize there's a new version of the stack (I was using 1.3 for the MSP430) I'll check out the new SPPLE demo.

    I noticed that the GATT_Handle_Value_Notification function sends packets with a payload of up to 20 bytes. Is there a way to increase this value to something bigger? I am not sure if this is related to the MTU and the Bluetooth standard.

    Thanks again for the help!

  • 0 in reply to Elliott Gurrola
    Mastermind 7225 points

    Hi,

    The 20 bytes is related to the MTU. The V1.4 release supports upto 50 byte MTU. You should look at the GATT_Exchange_MTU_Request function on how to a change of connection MTU.

    Regards,

    Stonestreet One.

  • 0 in reply to Stonestreet One Support
    Prodigy 230 points

    I am having a similar issue with the HID Demo.  

    What I have found is that I get an AllocFailed:  2334 bytes after a period of time.  Using an air sniffer, I found that the device was connected to sent a mal-formed SDU packet to an invalid CID with an invalid length of 2334.  Coincidence?

    it seems like the bluetopia stack saw it and tried to allocate memory for it but failed.  Then, I would see the string of AllocFailed's because my HID Demo was sending a packet every 10ms.

    Increasing the heap size of the system didn't help things.  In this case, the memory allocation succeeds, but it looks like the packet wedges the stack and trying to tx data back to the master stops.  The packets get queued up until memory allocation fails.

    I'm trying to fix the host from sending mal-formed packets, but it'd be nice if the Bluetopia stack could drop this packet without stopping the TX.  Or, is there some event I'm supposed to capture to reset the stack state?

  • 0 in reply to Steve Paik
    Prodigy 90 points

    Stonestreet One Support said:

    Hi,

    The 20 bytes is related to the MTU. The V1.4 release supports upto 50 byte MTU. You should look at the GATT_Exchange_MTU_Request function on how to a change of connection MTU.

    Regards,

    Stonestreet One.

    I'll go ahead and migrate my project from v1.3 to v1.4, hopefully this will not change things that much.

    Also, is there a way for the Server/slave device to receive a connection and have it start with this extended MTU? I think BR/EDR has some kind of negotiation about this when the L2CAP channel is started, but I am not sure if LE has something similar. This way I do not need to send an MTU_Request from the Master/Client side.

    Thanks for all the support!

    Steve Paik said:

    I am having a similar issue with the HID Demo.  

    What I have found is that I get an AllocFailed:  2334 bytes after a period of time.  Using an air sniffer, I found that the device was connected to sent a mal-formed SDU packet to an invalid CID with an invalid length of 2334.  Coincidence?

    it seems like the bluetopia stack saw it and tried to allocate memory for it but failed.  Then, I would see the string of AllocFailed's because my HID Demo was sending a packet every 10ms.

    Increasing the heap size of the system didn't help things.  In this case, the memory allocation succeeds, but it looks like the packet wedges the stack and trying to tx data back to the master stops.  The packets get queued up until memory allocation fails.

    I'm trying to fix the host from sending mal-formed packets, but it'd be nice if the Bluetopia stack could drop this packet without stopping the TX.  Or, is there some event I'm supposed to capture to reset the stack state?

    I agree, increasing the buffer size would probably just delay the memory allocation failing.

    Indeed dropping the packet without disturbing the rest of the transmission would be nice.

    I'm curious about this air sniffer you mention, is this a piece of hardware/software? Could you give me some information about it?

    Thanks!

  • 0 in reply to Elliott Gurrola
    Prodigy 230 points

    Elliott Gurrola said:

    I'm curious about this air sniffer you mention, is this a piece of hardware/software? Could you give me some information about it?

    There are many commercially available BT sniffers - just search for "bluetooth sniffer" or "bluetooth protocol analyzer".  They are usually a combination of hardware and software.

    The traces that I have captured show that my host module is sending a strange SDP packet, and it causes the Bluetopia stack to shut down.  The obvious fix is to fix the host, but I also want to know if there's a way to recover from this situation in Bluetopia itself to make my application more robust?

  • 0 in reply to Steve Paik
    Prodigy 90 points

    I think

    int BTPSAPI HCI_Reset(unsigned int BluetoothStackID, Byte_t *StatusResult)

    should do what you want::

    This command resets the Bluetooth Host Controller, Link Manager, and the radio module. The current operational state and all queued packets will be lost. After the reset is completed, the Bluetooth device will enter standby mode, reverting to the default values for parameters which have defaults.

    I am not sure if there's an API that avoids losing all packets.

    Hope this helps

  • 0 in reply to Elliott Gurrola
    Mastermind 7225 points

    Elliott Gurrola said:

    Hi,

    The 20 bytes is related to the MTU. The V1.4 release supports upto 50 byte MTU. You should look at the GATT_Exchange_MTU_Request function on how to a change of connection MTU.

    Regards,

    Stonestreet One.

    I'll go ahead and migrate my project from v1.3 to v1.4, hopefully this will not change things that much.

    Also, is there a way for the Server/slave device to receive a connection and have it start with this extended MTU? I think BR/EDR has some kind of negotiation about this when the L2CAP channel is started, but I am not sure if LE has something similar. This way I do not need to send an MTU_Request from the Master/Client side.

    Thanks for all the support!

    Steve Paik said:

    I am having a similar issue with the HID Demo.  

    What I have found is that I get an AllocFailed:  2334 bytes after a period of time.  Using an air sniffer, I found that the device was connected to sent a mal-formed SDU packet to an invalid CID with an invalid length of 2334.  Coincidence?

    it seems like the bluetopia stack saw it and tried to allocate memory for it but failed.  Then, I would see the string of AllocFailed's because my HID Demo was sending a packet every 10ms.

    Increasing the heap size of the system didn't help things.  In this case, the memory allocation succeeds, but it looks like the packet wedges the stack and trying to tx data back to the master stops.  The packets get queued up until memory allocation fails.

    I'm trying to fix the host from sending mal-formed packets, but it'd be nice if the Bluetopia stack could drop this packet without stopping the TX.  Or, is there some event I'm supposed to capture to reset the stack state?

    I agree, increasing the buffer size would probably just delay the memory allocation failing.

    Indeed dropping the packet without disturbing the rest of the transmission would be nice.

    I'm curious about this air sniffer you mention, is this a piece of hardware/software? Could you give me some information about it?

    Thanks!

    [/quote]

    Elliott ,

    The MTU must be negotiated on every connection. 

    Thanks,

    Stonestreet One.