• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 309 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650: zstack-linux-gateway: throughput low when requesting attributes from enddevice

Melchior FRANZ
Prodigy 110 points
Part Number: CC2650
Other Parts Discussed in Thread: Z-STACK, SIMPLELINK-CC13X2-26X2-SDK, LAUNCHXL-CC26X2R1

We are using Z-STack_Home_1.2.2 on CC2650 modules on coordinator and enddevices. The coordinator (iMX28/ARM) runs software derived from the Z-Stack_linux_gateway demo. This works in principle, but not with the expected throughput. Requesting up to 5 attributes once every few seconds works just fine. When I let the coordinator request more than 5 or 6 attributes at once, this request seems to be ignored. When I request four attributes more often than twice per second, then confirmation packages are starting to get lost after a few seconds ("if (waiting_for_confirmation)" in framework/socket_interface.c) and the querying process stalls.

This looks like a configuration issue, but I haven't found the limiting factor yet. I've searched for #defines and config symbols on both the enddevice and the coordinator, so far without luck.

Does anyone have an idea, why the zstack-linux-gateway could be that slow? (I have no reason to assume that the coordinator hardware or operating system has any resource problems.)

  • 0
    TI__Guru**** 202096 points

    You could try increasing the ZNP's NWK_MAX_DATABUFS_* or INT_HEAP_LEN.  You could also increase MT_UART_DEFAULT_BAUDRATE or set MT_UART_DEFAULT_OVERFLOW to false but this would require changes to your host accordingly.  It would be further beneficial if you could provide gateway and OTA sniffer logs.  The best recommendation is to use a LAUNCHXL-CC26X2R1 with the SIMPLELINK-CC13X2-26X2-SDK and SENSOR-TO-CLOUD gateway solution.

    Regards,
    Ryan

  • 0
    Guru 735455 points

    I think this read attribute throughput also depends on end device polling rate. You might have to decrease end device polling period to make it can respond fast.

  • 0 in reply to Ryan Brown1
    Prodigy 110 points

    Thanks for the quick response and I'm sorry I couldn't keep up with that pace. Even though this was an important matter, a few even more important things came in between.

    It was indeed the INT_HEAP_LEN in hal_board.c. This had been left at its default 1024, so the heap manager in OSAL_Memory.c ran out of memory, when I requested more attributes. The OOM return value was passed all the way up the call chain, of course, but was then dropped at some point and not indicated in the error handler. That hal_board.c hadn't been added to the IAR project wasn't exactly helpful either. I have now set INT_HEAP_LEN to the highest value supported by OSAL_Memory.c: 0x7fff, and this allows to request at least 21 attributes. (Not that we need that many.)

    Thanks a lot!