I am not sure if my Thread network is a Mesh network.

[Michael Simpson]

I am not sure if my Thread network is a Mesh network.

I have an RCP and 4 REEDs connected together.

But I am finding the furthest REED is regularly taking several seconds for a CoAP request to get its response back, when it normally takes around 70ms.

When I run the state command, this REED is a router, when I though it would have connected to another REED as a Child

This furthest away REED reports the following:

>ipaddr

fdde:ad00:beef:0:0:ff:fe00:0
fdde:ad00:beef:0:2e55:5eb:a96b:8b60
fe80:0:0:0:e0b1:733f:7f85:8991
Done

> ipaddr rlo c
fdde:ad00:beef:0:0:ff:fe00:0
Done

> rloc16
0000
Done

Is an RLOC16 of 0000 normal?

> neighbor table
| Role | RLOC16 | Age | Avg RSSI | Last RSSI |R|D|N| Extended MAC     |
+------+--------+-----+----------+-----------+-+-+-+------------------+
|   R  | 0x3800 |  30 |      -62 |       -65 |1|1|1| 6a8eb3ae74d508c9 |
|   R  | 0x5800 |  32 |      -81 |       -83 |1|1|1| aa540759e0ab4142 |
|   R  | 0xbc00 |  12 |      -72 |       -80 |1|1|1| 0a25f9c66de7d47a |
|   R  | 0xe800 |  30 |      -83 |       -84 |1|1|1| 7ad787d9c954d31b |

>scan

| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |

+---+------------------+------------------+------+------------------+----+-----+-----+

| 0 | AGS-FCC-OT-1     | 1111111122222222 | 1234 | 0a25f9c66de7d47a | 15 | -71 | 255 |

| 0 | AGS-FCC-OT-1     | 1111111122222222 | 1234 | 6a8eb3ae74d508c9 | 15 | -71 | 228 |

| 0 | AGS-FCC-OT-1     | 1111111122222222 | 1234 | 7ad787d9c954d31b | 15 | -78 | 206 |

Done

When I first started with Openthread, some of my REEDs would report a state of Child.

eg one device would report an IP RLoc address of fdde:ad00:beef:0:0:ff:fe00:3400 and it would have a child with fdde:ad00:beef:0:0:ff:fe00:3401

I had a problem with my REEDs sometimes starting up as another Leader so I changed my REED code initialization from providing a complete dataset, to only providing the MasterKey.

In doing this have I disabled the mesh capability?

How can I view the toplogy of my network? The Border Router topology graphic is attached.

It shows 1 Leader 5800, 3 routers 3800, e800, bc00 and no children.

So my bad REED rloc 0000 does not even show, and yet it is communicating with the OTBR

[Gabe Kassel]

Starting with just MK does not disable mesh capability. 

REEDs are, as their name suggests, router eligible. The network will determine if they should upgrade to become a router (or downgrade to a child) dynamically. Typically a device will first join as a child then upgrade to a router, so depending when you were inspecting state, it may have still been a child. 

The OpenThread "router table" is another useful representation of nexthops. I believe tools like Ubiqua can help create visual representations.

Some older discussion I quickly found here. 

--
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/a625e63b-4397-4680-bbbf-cd7fbcde8694n%40googlegroups.com.

--

_______

Gabe Kassel
Technology Strategist | Office of the CTO

m 770.490.0431
e  ga...@eero.com

[Jonathan Hui]

Adding to Gabe's response:

A Router ID of 0 is valid, which would result in an RLOC16 of 0x0000.

When there are less than 16 routers, REEDs will always attempt to upgrade themselves to the router role. To avoid all REEDs becoming routers at the same time, Thread specifies a random delay between 0 and 2 minutes before becoming a router. So it could be that when you observe a REED operating as a child, it is simply waiting to become a router.

