OpenThread support for 868MHz band on EFR32MG13

[Rohith R]

I am using EFR32MG13 2400/868 MHz 10 dBm Dual Band Radio Board (BRD4167A Rev A03). I am trying to implement Thread Network on 868MHz. I have generated the code  which implement Thread on 915MHz using BRD4158A in Simplicity Studio.
From that I have made following changes to support on 868MHz
1. In radio.c file  I changed the  OT_RADIO_915MHZ_OQPSK_CHANNEL_MIN to 0 and
Changing OT_RADIO_915MHZ_OQPSK_CHANNEL_MASK to 0x7ff.
2. I used  RAIL Test example to create RAIL configuration file (rail_config.c) on the BRD4167A with 868MHz, 500kbps,2GFSK modulation 125K and copied into the  PHY_IEEE802154_915MHZ_2GFSK_EFR32XG13.cfile, which is the radio proprietary file in the original code
When I try CLI command to form the Thread Network, The CLI command is not working (Typing help/dataset init new did not give any response).
3. When I used the same config array (const uint32_t generated[ ]) and changed only the generated channels according to below
const RAIL_ChannelConfigEntry_t generated_channels[] = {
  {
      .phyConfigDeltaAdd = NULL,
      .baseFrequency = 868000000,
      .channelSpacing = 1000000,
      .physicalChannelOffset = 0,
      .channelNumberStart = 0,
      .channelNumberEnd = 20,
      .maxPower = RAIL_TX_POWER_MAX,
      .attr = &generated_entryAttr,
}
}  The thread Network is forming on 915MHz and not on 868MHz.
Any one please tell me the reason for these errors? And also point out what modifications/changes i have to make to implement Thread on 868MHz.

Here I am attaching the rail_config.c file .

[Sagar Chinchani]

Hi Rohith

I had a few clarifying questions and suggestions regarding the issue you are currently facing:

Just to confirm, are you building your final application using Simplicity Studio or via OpenThread Github? This is because BRD4167a is currently not supported in GitHub. Accordingly, if you are trying to make this work via GitHub, a good first step might be to get it working on 2.4 GHz before proceeding to 868 MHz. 

If you are building your application using Simplicity Studio, refer to the guidelines in Section 2 of this document: https://www.silabs.com/documents/public/application-notes/an1350-openthread-single-band-proprietary-sub-ghz.pdf

1. Based on your details, it appears like, you have used 4158A for the project generation step. Is this correct?

2. While using BRD4158A for project generation seems like an okay workaround as it uses the same EFR32MG13 part, the radio board you are finally going to work with is BRD4167A, so there could be board specific headers/options that may be missing. A good intermediate step would be to generate, build and flash the image on BRD4167A with default options (no configuration changes) and check if you can bring up a Thread network on 2.4 GHz before proceeding to sub-GHz. Can you confirm if this works?

3. To enable operation on sub-GHz, once the project is generated you will need to enable the “Proprietary Sub-GHz Support (2GFSK in 915 MHz)” configuration option (as indicated in step 5), even though you are trying to make this work with 868 MHz. This step essentially enables the RADIO_CONFIG_SUBGHZ_SUPPORT macro in config/sl_openthread_subghz_config.h file to be able to work with a proprietary PHY. 

4. Next, replace the PHY_IEEE802154_915MHZ_2GFSK_EFR32XG13.c with your proprietary PHY i.e. the generated rail_config.c file for BRD4167A with 868MHz, 500kbps,2GFSK modulation 125K as done previously.

Note: The proprietary radio PHY supports 2-byte PHR by default. Accordingly, please make sure that this is taken into consideration when generating the PHY. If you are using a 1-byte PHR, update PHY_HEADER_SIZE in radio.c to use a value of 1 instead of 2.

5. Finally, update the following configurations defined in openthread-core-efr32-config.h to align with your designed PHY.

OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_CHANNEL_MIN

OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_CHANNEL_MAX

OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_CHANNEL_MASK

 

Please note that the above suggestions are just guidelines. OpenThread support for 868MHz band on EFR32MG13 has not been tested officially. Good luck!

Thanks

Sagar.

[Rohith R]

Dear Sagar Chinchani 

I am building my  final application using Simplicity Studio.

