Get serial type command response over mesh

[Tomi]

Hi!

1. We are using 1 Client over Serial and 30+ Server nodes over mesh network

When you want to know FW info regarding Client, you can call serial command like Opcode: 0x0a, which returns Firmware ID Data for the Client node.

Can you somehow run this commands over mesh, or how can I get Mesh node Firmware ID on request, or maybe TX Power Get?

2. Is there any Mesh packet documentation available on nordic site, other than just basic  Mesh packet (0xab) and then Data as payload, which encapsulates another packet with different Opcodes for Mesh which I can only see in class ConfigurationClient(Model) in Python interactive_pyaci script?

3. How much data is too much for mesh?
In our system I want to know as soon as possible if some node gets disconnected for monitoring status of the whole system.

For this, we currently have Server node Health ping set on 30 seconds.
We also have other devices which are not in mesh network but their PING is send over mesh to Client with their current RSS of Server nodes for location purposes. This is done each 10 seconds for each device.

Now in this case, if you have many devices pinging all the time your SERIAL port can be spamming all the time with different data about system status.

The problem happens when you try to run DFU over mesh, because our system has RS485 connection for Serial and we don't have Flow control and this devices are spamming all the time with data and DFU fails.
We changed Serial protocol to include HEADER/FOOTER of the packet, so we can remove corrupted messages and resend them but still not luck.

What is too much data for DFU to still work normally? Should DFU work anyway and we have problem elsewhere or was this tested only on your Development boards which have Flow control and this maybe cannot work properly?

Thank you for your response!

[Hung Bui]

Hi Tomi, 

1. You can use the composition data to get the firmware ID ( CID, PID and VID). This requires you to have a configuration client to read the composition data. Another option is to to use the Generic Property States model ( 3.1.8.1 in Mesh Model spec) where you can define the Generic Manufacturer Property for your firmware ID. 

2. I assume you want to know the documentation for mesh data packet. For that you would need to look into mesh spec: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=457092

3. I'm not sure how you can combine DFU and PyACI together. As far as I know we don't have the firmware support on the serial interface to receive DFU image. 

This is not what we have tested so I dont have a number. But can you pause the report of ping message to PC when you do DFU update ? 

I'm not sure using Health message as  a PING message is a good idea, it better to use Heartbeat message. 

[Tomi]

Thank you for 1 and 2 answer!

Regarding 3.

I am not combining PyACI and DFU together. I just meant looking at PyACI for mesh packet documentation.
We have DFU on Android side sending via Serial RS-485 (translated).

For PING we just set HEALTH model on SERVER to unicast address of Client on 10 seconds, so that we get Node(0xXXX) Alive messages.

Would it be better to not set Health model and use Heatbeat?

[Tomi]

1. How do you mean serial library enabled? We need this serial library to even communicate with Client. We are using  Nordic protocol for data transfer.

Regarding DFU
2. Is it ok to send same packet again? So if I don't get proper reponse from Client, can I send it again or will this break DFU?

3. I was testing DFU now with 5 provisioned devices. Sometimes I don't get response from Client for 30seconds but then it continues working properly, and I can see on Server that it gets DFU data, but then sometimes it just stops getting the data. Is it possible that the node disconnected from mesh for few seconds and DFU transfer stopped on that Server node? 

3.1 If DFU stops on Server but works on Client, will that node continue getting DFU after like reset, when Serial DFU transfer is finished or when it gets back into range? Because currently it doesn't look like it continues working and when it stops just stops and is not getting DFU anymore

4. Can you have no authorization DFU transfer over mesh only? Because I see that current BT device doesn't send only to mesh devices but to all devices in range. Can this somehow be enabled, to send only to mesh provisioned devices, or do you need authorized DFU?
Because problem with authorized DFU is that you need bootloader installed with private key (IF I am correct) so you need keys set up when flashing the devices, and we would rather have no auth DFU.

4.1 If you have No authorization DFU
and CLient has APP ID = 1
and Server has APP ID = 2

And if you want firmware update for Server, you make correct zip package and send it to CLient. Client will then send it to other devices, because the update is not for this device. 

