• State Verified Answer
  • Replies 12 replies
  • Subscribers 76 subscribers
  • Views 2116 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 301147
Options

NCS Mesh: Relay function delays response messages

mesh777

We are facing the problem that when relay feature is enabled on a mesh device (which is running nRF Connect SDK firmware), device response is delayed in a range of seconds.

To reproduce the problem we used light example project from NCS v1.8.0 and generated additional traffic using other device, which transmits unsegmented packets each 200ms. In between that traffic TTL packets are transmitted to which response gets delayed.

If relay feature is off, everything seems to work as expected.

  • 0 in reply to urieder

    I've asked around to see if I can find someone who can answer the questions about fixing this in 1.8.0 and about the qualification procedure. I'll get back to you with an answer as soon as I get a conclusive answer, hopefully within the day/tomorrow.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hi again,

    So the conclusion so far from the discussion I've had with my colleagues are the following

    urieder said:
    Will Nordic provide a fix for NCS 1.8.0 resulting in a behavior similar to NCS 2.2.0?

    I am still waiting for a verification from the product manager for Mesh on this, but initial talks about this question does not look promising with regards to adding that to 1.8.0. Nonetheless I believe that it will be faster to shift to the newest release and generate a new BT qualification than it will be to investigate the changes that might cause the throughput issues you're seeing and patch it into a NCS v1.8.x.

    But as mentioned, I am still waiting for a verification on this.

    urieder said:
    How can such problems and fixes be handled, since customers which already qualified older NCS version are not allowed to use newer NCS without new qualification. Is there a solution or way of work how to handle such issues without needing re-qualification for new NCS? Or do i have an incorrect understanding of NCS usage ?

    In terms of the qualification process, unfortunately for this case, any customer moving from 1.8.0 to 2.2.0 would have to generate a new qualification listing. This is because the qualification process for Bluetooth is based on the selection of features in a checklist (namely the ICS). When you add a new feature or features to an existing design, this automatically triggers the need for a new qualification (removing a feature does not). So in this case since there were quite a few feature changed between 1.8.0 and 2.2.0, a new listing would be required.

    Generally speaking, If a 1.8.x which had the same features as 1.8.0 but just with some bug fixes would have been released, that would not require a new QDID. 

    I will be out of office from this afternoon until Monday coming week, but I will try to relay any verification I get regarding the first question to you if they come before then.

    Kind regards,
    Andreas

Related
Terms of service