You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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,
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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,
The text was updated successfully, but these errors were encountered: