How  

to  setup  and  use  a  Connect  Sink  /  Sensor  example  project  (and  guide  
to  make  the  sensor  side  energy  friendly)  
 

These  examples  show  how  to  setup  a  coordinator  (the  sink)  and  (sleepy)  end  nodes  (the  sensors),  using  
the  built-­‐in  example  project,  configuring  /  compiling  /  running  them.  

In  case  of  Sink  /  Sensor  example  the  supported  network  structures  are  star  and  extended  star  topologies:  

 
The  configuration  of  Sink  /  Sensor  example  consists  of  two  independent  projects:  

 
 

The  coordinator  /  sink  

First,  we  need  a  coordinator,  to  which  the  nodes  can  connect.  In  Simplicity  Studio  ‘Launcher’  page,  select  
the  desired  device.  

Start   to   create   a   new   sink   project   by   starting   the   wizard   by   clicking   on   button.   Select   the  
desired   Flex   SDK,   choose   the   ‘Connect   (SoC):   Sink’   example   and   complete   the   remaining   steps   of   the  
wizard.  

The  AppBuilder  will  open  automatically  where  you  can  configure  the  high  level  settings  of  the  project.  
Radio  parameters  can  be  configured  by  switching  to  the  ‘Radio  Configuration’  tab:  
  
 

After   completing   required   changes   (if   any),   the   Studio   will   generate   additional   files   necessary   for   the  
project   by   clicking   on   the     button.   A   pop-­‐up   window   will   appear   about   overwriting  
_
flex callbacks.c  file  which  is  not  selected  by  default.  Keep  it  unselected.  

Compile  ( )  and  debug  ( )  the  project.    

To  configure  the   coordinator  a  terminal  software  is  necessary  to  set  up  the  parameters.  The  firmware  
prints  some  basic  help  by  issuing  the  help  command.  When  the  firmware  started,  issue  form  0  (form  a  
network  on  channel  0)  and  pjoin  255  (enable  join  of  nodes  for  unlimited  time)  commands:  

 
  

At  this  point  the  coordinator  is  up  and  running,  accepts  incoming  joining  requests,  so  sensor  nodes  can  
connect  to  the  sink.  

The  nodes  /  sensors  

The  next  task  is  building  sensor  nodes.  Go  back  to  ‘Launcher’  view  and  select  one  another  device  then  
create  a  new  project  by  going  through  the  wizard  except  that  select  ‘Connect  (SoC):  Sensor’  from  the  list.  
All  the  settings  can  be  kept  as  default,  but  radio  configuration  must  match  with  the  sink  settings.  

Compile  and  debug  /  run  the  project.  Beside  multiple  other  commands  the  two  most  important  ones  are  
join  and  join-­‐sleepy.  Issuing  join,  the  device  will  try  to  connect  to  the  coordinator,  and  if  the  join  
process  was  successful,  the  node  become  part  of  the  network.  In  case  of  issuing  the  join  command,  the  
device  will  not  try  to  enter  to  sleep  or  idle  mode  at  all,  keeping  the  device  wake  with  relatively  high  current  
consumption.  To  enable  to  enter  sleep  state  the  join-­‐sleepy  command  should  be  issued.  However,  
since  by  default  the  Idle/Sleep  plugin  is  not  enabled  in  AppBuilder,  even  connecting  by  join-­‐sleepy  will  
not  cause  the  device  to  sleep  whenever  it  is  possible,  but  using  this  command  does  not  cause  any  issue  
and   later   we   can   exploit   the   advantage   when   we   enable   the   Idle/Sleep   plugin.  After  a  successful   join  
process,  the  device  starts  sending  the  sensor  data  to  the  sink  periodically  (with  1s  rate  by  default):  

 
 

At  this  point  a  network  consist  of  a  coordinator  /  sink  and  one  node  /  sensor  should  work,  the  sensor  data  
should  be  sent  by  the  sensor  and  received  by  the  sink  with  1s  periodicity.  More  nodes  can  be  added  to  
the  network  by  downloading  the  sensor  firmware  into  multiple  devices.  

When  starting  the  experiment  with  sensor  sink  examples  it  is  a  good  practice  to  issue  the  leave  command  
on   both   sink   and   sensors.   For   example,   the   coordinator   maintains   information   about   the   previously  
connected  nodes  (based  on  their  EUI64  ID),  the  nodes  also  store  information  and  tries  to  reconnect  to  the  
coordinator  automatically  at  power-­‐up  based  on  this  information.  By  issuing  the  leave  command  these  
pieces  of  information  will  be  cleared.  

