Change "cyBle_connectingTimeout" ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi All,

In my project I have to reduce the "cyBle_connectingTimeout". But when I change ib the BLE.c file from 30 (default value) second to 1 then it works. But it automatically chaged to 30 when I compiled next time?

Is there a way to change this: cyBle_connectingTimeout = CYBLE_GAPC_CONNECTING_TIMEOUT;

Capture.PNG

So that I can reduce my connecting time??

Thanks

0 Likes
1 Solution
Anonymous
Not applicable

Thanks Pratt,

I have overwritten the variable to 1. And now it works.

But having major trouble in continuously connecting + Data Reading + Disconnection then goto next device and so on.....

As we discuss before about the project .......

In my central I am having huge trouble in reading the data from server. I made some test for sequential(connecting + Data Reading + Disconnection+Next Device) I can connect successfully and all but it does not always read the data from server. On testing I measured that in sequential mode the reading does not happen always. Which is deal break for us .....

If you have a bit time can you look over the central (client) ....

View solution in original post

0 Likes
11 Replies
Anonymous
Not applicable

There *might* be a connection timeout setting under the BLE component itself, so if you are setting it in code, and it is being recompiled, then the IDE would prioritize using the component's connection timeout setting instead of the code's timeout, and would recompile it back to the "default" setting of 30 seconds in the BLE component module

Anonymous
Not applicable

All of the files under the folder "Generated_Source" are generated by the IDE/Compiler on building the project, and are read/based on the components in the TopDesign.cysch file. If you want to change the connectingtimeout to a different value, then open up the BLE component and change the value there

0 Likes
Anonymous
Not applicable

Thanks Pratt,

I have overwritten the variable to 1. And now it works.

But having major trouble in continuously connecting + Data Reading + Disconnection then goto next device and so on.....

As we discuss before about the project .......

In my central I am having huge trouble in reading the data from server. I made some test for sequential(connecting + Data Reading + Disconnection+Next Device) I can connect successfully and all but it does not always read the data from server. On testing I measured that in sequential mode the reading does not happen always. Which is deal break for us .....

If you have a bit time can you look over the central (client) ....

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi Pratt

Finally it attached:

Any feedback will be helpful

0 Likes
Anonymous
Not applicable

Alright, so looking over the project, it seems like you have a nice debug/control menu to test things out (which looks really good).

I believe line 399:                ShowValue(&((CYBLE_GATTC_READ_RSP_PARAM_T *)eventParam)->value, 0u);

Is where you are copying the data from the read request for use? Is it sometimes showing the correct value, but sometimes showing incorrect values? Or is it pretty consistent?

From the looks of the layout, I would expect things to be 100% working, or at least failing on a consistent basis/timing. Can you give some more information about what you are seeing in your testing; E.G: log of the terminal commands/responses would be helpful to see what the sequencing is doing in your testing. It could be that the there is an error in the uart commands being sent/read, or the unit saving/reading the BLE attribute value, or with something crashing/messing up in the cases where it fails to read.

Something I've noticed when working with embedded projects, is that the time it takes to print out long debug messages (over a fixed 115 kbps uart for example) can cause the unit to crash, miss timing for events, or other issues that only occur because of timing constraints.

The BLE module has pretty stringent timing for the BLE connection interval timing, and will fail/crash if it doesn't get handled before that time is up. Thus, if you can mitigate time-intensive tasks like uart debug printing, or move them to be outside of the appCallback() interrupt, then it might end up fixing your issue.

For example: save the read value, store it to RAM, then do the UART print in main to allow BLE event handling to not be interrupted.

Most BLE timing issues come down to handling too much stuff inside of the BLE appcallback() event handler instead of using flags to save/signal the data from the BLE chip for what you want.

The UART is sending between 75-100 bytes in the cyble read response (estimated), and is running at 115385 bps. That means that the time to send the ~100 bytes (worst case) will be around 6.933 ms. This means that you would have between 0.56 ms to 3.06 ms to do ALL other processing on the chip besides the UART debug messages. Depending on the compression of the C-code to assembly, and the number of interrupts, speed of the clock, etc. then you might not have enough time to be sending the debug messages before the next cyble event occurs. AND if you get more than one UART debug-heavy event within the same 7.5ms window, then it's dead. You will miss the window timing.

The constraint here is basically: you have less than 7.5 ms to do everything you want between each call of the CyBle_Process_Events(), otherwise you start playing with crashes, failures, fire, etc.

I would suggest moving the UART prints to be in the main loop, and to using flags to signal them to send when you have time;

Otherwise, test removing/shortening the UART messages to see if that fixes things;

Increase the UART buffer length to have more temporary storage space.

Tl;Dr; Your UART is taking a long time to print messages, and being inside of the interrupt function will cause the unit to crash the BLESS if you get more than one BLE event in your appcallback() function in the same 7.5 ms window.

PS: Let me know if this doesn't make sense or you don't understand. Essentially the Printf() function blocks until data can be queued, and trying to print too much data too quickly could be causing the CPU to block the BLE chip from staying connected/reading data.

