Establish Smart Phone Data Link from Mesh Proxy

RE: Establish Smart Phone Data Link from Mesh Proxy

brent_dong — Fri, 23 Nov 2018 11:04:48 GMT

Yes, it works! but not so easy. nerf_mesh is just demo for provision. needs a lot of time to read through before start an workable application. Just get started with mesh stacks.

RE: Establish Smart Phone Data Link from Mesh Proxy

gsegment — Thu, 27 Sep 2018 18:16:35 GMT

Hi, do you have success with phone app to monitor mesh network?

RE: Establish Smart Phone Data Link from Mesh Proxy

Bjørn Kvaale — Wed, 12 Sep 2018 06:40:43 GMT

Hi Brent,

Thanks for the update. Let me know if you have any more questions regarding this subject.

Kind Regards,

Bjørn

RE: Establish Smart Phone Data Link from Mesh Proxy

brent_dong — Wed, 12 Sep 2018 06:37:56 GMT

Hi， Bjørn

Forget about this question.

Without nrf_mesh, we can not get through encryption_decryption process, I realized why the data received on smart phone is totally not what I sent.

Regards

Brent

RE: Establish Smart Phone Data Link from Mesh Proxy

brent_dong — Mon, 10 Sep 2018 22:43:35 GMT

Hi， Bjørn

Still a question to ask.

In mesh profile , page 141, there is a " GATT Proxy State" defined , this state decides Proxy enable, Proxy disable or Proxy unsupported.

I think , this state tell us why smart phone connection is rejected when trying sending data to mesh network.

When I trace back to code, this state is controlled by " Config_Server":

static void handle_config_gatt_proxy_get(access_model_handle_t handle, const access_message_rx_t * p_message, void * p_args);

static void handle_config_gatt_proxy_set(access_model_handle_t handle, const access_message_rx_t * p_message, void * p_args)

it is reasonable. and we know "Config_Server" will only be set by "Config_client" through opcode command.

In " Config_client.c"

uint32_t config_client_gatt_proxy_set(bool state)
{
return NRF_ERROR_NOT_SUPPORTED;
}

uint32_t config_client_node_identity_get(uint16_t netkey_index)
{
return NRF_ERROR_NOT_SUPPORTED;
}

uint32_t config_client_node_identity_set(uint16_t netkey_index, config_identity_state_t state)
{
return NRF_ERROR_NOT_SUPPORTED;
}

Is that means we can not set GATT_PROXY_STATE on app level ? or is there any other way to set this state?

I mean , if this sate can be set on app level , we can easily work with samrt phone via MESH_GATT.

Sorry for trouble you again.

Regards

Brent

RE: Establish Smart Phone Data Link from Mesh Proxy

brent_dong — Mon, 03 Sep 2018 09:18:40 GMT

Hi， Bjørn

Thanks a lot!

I will go New_Model plan, see if I can go through.

Let you know soon.

Regards

Brent

RE: Establish Smart Phone Data Link from Mesh Proxy

Bjørn Kvaale — Fri, 31 Aug 2018 08:03:10 GMT

Hi Brent,

We clearly have a misunderstanding here. I was not clear enough in explaining myself. If you want to use the smartphone to monitor a mesh network, you will need to create your own app that you can base off of the nrf mesh app for example.

To facilitate the communication between the smartphone & the mesh, you can create a new model that I mentioned in the last comment. Just create a new model based on the simple on off server model. Instead of then communicating to the simple on off server model, change the app to communicate with the new "generic message model" you create.

Kind Regards,

Bjørn

RE: Establish Smart Phone Data Link from Mesh Proxy

brent_dong — Wed, 29 Aug 2018 15:59:43 GMT

HI, Bjørn

I guess we have misunderstanding here, let me make it clear:

1. I do not have problem on adding models, models work good.

SDK co_existance is fine too, I used MESH SDK and SDK 5_15.00 together .

