Hi Hyeong KIM, first of all, the "VCOM enable pin" is used only on WSTK. This pin is connected to the mother board of the WSTK, and it controls whether the virtual COM port of the mother board should connected to the UART of the radio board or not.  You can refer to the schematic of the mother board(BRD4001) for detail.

In your case,  as you just connect tx/rx/gnd to your custom host board, you should set the flow control of the uart to "software flow control" or "None".  It's recommended to use "software flow control". To do that, you need to select "ncp-uart-sw" when you create your ncp project, and in the properties of the USART, set the flow control to be "xon/xoff". Then when you start the host, you will also need to set the flow control to be "xon/xoff".

Hi rain rain,  actually the "radio info EFR32" field is not part of the frame over the air. It's added by the radio hardware when it was received or captured. For mac layer frame format, please refer to spec 802.15.4 2006.

For network layer frame format, please refer to Zigbee spec section 3.3.

For aps-sub layer frame format, please refer to Zigbee spec section 2.2.5.

For application layer frame format, please refer to ZCL spec section 2.4.

Hello,

The server and client sample apps are a somewhat simple example of communication over a Thread network. The application state machine is definitely not robust enough for all situations. So, the applications of these examples would have to be redesigned to fit your needs. A network capture would better show what is happening over the air. The nodes should be passing MLE messages to each other to maintain routing and network information.  My recommendation would be to start a capture from the multiple nodes you are using to see what is happening over the air.

A couple of notes:

1. SL-Thread 2.10 is only supported with IAR 8.30.1
2. If you reset the network of node A (ie remove all network parameters) and re-form the network, it is essentially a different network and any other device that was on the same network as node A previously, will not be able to communicate with it. This is due to network security data that is generated during the forming of the network and when a node joins said network. I'm guessing this is what might be happening to the server and client nodes.

Hi Hubert,

Currently, EFR32 doesn't support running three stacks on one device at the same time using dynamic multiprotocol. If you have questions about the road map of supporting this feature, you can contact our local sales. If you do not yet have a sales contact, you can find them at this website: https://www.silabs.com/buysample/pages/contact-sales.aspx