Sending mesh packets (tutorial) via the UART API (Interactive pyACI) - detailed questions on how the data is transported across the mesh

[Sean Taylor]

I apologize if this was already answered elsewhere - I didn't find it.

I have been digging in the nRF52840 source code for the serial_nRF52840 SES project to understand what happens when use the command:

send(cmd.PacketSend(appkey_handle, d[0].local_unicast_address_start, publish_handle, ttl, segmented, mic_size, friendship_credentials_flag, "Hello World"))

As far as I can tell the function handle_cmd_packet_send() is invoked which calls nrf_mesh_packet_send() and the packet is submitted directly to the upper transport layer.

Other models appear to send data via access_model_publish() which calls packet_alloc_and_tx() which adds the 1-3 byte opcode and optionally company ID.

I'm wondering if this means that this demonstration does not add any model ID, company ID, opcode etc to the payload before submitting it to the transport layer - it appears to be using BLE mesh just as a transport.

I think this may be just what we need for our application, but in this scenario how does the receiving party (mesh stack) know what to do with data that arrives with no model ID, company ID or opcode, and does using mesh in this mode

a) Violate Bluetooth mesh specification (i.e. it's not an official part of mesh)

b) preclude using other models across the same mesh network ?

[Mttrinh]

Hi,

Yes, it is true that no opcode is sent. The opcode can be manually encoded into the packet being sent through cmd.PacketSend(). For example, see publish_set() in access.py: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/scripts/interactive_pyaci/mesh/access.py#L169

PacketSend  is an entry point to transport layer for the serial interface, which is used to send packets. Model ID, company ID, opcode etc are part of the access layer, not the transport. It won’t be BT Mesh compliant, if you don't use opcodes.

What do you mean by this “And if it preclude using other models across the same mesh network?”? Can you elaborate?

[Sean Taylor]

Thanks for the reply.  What I mean by "preclude using other models across the same mesh network" is that if there is no model ID & opcode then the first few bytes of user data might accidentally match the model ID and opcodes of other models causing erroneous behavior in the receiving node.

I wonder, however, if this is prevented by the serial interface messaging using a unique appkey - so the receiving node could assume that the data is non-model related messaging from the application key identifier.