Closed Doom4535 closed 3 years ago
Doom4535
commented
4 years ago Referencing issue: https://github.com/manuelbl/ttn-esp32/issues/28
I'm leaving this as a draft right now as I'd like to consider having it detect the configured region and default to a TTN sub-band in that region (since the naming indicates that it targets TTN).
manuelbl
commented
4 years ago Thanks for the contribution. It would be nice if it worked out of the box for the US.
I'll have a look at it. As I'm busy with other project, it might take a while. I hope to catch up soon.
manuelbl
commented
3 years ago Can you provide a code example how you would use this in a US network? Are you working with TTN or some other network? Are you using ADR? Shouldn't the join message configure the subband / channels?
Doom4535
commented
3 years ago @manuelbl The intent with this was to use something like the following after instantiating the ttn object:
ttn.setAdrMode( true );
ttn.selectSubBand( 1 );I am not currently using this with TTN, I'm using Chirpstack on a Raspberry Pi with a RAK board. ADR is enabled (and does appear to work). There is a possiblity that I have an error in my Chirpstack config. The issues I'm having occur can be broken into two pieces.
Adding the calls to LMIC_selectSubBand() solved my pairing and packet loss issues; however, I have discovered an issue with the approach used in this pull request, as LMIC_selectSubBand() is not defined in the EU plans, so blindly including it in the ttn object definition causes problems when the code is built for other regions (as it is apparently not a mandatory function). Additionally, I have since become aware of an issue with this where the library does not realize that it it successfully transmitted the message and continues to spam empty message uplinks (more on this below).
I believe the approach I laid out with this branch is not the best method (unless someone wants to go all the way and expose something like ttn.lmic; however, I'm not sure how to wrap the LMIC C object as a CPP class that can be exposed easily).
The good news is, I think that there is a simpler method of solving this issue, where a couple of parameters are added to the Kconfig and ttn object initialization. This is a fairly simple modification that allows the code to easily be ported between regions; however, I am having issues with the underlying LMIC_selectSubBand() function call.
LMIC_selectSubBand()I'm going to close this pull request and leave development tied to issue https://github.com/manuelbl/ttn-esp32/issues/28, as it looks like it may take more development than I had originally thought.
This resolves an issue where the library hid the underlying LMIC controls from the end user, and defaulted to enabling all the LoRaWAN channels. This is an issue as not all gateways support the full LoRaWAN band plan, and this will cause a large packet loss when communicating with such gateways (effectively
(total_region_channels - supported_channels) / total_region_channels). This is very likely to be encounter during normal use, as the library indicates it is targeting The Things Network (TTN), which explicitly does not use the full LoRaWAN allocated spectrum.LoRaWAN bandplan: https://lora-alliance.org/sites/default/files/2018-04/lorawantm_regional_parameters_v1.1rb_-_final.pdf#page=15 TTN bandplan: https://www.thethingsnetwork.org/docs/lorawan/frequency-plans.html.