WICED Smart Bluetooth

[AlSp_2628001]

Hi,

I'm trying to use a CYBLE-013025 in "retained command mode", that is keeping the CYSPP pin driven high and the CYSPP "enable" value to "enabled", so that no transparent mode is used.

In this condition, API commands, replies and events are visible and I can succesfully receive data from the central remote on the "Acknowledged Data Characteristic" (gatts_data_written event). Instead, I can't find a way to indicate data to the remote using the same characteristic.

When I try to indicate (/IH,C=0,H=0E,D=AB), I get a 0x108 error (operation not permitted). Of course, the remote central has subscribed to indications. Indeed, if I assert CYSPP low and try to indicate with the same command, I can see the indication packet that gets indicated on the remote.

So, my question is: how can I retain the command mode and indicate to a remote? Is this possible? If not, should I write my own custom GATT?

Thank you very much.

Alberto

[GyanC_36]

Hi Alberto,

    Firstly , if you are not making use of CYSPP profile I would suggest to create your own GATT database with required attributes permissions.

Which remote device are you using ? Is it another EZ- Serial device or a normal BLE central device?

Asserting CYSPP Pin will enable CYSPP Mode ( Exit Command Mode) , how are you sending indication command in this Mode ?

Of course if you are sending Indication/Notification ,the central device needs to subscribe the server device for it. If you are using a Non EZ -Serial Central device (OR Ez -Serial in Command Mode) ,you will need to Enable/Subscribe  for Indication/Notification.

Please send some command/response screenshot for our analysis and reproduce the behavior.

-Gyan

[AlSp_2628001]

Hi Gyan,

thank you for your kind reply and sorry for not being clear...

I've succesfully managed to communicate through CYSPP transparent mode communication to a BLE USB dongle. Everything fine, here.

Now, another company is developing a mobile app for both iOS and Android. I'm trying to maximize throughput, but they say they sometimes lose packets. Then, my idea was to use the acknowledge chracteristic and send data as soon as I get the acknowledge from the central device. In order to do so, I'd like to keep using command mode after connection by keeping the CYSPP pin de-asserted, but I don't even know if this is possible.

As soon as I get to my office (in a few hours) I'll post the exact API sequence I'm using.

Roughly, this is the logic:

• CYSPP left floating by my uC
• CYSPP and CONNECTION get asserted (central has connected and subscribed)
• CYSPP forced high by my uC
• from now on, I'd like to use the existing characteristic in command mode

Thank you very much,

Alberto

[AlSp_2628001]

Hi Gyan,

I've experimented a bit more and seen that I can use a custom characteristic for what I'm trying to do.

Anyway, please find attached two examples (both were produced using CYBLE-013025 with CYSPP pin forcedly de-asserted and I inserted some comments):

• EZ-Serial_command_mode_indication.txt
  this is what I'd like to obtain
  
  
• customized_characteristic_command_mode_indication.txt
  this is what I managed to make operational

Am I doing anything wrong, or the only feasible way is the second one?

Again, thank you.

Kind regards,

Alberto

[GyanC_36 · Accepted solution]

Hi Alberto,

   As soon as we subscribe the client device either for Notifications or Indications ,the CYSPP Command Mode will no longer work if the CYSPP is enabled in platform configuration ( CYSPPSP, E=1) and that is mandatory condition for command retained mode.  ( page # 14 " Starting CYSPP Operation")

Now, if you want to send indication packets based on an ACK from central device ,you need to create your own GATT database.

-Gyan

[AlSp_2628001]

Hi Gyan,

thank you very much for clarifying this.

I misunderstood the documentation and thought that the CYSPP pin (and CYSPP mode) were simply enabling communication transparency.

Kind regards,

Alberto