2. I do not want to use " nRF Mesh iOS/Android applications" example on smartphone to work as provisioner, I just want to use smartphone to monitor mesh network and set parameters with my own Phone_APP.

My understanding , " nRF Mesh iOS/Android applications" uses Mesh_GATT (PB_GATT) to provision the device. I want to use mesh_GATT to establish a packet exchange with mesh network after the nodes have been provisioned..

In the previous message, I show you how I did to cut_in from Proxy. but the data is not correct, anypoint, where I am wrong?

Best Regards

Brent

RE: Establish Smart Phone Data Link from Mesh Proxy

Bjørn Kvaale — Wed, 29 Aug 2018 12:11:48 GMT

Hi Brent,

Sorry for the delayed response. The reason nRF Connect disconnects from the provisioning service is that you are most likely not sending the correctly formatted data. I am not sure it is possible at the moment to send data via nRF Connect to the proxy node.

What you could do is create a new model based on the simple on off model. Then, if you take a look at the handle_set_cb() function in the simple_on_off_server.c code, you can see this line of code:

bool value = (((simple_on_off_msg_set_t*) p_message->p_data)->on_off) > 0;

p_message is an access_message_rx_t struct pointer. Inside this struct, you can see the const p_data pointer which points to the first byte of the message data. Instead of making that const, you can change this to be a byte stream instead. Make sure to change the length of the byte stream too (i.e. uint16_t length). It could also be useful to take a look at this documentation.

Kind Regards,

Bjørn

RE: Establish Smart Phone Data Link from Mesh Proxy

brent_dong — Wed, 29 Aug 2018 10:50:02 GMT

Hi,Bjørn

Any update?

Brent

RE: Establish Smart Phone Data Link from Mesh Proxy

brent_dong — Mon, 27 Aug 2018 17:57:35 GMT

Hi,Bjørn

Thanks again.

As for your mentioned link, definitelly many Nordic Ble central examples can talk with smartphone, but they are out of mesh.I could not add packet into mesh network, unless I add another model , such as smartphone_data model to handle this. and I can not use current GATT observer, i need a seperate one, and do not know what happens in next steps.

I saw some talks in this Blog, Proxy is aimed to enable mesh network to work with temperary connections such as smartphone, .mesh profile1.0 talks like this either. I think it is reasonable, otherwise , why Proxy is added here? Could you help to check with your team, definitely there is a way to work it out.

Actually I downloaded nRF mesh , but I think it is not a good ideal. Reliability level required of Mesh network is much higher than samrtphone. now a days , people change smart phone just like party meeting. but mesh network is Iot, it is engineering, need to be rubust against circumstances. Provisioner keeps all metadata of the network, It is riscky to provision from smartphone.

And one information I mentioned before is not full. Ater provision, the Proxy--Samrtphone connection becomes active. I defined an APP Timer to watch the connection, from Proxy side, data in/out stable, from smartphone side, data keep coming. but the data is not Tx data of Proxy.

It is very strange, I read all the Proxy code , it is not complicated, but designed to work between GATT and mesh network, permit only one connection for all mesh nodes, but have GATT packet relayable.

I just do not understand everything is just designed perfect here, why we can not make it work.

Please help to find what is best way out.

Best Regards

Brent

