Programming Channel Plan at runtime as opposed to compile time

[Ajay K]

We have a custom MDOT Firmware that allows us configure the channel plan based on the customer country/region at runtime as opposed to compile time. So before shipping the MDOT we configure the Channel Plan and stored it in the external flash, which the MDOT reads from the external flash on boot up and configures the channel plan based on the channel plan settings stored for that customer.

However by default all MDOT’s are configured to the US Channel plan, since to create an MDOT instance we need to pass a channel plan, without which I can not use the MDOT API’s to read the contents of the external flash.

For example lets say we set the channel plan to the Australian channel plan for a customer and then since we are setting the channel plan at runtime, we end up initially create an MDOT instance using the US Channel plan, reading the data in the external flash and switching it to the Australian channel plan. Also FYI the join mode is in “Auto OTA” mode.

Below is a message that’s logged by the MDOT API when we create the initial MDOT instance with the US Channel Plan say after a reset. It seems like the MDOT API is aware that the MDOT was configured with Australian channel plan previously and since we start of by creating an MDOT instance with the US Channel plan the following lines are logged. I was wondering if there is a way for us to get to the session data and identify what channel plan we have previously stored so we can create an MDOT instance with the appropriate channel plan?

[WARNING] New ChannelPlan detected since last saved configuration – defaulting TX power, datarate, & LBT settings
[INFO] Set radio to Private Mode
[INFO] mDot Ready
[WARNING] Link: ResetState
[DEBUG] mDotEvent – BeaconLost
[INFO] Saved session was not Joined

Thanks,
Ajay

[Ajay K]

Any thoughts multitech team?

[Jason Reiss]

Did you enable setPreserveSession? normally the session is reset unless this is enabled.

In the ALL-PLANS AT Firmware we use these settings for saving the channel plan.
https://github.com/MultiTechSystems/Dot-AT-Firmware

setDefaultFrequencyBand
getDefaultFrequencyBand
saveProtectedConfig

[Jason Reiss]

The latest commit to the dev libraries will skip this check.
[WARNING] New ChannelPlan detected…

A changed channel plan will need to perform a join if the session does not match. The application has a better chance of detecting and fixing this once the dot instance is configured.

https://github.com/MultiTechSystems/libmDot-dev

[Ajay K]

Thanks Jason for taking the time to respond. Do you have an estimated timeline as to when the libmDot-dev changes would make it to the production version?

Also Is this frequency band: “lora::ChannelPlan::US915_OLD” for US still valid.

Thanks,
Ajay

[Ajay K]

just wanted to follow up, what is the difference between the US915_old and US915? Should we be even using US915_old or AU915_old?

Thanks,
Ajay

[Jason Reiss]

They should both work the same and create the same channel plan.
The new ones are better to use, the old ones should not be used for new stuff.

The new ID’s have a bit field to specify that the plan is a dynamic vs fixed channel plan. US and AU are the only fixed plans, all the channels are provided by the plan, no channels can be added. Dynamic plans are EU,IN,AS, etc.. where new channel are sent in a join accept.

[Author]

Posts