54l15 mesh questions

[William.wei]

hi support team,

customer is using our 54L15  for mesh lighting project, here are three questions:

1.

customer needs timer model, i see the "time_cli.c" and "time_svr.c" in NCS sdk :"\v3.1.1\nrf\subsys\bluetooth\mesh", but there is no sample how to use it, do we have reference for this function?

2. 

customer needs to set up the lighting Strategy (for example: 8:00--8:30, 60% dimming;8:30--9:00,60% dimming and so on......).

how can we extend the package to more than 240 bytes?

I searched AI and showed me CONFIG_BT_MESH_RX_SEG_MAX=32, CONFIG_BT_MESH_TX_SEG_MAX=32,CONFIG_BT_MESH_SEG_BUFS=384. -----32*12=384.

which means This 384-byte packet will be fragmented into 32 segments, so customer only need to handle the data, and do not need to consider manually fragment this data, is it correct?

are there other configs need to be set?

3.I couldn't see documents about how to use IOS "mesh" app to OTA device, I tried but failed. I can only see "update" in right up corner of IOS app.

regards,

William.

[Hung Bui]

Hi Wiliam, 

1. You are right, there is no sample doing Time srv or Time cli. What I found is some test samples but I think they are a good start.
Time server: \nrf\tests\subsys\bluetooth\mesh\time_model

Time client:  \nrf\tests\bluetooth\tester\src\mmdl.c 

2. Correct the customer can have up to 384 bytes in total but 4 bytes is needed for MIC so 380 actual payload max. 

onfig BT_MESH_RX_SEG_MAX
	int "Maximum number of segments in incoming messages"
	default 6 if BT_MESH_BLOB_SRV || BT_MESH_BLOB_CLI || \
		     BT_MESH_RPR_SRV || BT_MESH_RPR_CLI
	default 3
	range 1 32
	depends on BT_MESH_RX_SEG_MSG_COUNT > 0
	help
	  Maximum number of segments supported for incoming messages.
	  This value should typically be fine-tuned based on what
	  models the local node supports, i.e. what's the largest
	  message payload that the node needs to be able to receive.
	  This value affects memory and call stack consumption, which
	  is why the default is lower than the maximum that the
	  specification would allow (32 segments).

	  The maximum incoming SDU size is 12 times this number (out of
	  which 4 or 8 bytes is used for the Transport Layer MIC). For
	  example, 5 segments means the maximum SDU size is 60 bytes,
	  which leaves 56 bytes for application layer data using a
	  4-byte MIC and 52 bytes using an 8-byte MIC.

As far as I know the segmenting is done on the Transport layer so the application doesn't do anything. It's transparent to the application. 
However, be very careful when transmitting a big packet. It consumes a lot of traffic to send segmented packets. So it has to be considered thoroughly. 

3. I assume you are asking about Mesh DFU for the whole network not Mesh DFU one to one. 
Have you follow the guide here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/protocols/bt/bt_mesh/dfu_over_bt_mesh.html 

I don't think you can do DFU from the Mesh app, you need to send the image via nRF Connect Device Manager to send the image from the phone to the distributor. The distributor will send the image(s) to the network. 

[Hung Bui]

Update: Regarding #3. I got an update that it's possible to do DFU from Mesh app on iOS. Could you give us some more info on the issue ? Any log, screenshot ? Documentation for it is still in progress. But you can try nRF Connect Device Manager as well if nRF Mesh app doesn't work. 

[William.wei]

Hi Hung Bui，

Yes,Regarding #3. Customer is dong DFU with nRF Connect Device Manager, and it works well,

but i was told Nordicers prefer to use Ios Mesh app, but i could not see any document about this. and couldn't see how to use that app

Regards,

William.

[Hung Bui]

Hi William, 
We are working on that. I don't know when the documentation will come. I would suggest to create a new ticket with more info&screenshot about the issue with nRF Mesh app so we can take a look.