The behavior you are describing sounds like the radio communication between neighboring devices is less reliable than expected. Can you provide a packet sniffer trace to help diagnose further?

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/CAOGWdyQgPXAxNWSRA9iF80PATV3BNBBRdnXKn9C_YM5b91MUaQ%40mail.gmail.com.

[Michael Simpson]

Hi Jonathan

As I said above my normal coap request / response cycles for my "/pumpStatus" and "/progData" update messages are between 50 and 100mS which is great. My REED times the request / response cycle and sends the result up in the next update with the tag sd=xxxxx (in msec)

Please see attached packet trace and tcpdump trace. I saved this in its native format from the Silabs Simplicty Studio. Let me know if you need it exported in another format.

I captured and examined a case of a 2729ms response cycle. sd=02729 at 12:10:09.239772 in my TCPDump log (line 114168)

This means the /progData message at 12:10:06.460127 (line 113978) took 2729ms to receive its response even though TCPDump reports a response at 12:10:06.466732 (line 113986)

The same REED sent 2 "/trace" messages and got responses back responses at 12:10:08.406216 (line 114104) and 12:10:09.021912 (line 114142)

I have examined the packet trace log and found this sequence starting at:

210.685801    3C00    0800    progData sy=10:04 sd=00059
210.693865    0800    5800    forwarded to my RCP
210.699938    0800    5800    repeat?
210.705052    0800    5800    repeat?
210.711442    0800    5800    repeat?

210.821839    3C00    0800    trace message
              0800    5800    forwarded to my RCP
210.860512    5800    0800    2.03 CoAP Ack         
              0800    3C00

So no response to my first progData
Then down at:
213.375997    3C00    0800    progData sy=10:04 sd=00059        Message sent again by stack? - not by my app
              0800    5800    to my RCP
213.422395    5800    0800    2.03 CoAP Ack
              0800    3C00

215.323914    3C00    0800    trace
              0800    5800
215.361811    5800    0800    2.03    CoAP Ack
              0800    3C00
215.939612    3C00    0800    trace
              0800    5800    to my RCP
215.979170    5800    0800    2.03 CoAP Ack
              0800    3C00

216.136307    3C00    0800    pumpStatus sy=10:09 sd=02729
              3C00    0800    Resend?
              0800    5800    to RCP
              0800    5800    from duplicate?
216.201364    5800    0800    2.03 CoAP Ack
              5800    0800    Repeat?

              0800    3C00

I am not sure what the detail of all of this tells you. I see repeated messages at a transport level and what looks like a case of a my RCP 2.03 CoAP response going missing altogether and CoAP retrying after a couple of seconds timeout?

Can I fix this eg playing with changing channels or something, or is this just the reality of wireless coms. I have seen the response times I measure blow out to over 8 seconds. Is it possible / recommend to play with the CoAP response timeout somehow? Response cycles longer than 2 seconds is really going to be a problem in this application.

If I stop my host app on my border-router, I am seeing my REED CoAP response retries (a little variable in consistency) increasing from a couple of seconds to over 20 seconds

Thanks in advance for your support

[Jonathan Hui]

Thanks for sharing the packet trace. I was not able to decode the frames without the decryption key, but I can see the MAC retransmission behavior.

It seems that your devices are configured with a MAC retransmission limit of 3 (for a total of 4 transmission attempts). The latest Thread Specification increases the MAC retransmission value to 15 and we recently merged openthread/openthread#6263 to reflect that. If possible, you may want to try testing with this increased MAC retransmission value.

What OpenThread commit are you using on your Thread devices? I presume that your devices do not have the recent MAC retransmission change.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/9ce2c17a-d305-4bae-a69b-f90e442f40d9n%40googlegroups.com.

[Michael Simpson]

Hi Jonathan

You said " The MAC response timeout is less than one millisecond. At several milliseconds between retransmissions, you can expect 15 retransmissions to take on the order of a couple hundred milliseconds."

This sounds good, but I don't know how to go about this. 

I am using Simplicity studio with the latest sdk 3.1.1 which reports it includes: OpenThread 1.1.1.0 (GitHub-5c2ad91cf). 

I found there is another SDK with later OT update available from Silabs. Unfortunately the compulsory product update failed before I could update the sdk so now I am having to reinstall everything from scratch.

This will take some time, and so as to get an answer if possible before your end of day, can you advise how I can tell if the new version has the MAC retransmission increase to 15?  If it isn't is it possible fro me to change this and if so, how?

Thanks

[Jonathan Hui]

The PR I linked earlier (openthread/openthread#6263) has the diff. As for details in how to make the change in Simplicity Studio, I suggest reaching out to Silicon Labs.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/384d277c-fd45-4c2a-8c75-eb9e38dea1f4n%40googlegroups.com.

[Michael Simpson]

Hi Jonathan

I upgrade simplicity studios to the latest build which is sdk 3.1.2 which reports  OpenThread 1.1.2.0 (GitHub-5c2ad91cf)

I found the mac.h in the directory skd_.../util/third_party/openthread/core/config

macMaxFrameRetries still had a value of 3 so I changed this to 15 per your advice.

I changed this and rebuilt my REED and the RCP.

I also found and edited edited the matching file on the border router at: ot-br-posix/third_party/openthread/repo/src/core/config/mac.h

It also had a macMaxFrameRetries value of 3 which I increased to 15. I am not sure if this is used in the OTBR or not but no harm done right?

But I am still having delay problems.

I have bookmarked the attached NCP file at: 

• a delayed message (time 715.897742)
• the message before(time 712.638959)
• the message following (time 718.669921) which reported the extended stand-down time sd=20751

My key is f34dd4690e631a68b0611565036cc853

Could you please take a look and advise.

Another thing, I send 3 types of requests from my REED to my host app on the Border Router. For each type of message I only send one message at a time and wait for a response or an error (eg timeout). But this means I could send up to 3 messages (one of each type) at the same time. I see the "trace" messages in between the "status" and "progdata" messages when the problem occurs, and am not sure if this is my problem  Is this a bad idea sending multiple outstanding messages which is over working the stack?

[Jonathan Hui]

From the trace, I see that the /progData request at time 715.897742 has a corresponding CoAP ack/response at time 715.944362. Can you clarify what you mean by this message being delayed?

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/df2a1cfa-42dc-439c-97fa-df8c9c734f69n%40googlegroups.com.

[Michael Simpson]

The packet trace is taken from another REED running on my dev kit board.  The node with the delay is a custom board with an mgm12p32f1024GA  module.

So the packet trace shows the response quickly following the request, but the REED measured this 02751 msec later (sorry for typo in my last message where I said 20751)

I did think about swapping the reeds, but if I take the packet trace on the reed in question, it will show the delays in the response but it won't show delays in the request going out.

I will do this though and submit another packet trace.

Regarding my other questions:

Does the mac.h file get used in the RCP or the otbr-agent build? I am guess the RCPO only otherwise it would already be changed to 15 oin the otbr source. I just need to know for future updates.

Is it ok to send multiple Coap requests (up to 3) before their responses come back?

Could it be interference on the network and should I play with changing channels. Is there any best practice on channel selection? Can / should this be done this done dynamically in software? 

[Jonathan Hui]

On Thu, Apr 8, 2021 at 10:59 PM Michael Simpson <michae...@gmail.com> wrote:

Does the mac.h file get used in the RCP or the otbr-agent build? I am guess the RCPO only otherwise it would already be changed to 15 oin the otbr source. I just need to know for future updates.

The RCP implements the 802.15.4 MAC, so the MAC configurations are only used by the RCP.

Is it ok to send multiple Coap requests (up to 3) before their responses come back?

Yes, this should be OK.

 

Could it be interference on the network and should I play with changing channels. Is there any best practice on channel selection? Can / should this be done this done dynamically in software? 

There could be interference - if you have a channel analyzer, you could determine this more definitively. OpenThread also has a channel monitor feature that you can enable. In practice, unless you're streaming a lot of Wi-Fi data, the coexistence should be fine.

Thread requires all nodes in the network to use the same channel. Changing the channel is a fairly involved operation because it requires all devices to switch at the same time. OpenThread has a channel manager feature that can assist with changing channels manually or dynamically.

--

Jonathan Hui

[Sébastien Parent-Charette]

Hi,

You mentioned before having some issues with your update of the GSDK (from 3.1.1 to 3.1.2) and having to reinstall Simplicity Studio from scratch. This obviously seems like an abnormal situation (though it looks like it is resolved for now). That being said, if you do have any other issues with updates please do reach out to us (or for opening a ticket) and we will assist you.

As for the OT part of your situation, like Jonathan said there could be some interference around your network causing the MAC-layer retries you've noticed (and exceeding the original default setting of 3 retries).

Sincerely,

--

Sébastien Parent-Charette

[Michael Simpson]

The update stopped part way through and when I went to restart Simplicity Studios, the executable was gone altogether from my drive meaning a reinstall from scratch.

By the way sdk 3.1.2 shows as 3.1.1 in explorer and in Simplicity Studios project tree view. In preferences Simplicity Studio SKDs it shows as 3.1.2, and if I run version from the cli it reports the correct of OpenThread 1.1.2.0

A little confusing?

How regularly to Silabs update the SDK with the latest openthread changes?  The latest Silabs release does not have the mac.h file changes Jonathan advised me about.

[Michael Simpson]

Hi Jonathan and Sebastien (assuming you represent Silabs)

I caught another case - see packet trace attached - same key.

I have bookmarked the message which seems to me to be 1 send  + 3 retries and MAC level with no ack 

518.698067     /progdata 8000 f800

Followed by 3 retries down to 518.718159

And then 2 seconds later I see another resend which I am guessing is at the CoAP level.

520.972466     resend of /progdata 8000 f800

If I am interpreting this correctly, the file I changed at gecko_sdk_3.1.1/util/third_party/openthread/src/core/config/mac.h from line 72 (see attached)

#ifndef OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT

#define OPENTHREAD_CONFIG_MAC_DEFAULT_MAX_FRAME_RETRIES_DIRECT 15

#endif

...has not increased the MAC resends from 3 to 15. When I changed this I selected to make a local copy which is the file I attached.

Can you please advise next steps.

[Michael Simpson]

Hi Jonathan and Sebastien

I edited the file in the root silbas sdk folder outside simplicity studios at C:\SiliconLabs\SimplicityStudio\v5_3\developer\sdks\gecko_sdk_suite\v3.1\util\third_party\openthread\src\core\config\mac.h

I rebuilt and compared the s37 files and there found the byte changed from the previous version.

S21401954029600F2304F13C06E06084F83030394688

S2140195402960032304F13C06E06084F83030394694

So taking a copy into my project and editing it doesn't work.

Anyway now I have a version with 15 retries but my problem remains. See attached packet trace bookmarks at:

799.223999 showing 1 send + 15 retries

801.266999 showing another send of the same packet (CoAP level resend?) 1 send + 15 retries

805.304999 showing successful 1 send and ack response

It seems to me the MAC level retries span a period to short to get the message through, although this case seems particularly bad.

One thing I don't understand is that this REED RLOC16 4000 is spaced in another room approx 30 metres from my RCP RLOC16 f800. There is another REED RLOC16 9400 about sitting between the trouble REED and the RCP - approx 10 metres closer to the RCP and in the same room.

Sometimes the REED messages pass through this REED router to the RCP and other times they go directly to the RCP.

I thought the mesh network meant the message take multiple paths and the first one to get through succeeds. I don't seem to see this in the packet trace, but I am a novice at all of this.

Unless you have some magic for me, I am thinking I might be better with MAC 3 retries and shorten my CoAP timeout from the default of 2 seconds down the the minimum of 1 for just for these important messages

[Jonathan Hui]

Not receiving an acknowledgement after 16 total transmit attempts should be pretty exceptional, especially when it is fairly reliable most of the time. I would try to understand why the platform is not receiving the packet. It could be an issue with the radio driver.

You said earlier that you are using both 15.4 and BLE simultaneously, which requires the radio to multiplex the operations. If so, have you tried disabling BLE to see if performance improves?

--

Jonathan Hui

--
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/9937f5f7-b6b9-4fb4-891a-18a8dad30ce7n%40googlegroups.com.

[Michael Simpson]

Hi Jonathan

My BLE task doesn't do anything at the moment, but I will need it soon in the project.

All the other REEDs in different positions work fine using the same software. The REED in the position which causes intermittent problems works fine when it is moved closer to the RCP. I have also tried two types of hardware platform being:

• my Silabs Devboard with an  EFR32MG12P432F1024GL125 SOC
• my custom board using an MGM12P32F1024GA with integrated chip antenna
  

Both have the same issue which is that they work fine most of the time, but CoAP messages are delayed occassionaly.

My REEDs are configured with max transmit power 17dBm and 14 dBm.

The problem occurs when I move the REED about 30 meters away from my RCP on the other side of a internal drywall wall (plaster board).

See my diagram attached. I have another REED sitting between the problem REED and the RCP which works fine.

I have proved that when I get the problem, a retry at CoAP level is what resumes my coms. That is not to say I don't have issues and recovery at MAC transmission level, but when it drops out, it seems to not be able to recover withing 15 transmissions cycles as you saw in my last packet tare logs.

My question is, why do the messages not go through the REED in the middle if there are problems.  This was why I named this conversation "I am not sure if my Thread network is a Mesh network."

[Jonathan Hui]

Thread devices forward a given message to a single next hop. Thread does not implement multi-path forwarding (i.e. forwarding multiple copies of the same message across different paths). Thread devices will always try to choose the best path. If a direct connection is available with a decent link margin, it will try to use that.

I noticed that the 15 retries from 0x4000 to 0xF800 is occurring at:

1. 799.22
2. 799.77
3. 801.26
4. 801.87

So 0x4000 actually tried sending a packet to 0xF800 a total of 64 times and did not receive an ACK for any of them.

The sniffer trace does show 0x4000 receiving some frames from 0xF800, but the RSSI is on the lower end. I saw some RSSI values down in the -94 dBm range. If 0xF800 is transmitting at a higher power than 0x4000 then transmit failures will be pretty likely.

As mentioned above, Thread measures link quality using link margin - higher link margin are better links. OpenThread implements this by taking the difference between RSSI and the radio's reported receive sensitivity value. One thing you could try doing is increasing EFR32_RECEIVE_SENSITIVITY. Maybe try increasing the value to -90 dBm. This will help encourage more stable links, but will also reduce the effective communication range at the same time.

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/491b007c-5637-419f-b067-3cfa3699ced7n%40googlegroups.com.

[Michael Simpson]

Hi Jonathan

This sound good.

Can the Receive Sensitivity be changed by the API as it would be good to be able to configure this for a node on site rather than having to hard code it. It would be nice to confirm the change from a CLI command, does one exist to at least check this.

Also on my pilot it is not easy to change the RCP software so it would be good if it could be done through the CLI.

If I can't change the RCP immediately, will changing the REEDs be good enough as they initiate coms with the Border Router to logon. Or will the RCP establish its own route back to the REED?

If anyone from SIlicon Labs is following this,  I am not sure where this file is in the silab sdk. I have found a radio.c file in two directories which have the line "#define EFR32_RECEIVE_SENSITIVITY (-100)    // dBm". These are at:

• C:\SiliconLabs\SimplicityStudio\v5_3\developer\sdks\gecko_sdk_suite\v3.1\util\third_party\openthread\examples\platforms\efr32\src
• C:\SiliconLabs\SimplicityStudio\v5_3\developer\sdks\gecko_sdk_suite\v3.1\protocol\openthread\platform-abstraction\efr32

I guess I can try changing both?

Thanks

Michael

[Bob MacDonald]

Hi Michael,

 

When building from Simplicity Studio the platform specific code in protocol\openthread\platform-abstraction\efr32 is used.  The platform code from util\third_party\openthread\examples\platforms\efr32 is not used with Simplicity Studio.

 

Bob

 

From: <openthre...@googlegroups.com> on behalf of Michael Simpson <michae...@gmail.com>
Date: Monday, April 12, 2021 at 6:46 PM
To: openthread-users <openthre...@googlegroups.com>
Subject: Re: I am not sure if my Thread network is a Mesh network.

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/5c3f9756-fec2-4e68-b23f-f33f489ec888n%40googlegroups.com.

[Jonathan Hui]

On Mon, Apr 12, 2021 at 3:46 PM Michael Simpson <michae...@gmail.com> wrote:

If I can't change the RCP immediately, will changing the REEDs be good enough as they initiate coms with the Border Router to logon. Or will the RCP establish its own route back to the REED?

Changing just the REEDs first should be sufficient since Thread evaluates link quality in both directions. However, if that results in improved performance, ideally you would change the RCP as well.

--

Jonathan Hui

[Michael Simpson]

Hi Silicon Labs and Jonathan

I am really battling with this now.

I have just discovered that since I updated to SDK 3.1.1 and 3.1.2, the Txpower seems to be limited on my target to 14dBM when the  MGM12P32F1024GA  is a 17dBM part. I have previously been running this at 17dBm.

I found this with my REED using cli as well as my RCP using ot-ctl. See tests below.

The API spec states 

Note: The real transmit power will be no larger than the power specified in the max power table for the current channel.

Where is the max power table and how do I configure it back to 17dBm?

> txpower

14 dBm

Done

> txpower 13              set power down to 13

Done

> txpower

13 dBm                       Verify

Done

> txpower 15              Set power up to 15

Done

> txpower

14 dBm                      Verify - it tops out at 14dBm

Done

>

Also note the following

> txpower 3

txpower 3

Done

> 

> txpower

txpower

2 dBm                             set to 3 confirmed back 2

Done

> 

> txpower 4

txpower 4

Done

> 

> 

> 

> txpower

txpower

3 dBm                            set to 4 confirmed back 3

Done

> 

> 

> 

> txpower 5

txpower 5

Done

> 

> 

> 

> txpower

txpower

5 dBm                          set to 5 confirmed back 5

Done

The project configurator correctly reports

Target and SDK Selection

MGM12P32F1024GA

Custom Board

[Michael Simpson]

Regarding the TxPower issue, I would really appreciate some help from Silabs ASAP on this please as I am sure this will help my immediate problem.

I have also opened a case on my account with the Silabs.

Thanks

Michael

[Sébastien Parent-Charette]

Hi Michael,

Please find below my answers concerning your questions and comments:
1) Sdk3.1.2 seems to limit my transmit power to 14dBm when I am using a custom board with an MGM12P32F1024GA which supports 17dBm. When I originally developed this on earlier SDKs I could get 17dBm.
> When txpower <new value> is invoked to change the transmission power, it forwards the request down to RAIL (Silabs' Radio Abstraction Interface Layer library). This library ensures the closest value to what is requested is used.

As for obtaining 17 dBm with a previous GSDK version and not in this one, it seems likely this is due to a default setting that changed in this update of the GSDK. Since your txpower seems capped at 14 dBm specifically it would indicate your device is using the "low" power curve (vs the "high" power curve). This is simple to check (and fix it that is the case):

1. In Simplicity Studio, open your project configuration (SLCP) and click the SOFTWARE COMPONENTS tab. In the search bar (top right), type in "rail utility, pa" and press enter.
2. Then, select the RAIL Utility, PA component and either click the small blue gear icon or the large blue button with a white gear labeled Configure.
3. In the component configuration screen please confirm the value you have under the third field (Milli-volts on PA supply pin (PA_VDD). To have access to the maximum power, set this value to a number larger than 1800 (minimum for MGM12P). Typically, this would be 3300 for parts like the radio board BRD4304A (which uses the same module, MGM12P). On your custom board, what voltage are you providing to the MGM12P module's VDD?

2) Jonathan has advised "[…] If possible, you may want to try testing with this increased MAC retransmission value." I found the mac.h in the directory skd_.../util/third_party/openthread/core/config macMaxFrameRetries still had a value of 3 so I changed this to 15. When with Silabs update the latest Openthread into into the SDK?
> The OpenThread part of the Silabs GSK 3.1 is based on OT specs 1.1, which specified 3 at the time. The upcoming update (GSDK 3.2) will include the changes Jonathan Hui referred to (including the change from 3 to 15).

3) With increasing EFR32_RECEIVE_SENSITIVITY which I have been advised can be changed in protocol\openthread\platform-abstraction\efr32 by Jonathan […] Are there any plans to make this configurable by the API and if so when will this be available in Silabs SDK? It sounds like it is something people would need to change.
> Indeed, the value for EFR32_RECEIVE_SENSITIVITY must be changed directly in the appropriate configuration file (radio.c) at this time.
I am not aware at this time of any plans concerning adding this setting in the configuration interface (in Simplicity Studio) or through the API (this value is currently read-only in the API). This is mostly simply because it has not been requested before.

