- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I build a application based on the hello-client that is checking some
environmental values and send some data to connected slaves. A user can change
some data with his smartphone. But if the smartphone is connected, the
hello-client can't write to the connected slave.
How can I switch back to the slave to send new data?
Solved! Go to Solution.
- Tags:
- hello-client
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
We ran your code and found the same error.
Here's what we did:
1. Connect hello_sensor to your hello_client (connhandle : 0x41)
2. Connect 2nd hello_sensor to your hello_client (connhandle : 0x42)
The error happens because of the way connections are added to the conn mux and the way hello_client keeps track of those connections.
The hello_client adds a new connection to the mux by calling:
blecm_AddConMux(con_index, con_handle, sizeof (hello_client_gatt_database), (void *)hello_client_gatt_database,
&hello_client.dev_info[cm_index], &hello_client.smp_info[cm_index]);
and keeps track of them by storing the connection info in hello_client.dev_info
Notice how con_index is used to add new connection and how cm_index is used to index those connections in the dev_info array.
Those two numbers should match when you are adding a new connection. However, they don't in your hello_client.
From the code:
con_index = connhandle - 0x40;
cm_index = blecm_FindFreeConMux();
The original hello_client expects the connhandle from first connection to be 0x40.
The following is the debug trace from the original hello_client:
10:01:21 - con_handle: 64, con_index: 0
10:01:21 -
10:01:21 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1
10:01:21 - $$$$$$$$$$$$$$$$$$$ what is cm_index: 0
10:02:25 - con_handle: 65, con_index: 1
10:02:25 -
10:02:25 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1
10:02:25 - $$$$$$$$$$$$$$$$$$$ what is cm_index: 1
note 64 is 0x40. Notice how con_index and cm_index are matching?
Now for some reason, using your hello_client, the connhandle from the first connection is 0x41.
The following is the debug trace from your hello_client:
09:38:57 - con_handle: 65, con_index: 1
09:38:57 -
09:38:57 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1
09:38:57 - &&&&&&&&&&&&&&&&&&& what is cm_index: 0
09:39:31 - con_handle: 66, con_index: 2
09:39:31 -
09:39:31 - &&&&&&&&&&&&&&&&&&& what is found cm_index: -1
09:39:31 - &&&&&&&&&&&&&&&&&&& what is cm_index: 0
note 65 is 0x41. Notice the difference in con_index and cm_index?
Remember you are using con_index for adding new connections to con mux and cm_index to access dev_info from the app.
So the first connection gets saved in con mux with index 1 and the second connection gets saved with index 2.
But index 0 is still unused. So when you initialize cm_index with blecm_FindFreeConMux, you always get 0, since the method returns first unused index in con mux. So since cm_index is the same for both connections, you are overwriting the data in the array dev_info.
So when you loop through it, you only have the info about the latest device.
A simple solution that I found was to use cm_index when you are adding the new connection to con mux in connection_up callback.
blecm_AddConMux(cm_index, con_handle, sizeof (hello_client_gatt_database), (void *)hello_client_gatt_database,
&hello_client.dev_info[cm_index], &hello_client.smp_info[cm_index]);
Also in connection_down, you might want to change con_index like this:
UINT32 con_index = blecm_FindConMux(con_handle);
With these changes I was able to get this result:
11:50:03 - hello_client_timeout sending 15 to:0041
11:50:03 -
11:50:03 - l2cap Tx:
11:50:03 - 41200800040004001202010f
11:50:03 - hello_client_timeout sending 15 to:0042
11:50:03 -
11:50:03 - l2cap Tx:
11:50:03 - 42200800040004001202010f
I don't know why the connhandle from the first connection is 0x41 from your code.
I'll ask the developers about that.
Does this solve your problem? Please let us know.
Thank you
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Matthias,
Are you attempting to have both hello client and the smartphone client connected to the same slave simultaneously?
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi j.t,
No, client is connected to the hello-client. Later the user should be able to change some settings with his smartphone on the hello-client, so the hello-client can send other data to the connected clients.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think what he you are saying is that you would like for your handset (Central) to connect to a sensor (peripheral), read some data from the sensor, then display that data within an app on the handset.
---Standard operation at this point right, everything is working fine---
Now, you want to be able to make changes to that data within the peer/handset app and then send it back to the sensor as to modify the contents of the sensor's GATT DB.
Note that at a high level, the peer/central device can perform GATT discovery to find services, characteristics, and descriptors that are exposed by running the application. After discovery the peer can read and write to the GATT database of the connected client/sensor/peripheral, subject to characteristic properties and permissions that are setup by the application. So how has the GATT DB been formed on the sensor? Are the characteristics/attributes designated as writable?
The application on the sensor side can then can register a callback (legattdb_regWriteHandleCb) to receive notification when a peer writes something to the GATT database. When a callback is executed the application receives a handle of the characteristic that has been updated. The application can read the new value from the database using bleprofile_ReadHandle.
This is pretty standard operation if I understand what you are trying to do correctly.
More on this here:How to Write WICED Smart Applications
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi mwf_mmfae,
The communication between the handset and sensor is working fine at the moment.
The handset connects to the sensor and can write the data.
But if a user connects later on with his smartphone (just connect and disconnect is enought),
there is no write-response again from the sensor. Also there are no new data on the sensor.
In the real application, the handset is measuring some environmental data and drive the sensors,
the user can adjust some settings with his smartphone from time to time, if needed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
void hello_client_process_data_from_slave(int len, UINT8 *data) { // if master allows notifications, forward received data // Because we will be sending on the different connection, change Set Pointer to the master context if ((hello_client.hostinfo.characteristic_client_configuration & CCC_NOTIFICATION) != 0) { blecm_SetPtrConMux(hello_client.handle_to_master); bleprofile_sendNotification(HANDLE_HELLO_CLIENT_DATA_VALUE, data, len < 20 ? len : 20); } else if ((hello_client.hostinfo.characteristic_client_configuration & CCC_INDICATION) != 0) { blecm_SetPtrConMux(hello_client.handle_to_master); bleprofile_sendIndication(HANDLE_HELLO_CLIENT_DATA_VALUE, data, len < 20 ? len : 20, NULL); } }
Please check out the snippet from hello_client
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi kwang,
I think this is only if I receive data from the slave,
but my handset is writing into a characteristic on the slave
(at the moment only on one slave, in the later product on multiple slaves)
So I think the snippet won't help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This problem is still not solved.
Also if I the handset is connected to two slaves how can I switch back to the first slave to write some data to that slave?
Is there a function I can switch to/between the connected slaves?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We will ask the developers to take a look and get back to you.
-Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Kevin,
I even tried to call
blecm_SetPtrConMux(handle);
just before writing the data to the sensor.
But if I connect with to the handset with a smartphone,
writing to the sensor is not possible anymore.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
blecm_SetPtrConMux(handle); just before you do the write is likely to be a solution. I would recommend to trace handles when connection I sect established and when you do the write and make sure you are addressing the slave you want.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi victorz,
At the moment I save the handle for the clients in an array.
When writing data to the slaves, i go through the array and for every entry I call:
blecm_SetPtrConMux bleprofile_sendWriteReq
(next handle)
But this is NOT working.
In the trace I got a handle 65 for the slave which should be OK I think.
The handle won't change if I connect with a smartphone, but it seems no data will be sent to the slave.
I send the data every 100ms. Is this to fast to switch the mux and send the data? On my tests there is only one slave and later a master connected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please print the handles when connections are established and between SetPtrConMux and WriteReq and the publish trace. Also please add
extern UINT32 blecm_configFlag ;
blecm_configFlag |= BLECM_DBGUART_LOG | BLECM_DBGUART_LOG_L2CAP | BLECM_DBGUART_LOG_SMP;
in the create function.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can see the trace for your connection to master
11:09:22 - sensor_connection_up handle:40 slave:1 num:1 to_master:64
When you think that you set pointer to 41 the packet still goes to 40
11:09:38 - SetPtrConMux to handle 65 and index to 41, tx-buffers: 15
11:09:38 - l2cap Tx:
11:09:38 - 402008000400040012020129
Please compare your code in the connection_up function with hello_client. This should work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, the "index" is the data I send to the slave.
As you can see in the trace, I send from 254 to 0 (regarding the environmental data).
The handle for blecm_SetPtrConMux is always 0x41
But I can see that the Tx and Rx are from 40, instead of 41.
Perhaps I forgot to call another function before I can use blecm_SetPtrConMux?
It seems that function won't change the mux, or I can't change back to slaves?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please compare your code in the connection_up callback with hello_client.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any specific I should look for?
My application uses hello_client as the basis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Allocation of the cm_index blecm_FindFreeConMux saving device connection info
// copy dev_pinfo |
memcpy((UINT8 *)&hello_client.dev_info[cm_index], (UINT8 *)emconinfo_getPtr(), sizeof(EMCONINFO_DEVINFO));
and blecm_AddConMux
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Both are called in the connection up and give diverent values:
if connecting to the slave:
07:28:24 - dev_info: peerClkAccuracy: 5, connHandle: 65, role: 0, peerDeviceBonded: 0, addrType: 0, appTimerId: -1
07:28:24 - dev_info: connIdleTimeout: 60, devState: 5
if connecting to the smartphone:
07:28:39 - dev_info: peerClkAccuracy: 5, connHandle: 64, role: 1, peerDeviceBonded: 0, addrType: 0, appTimerId: -1
07:28:39 - dev_info: connIdleTimeout: 60, devState: 5
blecm_AddConMux don't give me something back, but here is the call:
blecm_AddConMux((INT32)con_index, con_handle, gatt_database_len, (void *)gatt_database,
& handset.dev_info[cm_index], &handset.smp_info[cm_index]);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I modified hello_client connection timeout routine to send some message to all connected slaves, and it seems to work ok. I struggles for a bit, because I forgot to program devices with different BDADDRs. Make sure that you do not have the same problem.
UINT8 con_index, u8 = 1; | |
ble_trace1("hello_client_timeout:%d", count); |
for (con_index = 0; con_index < HELLO_CLIENT_MAX_SLAVES; con_index++) | |
{ | |
if ((hello_client.dev_info[con_index].connHandle != 0) && | |
(hello_client.dev_info[con_index].connHandle != hello_client.handle_to_master)) | |
{ | |
ble_trace1("hello_client_timeout sending to:%04x", hello_client.dev_info[con_index].connHandle); | |
blecm_SetPtrConMux(hello_client.dev_info[con_index].connHandle); | |
bleprofile_sendWriteReq(HANDLE_HELLO_SENSOR_CONFIGURATION, (UINT8 *)&u8, 1); |
} | |
} |
12:39:19 - hello_client_timeout:130
12:39:19 - hello_client_timeout sending to:0041
12:39:19 -
12:39:19 - l2cap Tx:
12:39:19 - 4120080004000400122d0001
12:39:19 - hello_client_timeout sending to:0042
12:39:19 -
12:39:19 - l2cap Tx:
12:39:19 - 4220080004000400122d0001
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, I was out of office for the last two weeks.
I compared the hello_client and my application again, but can't find bigger differences.
Is there something I can check why I blecm_SetPtrConMux fails?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not think blecm_SetPtrConMux can fail. You either save wrong information or save to the wrong location or point to the wrong location.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But I checked more than once the handle in conn_up and when I set the Mux. This is always the same, but in the trace the stack don't change the mux.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi jaruhl,
We are having trouble pinpointing where you are having problems. I think your best options are 1) start over with the hello_client code or 2) send us your code and we can take a look and see if we can find anything.
Thanks,
Kevin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I retested your code in the hello-client with my appliction and advertisements all the time:
I start the hello_client,
start the BLE-device,
press the button on the hello_client:
Both are connected and writing some data is working fine.
Now I start a android-application and connect to the hello_client
after the connection is established,
writing to the BLE-device is not possible anymore.
So also with the hello_client and your snippet it won't work.
All my versions:
SDK: WICED-Smart SDK 2.2.1
Smartphone: Android 4.4.2
Applications on Android: WICED SMART Explorer 2.06
nRF Master Control Panel (BLE) 3.4.1
Connection:
BLE-Device -> hello_client <- smartphone
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a NDA between you and us,
so I could send you the modified hello_client-application if you need it to check where the problem is.
Or is there a solution?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Matthias,
I have checked with my applications colleagues and can confirm that our code example executes correctly so the issue must be related to the changes you have made to the code. Please compare your code vs the sample application to identify the areas that were changed and advise where the differences are.
If you are unable to debug the issue then please share the code and we will review.
Regards
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
since two days it's working now. I don't know why, but if it's woking it's ok.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Matthias,
Many thanks for the feedback. It might be worth checking if there were any updates to the phone that may have cleared the issue but for the moment I'll mark the issue as resolved. If you encounter the issue again then please let me know.
Regards
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
No, there were no updates on the phone. The phone is only for testing my application without access to the internet.
But at the moment, I stopped sending the security request. The Smartphone can't bond, don't know why.
Withou bonding the Smartphone can connect and read and write data.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
Now I have two sensors connected to my client, with the same result.
The mux is not working!
In the trace you can see I'm connecting a device 'X' with the handle 41.
The communication to it works fine.
But if the second device ('M') connectes, there is no further connection to the device 'X' with handle 41.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @david_armour
After a week, are there new updates?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Matthias,
Let me see if I can replicate this here.
Regards
Dave
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
Any new updates?
Can you reproduce the problem?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi david_armour
Any new updates from the labor?
Is somebody working on this?
Could you replicat the problem?
A lot of questions, no answers.
But I need a solution within the next days. I don't think our customers will wait forever.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Matthias,
We attempted to replicate your problem today but were unsuccessful.
We will try it again tomorrow morning and give you some feedback.
Thanks
JT