International transmit power limit management: how often does the channel change?
39 views
Skip to first unread message
Stuart Longland
Nov 14, 2021, 11:16:57 PM11/14/21
to openthread-users
Hi all,
So, at my workplace, we've developed a small data logger device that
uses a +22dBm radio (TI CC2538+CC2592) to communicate on a 2.4GHz
Thread mesh network.
Initial firmware was done for the Australian market, where things are
pretty permissive. Consequently the device can run at +22dBm across
the whole channel range (11-26). We're looking to do a version for the
US market, and FCC rules require us to drop the TX power level a little
on channel 26 due to spurious conducted emissions.
It's not known if these conducted emissions are also radiated or
whether our design's power supplies will mitigate the conducted
emissions, but I figure it's better to play it safe with the FCC.
My immediate thought is to do something similar to what's done on WiFi:
a small embedded regulatory database, which can be used to figure out
what the max transmit power should be given the channel and
user-defined country.
If country=AU, we proceed as we are, but if country=US and channel=26,
we limit the power. I understand for EU markets, we may need to reduce
this further (TI's AN130 suggests limiting to +12dBm in the EU).
I have an idea how this might be achieved, and might look at making it
available as a pull request for OpenThread upstream, as we can't be the
only mob facing this issue.
Question is, how "optimal" in terms of RAM and CPU must such a database
be? If we just picked a channel and stayed there indefinitely, I'd
tend to optimise for RAM-efficiency at the cost of CPU overhead.
However, this discussion made me wonder:
https://groups.google.com/d/msgid/openthread-users/CAGwZUDuGiQUgTp21M-rCVkr4GSdxVGnuL8JgaN9DyHU7t_Fo_Q%40mail.gmail.com
On Tue, 13 Jul 2021 14:26:37 -0700
"'Jonathan Hui' via openthread-users" <openthre...@googlegroups.com> wrote:
> On Mon, 12 Jul 2021 05:13:31 -0700 (PDT) Matthias Alleman
> <matthias...@hotmail.com> wrote: On Thu, 8 Jul 2021 10:54:22
>
> > On Thu, 8 Jul 2021 10:54:22 -0700 "'Jonathan Hui' via
> > openthread-users" <openthre...@googlegroups.com> wrote:
> >
> > > On Thu, 8 Jul 2021 02:23:04 -0700 (PDT)
> > > Matthias Alleman <matthias...@hotmail.com> wrote:
> > >
> > > > This one occurs quite often
> > > >
> > > > <wrn> net_openthread: [WARN]-MLE-----: Failed to process UDP:
> > > > Security
> > >
> > > This occurs when there are other neighboring devices that have
> > > different Thread network credentials.
> >
> > Our setup consists of 2 Openthread networks that exist next to each
> > other, both on a different channel but with the same commissioner
> > credential. Is it expected to throw the warning in this situation,
> > or can we resolve this warning in some way?
>
> The warning message is expected in this case.
>
> Thread sends MLE Announce messages periodically on different channels
> to synchronize on the channel. MLE messages are secured with the
> network key. Neighboring devices in a different Thread network will
> receive the MLE message, but the security check will fail due to
> mismatch of the network key.
So if I understand this correctly, even though I may set a device to,
say, channel 15, it may momentarily switch channels and send a small
broadcast on that alternate channel. If a device in the US configured
for +22dBm did this, "randomly" choosing channel 26 to do its
broadcast, right now it'd breach FCC rules in the process.
Thus when the channel changes, the onus is on me as the firmware
writer, to have the device "look up" and clamp the TX power when
switching channels so that the emissions requirements are not breached.
Question is, how often does this happen? Storing a 16-element array
with the max TX powers (as `int8_t`s) for each channel (11-26; or a
27-element array if the device has a 868/915MHz radio in it too) is an
option, but chews up a bit of RAM. Iterating over a "rules" table costs CPU.
If the "different channel" MLE broadcast takes place once an hour (for
example), a CPU-intensive approach probably isn't so bad, but if it
happens a few times a second, this should be avoided.
How often is such a broadcast made?
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
So, at my workplace, we've developed a small data logger device that
uses a +22dBm radio (TI CC2538+CC2592) to communicate on a 2.4GHz
Thread mesh network.
Initial firmware was done for the Australian market, where things are
pretty permissive. Consequently the device can run at +22dBm across
the whole channel range (11-26). We're looking to do a version for the
US market, and FCC rules require us to drop the TX power level a little
on channel 26 due to spurious conducted emissions.
It's not known if these conducted emissions are also radiated or
whether our design's power supplies will mitigate the conducted
emissions, but I figure it's better to play it safe with the FCC.
My immediate thought is to do something similar to what's done on WiFi:
a small embedded regulatory database, which can be used to figure out
what the max transmit power should be given the channel and
user-defined country.
If country=AU, we proceed as we are, but if country=US and channel=26,
we limit the power. I understand for EU markets, we may need to reduce
this further (TI's AN130 suggests limiting to +12dBm in the EU).
I have an idea how this might be achieved, and might look at making it
available as a pull request for OpenThread upstream, as we can't be the
only mob facing this issue.
Question is, how "optimal" in terms of RAM and CPU must such a database
be? If we just picked a channel and stayed there indefinitely, I'd
tend to optimise for RAM-efficiency at the cost of CPU overhead.
However, this discussion made me wonder:
https://groups.google.com/d/msgid/openthread-users/CAGwZUDuGiQUgTp21M-rCVkr4GSdxVGnuL8JgaN9DyHU7t_Fo_Q%40mail.gmail.com
On Tue, 13 Jul 2021 14:26:37 -0700
"'Jonathan Hui' via openthread-users" <openthre...@googlegroups.com> wrote:
> On Mon, 12 Jul 2021 05:13:31 -0700 (PDT) Matthias Alleman
> <matthias...@hotmail.com> wrote: On Thu, 8 Jul 2021 10:54:22
>
> > On Thu, 8 Jul 2021 10:54:22 -0700 "'Jonathan Hui' via
> > openthread-users" <openthre...@googlegroups.com> wrote:
> >
> > > On Thu, 8 Jul 2021 02:23:04 -0700 (PDT)
> > > Matthias Alleman <matthias...@hotmail.com> wrote:
> > >
> > > > This one occurs quite often
> > > >
> > > > <wrn> net_openthread: [WARN]-MLE-----: Failed to process UDP:
> > > > Security
> > >
> > > This occurs when there are other neighboring devices that have
> > > different Thread network credentials.
> >
> > Our setup consists of 2 Openthread networks that exist next to each
> > other, both on a different channel but with the same commissioner
> > credential. Is it expected to throw the warning in this situation,
> > or can we resolve this warning in some way?
>
> The warning message is expected in this case.
>
> Thread sends MLE Announce messages periodically on different channels
> to synchronize on the channel. MLE messages are secured with the
> network key. Neighboring devices in a different Thread network will
> receive the MLE message, but the security check will fail due to
> mismatch of the network key.
So if I understand this correctly, even though I may set a device to,
say, channel 15, it may momentarily switch channels and send a small
broadcast on that alternate channel. If a device in the US configured
for +22dBm did this, "randomly" choosing channel 26 to do its
broadcast, right now it'd breach FCC rules in the process.
Thus when the channel changes, the onus is on me as the firmware
writer, to have the device "look up" and clamp the TX power when
switching channels so that the emissions requirements are not breached.
Question is, how often does this happen? Storing a 16-element array
with the max TX powers (as `int8_t`s) for each channel (11-26; or a
27-element array if the device has a 868/915MHz radio in it too) is an
option, but chews up a bit of RAM. Iterating over a "rules" table costs CPU.
If the "different channel" MLE broadcast takes place once an hour (for
example), a CPU-intensive approach probably isn't so bad, but if it
happens a few times a second, this should be avoided.
How often is such a broadcast made?
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
Jonathan Hui
Nov 15, 2021, 6:47:08 PM11/15/21
to Stuart Longland, openthread-users
As you are probably aware, OpenThread defines some platform APIs to configure TX power and region codes. For example:
In steady state, the most common message sent "off channel" is the MLE Announce message. The latest Thread spec and current implementation performs a full cycle every 11 to 12 minutes. For 16 channels, that means about one MLE Announce message every 45 seconds, on average. You can find more information in src/core/config/announce_sender.h.
--
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/20211115141649.5d92254e%40longlandclan.id.au.
Stuart Longland
Nov 15, 2021, 6:55:47 PM11/15/21
to 'Jonathan Hui' via openthread-users, Jonathan Hui
On Mon, 15 Nov 2021 15:46:55 -0800
"'Jonathan Hui' via openthread-users" <openthre...@googlegroups.com> wrote:
> As you are probably aware, OpenThread defines some platform APIs to
> configure TX power and region codes. For example:
>
> - otPlatRadioSetRegion()
"'Jonathan Hui' via openthread-users" <openthre...@googlegroups.com> wrote:
> As you are probably aware, OpenThread defines some platform APIs to
> configure TX power and region codes. For example:
>
> <https://github.com/openthread/openthread/blob/88d946cc08e1f692fb3cf3063e6f659345117c68/include/openthread/platform/radio.h#L1100>
> - otPlatRadioSetChannelMaxTransmitPower()
> <https://github.com/openthread/openthread/blob/88d946cc08e1f692fb3cf3063e6f659345117c68/include/openthread/platform/radio.h#L1085>
Ahh okay, those are added in a newer OpenThread release than what we
are running at present. No doubt a rebase of our firmware is needed at
some point.
I shall have a close look at these to see how they operate.
> In steady state, the most common message sent "off channel" is the MLE
> Announce message. The latest Thread spec and current implementation
> performs a full cycle every 11 to 12 minutes. For 16 channels, that means
> about one MLE Announce message every 45 seconds, on average. You can find
> more information in src/core/config/announce_sender.h
Ahh okay, so not super-frequent… I don't have to optimise for
sub-second intervals.
Many thanks. :-)
Regards,
Reply all
Reply to author
Forward
0 new messages