search

TheThingsNetwork / lorawan-frequency-plans

LoRaWAN Frequency Plans for The Things Stack
https://www.thethingsnetwork.org
Apache License 2.0
37 stars 26 forks source link

Feature/au915 fsb1 dwelltime off #56

Open EduardoPfeifer opened 1 year ago

EduardoPfeifer commented 1 year ago

Summary

References https://github.com/TheThingsNetwork/lorawan-frequency-plans/issues/55

Changes

Checklist

johanstokking commented 1 year ago

In which case can this be used in Austrlia?

EduardoPfeifer commented 1 year ago

In which case can this be used in Austrlia?

The idea is to use in Brazil, not necessary Australia. Since the region em regulamentation don't restrict the dwell time of uplinks.

References: Frequency Plans by Country National Telecommunications Agency (ANATEL) Resolution No. 680, from June 27, 2017 - Portuguese only, Article 10 National Telecommunications Agency (ANATEL) Act No. 14448, from December 4, 2017 - Portuguese only Section 10.3

adriansmares commented 1 year ago

I am inclined to propose that we also introduce the NDT variants of the other FSBs, and that instead of cloning the plan, we disable dwell time via inheritance:

https://github.com/TheThingsNetwork/lorawan-frequency-plans/blob/9313b1ac0262da74f4f23f9e87aaa1234c468697/frequency-plans.yml#L280-L286

In this case you just inherit the original plan (using base-id) and then extend it with disable_dwell_time.yml.

johanstokking commented 1 year ago

I am inclined to propose that we also introduce the NDT variants of the other FSBs

We'll get a lot of plans then, right?

I'm almost inclined to take a step back and see if we should split channel plans (frequencies) from regulations (max EIRP, dwell time, duty cycle). I believe we're mentally preparing for a refactoring of the frequency plan handling anyway.

I agree to use https://github.com/TheThingsNetwork/lorawan-frequency-plans/blob/master/disable_dwell_time.yml anyhow, regardless of how many FSBs we support. @EduardoPfeifer does BR allow all AU915 defined channels?

adriansmares commented 1 year ago

We'll get a lot of plans then, right?

We already have 14 AS_923 variants, but using inheritance they are very easy to maintain in that regard.

My plan for https://github.com/TheThingsNetwork/lorawan-frequency-plans/issues/38 is to mark the base plans (for which the dwell time is 'unknown'/'default') as deprecated, such that the UI stops them from rendering in the plans list unless you had it pre-selected. Then you would only see 16 plans (8 with DT and 8 without DT).

Also by marking the _TTN or at least Used by TTN variants as endorsed (https://github.com/TheThingsNetwork/lorawan-frequency-plans/issues/51), we can make selection easier - you only see the endorsed plans, and a button to load the rest if none of them are applicable. Then you would see only two plans at most (and if we make the endorsement depend on the country, even only 1).

I will re-write the refactoring issue with the ideas that we've been circulating for a while (separating end device from gateway plans, adding LR-FHSS support, endorsement and depreciation), but I don't think that adding these plans is bad necessarily. They can be there - it's just that we need to filter out more on what do we show / not show to the user when he has to make a choice.

EduardoPfeifer commented 1 year ago

@EduardoPfeifer does BR allow all AU915 defined channels?

Yes, starting form 915 MHz to 928 MHz. The most common sub-band (approximately 90%) is the FSB 1 (915.2 MHz .. 916.6 MHz).