And if you have like 3 provisioned Server devices, with 1 Client, and if CLient doesn't see all Servers
Like Client -- Server 1 -- Server 2, where Server 2 doesn't see CLient, will Server 1 receive DFU update and also send it to Server 2 / (will forward it also to other devices even if case is that the DFU update is for it)?

[Tomi]

For example running DFU, it works ok, but then on server I just get

<t:    8906235>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 5, count 3, interval: periodic, handle: FFFC
<t:    8906248>, nrf_mesh_dfu.c,  324, Write complete (0x2003FE98)
<t:    8906251>, nrf_mesh_dfu.c,  333, Flash idle.
<t:    8913854>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 6, count 3, interval: periodic, handle: FFFC
<t:    8913866>, nrf_mesh_dfu.c,  324, Write complete (0x2003FE98)
<t:    8913870>, nrf_mesh_dfu.c,  333, Flash idle.
<t:    8921823>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 7, count 3, interval: periodic, handle: FFFC
<t:    8921836>, nrf_mesh_dfu.c,  324, Write complete (0x2003FE98)
<t:    8921839>, nrf_mesh_dfu.c,  333, Flash idle.
<t:    8928983>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 1, count 3, interval: periodic, handle: FFFC
<t:    8928996>, nrf_mesh_dfu.c,  324, Write complete (0x2003FE98)
<t:    8928999>, nrf_mesh_dfu.c,  333, Flash idle.
<t:    8937163>, nrf_mesh_dfu.c,  528, 	RADIO TX! SLOT 2, count 3, interval: periodic, handle: FFFC
<t:    8937176>, nrf_mesh_dfu.c,  324, Write complete (0x2003FE98)
<t:    8937179>, nrf_mesh_dfu.c,  333, Flash idle.
<t:    8946026>, nrf_mesh_dfu.c,  383, 	Abort event. Reason: 0x3
<t:    8946029>, dfu.c,   62, NRF_MESH_EVT_DFU_END

and then after some time I get 

4238633>, app_error_weak.c,   96, Softdevice assert: 87596:0

I am running DFU on 250ms, with Server in close proximity of Client and if I get corrupted packet or Client doesn't respond for 5seconds I send same packet again until I get response

If a connect like second client which has different App ID and which only forwards packets then on this devices it looks like the packet is forwarded OK

Edit: I seems that also on Client I got mesh assert crash after a while

[Hung Bui]

Hi, 

It's my mistake that I confused between the DFU serial interface and the mesh serial interface, they actually use same library. 

I will try to do some test to get deeper here and get back to you.

In the mean time could you try to reproduce the issue using minimum modification from the dfu example we have  ? You can try to send some data between nodes until it crash the DFU process. 

Regarding your question:

2. I don't think we have packet retransmission on the serial interface, there is retransmission when sending the image packet via mesh but not when receiving it on serial. 

3. My understanding is that the mesh network will retransmit until all mesh node are aligned with same packet number of the image and then continue to the next packet. If your node reset and get back to the network after a few image it should be able to request the missing part and get up to date with the DFU process.

4. The image sending over mesh is not encrypted and any node support OpenMesh is able to receive the image. There is authentication check and it's optional. There is a public-private key that the bootloader can check the signature of the image to see if it's from authenticated source or not. I'm not sure if it's the authorization you are asking about. 

You can choose to update specific nodes based on app ID as you mentioned. The image will be forwarded in all nodes but only stored on the node that has the matching app ID. 

We have an updated documentation about mesh here. 

[Tomi]

Hi,
first thank you for your responses!

Regarding DFU I kinda managed it to work without Abort

We disabled every other serial send so only DFU gets ACK on Serial and it looks like it works!

The problem happened if the packet got corrupted and if you resend same packet everything gets aborted, so only DFU can run on Serial (Or maybe if we also add some CRC at the end or some other measurement, then maybe it could work?)

So currently it works, but I need to do some more testing if something else fails, because now mesh asserts were solved

[Hung Bui]

Good to know that it works now. Could you tell me a little bit more on the corrupted packet. By default we have 5 retries before the process being aborted. You meant the packet is corrupted on all 5 trials ?