Hi,

I'm afraid we don't provide remote debugging support. Additionally, there are internal resources we have access to, but that would not be available in case of a remote session.

Not sure about "re-initialize" RAIL - actually, once you've initiated RAIL you don't need to do it again. What would be the purpose / why it is necessary?

I still think a reproducer would be useful to figure out what happens.

BR,

/sza2

HI,

Sounds good. Let us know if you have further questions.

BR,

/sza2

Hi,

You did not detailed how do you mean "at some points in time" and what do you mean on errors.

I don't think you need your function(s) similar to emberAfPluginIdleSleepTickCallback(). Connect uses an event driven approach - everything happens in the application basically should be happen on events (that fires a callback - codes in the callbacks should be as fast as can and should not block).

So, my idea was that if something happens (button push, receiving message, etc), you can do what you want and then execute the lines I pasted above) - you can also create your own event (that will be executed sometimes later in time) and go to sleep from that even, meaning that the radio is still receiving until your event is not executed.

BR,

/sza2

Hi,

I've found that we have nan API, emberSetRadioPowerMode() but I've tested, and unfortunately that can be only used if the device is configured as Direct Mode device, thus it does not work for Star Mode devices (the call returns with EMBER_INVALID_CALL (0x70)).

However, actually I think that turning off the radio is just not you really want.

If I understand correctly, what you want is a non-sleepy device that you can put to sleep when you want and otherwise it operates like a non-sleepy device. Do you think that my assumption is correct?

If yes, there seems to be solution. You can force a non sleepy device to sleep for a specified period. Here is the code you can use:

void sleep(uint32_t durationMs)
{
  emberStackPowerDown();
  halPowerDown(); // by default it is empty
  halSleepForMilliseconds(&durationMs);
  halPowerUp(); // by default it is empty
  emberStackPowerUp();
}

The above will enter to EM2 for the specified amount of time. It turns the radio off and then on wake up turns on the radio. As I tried, it does work correctly with Star Mode devices.

Do you think it is suitable for your purpose?

BR,

/sza2

Hi,

First of all, which SDK version do you use?

The example in Flex 2.x has an additional node table in RAM that is cleared on restart - so, although the nodes are still associated the coordinator ignores the messages from the nodes. This behavior has been changed in Flex 3.x, in that case the coordinator accepts incoming messages from the previously associated children regardless of coordinator reset.

However, emberResetNetworkState() clears the table of the previously associated children and also de-configures the network. So, if you call that API function, you must configure the network ("form") and re-join all the previously associated children to be able to communicate (not only end-device <-> coordinator, but even end-device <-> end-device obviously as in case of Star mode network the coordinator does the routing).

The network parameters are stored in the NVM so, those are available after reboot but not automatically applied. You should call emberNetworkInit() to apply the previously stored values and configure the network.

BR,

/sza2

Hi,

So what I think the radio is busy swithing to BLE and right this time a proprietary message arrives, so it is lost. There isn't a mechanism to handle with this in DMP? Because if not, DMP by itself will always lose packets.

Since in the device there is only one radio HW, so, it is simply not possible to detect any incoming packet while the radio is not switched and setup on the proprietary frequency. Thus, it is obvious, that you will lose proprietary packets if the radio is operating on BLE and during the time it switches vice-versa.

I can implement an algorithm to resend the message is an acknowledgement is not receive back, so this PER of 4.5% can be reduced to zero. But is that the right way to go?

Yes, definitely.

Most time I need only proprietary communication, BLE is connected few times. So is there a way to BLE tasks do not use the radio?

I would ask this in the BLE forum, since that team has deeper knowledge on that. BLE is strict on timing, and there are multiple phases I'm not sure when / how it is possible to disable / turn off BLE.

BR,

/sza2

Hi,

OK, I'll try to figure out something. I'd like to ask your patience.

BR,

/sza2

Hi,

The radio turn on/off capability does not really depend on the Studio / SDK version - however, the power management pretty different.

So, depending whether you want to stay on Studio 4 or switch to Studio 5 I will try to find a solution for you - but it would be good to know which one you plan to work with and I start on that path.

BR,

/sza2

Hi,

I'm afraid, RAIL source is not available even under NDA. Although, this is rather a marketing question than technical so, I would recommend to contact with your local Silicon Labs sales representative and they can forward your request to the marketing department.

BR,

/sza2

Hi,

You mentioned that you use Studio V4 / Flex 2.7.9. Is there any reason not starting the development in Studio v5 / Flex 3.2.0 (the latest)?

The power management is different (probably easier to use) in Studio v5 than in the prior versions.

I can check whether we can solve sleeping a non-sleepy end device / control the radio in both versions, but if there is no strong to stay on the older one, I strongly recommend using Studio v5 as it will be actively developed as opposed to Studio v4.

BR,

/sza2