how to send 1-3kB of data on a trigger event cc2541

Amy,

This depends on exactly what the customer wants to do with the CC2541.

It sounds like the customer needs reference for transmitting upon a GPIO input level change or a UART buffer filling.

We have several examples of this in our BLE-STACK application software package.

CC2541 BLE Code Examples: http://www.ti.com/tool/ble-stack

Also, if they need reference for setting up triggers using the DMA this is covered in the CC2541 User's Guide on page 95.

CC253x/4x User Guide: http://www.ti.com/lit/ug/swru191c/swru191c.pdf#page=95

One more thing that I think the customer will find useful during software development is the BLE SW Developer's Guide, which gives detailed explanations for designing with CC2541.

CC2540/41 BLE Software Developer’s Guide: http://www.ti.com/lit/ug/swru271b/swru271b.pdf

Let me know if you need anything else. 

Austin -

Thank you for your reply.  I am on the project team that Amy Garcia was referencing.  Let me try to frame our needs a little differently as your reply didn't quite get us what we need.

We are looking for advice on what GATT functions should be used optimally move 1 to 3kb of sensor data (as a package) from the CC2541 device acting as a GATT server to an iPhone acting as a GATT client.  We require guaranteed delivery of data, so notifications are not an option.

Our application on the CC2541 buffers sensor data until a specific sensor condition is found.  At that point we want to transfer the buffered data as quickly as possible to the iPhone using BLE and GATT with guaranteed delivery.  The amount of data to be sent is nominally 3kbytes.  It is our understanding that approximately 80 bytes distributed across 4 packets can be transferred in a single connection event.

Being new to BLE, we are looking for advice on whether to use Read Characteristic Value,  Read Using Characteristic UUID,  Read Long Characteristic Values, or Read Multiple Characteristic Values or some other approach.   Furthermore, how does the GATT server application know when a Read Characteristic has occurred so it can refresh the characteristic value with the next buffered data to be sent ?  Do we need to set up some form of handshake with the phone using another attribute?
Thanks for your help.

Pat S.

Thanks, Greg.  That is exactly what we needed.

Can we count on the data being received in the order queued by the server application or do we need to add a serial number to each transmission?

Pat.

Some customers say they see out of order, but in all  my throughput testing so far I do not see this.   As long as you check the GATT_notification return value, and resend it (in order) if it fails, then all should go in order.

BR,

-Greg

Hello Pat

We have a similar need to send about 2kbytes of data. can you share some thoughts on your approach on this? Here is what I'm roughly thinking

server (sensor) sets a notification

client (tablet) gets notification. executes a read characteristic - how do we transfer bulk data from sever here? 

thanks

ganesh

Ganesh -

We successfully implemented the approach shown above recommended by GregS.  When our device (server) wakes up it advertises, we establish a connection with the iPhone.  When the 3k of data is ready to be sent to the phone we send it via sequential notifications.  We have optimized the packing of the data into the notifications and are able to get the data to the iPhone in about 1 second.

Good luck.

Pat.

Hi Pat,

We have a similar issue with the CC2541. We modified the sample keyfob application and used GATT_Notification to send our data. Could you please clarify if you meant 3k bytes or bits per second.

Hi GregS,

We currently have a data size of 7kilobits that need to to be transmitted in a second to either an android phone or PC. Is there any way we can define a custom-packet format (excluding the the existing Header, PduLen, Handle fields of the GATT_Notification)? If so, what API should we beuse in the firmware? If not, could you point us in the right direction to achieve this in firmware.

Thank You,

Regards,

Vinay

Vinay -

We sent 3K bytes in 1 second using notificatons.

Pat.

Hello,

Previous to 1.4, to achieve above 5K byte/sec you would have to use short connection interval - maybe 10 or 12 ms, and use large packet sizes (20 bytes user data). Some phones and devices limit min connection interval to 30ms or more which limits throughput.

With 1.4 there is new feature allowing phy to accept new packets from application as packets are sent out and acked. Check wiki for details

http://processors.wiki.ti.com/index.php/OverlappedProcessing

Processing and MIPS can still be an issue, but this should help achieve higher throughput on phones which allow more than a few packets per connection interval.

BR,

-Greg 

@Pat

Thanks for clearing that up.

@Greg

Thanks for the info and link. We'll try this and get back to you with the results.

Vinay

Hi Greg,

We tried using the "Overlapped Patch" on the peripheral(CC2541 keyfob), but what about the USB dongle(Central). If we substitute the patch-provided SimpleBLECentral.c file and flash the USB dongle, it fails to be recognized as a CDC device that can be read from BTool (using an emulated COM port).

We appreciate all your help.

Thank You,

Best Regards,

Vinay

Hello,

Typically, USBDongle is loaded with HostTestRelease and runs as a network processor - accepting commands from PC. Note, that serial processing will impact max throughput.

Send this command from Btool, or add it to init function.

HCI_EXT_OverlappedProcessingCmd(HCI_EXT_ENABLE_OVERLAPPED_PROCESSING);
You will also need 

HCI_EXT_HaltDuringRfCmd(HCI_EXT_HALT_DURING_RF_ENABLE);

If you do want to run SimpleBleCentral - then I recommend adding these commands, but running it on SmartRF board with EM module.

BR,
-Greg

Hi Greg,

Thank you for that information. Even with overlapped processing, we are not able to break through the 2k bytes per second barrier (excluding header-bytes, viz.  Type, EventCode, DataLength etc.). We have our connection interval set at 7.5ms. Including the stack-added header bytes (11 in total) the data-rate is 3.1k bytes per second.

We're measuring this sample-rate based on the time-stamps in BTool. What are we missing? Or is this the limit of BLE?

Thank you,

Best Regards,

Vinay