Anonymous
Not applicable

Hi Pratt

  1. Thanks for very detailed and clear replying 

“I believe line 399: ShowValue(&((CYBLE_GATTC_READ_RSP_PARAM_T *)eventParam)->value, 0u);

Is where you are copying the data from the read request for use? Is it sometimes showing the correct value, but sometimes showing incorrect values? Or is it pretty consistent?“

Yes you are correct, I am copying the data in showvalue. But it always shows me correct value. I never had an incorrect value.

read response.PNG

As you can see in the image that , its not the problem with the UART but that after setting the connection up I can not read the data, then I have a 1 second timeout and it goes to next device.

The device 3 got connected but I can not read data. So I debugged the program for long time and I found why it is happening:

CyBle_GattcReadCharacteristicValue() in central. The

CYBLE_EVT_GATTS_READ_CHAR_VAL_ACCESS_REQ must come in BLE Sensor (Peripheral).

And then We get a response at central as CYBLE_EVT_GATTC_READ_RSP: And can display the data on UART.

But the problem is after calling CyBle_GattcReadCharacteristicValue()in central the CYBLE_EVT_GATTS_READ_CHAR_VAL_ACCESS_REQ does not come at server (sometimes)and therefore there is no response event at central as CYBLE_EVT_GATTC_READ_RSP.

It has never happened  that after getting  CYBLE_EVT_GATTS_READ_CHAR_VAL_ACCESS_REQ event in BLE Sensor(Peripheral), we have not received response event at OFS.

And I cant figure out why it is happening sometimes.

I hope it is helpful

What you think what can be the problem?

0 Likes
Anonymous
Not applicable

Hmmmm, interesting.

Wirelessly, it could be that your read request from the Central device is not being detected by the peripheral device (wireless noise/interference, etc.) If that is the case, then you will want to change your device to retry the read request if you don't get a response within the expected time frame (multiple read responses would be preferable to not getting any read response).

I can't find it, but there might be a "reliable read" operation, but with your timing constraints you might be better off just retrying the read within a time limit.

Wireless packets have a natural failure rate. Depending on how noisy the environment is, that could be what you are seeing.

0 Likes
Anonymous
Not applicable

We tried everything.

Even created a technical support case. But till now no solution.

I do not know where is the problem

Or may be bluetooth  or cypress is not fit for this kind of application...No idea

We are stuck. May be try with bluegiga module for Receiver which can have 8 simultaneously.

0 Likes
Anonymous
Not applicable

Do you know for sure that the peripheral device is physically receiving the data read request?

Another option would be to have the peripheral do a Notification every couple milliseconds when a device connects to ensure quick data sending to the central device, rather than needing to wait for the central to read the value explicitly.

The new PSoC 6 supports 4 simultaneous BLE connections, and has two processors for faster operation with the big.little architecture.

If you can afford the larger power draw and size, a wiced or different module would work for supporting more connections/faster communication. Also, switching from BLE to standard bluetooth would speed up communication, but would force both ends to use classic bluetooth eliminating the power saving gains from BLE.

If the devices you are testing with aren't near each other, you could try placing them all on the same table to see if the distance is causing the missed packets.

Since you already have a cypress project, it should be easy to port it to other BLE modules for testing if you can get more reliable signaling and communications. Also, the CAP_TRIM value for the BLE module could be incorrect causing some mistiming/dropped packets like you are seeing?

user_1377889​ Has pretty good knowledge and might have some helpful advice as well

0 Likes
Anonymous
Not applicable

Do you know for sure that the peripheral device is physically receiving the data read request?

😆 Ya the packets are not receiving by peripheral. we debug it

We tried with notification but the same problem exits. This time the connecting timeout occurred sometime  

Now it will be too much change in our project.

We need a long range module and there are not much available from cypress.

Now we tested bluegiga 121LR and tried 8 simultaneous connection with notification and works perfect. But this will delay our product.

If cypress can provide solution then perfect, otherwise we will have a shot at bluegiga 121LR.

One more question:

When I defined my custom characteristics but I can not see the characteristics name in the app?

But when I use any example like: Heart rate or thermometer then I can see the android app (CySmart) the characteristics name?

I will write him. Let see

0 Likes
Anonymous
Not applicable

You could try send the same notification twice in a row to double the chances of receiving notifications?

But otherwise, it is a hardware constraint for timing and wireless reliablility (which is always hard)

If you open a case with Cypress' support team you might get help with reliable transmission/faster resolution for the timing of packets, but it may be difficult to get higher reliability with the same module too. The PSoC 6 that came out supports 4 devices simultaneously, and some of the WiCED devices support more BLE modules, but I'm not sure which exact product numbers have the best specs.

That's great that you got it working with the Bluegiga though!

You have to specify the name in the BLE component when you create a custom characteristic, and if you do so it should be showing up on the Cysmart app easily. Under the Custom Characteristic, there is a "Description" and a "CCCD" field. The "description" field is the "name" of the characteristic, and if you put the data for your name in there it should work for showing up in Cysmart.

0 Likes