Which border router example code is latest? esp-idf/examples/openthread/ot_br or esp-thread-br/examples/basic_thread_border_router? (TZ-187)

[DanTup]

I was trying to use the example project from esp-idf v5.1 examples/openthread/br, but it didn't seem to include the web GUI mentioned in the docs.

I just came across another example at https://github.com/espressif/esp-thread-br/tree/main/examples/basic_thread_border_router.

It's not clear what the difference/relationship is between these two examples (both projects have been updated recently):

• https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br
• https://github.com/espressif/esp-thread-br/tree/main/examples/basic_thread_border_router

Could you clarify the differences (perhaps updating their READMEs to be clearer, or link to each other explaining the difference)? Which one is best to use to set up a border router for testing some simple Thread devices?

[DanTup]

I found a little more info here:

#9 (comment)

If you want to run the Thread BR on ESP32-C6 single SoC, please use the ot_br example from the ESP-IDF repo:

The example in this esp-thread-br repo is designed for the two SoCs solution

However, I'm still a little confused. I was using the one from the ESP-IDF repo, but couldn't find anything about enabling the Web GUI, whereas in this repo I can see some OPENTHREAD_BR_START_WEB checks that I can't find in the other.

I presume there's nothing about the single SoC setup that prevents using the web gui, so I'm still not sure that the only difference between these examples is using 1 vs 2?

[chshu]

@DanTup The difference between the two:

• ot_br in esp-idf: A simple br example based on two standalong modules, with 2 wires UART connection. It's a quick example setup to demonstrate BR functionality.
• basic_thread_border_router in esp-thread-br: It's the production-ready example based on the ESP Thraed Border Router Board, with more wires connection for UART/SPI, BOOT, REST and PTA. This example supports more additional features like RCP update, Web GUI and RF coexistence.

So you can use the ot_br example to tryout the BR features quickly; but if you want some more production features like RCP update and Web GUI, you should start with the basic_thread_border_router.

[DanTup]

@chshu perfect - thanks!

It could be really useful to add a note to the top of the respective READMEs with those descriptions, and a link to/description of the other.

I was a bit confused because I found the Web GUI mentioned in some of the docs (https://docs.espressif.com/projects/esp-thread-br/en/latest/esp32/codelab/web-gui.html), but there were other docs that referenced the esp-idf example (https://docs.espressif.com/projects/esp-idf/en/v5.1/esp32s3/api-reference/network/esp_openthread.html).

[DanTup]

Actually, I'm still confused

ot_br in esp-idf: A simple br example based on two standalong modules

basic_thread_border_router in esp-thread-br: This example supports RF coexistence.

In the readme for esp-idf/ot_br it says:

In order to run the example on single SoC which supports both Wi-Fi and Thread, the option CONFIG_ESP_COEX_SW_COEXIST_ENABLE and option CONFIG_OPENTHREAD_RADIO_NATIVE should be enabled. The two options are enabled by default for ESP32-C6 target.

And the readme in esp-thread-br/basic_thread_border_router there is no mention of coexistence. This seems to be the opposite of what you noted above (although I do see CONFIG_ESP_COEX_SW_COEXIST_ENABLE is in the sdkconfig for basic_thread_border_router too).

[chshu]

@DanTup There is already a note in the ot_br README: https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br#overview

CONFIG_ESP_COEX_SW_COEXIST_ENABLE is used to enable the Wi-Fi and Thread Internal coexistence on C6.

For the two SoCs solution, we use the External coexistence which is not mandatory, since there are two separate RF pathes on each SoC.

And more feedback here: #21 (comment)

[DanTup]

There is already a note in the ot_br README

Oops, I don't know how I missed that 🤦‍♂️ I'll close this then, probably nothing to do here :-)

For the two SoCs solution, we use the External coexistence which is not mandatory, since there are two separate RF pathes on each SoC.

Sorry if this is a basic question (this is all new to me), but can you explain why this is used if it's not required?

Thanks! :-)

[chshu]

The Internal Coexistence (single SoC) is mandatory since there is only one RF path, Wi-Fi and Thread can't access RF at the same time.

The External Coexistence (two SoCs) is not mandatory, since there are two SoCs with two separate RF paths, Wi-Fi and Thread can always access RF for transmiting or receiving. But the External Coexistence feature helps to reduce the interference between the two.