I am trying this baed on    https://www.silabs.com/documents/public/application-notes/an1350-openthread-single-band-proprietary-sub-ghz.pdf.

1.I am not physically using  4158A, In simplicity studio I forcefully selected this board and generate the ot-cli-ftd and enabled the 

Proprietary Sub-GHz Support(915 Mz). Edited radio.c,  PHY_IEEE802154_915MHZ_2GFSK_EFR32XG13.c, and openthread-core-efr32-config.h

 files in accordance with 868MHz and flashed to 4167A radio board

2. Thread Network on 2.4 GHz is working properly in the board 4167A  and Thread on 915 MHz  also working fine.

3. The problem I am facing is that:

 The rail_config.c  generated by the rail test example is used as the proprietary phy for the Thread on 868MHz.When I used the

same  config array (const uint32_t generated[ ])  in the rail_config.c for 868MHz, keeping the remainings  same  CLI command is not working.

But when using  config array (const uint32_t generated[ ])   in the 915MHz phy(generated by BRD4158A)  for 868MHz Thread Network is forming

4.  I have already edited openthread-core-efr32-config.h  files  OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_CHANNEL_MIN  to  0 and  OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_CHANNEL_MAX to  20 and OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_CHANNEL_MASK to 0x1fffff.

When I form the thread Network, in the dataset it shows  Channel Mask: 0x001fffff . But in the  MLE data of Radio Info 

still shows North America 915 MHz (Using Network Analyzer).  Is the Thread Network is on 868MHz or 915MHz? How will I verify it?

Also can you give the reason for (3)

Thank You

--
You received this message because you are subscribed to a topic in the Google Groups "openthread-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openthread-users/EMcCu8B0Rms/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/0abcca0e-36d5-4c23-8c53-8989341f2786n%40googlegroups.com.

[Sagar Chinchani]

Hi Rohith

Thank you for writing back. This definitely gives me more clarity on your workflow.

In regards to your point number 2, when you say that “Thread on 915 MHz is also working fine” -  this does not seem correct. BRD4167A is a 2400/868 MHz 10 dBm Dual Band Radio Board, and so (as per my understanding) should not be operating in the 915 MHz band. 

If you are looking at the packet traces in Studio to conclude this, then this is because of the RAIL PTI setting. When working with the Proprietary Sub-GHz PHY option in OpenThread, the radio.c code currently sets the PTI configuration to RAIL_IEEE802154_PTI_RADIO_CONFIG_915MHZ_R23_NA_EXT, giving an impression that the node is operating on the 915 MHz band which may not be the case.

status = RAIL_IEEE802154_SetPtiRadioConfig(gRailHandle, RAIL_IEEE802154_PTI_RADIO_CONFIG_915MHZ_R23_NA_EXT);

Since this is a custom PHY for 868 MHz (currently not supported), I don’t believe there is a standard PTI setting you can use. You could use the value of 0x9C for a custom 2-byte PHR PHY. 

If you have enabled the Proprietary Sub-GHz PHY configuration and are able to form a network with multiple nodes using the same channel, you probably have it working on the 868 MHz. That being said, manually editing a rail_config.c file is not a good idea. Changing things like RAIL_ChannelConfigEntry_t baseFrequency might appear to work but that seems unreliable and unsupportable. The correct approach would be to generate a custom PHY (like you are attempting) for the required configurations and use a Spectrum Analyzer to validate your findings.

In regards to your point 3, at an onset, I am not sure why the radio configurator-generated one wouldn't work unless its packet structure isn't compatible. It would be difficult to determine the cause of failure simply based on eyeballing the generated file or diffing register values. Can you provide more details on your custom PHY generation process / the inputs to the radio configurator?

Thanks

Sagar

[Sagar Chinchani]

Hi Rohith,

Just a quick update on my last email.  When I said that BRD4167A is a 2400/868 MHz 10 dBm Dual Band Radio Board, and so (as per my understanding) should not be operating in the 915 MHz band - is not completely accurate. Turns out, it could, as 868 and 915 are close, but with a performance hit. If you have changed the PHY configurations to use 868 MHz and the Network Analyzer traces still show 915 MHz, then that is because of the PTI setting as explained in my last email.

