Receive string message from node in ble mesh.

[Pooja]

I have extend the light switch example to send message to the other node. I have refer This example to send message. But how to configure another node to receive the message and relay the same message to server using WiFi. Will you please provide some sample example code to receive the message and relay that message. It also gives the error "Undefined reference to address_set." in following code

uint32_t status=0;
uint8_t buffer[30];
uint8_t length;
uint16_t address;
access_message_tx_t msg;
length= SEGGER_RTT_Read(0,buffer, sizeof(buffer));
           if (length)
            {
              msg.opcode.opcode =simple_message_OPCODE_SEND;
              msg.opcode.company_id = 0x0059; // Nordic's company ID
      
              msg.p_buffer = (const uint8_t *) &buffer[0];
              msg.length =length;
              address = 0xCAFE;
              address_set(address);
              SEGGER_RTT_printf(0,"Sending to group address 0x%04x\n", address);
              status= access_model_publish(m_clients[0].model_handle, &msg);

              if (status == NRF_ERROR_INVALID_STATE ||
              status == NRF_ERROR_BUSY||status == NRF_ERROR_NO_MEM)
               {
                 __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Cannot send. Device is busy.\n");
                  hal_led_blink_ms(LEDS_MASK, 50, 4);
               }
               else
               {
                     ERROR_CHECK(status);
               }
            }

[leonwj]

Hello Pooja,

In my response to your previous question, it clearly stated that you would need to implement your own solution in order to send data across wifi and/or the cloud. Bluetooth Mesh doesn't define any requirement or have any notion of a gateway, so you will either have to implement one or use something like nrfCloud using a devkit/PC combination coupled with Mesh SDK firmware to send data into the Nordic cloud service (or your cloud service/database of choice).

Additionally, Bluetooth Mesh works on a publish/subscribe message paradigm, so once a node (which has been successfully provisioned into the mesh network) subscribes to a message, upon publication of that message (by a client), the underlying mesh network should deliver it to that subscribing node. Please re-read the links provided in my previous post so that you clearly familiarize yourself with underlying mesh concepts. Only then can you hope to build any mesh solutions which adequately comply with the standard.

Regarding the "Undefined reference to address_set" error that you refer to, in the post that you linked, it clearly states the following...

Again, as above, re-reading a post a couple of times will go a long way to helping you to resolve many of the issues that you come across.

Regards,

[Pooja]

Now i am able to read the message at server side. But how we send the string using advertising packet and how we define the ttl value so that it reach to the destination.?

[Bjørn Kvaale]

The message goes through the packet. access_model_publish() calls packet_tx(). From the handle, the function is able to find the ttl from the m_model_pool array. The ttl value is set up to a default value equal to the server count (see ACCESS_DEFAULT_TTL in nrf_mesh_config_app.h). This makes sense because in the worst case, it will take you SERVER_COUNT number of hops to get from the first node to the last node (e.g. if the mesh network is a line of nodes). You can change the ttl value by using the access_model_publish_ttl_set() function.

Regarding the max packet size, see packet.h header file:

#define BLE_ADV_PACKET_BUFFER_MAX_LENGTH \
(BLE_ADV_PACKET_HEADER_BUFFER_LENGTH + BLE_ADV_PACKET_OVERHEAD + \
BLE_ADV_PACKET_PAYLOAD_MAX_LENGTH) /**< Longest possible BLE advertisement packet */.

access_model_reliable_publish() calls access_model_publish(), but has a few more checks compared to access_model_publish(). Which one is better depends on the usecase(i.e. whether you need all of the checks that access_model_reliable_publish has). See this link for more info.

[Pooja]

Thanks for your response.

[Bjørn Kvaale]

The relay functionality should already be enabled if you take a look at the light_switch example in the mesh sdk v1.0.1 for example. In network_init() in network.c, the m_relay_enable boolean is set to true during initialization of the network layer. 

The should_relay() function inside network.c decides whether a packet should be relayed or not. The packet_relay() function relays the actually packet. The ttl is decremented inside the packet_relay function.

This link (search for Network Layer)  also verifies that the network layer is responsible for the relay feature, just as the Nordic Mesh SDK has implemented it.

[Pooja]

Thanks for you response.

But how we know that message is relayed, because at server side in light switch example message is received in function set_cb(). So relaying of packet is automatically handled by sdk or we have use access_model_publish to manually relay it? and at remote node how we know the message is received from relay node or how we detect message is received or not?

[Pooja]

should_relay() method returns true only when dst address is group address and not unicast address, so that packet_relay() method is not called when dst address is unicast address.