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 was suspecting vendor specific opcodes as if I replace the opcodes with the generic on onff's everything works fine. What I mean is that applying the changes that are commented in the following :

typedef enum
{
    GENERIC_MESSAGE_OPCODE_SET = 0xC1, // -> 0x8202
    GENERIC_MESSAGE_OPCODE_SET_UNACKNOWLEDGED = 0xC2, // -> 0x8203
    GENERIC_MESSAGE_OPCODE_GET = 0xC3, // -> 0x8201
    GENERIC_MESSAGE_OPCODE_STATUS = 0xC4 // -> 0x8204
} generic_message_opcode_t;

and these types of call

ACCESS_OPCODE_VENDOR(GENERIC_MESSAGE_OPCODE_SET, DEVICE_COMPANY_ID)
// -> ACCESS_OPCODE_SIG(GENERIC_MESSAGE_OPCODE_SET)

If I do that, everything works fine, but then I can't send messages from my phone to the network, as the API does not allow to send byte arrays within a generic on off set message.

I am sending byte arrays of size between 1 and 9 bytes in order to only have unsegmented messages, and the mesh stack API calls I'm using are access_model_reliable_publish() for reliable messages and access_model_publish() for unreliable messages.

Also I should mention that sending unreliable messages makes it that the message never arrives if sent too fast after another message (less than 2 seconds after), and sending a reliable message is always successful as it will try again until the message is received, but it will arrive with the 2 seconds latency.

Regards,

Quentin

[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