In regards to point 3,  can you provide the .radioconf file from your <proj>/config/rail directory of your railtest project used to generate the custom PHY for 4167A on 868 MHz?

Thanks

Sagar.

[Rohith R]

Dear Sagar Chinchani

With BRD4167A, i flashed the code for 915MHz, and form the thread network with two nodes. Supported channel and Radio Config was the same as specified in the

https://www.silabs.com/documents/public/application-notes/an1350-openthread-single-band-proprietary-sub-ghz.pdf .

When I  changed the   PTI configuration  to  RAIL_IEEE802154_PTI_RADIO_CONFIG_863MHZ_GB868 (I also tried with 0x9C).Then the RdioConfig ID was changed as 

expected.

My custom PHY generation is as follows

 From the simplicity studio I have created the railtest  example for BRD4167A and used  its rail_config.c file for PHY for 868MHz application. Here I am attaching the files and .radioconf  file.

Copied the content of  rail_config.c file to  PHY_IEEE802154_915MHZ_2GFSK_EFR32XG13.c ( except const uint32_t generated[ ] ), which is my  proprietary PHY for 868MHz. Here i am  attaching .

I am able to form the Thread Network with two devices. I am not sure that  it is in 868MHz.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/1f0109e5-8d40-4a44-80de-57f6f0b9372dn%40googlegroups.com.

[Sagar Chinchani]

Hi Rohit,

Thank you for your reply.

One issue I do see in your radio_setting.radioconf file is the value of the PHY header length. As mentioned in one of my earlier emails,  the proprietary radio PHY (shipped by the GSDK for 4158a) and the radio implementation support a 2-byte PHY header. The .radioconf attached in your last email has it set to 1. When generating the PHY,  please update this setting and let me know if it helps. For this change, you will need to customize the PHY settings,  enable the header under the 'Frame General' option, and finally set header size to 2 under the 'Frame Header' option.

Thanks

Sagar.

[Rohith R]

Dear Sagar Chinchani

  As per your instructions, I have changed the PHY header to 2byte in the Radio configuration. But still the CLI command  for forming the Thread Network is not working.

The problem is with the  uint32_t Protocol_Configuration_modemConfigBase[] (in rail_config.c)  or onst uint32_t generated[ ] in  PHY_IEEE802154_915MHZ_2GFSK_EFR32XG13.c

Thanks

Rohith R

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/aab312e9-abd8-4954-b052-3f86385035fan%40googlegroups.com.

[Sagar Chinchani]

Hi Rohith,

Thank you for your response. I am currently working with the team on this issue and will get back to you as soon as I have more updates.

Thanks

Sagar

[Sagar Chinchani]

Hi Rohith,

I had a further discussion with the team in this regard. 

The base_profile configuration available with the railtest project, is a starting point for users to design their own custom PHY and is not supported by the OpenThread radio code as implemented today. The PHY_IEEE802154_915MHZ_2FSK_EFR32XG13.c shipped with the GSDK, uses several additional configurations compared to the base profile in railtest, and hence the generated[] arrays differ. As the Sub-GHz support with OpenThread was an alpha feature, using a Proprietary PHY, we may not be able to share these configuration settings at this point.

That being said since you are trying to get this feature to work on 868 MHz, the team was able to generate a PHY for EFR32MG13 on 868 MHz with same configuration settings that were used when generating the PHY for EFR32MG13 on 915 MHz shipped with the GSDK (attached with this email). Again, please note that the PHY has been generated for experimental purposes and has not been exhaustively tested.

In regards to your new question - to get this feature working on the OTBR, like mentioned in the documentation:

For the RCP, you will need to enable the Proprietary Sub-GHz Support configuration option and make sure that the OPENTHREAD_CONFIG_PLATFORM_RADIO_PROPRIETARY_XX configuration options in openthread-core-efr32-config.h file are correctly updated.

On the host, you will need to rebuild the BR image with the radio configuration options listed in the table on page 5 of https://www.silabs.com/documents/public/application-notes/an1350-openthread-single-band-proprietary-sub-ghz.pdf

One way to do that is by updating the CMakeLists.txt file, and running the build command as indicated in the following PR: https://github.com/openthread/ot-br-posix/pull/892

