hello-client switch to slaves after smartphone connectes

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

cross mob
Anonymous
Not applicable

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?

0 Likes
1 Solution
Anonymous
Not applicable

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

View solution in original post

41 Replies
Anonymous
Not applicable

Hello Matthias,

Are you attempting to have both hello client and the smartphone client connected to the same slave simultaneously?

Thanks

JT

0 Likes
Anonymous
Not applicable

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.

0 Likes

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

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable
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

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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?

0 Likes
Anonymous
Not applicable

We will ask the developers to take a look and get back to you.

-Kevin

0 Likes
Anonymous
Not applicable

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.

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes

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.

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

in connection_up, the handle is 65 (0x41),

blecm_SetPtrConMux sets handle also to 65.

As you can see in the log, after the smartphone was connected,

there is now write-response anymore.

0 Likes

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.

0 Likes
Anonymous
Not applicable

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?

0 Likes

Please compare your code in the connection_up callback with hello_client.

0 Likes
Anonymous
Not applicable

Any specific I should look for?

My application uses hello_client as the basis.

0 Likes

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

0 Likes
Anonymous
Not applicable

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]);

0 Likes

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

0 Likes
Anonymous
Not applicable

jaruhl any updates?

0 Likes
Anonymous
Not applicable

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?

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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?

0 Likes
Anonymous
Not applicable

Hi kwang, victorz,

Do you have new updates on this issue?

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

Hi David,

since two days it's working now. I don't know why, but if it's woking it's ok.

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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.

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

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.

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

I created a sample based on the hello_client application with the same result.

After I connect the second sensor (not registering for notifications) the client can't set the index on the first sensor.

0 Likes
Anonymous
Not applicable

Hi @david_armour

After a week, are there new updates?

0 Likes
Anonymous
Not applicable

Hi Matthias,

Let me see if I can replicate this here.

Regards

Dave

0 Likes
Anonymous
Not applicable

Hi David,

Any new updates?

Can you reproduce the problem?

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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

0 Likes