Sincerely,

[Gabe Kassel]

@Sebastian

The OpenThread part of the Silabs GSK 3.1 is based on OT specs 1.1, which specified 3 at the time. The upcoming update (GSDK 3.2) will include the changes Jonathan Hui referred to (including the change from 3 to 15).

Is this only the case when building within SimplicityStudio? It would seem odd to build with Thread 1.2 enabled via CMake/directly against OpenThread but have different behavior than intended upstream. For my implementation, I build directly with Openthread outside of SimplicityStudio, so wanted to understand better. 

--
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/811d377b-bceb-40bd-9a90-845dd245b380n%40googlegroups.com.

[Sébastien Parent-Charette]

Hi Gabe,

My apologies, I was a bit unclear on this point. Support for OT 1.2 is available in GSK 3.1+ (in Simplicity Studio or otherwise) but it is not enabled by default (still in alpha). You can read more about it in the latest release notes here (PDF; section 7.2). Your use case is completely valid and the same could be done in SSv5 by enabling OpenThread 1.2 support in the configurations of the project by double-clicking the SLCP file > Software Components > OpenThread > Stack (FTD/MTD/RCP) > Thread Version and choosing from the dropdown 1.2 instead of 1.1 (default value).

I hope this clears up any misunderstandings!

Sincerely,

[Gabe Kassel]

Makes sense. Thanks for letting me detour this thread. 

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/184d16c7-3b4d-4542-bf37-bde4ca3d0934n%40googlegroups.com.

[Michael Simpson]

Hi Sebastien

Thanks for the response.

I am driving my VDD with 3.3V

I found my older software running SDK 3.0.0 did not have  "rail utility, pa" installed. This ran at 17dBm when TxPower was set.

I have never installed  "rail utility, pa"  , but it seems on later SKDs it is installed automatically, and the "mV on PA supply pin" is set to 1800.

I increase this to 3300 per your advice and found my software is now reporting 17dBm.

There was no mention of this in the SKD release notes history, but I imagine this could affect a lot of people. I think you should add this to the release notes.

Cheers

[Sébastien Parent-Charette]

Hey Micheal,

Yes, I agree such a change should probably be more explicit/visible to users of the SDK. That being said, the issue you had (i.e.: wrong platform header values imported; i.e.: 1800 vs 3300) has been corrected and should show up in an SDK patch soon.

Please do let me know if you see any other oddities with the default values (ex: they need to be changed for the base case to work) when you create a new project.

Sincerely,