The 01-join_control sample application relies on the local module to handle joining. It does this by passing the fJoin flag = JOIN_YES, and supplying a semaphore to notify the application when the mote has joined.  Behind the scenes, the mote is using the joinDutyCycle parameter stored in its persistent parameter settings (default = 64 or 25%), and will listen continuously at this duty cycle until it joins a network.  The 

01-join_control sample 

An OCSDK application can control join behavior on its own by passing JOIN_NO and a NULL pointer for the join semaphore to the local module.  The 01-join_control illustrates using the application to control join behavior:

• It changes a 

The 01-join_control Sample Application

The application cycles through listing at 100%, 5%, and sitting in idle (burning a few µA).   

Join app, ver 1.2.0.1
SmartMeshIP stack, ver 1.4.1.6
Setting Join duty cycle to 100%
Setting Join Duty Cycle to 5%
Stop listening and return to idle state
Starting to try joining again...
Setting Join duty cycle to 100%
...

You can also turn on the mac trace to see the radio listening 

> mtrace mac on

Implementation Details

The 01-join_control sample application uses the Helper Modules to initialize the CLI Module and interaction with the local interface. In particular, it configures the loc_task helper module to join the network  - it tells the local module to not open a socket by passing NULL in the port field.

It uses a single task (joinTask) which:

• waits for the loc_task helper module to have joined the network (by pending on the joinedSem semaphore);
• waits for the loc_task helper module to be granted the requested service service (by pending on the serviceSem semaphore);
• every 10s, request the current service to the manager (by calling dnm_loc_getAssignedServiceCmd()), and print that over CLI.
• It issues dnm_loc_joinCmd() to start the mote listening for a network