Please note that, when working with OTBR, it is strongly recommended to use the host code and a compatible RCP from the same SDK. Trying to make an OT BR image from GitHub work with an RCP build using Simplicity Studio is NOT a supported workflow, not tested, and beyond the scope for support in case you hit any issues. 

Thanks

Sagar Chinchani

[Sagar Chinchani]

Hi Rohith,

It looks like the C file did not get added in my last email. Reattaching the files in this email.

Regards,

Sagar Chinchani

[Rohith R]

Dear Sagar Chinchani,

Thank you for your reply. Now the  CLI command is working for the file you shared. The Thread network is formed and pinged each other. later I will Verify the frequency .

I have some doubts  regarding Thread on Sub GHz because no enough  information in the internet related to this

1. Is it possible to form a network(Thread) consist of both 2.4GHz and Sub GHz devices ?(I assume a thread device on 2.4Ghz can not communicate with a thread device on Sub GHz )

2. A single border router can be used for both the devices (2.4GHz and sub GHz ) or a single border router can handle both the devices ?

3. Can we manually assign an IP address to a new device joining the thread network. (a device on the thread network is damaged, can we assign its IP address and other information to a new device joining to the thread network)

Regards

Rohith R

You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/59eaf550-41a6-4076-88dd-6477163715fan%40googlegroups.com.

[Sagar Chinchani]

Hi Rohith,

Forming a Thread network consisting of both 2.4 GHz and Sub-GHz devices is currently not supported. This is true for both SoC as well the border router application.

In regards to your question about IP address assignment, it depends on the kind of addresses you are referring to. If you are referring to mesh local addresses, then you cannot, as these are derived from the device's EUI. If you are referring to Global Unicast Addresses, then yes, there is an option to manually set this by the application. For more details on IP addressing, please refer to the following documentation: https://openthread.io/guides/thread-primer/ipv6-addressing

As this is a new question (not related to your original Sub-GHz question), please create a new thread, if you have any further questions in this regard.

Thanks

Sagar Chinchani

[Jonathan Hui]

If you are referring to mesh local addresses, then you cannot, as these are derived from the device's EUI. If you are referring to Global Unicast Addresses, then yes, there is an option to manually set this by the application

Minor correction to this statement - Mesh-Local Addresses are not derived from the IEEE EUI-64, the Interface Identifier is randomly chosen. But the high-level statement is the same - applications should not manually assign mesh-local addresses.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/2401a5af-71a1-4ce3-a8fa-cc62fb0f552dn%40googlegroups.com.

[Adrien Bruant]

Hi Sagar,

I've read this thread with great interest and I was wondering if it would be possible for a device to run two thread instances? One in the 2.4GHz band and another in the sub-GHz band. If not possible, is it a limitation of :

• The PHY not being able to serve both instances dynamically. My understanding is that BLE+Sub-GHz can be achieved, but maybe it depends on BLE having different timing constraints?
  
• The amount of RAM necessary to run two instances
• The current port of Openthread not supporting multiple instances
• others?

Thank you for considering my request,
Adrien Bruant

[Sagar Chinchani]

Hi Adrien,

Running two thread instances, in theory, should be possible. However, this area hasn’t been explored much and so I may not be able to comment on its limitations. Your concern around RAM size seems like a legitimate concern.

That being said, trying to extend this theory for dual-band support will definitely need additional considerations. For starters, the OpenThread Platform Abstraction Layer (radio code) as implemented today supports a single PHY. Supporting two PHYs (2.4 GHz and Sub-GHz) will require the use of two RAIL handles configured for the appropriate PHY and the RAIL multi-protocol library support. While this can be done, with a single radio the two PHYs will have to be time-shared i.e. the single radio trying to operate on 2.4 GHz and sub-GHz. There will be additional challenges that may have to be tackled at the higher layers - for instance, the node’s behavior in the network, its availability on a certain band, packet losses, and so on. Unfortunately, there is no Thread specification around this topic, at this point.

I hope this reply provides some insight into your question.

Thanks

Sagar Chinchani

[Adrien Bruant]

Hi Sagar,

Thank you for your help. I hope we'll be seeing more development and standardisation of Thread on the sub-GHz bands.

Best Regards,

Adrien Bruant