Hello,
I working on a project that uses the BC127 for remote control using BLE. Our app works on both IOS an Android. Our initial prototype used an HM-10 module, which has the following GATT properties.
HM-10
Service : “0000FFE0-0000-1000-8000-00805F9B34FB”
Characteristic: “0000FFE1-0000-1000-8000-00805F9B34FB”
Properties: WriteWithoutResponse, Notify
Accepts up to 20 bytes, sends data out UART
Data sent to UART comes back as NOTIFY
Our controller module was designed and built with the BC127.
We noticed that the BC127 Melody Smart has a similar feature:
BC127
Service:“BC2F4CC6-AAEF-4351-9034-D66268E328F0”
Characteristic:“06D1E5E7-79AD-4A71-8FAA-373789F7D93C”
Properties: write, notify
Write Type: WRITE REQUEST
Accepts up to 20 bytes, sends data out UART (DATA?)
Data sent to UART comes back as NOTIFY
Characteristic:“818AE306-9C5B-448D-B51A-7ADD6A5D314D”
Properties: WriteWithoutResponse, Notify
Write Type: WRITE REQUEST
Goes to DEV/NULL (CONTROL?)
The system works just fine sending data to the first BC127 characteristic (100’s of test hours doing that). The only problem is Write versus WriteWithoutResponse. The response mode basically cuts the bandwidth in half (meaning the HM-10 is twice as fast as the BC127 for this application). It really means the difference between smooth flowing operation versus jittery operation. We’ve tried all forms of compression to make the BC127 solution work, but the uncompressed HM-10 is still smoother.
So …
- Is there any way to switch the first characteristic (DATA) accept WriteWithoutResponse on either/both sides?
- Is there a way to petition for another GATT entry that behaves the same but does accept WriteWithoutResponse?
- Can we get more info on these GATT entries?
- Can we get behind the scene documentation on the Melody Smart system? Maybe opensource the java module sent in the android demo, which others can then stare at and adapt to their own needs.
- Any ideas, pointers, or brain storm on how to address this issue.
I found a note on Melody Smart in transparent mode, and how the UART speed affected that mode throughput. However while switching out of 9600 it only worked for a few seconds before losing the audio. We knew about a note that said you would loose audio if you switch to high speed due to the use of the DSP, so that wasn’t totally unexpected.
We love the A2DP support but NEED the 2X bandwidth that WriteWithoutResponse would provide. The solution works perfectly if only for that one thing. Heck, I would go back to just SPP which we tested originally and worked wonderfully, but … IOS … 'nuff said.