Hi,

There can be several causes that the radio does not receive.

Did you set all the related RX events to check what happens?

Do you use one of our examples? If yes, which one?

Do you use auto state transition or do you manually initiate RX (RAIL_StartRX()?

BR,

/sza2

Hi,

There can be several causes that the radio does not receive.

Did you set all the related RX events to check what happens?

Do you use one of our examples? If yes, which one?

Do you use auto state transition or do you manually initiate RX (RAIL_StartRX()?

(Current link of your ticket in the proprietary forum: https://www.silabs.com/community/wireless/proprietary/forum.topic.html/efr32fg1v131_radiolockup-sjlT)

BR,

/sza2

Hi,

Yes, I meant exactly as Gene wrote.

Some background and additional info:

The coordinators store information about the joined devices in a non-volatile memory are (NVM3) in their flash called "child table" (this table has 64 elements by default). When you de-configure the network on the coordinator the stack clears the child table. From that point it will drop messages arrives from the previously already joined devices.

There is one more difficulty, that acknowledge will be sent to the devices even if those are not in the child table as ACK is a low level stack feature and automatically sent for the incoming messages.

This means, if the coordinator purges its child table (de-configure) and then re-configure the network (form a network) the end devices will "think" that the message is successfully sent (as they will receive the ACK) - but the coordinator will not process the message (and will not forward to another node either).

This is usually not a problem as the whole network is static, but if you need to avoid this kind of situation you have to implement an "application level ACK" (or we can call "end-to-end ACK) method to make sure the messages received and processed by the other party.

BR,

/sza2

Hi,

Yes, I meant exactly as Gene wrote.

Some background and additional info:

The coordinators store information about the joined devices in a non-volatile memory are (NVM3) in their flash called "child table" (this table has 64 elements by default). When you de-configure the network on the coordinator the stack clears the child table. From that point it will drop messages arrives from the previously already joined devices.

There is one more difficulty, that acknowledge will be sent to the devices even if those are not in the child table as ACK is a low level stack feature and automatically sent in case of the incoming messages.

This means, if the coordinator purges its child table (de-configure) and then re-configure the network (form a network) the end devices will "think" that the message is successfully sent (as they will receive the ACK) - but the coordinator will not process the message (and will not forward to another node either).

This is usually not a problem as the whole network is static, but if you need to avoid this kind of situation you have to implement an "application level ACK" (or we can call "end-to-end ACK) method to make sure the messages received and processed by the other party.

BR,

/sza2

Hi,

Yes, I meant exactly as Gene wrote.

Some background and additional info:

The coordinators store information about the joined devices in a non-volatile memory are (NVM3) in their flash called "child table" (this table has 64 elements by default). When you de-configure the network on the coordinator the stack clears the child table. From that point it will drop messages arrives from the previously already joined devices.

There is one more difficulty, that acknowledge will be sent to the devices even it those are not in the child table as ACK is a low level stack feature and automatically sent for the incoming messages.

This means, if the coordinator purges its child table (de-configure) and then re-configure the network (form a network) the end devices will "think" that the message is successfully sent (as they will receive the ACK) - but the coordinator will not process the message (and will not forward to another node either).

This is usually not a problem as the whole network is static, but if you need to avoid this kind of situation you have to implement an "application level ACK" (or we can call "end-to-end ACK) method to make sure the messages received and processed by the other party.

BR,

/sza2

Hi,

Actually, one idea:

From the application you can configure and de-configure the network (both for coordinator and the end device, BTW). So, you can start a network always with a specific PAN ID (like 0xAAAA) and the gather surrounding PANs by emberStartActiveScan() and choose a unique PAN ID which is not in the list, de-configure, then reconfigure the network. Of course, this assumes that you don't start more than one coordinator at a time.

If you have multiple coordinators all have permit join enabled the end device will try to join the first one it received the beacon from - and by enabling / disabling permit join you can control to which coordinator a device can join that initiate the join process.

BR,

/sza2

Hi,

Please note that networks based on Connect are "static" networks, routing is also static (as opposed to "mesh" networks). So, you usually have to define these parameters at / prior deployment.

Since in Connect the coordinator has a special role, you must have only one coordinator in a Connect network (i.e. same network and radio parameters (including PAN ID)). I assume you made a Connect (Extended) Star network (like our Sink / Sensor example) - in that case the coordinator assigns short addresses to the end devices and this short address is used for any further communication after the join process (the coordinator's address is always 0 in Connect Star networks). This means, if you have more than one coordinators and the networks "see" each other there will be address collision (and for example an end device send a message to the coordinator or to an end device with the same short address and both / multiple devices will receive the message and will acknowledge which result in malfunction of the network). Just like if you have multiple devices with the same IP on an TCIP/IP network.

So, you must use different PAN IDs to separate the networks (if no other parameters differ).

You can assign the PAN ID statically at production time (but this obviously limits the number of the possible networks to 64k max) or for example at runtime using UART CLI (this assumes you have a host controller(s) connected to the Coordinators that accounts the PAN IDs) - or as you mentioned assign PAN IDs randomly, but the drawback is that PAN ID is only 16 bit, so it can happen that multiple coordinators set the same PAN ID.

Regarding the joining of end devices using emberStartActiveScan() is a proper way to gather the possible coordinators and select one based on the different PAN ID but in that case you still have to use some algorithm to spread the end devices between the coordinators based on the gathered PAN ID list.

No sure what is the purpose of multiple coordinators BTW - probably you need more than 64 end devices, I assume. If that's the case, you can still use the Extended Star network topology where you can connect ~2k devices to a coordinator (through "extender" devices) - although, note that the network is still "static" in this case, so you have to solve that devices connect to the corresponding extenders.

Hope this help, let us know if we can help further.

BR,

/sza2

Hi,

Theoretically, you can use any PHY parameters for Connect as far as the frame format matches with Connect frame format.

BR,

/sza2

Hi,

Not sure I fully understand your question - let me know if I misunderstood.

In Studio, you can open the Radio Configurator and for example select a PHY which is close to the required PHY. In this case above I would probably select 434MHz 2GFSK 200kbps. In the Radio Configurator there is a switch "Customized". If that's turned "on", you can change the PHY parameters, like center frequency to 490MHz, and the required data rate (ex.: 250kbps) and the deviation (rule of thumb: the date rate should be about the double of the deviation in this case). The save the configuration and recompile the project.

BR,

/sza2

Hi,

Again, please don't move sl_power_manager_sleep() from main.c to app_process.c. That's not how it should work.

Configure sl_sleeptimer_start_periodic_timer_ms() to wake the app periodically any place your code to the callback.

BR,

/sza2