Help on Thread External Commissioning on 868MHz #7462
-
[Hi] , I am trying to implement Border router and external commissioning in Thread network on 868MHz using EFR32MG13. In my Thread Network RCP is connected to raspberry Pi (Border Router) . I have made some modifications in the ot-rcp code to make it compatible with 868MHz. Proprietary radio PHY support has been added, Changed some defines (Channel settings) in the openthread-core-efr32-config.h
In the Thread Commissioning Android app when I enter this J01NME password to connect to the Border Router ,it shows incorrect password Thanks |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
The OTBR PSKc script is an example, but to my knowledge doesn't actually set the PSKc in the network operational dataset. Either as part of creating the initial dataset or as a dataset update after formed, you need to set the PSKc to the derived value you expect. One flow would be:
https://github.com/openthread/openthread/blob/main/src/cli/README_DATASET.md I also don't believe the Thread Group app works any longer, though others can confirm, and recommend using the OpenThread app. Also, depending what you're testing you can always skip the joiner process and directly set the network key into the end device. This may not be obvious. Let us know if this is in the direction of your issue or if you think it's something else. |
Beta Was this translation helpful? Give feedback.
-
I have changed the OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_CHANNEL_MASK to 0x01fffff in the file openthread-core-efr32-config.h in the RCP. I need to form the Thread network on the channel < 10 |
Beta Was this translation helpful? Give feedback.
-
When I set the Channel mask using CLI src/cli/README_DATASET.md. Its not working properly. Also The Thread Network is not showing in the Thread Commissioning App. Thread network prefix in the dataset is different from the Network prefix in the Ip6 of the device. |
Beta Was this translation helpful? Give feedback.
-
Hi Rohith, While there could be more than one issue going on here, when trying to work with OT BR on Sub-GHz (868/915 MHz) using the Proprietary PHY option, you will definitely need to rebuild the OpenThread border router application on the host with the following OpenThread stack configurations: OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_SUPPORT= 1 When these configurations are not set (which is the default case), the radio piece of the stack code built on the host picks the 2.4 GHz option (i.e sets OPENTHREAD_CONFIG_RADIO_2P4GHZ_OQPSK_SUPPORT to 1) in turn causing the channels supported on the proprietary option (0-10) to get masked out. One way to do this is by modifying the CMakeList.txt file and specifying the configurations as indicated in this PR: The changes on the RCP side should align with the changes you made for the SoC case to work on 868 MHz. Once you have rebuilt the OTBR application with the above configurations, verify your changes by running the sudo ot-ctl channel supported command on your border router. Please note that the above instructions are just recommendations. OTBR on 868MHz is not officially tested. Good luck, Sagar. |
Beta Was this translation helpful? Give feedback.
Hi Rohith,
While there could be more than one issue going on here, when trying to work with OT BR on Sub-GHz (868/915 MHz) using the Proprietary PHY option, you will definitely need to rebuild the OpenThread border router application on the host with the following OpenThread stack configurations:
OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_SUPPORT= 1
OPENTHREAD_CONFIG_RADIO_2P4GHZ_OQPSK_SUPPORT=0
OPENTHREAD_CONFIG_RADIO_915MHZ_OQPSK_SUPPORT=0
(Note, that you will need to define all three configurations mentioned above)
When these configurations are not set (which is the default case), the radio piece of the stack code built on the host picks the 2.4 GHz option (i.e sets OPENTHREAD_CONFIG…