BLE Mesh Project with BLE_NUS

[sara]

Hello,

I'm using the sample project from this post.

Following the steps and using nRF52DK, one for server and one for client. I've modified the server count from 3 to 1 in client project .

#define SERVER_COUNT (<<1>>)

The provisioning is success, the server side will get the response and show

RX: [aop: 0x00C3]

on the J-Link RTT Viewer when I press button 3,but there is no response in server side when I press button0.

I don't have any idea how to solve this problem, could you give me some hints? Thanks.

P.S. The following image is the log of client side.

[Updated on 2017/10/18]

Based on Hung Bui's comment, I tried to get the unicast address by dsm_local_unicast_addresses_get() function. I get the same unicast address "1" when I press button 0 or 3.

Still can NOT solve the problem...

[Hung Bui]

Hi Sara,

This is showing the server subscribed successfully to the group address (0xCAFE) but for some reason the unicast address was not matched. You need to check which unicast address the server has after provisioning. You can use dsm_local_unicast_addresses_get() to get the unicast address.

Then you compare it to the broadcast address of the client when you press button 0.

If you have a look at the mesh_msg_handle() function in access.c you can print out more information about the packet including source address, destination address.

[sara]

Thanks for your reply, and I updated on the main post, thanks.

[Hung Bui]

Hi Sara,

It's not really what I want you to do. I want you to get the unicast address of the server, not the client. You need to understand how the example works. There are 3 servers (or one in your case), and there are 3 clients on the provisioner (the client project). Each client control one server.

The publication address of the client should match with the unicast address of the server.

To get the publication address of the client you need to call smth like this:

 for (uint32_t i = 0; i <= CLIENT_COUNT; i++)
 {
          dsm_handle_t address_handle = DSM_HANDLE_INVALID;
          nrf_mesh_address_t publish_address;
          ERROR_CHECK(access_model_publish_address_get(m_clients[i].model_handle, &address_handle));
          ERROR_CHECK(dsm_address_get(address_handle,&publish_address));
          __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Client %d's publish address: 0x%x\n",i,publish_address.value);
 }

[sara]

Hello Hung Bui, Got it, I thought wrong before. The unicast address and the publish address what I got are the same which are 0x10. The addresses are matched, maybe it's not the main problem. I'm thinking maybe I should check the "simple_on_off_client_set()" function first, because the function "simple_on_off_client_set_unreliable()" works but "simple_on_off_client_set()" doesn't. Anyway, thanks for your help again.

[Hung Bui]

You can try to send a unreliable packet but with address 0x10 to see if it manage to get to the server.

Actually you can send a packet directly using access layer call access_model_publish()