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.
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,
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):
this is what I'd like to obtain
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.
1 of 1 people found this helpful
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.
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.