There  are  cases  when  the  node  cannot  join  to  the  coordinator.  In  these  cases,  the  firmware  prints  only  
numerical  codes  on  the  console,  instead  a  textual  description  on  the  problem.  The  table  below  contains  
the  codes  and  their  meaning:  

•   0x40:  no  ACK  received,  the  node  that  a  message  was  transmitted  to,  did  not  respond  
•   0x41:  indirect  MAC  timeout,  may  occur  if  the  sender  did  not  get  a  poll  request  to  send  its  
pending  message  
•   0x70:  Invalid  call,  usually  when  an  unexpected  operation  is  carried  out  (e.g.  joining  when  
joined  or  sending  when  not  joined  etc.)  
•   0x90:  Network  up,  the  expected  status  after  forming/joining  networks  
•   0xAB:  No  valid  beacons,  the  other  radio  can’t  be  heard  (e.g.  no  antenna  attached)  

Low  power  mode  for  sensor  nodes  

 

Using   the   default   configuration   and   unmodified   code   the   current   consumption   of   a   sensor   node   is  
relatively  high,  ~10mA  even  if  the  firmware  does  not  do  any  useful  task.  

There  are  multiple  steps  necessary  to  lower  the  consumption  of  a  sensor  node:  

-­‐   Enable  Idle/Sleep  plugin  

-­‐   Increase  report  period  
-­‐   Disable  network  status  indication  
-­‐   Disable  heartbeat  
-­‐   Set  SPI  flash  deep  power  down  mode  

Energy  profiler  is  a  useful  tool  to  inspect  current  consumption  real-­‐time.  The  following  graph  shows  the  
consumption  of  a  non-­‐optimized  sensor  node.  
  
 

The  first  step  which  reduces  the  consumption  the  most  is  enabling  ’Idle/Sleep’  plugin.  The  plugin  enables  
entering  EM2  mode  when  it  is  possible.  The  ‘Idle/Sleep’  plugin  can  be  enabled  in  AppBuilder  under  the  
‘Plugins’  tab  by  enabling  ‘Idle/Sleep’  plugin:  

 
 

Note,  that  if  ‘Idle/Sleep’  plugin  is  enabled,  issuing  commands  through  CLI  (UART)  is  not  possible.  Thus,  it  
is  practical  to  apply  all  necessary  settings  before  enabling  of  ‘Idle/Sleep’  plugin.  

 
Changing  the  report  period  can  significantly  reduce  the  average  consumption  if  the  sleep  consumption  is  
low   enough.   To   change   the   report   period,   open   flex-­‐callbacks.c   and   modify  
sensorReportPeriodMs  value:  

 
By  default,  the  network  status  indicator  LED  is  on  when  the  network  stack  is  up,  ie.,  after  the  join  process  
it  is  continuously  on.  Changing  this  behavior  can  reduce  the  consumption  by  a  few  hundred  uA.  The  code  
responsible  for  setting  the  LED  status  is  also  in  flex-­‐callbacks.c  in  the   emberAfMainTickCallback  
function:  

 
The  solution  can  be  to  comment  out  the  halSetLed()  portion  or  invert  the  if  statement.  

In   the   example   project   the   ‘Heartbeat’   plugin   is   enabled.   To   decrease   the   consumption   further,   this  
feature   can   be   disabled   in   AppBuilder   under   the   ‘Plugins’   tab   by   disabling   ‘Heartbeat’   plugin:

 
Applying  the  modifications  above  the  sleep  current  can  be  reduced  to  ~10-­‐12uA.  However,  all  the  radio  
boards  designed  by  Silicon  Labs  contain  a  SPI  flash  chip  which  consumes  ~8-­‐10uA  if  left  uninitialized.  The  
required  ‘SPI  Flash’  plugin  must  be  enabled:  
  
 

Additionally,   halEepromInit()  and   halEepromShutdown()  functions  which  initializes  the  flash  and  set  
deep   power   down   mode   of   the   device   have   to   be   called,   thus   it   must   be   added   manually   to  
flex-­‐callbacks.c  (preferably  to  emberAfMainInitCallback):  

 
 

Finally,   if   these   modifications   applied   the   sleep   mode   current   consumption   should   be   reduced  
significantly:  
  
 

It  should  be  noted  that  the  built-­‐in  current  measurement  of  the  WSTK  board  is  not  really  accurate  in  uA  
range  and  below.  The  current  consumption  of  the  above  sensor  node  setup  should  be  in  2-­‐5uA  range.