Hi,

Cool! Let us know if you have more questions.

BR,

/sza2

Hi,

Probably the easiest way is to open the Simple TRX example, configure the required frequency in the radio configuratior, modify the code to call RAIL_SetTxPower() to set the required power and RAIL_StartTxStream() from the app_init() function instead of start reception (RAIL_StartRx()).

BR,

/sza2

Hi,

If you have Zigbee related questions it is better to open a case in the Zigbee forum.

BR,

/sza2

Hi,

Connect Star network supports only 1-hop.

In Connect networks there can be only one coordinator (sink in your case) and its address is fixed to 0x0000.

Calling RAIL functions from Connect applications are not supported.

Since you use 2.4GHz (Thunderboard Sense 2 supports 2.4GHz only) if you need multi-hop possibility you may want to check our Zigbee stack.

BR,

/sza2

Hi,

Yes, the extender acts as sensor as well. If you don't want the extender to send sensor data, you should modify the the code. One solution is to not starting the reporting on network up (see the report event) in this case you may need three different images (sensor, extender, sink). Or you can modify the code by adding a CLI command which controls report handling. Additionally, you can check the whether the device is an extender and in emberAfStackStatusCallback() you can filter on that to decide whether you call emberEventControlSetDelayMS() when the status is EMBER_NETWORK_UP.

Also, the idea is that I can put the end device out of the sink's range and the extender will help to reach his message to sink?

Yes, exactly.

BR,

/sza2

Hi,

Finally, I found the root cause. I've created the example and setup a sink, an extender and an end device - and I faced the same issue you run into.

The problem is that the children (the end device and the extender) send their messages to EMBER_NULL_NODE_ID (0xffff) which is incorrect.

You can fix the issue by changing sink_node_id in app_process.c of the sensor project:

static EmberNodeId sink_node_id = EMBER_COORDINATOR_ADDRESS;

Thanks letting us know about this issue, hopefully it will be fixed soon in the SDK. Meanwhile the patch above is applicable.

BR,

/sza2

Hi,

Unfortunately I cannot see the picture, most probably as the spam filter recognized it as spam.

What you wrote sounds weird. The sink should print messages both from sensor and extender.

So I thought I can make another sensor project for extender, in which I send the message->payload I just received.

Maybe I misunderstand, but forwarding the message by the application is not the right way. Range extender does this forwarding transparently.

Can you try it with unmodified / original example projects?

BR,

/sza2

Hi,

OK. The method should work if all the boards are connected (it should work with TB Sense 2 too). I assume, it should work even if you power cycle the coordinator.

But it is worse to prove that it work with the "normal" circumstances. If that works you can check if it works if you cycle the power.

BR,

/sza2

Hi,

OK. The method should work if all the boards are connected (it should work with TB Sense 2 too). I assume, it should work even if you power cycle the coordinator.

But it is worse to prove that it works with the "normal" circumstances. If that works you can check if it works if you cycle the power.

BR,

/sza2