2818608>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 2818611>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 2818616>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 2887963>, network.c, 409, RX1_Start
<t: 3051716>, network.c, 409, RX1_Start
<t: 3146272>, server_model_application.c, 101, ----- Server_Trig Timer Started -----
<t: 3146275>, et_sensor.c, 174, belt_sensor_status=0
<t: 3146278>, et_sensor.c, 183, seat_sensor_status=0
<t: 3146280>, et_sensor.c, 240, Battery_Value=0
<t: 3146282>, et_sensor.c, 44, DeviceId = 6794
<t: 3146288>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 3146292>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 3146297>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 3473952>, server_model_application.c, 101, ----- Server_Trig Timer Started -----
<t: 3473955>, et_sensor.c, 174, belt_sensor_status=0
<t: 3473957>, et_sensor.c, 183, seat_sensor_status=0
<t: 3473960>, et_sensor.c, 240, Battery_Value=0
<t: 3473962>, et_sensor.c, 44, DeviceId = 6794
<t: 3473968>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 3473971>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 3473976>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 3706927>, network.c, 409, RX1_Start
<t: 3801632>, server_model_application.c, 101, ----- Server_Trig Timer Started -----
<t: 3801635>, et_sensor.c, 174, belt_sensor_status=0
<t: 3801637>, et_sensor.c, 183, seat_sensor_status=0
<t: 3801640>, et_sensor.c, 240, Battery_Value=0
<t: 3801642>, et_sensor.c, 44, DeviceId = 6794
<t: 3801648>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 3801651>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 3801656>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 3871537>, network.c, 409, RX1_Start
<t: 4034280>, network.c, 409, RX1_Start
<t: 4129312>, server_model_application.c, 101, ----- Server_Trig Timer Started -----
<t: 4129315>, et_sensor.c, 174, belt_sensor_status=0
<t: 4129317>, et_sensor.c, 183, seat_sensor_status=0
<t: 4129320>, et_sensor.c, 240, Battery_Value=0
<t: 4129322>, et_sensor.c, 44, DeviceId = 6794
<t: 4129325>, et_sensor.c, 99, batt_volts=57
<t: 4129330>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 4129333>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 4129338>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 4198997>, network.c, 409, RX1_Start
<t: 4362521>, network.c, 409, RX1_Start
<t: 4456992>, server_model_application.c, 101, ----- Server_Trig Timer Started -----
<t: 4456996>, et_sensor.c, 174, belt_sensor_status=0
<t: 4456998>, et_sensor.c, 183, seat_sensor_status=0
<t: 4457002>, et_sensor.c, 240, Battery_Value=0
<t: 4457004>, et_sensor.c, 44, DeviceId = 6794
<t: 4457010>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 4457013>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 4457018>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 4784672>, server_model_application.c, 101, ----- Server_Trig Timer Started -----
<t: 4784675>, et_sensor.c, 174, belt_sensor_status=0
<t: 4784678>, et_sensor.c, 183, seat_sensor_status=0
<t: 4784680>, et_sensor.c, 240, Battery_Value=0
<t: 4784682>, et_sensor.c, 44, DeviceId = 6794
<t: 4784688>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 4784691>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 4784696>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 5018187>, network.c, 409, RX1_Start
<t: 5112352>, server_model_application.c, 101, ----- Server_Trig Timer Started -----
<t: 5112355>, et_sensor.c, 174, belt_sensor_status=0
<t: 5112357>, et_sensor.c, 183, seat_sensor_status=0
<t: 5112360>, et_sensor.c, 240, Battery_Value=0
<t: 5112362>, et_sensor.c, 44, DeviceId = 6794
<t: 5112368>, smartphone_connection.c, 112, ----- Smartphone_Trig Timer Started -----
<t: 5112371>, smartphone_connection.c, 71, Rx_Buffer : 00000000000000000000000000000000000000000000000000000000000000FFFF
<t: 5112376>, smartphone_connection.c, 72, Tx Buffer : 999999999999999999999999999999999999999999999999999999999999999999
<t: 5345625>, network.c, 409, RX1_Start
<t: 5440032>, server_model_application.c, 101, ----- Server_Trig Timer Started ----

RE: Establish Smart Phone Data Link from Mesh Proxy

Bjørn Kvaale — Mon, 27 Aug 2018 11:00:36 GMT

Hi Brent,

From my understanding, the mesh provisioning service, along with the Mesh Provisioning Data In & Data Out characteristics are currently only useable via the nRF Mesh iOS/Android applications. As soon as you try writing a value to the Data In characteristic, the device disconnects (as you have noticed).

Have you tried merging the mesh example with the ble_app_uart functionality from sdk 15 or 15.1?

Kind Regards,

Bjørn