Mesh Vendor OpCodes provokes low message rate within the network

[Quentin-LL]

Hi,

I have implemented my own Vendor model, using the light switch client/server as a starting point. The model allows to send byte arrays. Since I have used the generic on off model as a starting point, I was previously using the model id and the opcodes of the generic on off.

As I now need to send messages to the network from my phone, I needed to change these opcodes to be able to send VendorMessages. So I used my company's id and some custom model id and changed the opcode values to the same as in the tutorial showing how to implement a vendor model.

The problem I am facing when doing this is that once the node is provisioned, when a node receives a message, it wont receive another message until one or two seconds have passed since the reception of the previous message. Through some testing, I have noticed that this only happens when i'm using custom vendor opcodes, however using generic on off opcodes with my company's id and custom vendor id works fine.

I found this post in which the user is using his own company id and model id while still using the generic on off opcodes, so I tried only using my company's id and model id while keeping the generic on off model opcodes as well, however when trying to send a message from the nrf mesh app, when I set the opcode to 0x8203 and the parameters to any value, the mobile application crashes.

Any idea what could be the cause of the problem ?

I am developing on a nRF52 DK (nRF52832), with SDK 16.0.0, SDK for mesh 4.0.0 and softdevice s132 v7.0.1 and nRF mesh application on Android.

Regards,

Quentin

[tesc]

Hi,

Since you mention the sending of byte arrays, I suspect this to have less to do with vendor specific models, and more to do with the length of the messages. For segmented messages there is a limitation that only one segmented message can be sent at a time. The next segmented message must wait for the previous message to have finished transferring. Especially you should expect latency if on top of that you use reliable messages. How long are the byte arrays sent in each message, and what is the mesh stack API call used for sending the message?

Regards,
Terje

[Quentin-LL]

Hi, I have an update.

Your guess on the segmented packets was right, with the generic on off opcodes I was allowed to send unsegmented messages with 9 data bytes at most, while with custom opcodes, I am only able to send data of 8 bytes maximum. Changing the maximum data size from 9 to 8 fixed the problem.

Thanks a lot for your help !

Best regards

[tesc]

Hi,

Thanks for the update. Yes, that makes sense, as the vendor specific opcodes are longer. Sorry for not mentioning this difference in my previous reply. In any case I am happy to hear that you figured out what was the issue!

Regards,
Terje