• State TI Thinks Resolved
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 56 subscribers
  • Views 255 views
  • Users 0 members are here
Support feedback
Options
Options
Related

CC2340R5: how can I make the beacon request sent faster using CC2340R5?

?? ?
Prodigy 90 points
Part Number: CC2340R5
Other Parts Discussed in Thread: SYSCONFIG

Hi
I use 2652 as the coordinator and 2340 as the node. In the factory test, I want to make the 2340 network connection faster so that we can conduct rapid tests in the factory. Are there any methods to increase the sending frequency of beacon requests? Does the end as the coordinator of 2652 need to be changed?
regards

  • 0
    TI__Genius 13654 points

    Hello,

    We could try to call "bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING);" to start the commission process to send another beacon request.

    Thanks,
    Alex F

  • 0
    TI__Guru**** 219127 points

    Hi,

    When steering fails there is a 10 second delay between the next retry

          case ZB_BDB_SIGNAL_STEERING:
        Log_printf(LogModule_Zigbee_App, Log_WARNING, "Steering failed, retrying again in 10 seconds");
        ZB_SCHEDULE_APP_ALARM(restart_commissioning, 0, 10 * ZB_TIME_ONE_SECOND);
        break; /* ZB_BDB_SIGNAL_STEERING */

    You can also determine the ZB_ZDO_NWK_SCAN_ATTEMPTS and ZB_ZDO_NWK_TIME_BTWN_SCANS in zb_config_common.h

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 90 points

    Hi Ryan,What I mean is how to reduce the time between two beacon requests. Currently, the interval between each request is approximately several seconds.

  • 0 in reply to ?? ?
    TI__Guru**** 219127 points

    ZB_ZDO_NWK_SCAN_ATTEMPTS  

    Please remind me what F3 SDK version and example you are evaluating.  Are you observing this behavior with out-of-the-box examples?  How many channels are enabled for scanning in SysConfig?  Here is an example of changing the "restart_commissionin" frequency to every 3 seconds in on_off_switch.c (F3 SDK v9.14) with only channel 17 being scanned.  I have filtered out all other packets, including Beacon Responses.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 90 points

    Hi Ryan, perhaps I have identified the reason for the slowness of my engineering beacon request. Through debugging the program, I found that after my program entered zb_osif_sleep, it proceeded with SemaphoreP_pend(buttonSem, sleep_ticks); The brief period of time spent here would cause my beacon request packet to be sent very slowly. But when I use the routine, I almost never write: SemaphoreP_pend(buttonSem, sleep_ticks); The stay is short, so the beacon request interval is very short. I would like to know how zb_osif_sleep is used? Where does the parameter sleep_tmo come from? And why does it cause my program to be stuck for a long time? My SDK version is V_911.

  • 0 in reply to ?? ?
    TI__Guru**** 219127 points

    When you application calls zb_sleep_now from the ZB_COMMON_SIGNAL_CAN_SLEEP case, source code calculates the amount of time the stack can be allowed to sleep, confirms that this is above the sleep threshold, and sends the "sleep_tmo" parameter to zb_osif_sleep.  Whether the function enters SemaphoreP_pend (and waits for the semaphore to be posted by sleep_ticks) or uses ClockP_usleep, this will cause any radio activity to be delayed during that amount of time or cancelled/expired entirely.  Since this is not the default behavior (confirmed on an out-of-box v9.11 SDK example), you will need to closely inspect how your application is allowing entry of sleep mode.

    The SIMPLELINK-LOWPOWER-F3-SDK v9.14 has been released and enables test APIs which can send a carrier wave continuously using rf_test_start_tx_cw.  If this is of interest to you then please download the latest SDK and evaluate the rf_test example project in the zigbee folder.

    Regards,
    Ryan