Maybe a stuped question, but I tried to search it in this forum and on the internet, but couldn’t find it anywhere.
In the examples of matthijskooijman (ttn-abp and ttn-otaa) and Ed Smallenburg (ESP_LoRa_tracker) different methods are used to setup a frequency plan.
ttn-abp: in setup a whole frequency plan with 9 channels.
ttn-otaa: no frequency settings at all.
ESP_LoRa_tracker: in setup only one channel (at 868.1MHz).
Who can tell me (or where can I find it) who and where makes the choise where the transmit frequencies are determined? Is it the TTN-server, the gateway or LMiC? Or the application itself?
The node determines when and on which frequency it sends. The network can support it in some cases.
For ABP you will need to set all parameters in your application on the node, including frequencies and RX2 data rate. OTAA takes care of this for you.
A node with just one frequency is probably used in combination with a one channel ‘gateway’. These gateways are not compliant and can only receive data on one channel and with one data rate. A node must match the these setting for the gateway to be able to receive the data.
The best setting for any node is OTAA. ABP is the next best solution. One channel nodes should be avoided because of the (ab)use of a single frequency.
Hello Jac,
Thanks for the respons. In the mean time I have found and read a lot of information in the “one channel gateway’s” topics. Is there somewhere documentation how LMIC works (as a aflowchart)? There is still one question, maybe you can answere that. In ABP you define the frequency plan (one frequency for a one channel gateway or a channel list if you want to use frequency hopping) in your setup, LMIC takes a frequency randomly. But where can I find the frequency plan setup for OTAA?
Regards…
LoRaWAN protocol v1.0.2 is, I think, the current LoRaWAN protocol version used by TTN. When a device sends an uplink “join request” using OTAA, the resulting downlink “join accepted” message includes a MAC command to configure the additional channels. With ABP there is no join request and join accepted exchange so there’s no MAC command to set the channels.
Thanks for all the answers and links, it starts to become clear now. I wonder there is no (?) document for IoT-starters, where the concept of LoRaWAN and TTN is explained in a popular scientific way. Of course you can start using LMIC blindly, but one day you are curious how it really works.
Regards…
I read a lot of stuff, but the only question for me stays, when you are using OTAA, why you can’t use the same frequensy plan (programmed on the node) as with ABP. You need a lot of transmission time for the MAC commands to ad more frequencies to the frequency plan. Is it, because you need to change your frequency plan if you are on the move?
For OTAA there is no need to program the channel plan apart from the required three EU868 channels (for EU868).
The specification for EU868 does not take into account you programming the channel plan. During join you will get the channels anyway, so programming them yourself does not save any airtime. And programming RX2 to anything but SF12 will result in not receiving the OTAA response for any request transmitted at speeds SF9 and higher.
Fixing the channel plan is a bad idea anyway. Recommendation is for a node to rejoin periodically/upon request from the application to allow for changes a channel plan (for instance KPN expanded their channel plan from 8 to 16 channels).
Hello Jac,
So it’s part of the join procedure. During an ABP session there is no join procedure, su you have to init your fequency plan in your application. That means that of you travel with ABP to a different country with a different frequency plan, you get problems. Aha… so always start with OTAA and then (if you have the frequency plan) switch to ABP? Last question (): When you shut down (power of the node, also the tranciever) after an OTAA session, and go further with ABP you lost your frequency plan from OTAA?
Thanks for your explanation, regards…
There might not be a need to switch to ABP depending on your implementation and device. Some devices stay powered in a very low usage mode and keep the Information they received during OTAA join in memory.
Some like the RN2483 allow saving the information and require ABP join after reset/power cycle.
Whether the device saves the frequency plan or not depends on the software stack used. Microchip saves it with all other variables, other stacks might as well. There is no generic answer to that question. Last time I checked LMIC did not save anything (not even the counters) so it required an OTAA join each time (which is a bad idea due to nonce collisions).
): When you shut down (power of the node, also the tranciever) after an OTAA session, and go further with ABP you lost your frequency plan from OTAA?