Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support channel selection strategy that ensures rotation through all channels #21

Open
frankleonrose opened this issue Jul 4, 2017 · 1 comment

Comments

@frankleonrose
Copy link
Member

Looking at some of the new mDot code, they break out a new class called ChannelPlan, which has specializations for US, EU, Aus, India, etc. In the US plan, it looks like they set a timeout after using a channel such that they don't reuse it until after a wait. Might be an idea to bring to LMiC - it means a sequence of transmissions won't reuse the same channel until all have been used, but if there's a gap between transmissions longer than the timeout, all channels will have a chance of being used.

From @terrillmoore: I would much rather have a guarantee of reuse, so use a shuffle pattern. I want to know that channel n will be reused within a maximum of 8 transmissions, in case that's the only one that works. (The current random sequence has the same chance of a channel to be reused every time -- no exclusion other than it must be not the same as the last one -- but it means we can go a long time in some of the marginal deployments before a good channel gets used, much more than 6min*7 tries -- not 48 minutes, but sometimes eight hours.

Of course, the plan would have to abide by the LoraWan spec. Also, any such plan requires storing history. Therefore,

  1. It would have to be opt-in. Devices unwilling to store LMiC internal state outside of active transmissions would operate in the current, history-free manner.
  2. LMiC would have to introduce an API for storing its internal state and then re-initializing from that state. Using this API a device could maintain channel use history across episodes of RAM-wiping deep sleep.
@frankleonrose
Copy link
Member Author

In discussion with @terrillmoore he proposed supporting a debug mode wherein the channel selection is simply sequential. He's found utility in having a system where a downlink command turns on a diagnostic mode that sends on every active channel sequentially. It makes it possible to test performance at each frequency in a band.

Perhaps the API could look like this:

debugSetChannelSelector(channel or CHANNEL_SEQUENTIAL or CHANNEL_NORMAL, duration);

Passing a single channel will stay on that channel. duration specifies how long to alter behavior. This API helps ensure that performance returns to spec normal after a preset amount of time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant