Hi,

In Connect, there is a callback (emberAfIncomingMessageCallback(EmberIncomingMessage *message)) which is fired when a message arrives. EmberIncomingMessage structure has a member named payload - which contains the message payload.

For more details about Connect stack see https://docs.silabs.com/connect-stack/latest/.

BR,

/sza2

Hi,

From Flex v2.0 Connect is only supported on EFR32 devices.

BR,

/sza2

Hi,

Did you check the documentation at https://docs.silabs.com/rail/latest/group-auto-ack?

BR,

/sza2

Hi

I think, we are on the same page. If something is not explicitly stated, it is always worse to check if that works.

One minor correction: based on our debugging result, the issue does not come from the Connect stack, but from the underlying layers. The Connect stack uses the RAIL library as a black box, and relies on the API provided by RAIL. In the same manner, RAIL library depends on the underlying radio and MCU hardware.

There are uncovered and known limitation of the hardware just as uncovered and known bugs in the firmware - however this is not Silicon Labs specific. I assume we both agree that devices nowadays are highly complex and it is not possible validate them from all aspects. We continuously try to do our best to improve the quality of our products, and customer feedback is the part of this process - especially in cases like this one, where the current issue was not covered by tests.

Issues can be classified based on their nature. The worst case, when no solution is available for the problem. There are cases, where the problem itself cannot be eliminated, but there is a temporary or permanent workaround. The best case is when the issue is fixable - in this case it is just the matter of time when the fix will be released.

To prepare to the worst case, it is preferable to test the required function as early stage of the development as it is possible and report it - to have time to fix it or find another way if there's no possible solution for the issue.

I hope this helps to understand that we are not against the customers, and customers also have responsibility to make a design successful.

BR,

/sza2

Hi,

Yeah, I think it is a good approach to at least verify that everything works as expected before mass production / deployment on the field.

BR,

/sza2

Hi,

Neither I do test with previous version. I just found weird that this issue just raised when you already have the schedule for production / deployment.

Although, the FEC issue maybe more difficult that it  It seems for the first glance, probably there is a solution for low data rate (4.8k). The timeout for ACK is 25ms by default. In case of 4.8kbps the ACK reception takes longer than this time. Solution: the MAC ACK timeout should be defined as a compile time macro (-D EMBER_MAC_ACK_TIMEOUT_MS=50) - in Simplicity Studio you can add it in AppBuilder / Other / Additional Macros.

Additionally, regarding the validation question, yes, we validate Connect stack. However, you may know, that there are enormous amount of combinations - even for radio parameters only. So it is technically impossible to test all cases and 4.8kbps and / or FEC hardly ever used by the customers developing on Connect base.

BR,

/sza2

Hi,

Yes, I agree it's a shame on us. I'm sorry that this issue blocks you to deploy your product.

What version did you use when you started to work on this project? Is it possible that this is a regression? In the early trial phase of the design, when you tested the long-range PHY, was the communication OK between the nodes?

BR,

/sza2

Hi,

OK, I see.

You may want to check RAIL auto-ACK feature: https://docs.silabs.com/rail/latest/group-auto-ack

BR,

/sza2

Hi,

Unfortunately, it is not clear what you mean. Could you please described more detailed?

BR,

/sza2

Hi,

Currently it seems RAIL lib causes the issue.

First, the team has to prioritize the the issue, than estimate the work to fix it. Unfortunately we cannot provide ETA for the fix yet.

BR,

/sza2