Hi,

OK, Let us know if you have further questions.

BR,

/sza2

Hi,

Just for clarification the data you send to the hub ("Coordinator") is different from the poll ("data request").

So, if I understand the case correctly it could be solved in a much simpler way.

Here is the idea:

• Don't install either Poll or Mailbox component.
• Simply create an even (just like in case of Sensor) which sends the data periodically (ex.: 10sec, without ACK - see emberMessageSend() and its last parameter).
• Create a counter which you increase in the event mentioned above
• Implement emberAfMessageSentCallback() - this will be called every time a message sent (it is worth to implement anyway to handle errors too)
• In emberAfMessageSentCallback() check the counter and if it reaches ex. 100, clear the counter and call emberPollForData()
• Implement emberAfIncomingMessageCallback() and process the info sent from the hub to the device

There is no any drawback setting the indirect queue timeout to any big value. What you have to consider is to set it corresponding the device number and the frequency of sending messages to the devices. The indirect queue has two parameters in this regard, the timeout and the queue depth. Since you will have a relatively few devices I would recommend to set the queue depth the same as many devices you have. Queue size depends only on the available RAM.

BR,

/sza2

Hi,

The first question: it is not clear whether BLE is a strict constraint?

If you need BLE then you need EFR32BGxx device as our BLE stack is not supported on EFR32FGxx devices. In this case you may want to open a case in the Bluetooth forum.

If BLE is not a requirement, but you can use proprietary protocol, you can use any of our devices including FG series.

We have developer kit for all kind of devices but the recommendation depends on which kind of protocol you want to use.

BR,

/sza2

Hi,

First, I would recommend to read UG435.07, in section 1.5 there is a bit more detailed explanation of sleepy end devices, poll, indirect queue, and mailbox system. These approaches makes sense for sleepy end devices, as non-sleepy devices can receive messages anytime (as opposed to sleepy devices which spend most of their time in low power mode where reception is not possible).

Polling uses "data request" which is implemented based on the 15.4 standard - the method is the following: the sleepy end device device send a data request to the parent device in which it ask if there is a message waiting in the parent's queue. The parent replies with an ACK. If the frame pending bit is not set in the ACK message, it means no message for the end device and the end device immediately turns off its radio (and can enter to sleep mode). If the frame pending bit is set in the ACK, then there is a message for the end device, so after it receives the ACK it still keep the radio on and wait for an additional message (which will contain the data).

The application will be notified the received data message through emberAfIncomingMessageCallback(). Note: on one data request only one message can be received, so polling must be repeated until no more messages are pending in the queue.

Both Poll and Mailbox components based on the above (indirect queue).

Actually, the Poll component is just implements a method where the the parent polled periodically and there are two intervals specified (short poll is basically to get the data, long polls main purpose of some kind of keep alive as usually parent the applications are configured to kick off the children not seen for a while - but that's not mandatory. The Poll component uses emberPollForData().

So, it is not necessary to enable the Poll component, you can call emberPollForData() from the application directly, either calling from a periodic or non-periodic event or from any point in the application.

Mailbox is also implemented on the top of indirect queue, but it is in the application layer. It is somewhat more flexible than Poll - for example, the mailbox server is not necessarily on the coordinator, any device can act as mailbox server (although, it should be an always-on device, otherwise messages can lost). Pending messages can be retrieved by calling emberAfPluginMailboxClientCheckInbox() and the app will be informed through emberAfPluginMailboxClientCheckInboxCallback().

Since you didn't even mention your use case it is hard to figure out which solution would be optimal for your application. Based on the above or if you share more information probably it is possible to find the right solution for your project.

BR,

/sza2

Hi,

Sorry that we have intellectual properties and thus not all the sources are available publicly.

Obviously, it is always easier to figure out the root cause of an issue if the customer provides relevant information or at least tries to answer the questions.

We are glad that finally the problem is solved and help others by sharing these information on our community forum.

BR,

/sza2

Hi,

I'll keep this topic here as it seems there are unresolved flash related issues.

Jay Zhu,

If you have further proprietary wireless question, please open a new topic in prop. wireless forum.

BR,

/sza2

Hi,

It is not possible to mix Connect stack and RAIL library based applications.

BR,

/sza2

MCU Team,

Could you please help to resolve the flash protection issue and give some hint on using MSC and SimEE/NVM3 together?

If there are open question after clarifying the above just move this topic back to the Proprietary forum.

Thanks,

BR,

/sza2

Hi, team

I'm working on EFR32FG13P231F512GM48. And there are something confused for me.

Now , I want to add the sensor/sink feature to my project, so I add the Connect(SoC) : Sensor code to my project based Connect (SoC): Empty Example. 

So my firmware is included the sensor feature , and I bulid a sink firmware to be the coordinator.

Before ,some config area parameters are stored in the sensor mainflash 0x7f8000-0x80000. 

After sink is up, I have input "join 0" in sensor part.  

And sensor/sink connected successfully .

So I input "leave" to disconnect.

But here is the issue :

Before sensor connected with sink , data stored in sensor mainflash  0x7f8000-0x80000 is still here, and will not lost whether power on/off.

After sensor connected with sink and disconnected , power off and on  , those data lost .

I have read the sensor/sink related documents and find this.

So I have a try :

Erase sensor mainflash then flash sensor firmware again .

When I get the flash map though commander. I find that 0x7f000-0x7f800 contains data but it is not my firmware data.

So I suppose that sensor will create some data for ID and "leave" will erase it.

But I need both  keep data in 0x7f000-0x7f800, 0x7f800-0x80000 and sensor/sink feature .

Could you please give me a suggestion about this issue ?

Hi,

No problem ;-)

Let us know if you need further assistance!

BR,

/sza2