• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 56 subscribers
  • Views 1261 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Enable many-to-one / source routing with ZNP

Philipp Buluschek
Prodigy 180 points

Other Parts Discussed in Thread: CC2530, Z-STACK

Hello

I run my coordinator on CC2530 with the ZNP firmware. Currently routing is done with standard AODV.

To support larger networks, I might have to switch to MTO / Source routing, with the routes stored in the host application and the coordinator being the concentrator.

- Do I need to compile the ZNP code with a special flag for this?

- Using ZNP, is the "host" or the "ZNP firmware" responsible for sending the RouteDiscoverRequests?

- If RouteDiscoveries are initiated by the host application (which would make sense, I guess), which ZNP/Z-Tool request sends this RouteDiscoveryRequest?

Thanks fro your answers

  Philipp

  • 0
    Guru 735695 points

    1. You can enable the following defines in znp.cfg and rebuild ZNP hex file to enable many-to-one.
    -DSRC_RTG_EXPIRY_TIME=255
    -DCONCENTRATOR_ENABLE=TRUE
    -DCONCENTRATOR_DISCOVERY_TIME=60
    -DMAX_RTG_SRC_ENTRIES=100
    2. You can try to send MT_NLME_ROUTE_DISCOVERY_REQ from host.

  • 0 in reply to YiKai Chen
    Prodigy 180 points
    Thanks for your answers.

    The doc for ZDO_MGMT_RTG_REQ says "This command is generated to request the Routing Table of the destination device.". Are you sure this also initiates a route discovery? Especially, I would expect the MTO discovery to be a broadcast...

    Outside of ZNP, but part of the MT API, I found the "MT_NLME_ROUTE_DISCOVERY_REQ" (which needs the compile flag "MT_NWK_FUNC"). This seems to do the right thing - can you confirm?

    Philipp
  • 0 in reply to Philipp Buluschek
    Guru 735695 points
    Yes, you are right. It is my typo. You should define MT_NWK_FUNC and use MT_NLME_ROUTE_DISCOVERY_REQ.
  • 0 in reply to Philipp Buluschek
    Expert 1405 points
    Philipp,

    Who sends the broadcast depends on CONCENTRATOR_DISCOVERY_TIME. It's the period (seconds) of the broadcast NLME_RouteDiscoveryReq sent by z-stack. Set to zero to disable it. Then you can use MT_NLME_ROUTE_DISCOVERY_REQ but, there is a bug in that function - the parameters for NLME_RouteDiscoveryReq are extracted starting from message buffer index 0, which should be 3. (The first three bytes are length, cmd0 and cmd1).


    Sjef.
  • 0 in reply to Sjef de Krijger
    Prodigy 180 points
    If I want my host app to trigger the route discovery, do I still need to define "CONCENTRATOR" etc? As I'm managing the source routing from the host, and also store the routes there, I guess the routes should not be additionally stored in the CC2530...

    Regarding the implementation of MT_NLME_ROUTE_DISCOVERY_REQ: my (2.6.1) version looks like this:
    cmdId = pBuf[MT_RPC_POS_CMD1];
    pBuf += MT_RPC_FRAME_HDR_SZ;
    if ( ZSTACK_ROUTER_BUILD )
    {
    retValue = NLME_RouteDiscoveryRequest(BUILD_UINT16(pBuf[0], pBuf[1]), pBuf[2], pBuf[3]);
    ...
    It looks OK to me, as pBuf is shifted forward by the header size, so after that the data are really in position [0..3]. Am I missing something?
  • 0 in reply to Philipp Buluschek
    Guru 735695 points
    If you want to do it from host, you don't have to define CONCENTRATOR.
  • 0 in reply to Philipp Buluschek
    Expert 1405 points

    Hi Philipp,

    Looks like I haven't been paying attention to the fact that you're using 2.6.1 and I'm glad to see TI fixed this bug. However, in Z-Stack Lighting 1.0.2 the bug is not fixed and should be patched.

     

    Regards,

    Sjef.