When switched to OTAA- SF,CHs not func as programmed

Hi Everyone,
I have a little problem after changing to OTAA. Please someone tell why

  • Node- Heltec wireless shell+LMIC library+OTAA method

  • GW- Heltec mini gateway

       // TTN uses SF9 for its RX2 window.
          LMIC.dn2Dr = DR_SF9;
    
          LMIC_setLinkCheckMode(0);
    
          // Set data rate and transmit power for uplink
          LMIC_setDrTxpow(DR_SF10,20);
    
      // Start job (sending automatically starts OTAA too)
      do_send(&sendjob);
    
  1. I have set the SF to (7,8,9,10), but the node transmit only at SF12(when seen in console).

     #if defined(CFG_in866)
             LMIC_enableChannel(0);
             LMIC_disableChannel(1);
             LMIC_disableChannel(2);
          #endif
    
  2. I have enabled only one channel,but messages are sent at every 3 default channels.

  3. I had problem with timing of messages and I have corrected it with this lines

LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
but why MAX_CLOCK_ERROR multiplied with 1, many have used 5.

Rest of the other are working good.
Thanks
Ajay

You should not be trying to restrict the channels used by LMiC, the proper set should come from your regional configuration, apparently IN866. (Exception would be in the US where we have multiple 8-channel banks, and do want to restrict joins to the second bank for which TTN gateways are actually configured).

/// TTN uses SF9 for its RX2 window.
LMIC.dn2Dr = DR_SF9;

That’s true for TTN Europe, is it also true in India? It’s also not clear that even in Europe it would be in effect for a join request, as the first opportunity for the network to inform the node of that fact would only occur when it has joined. More generally, although the frequencies are similar, you cannot mix and match here, LoRaWAN regional parameters include a lot of rules for interaction beyond simply frequency

LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
but why MAX_CLOCK_ERROR multiplied with 1, many have used 5.

Not clear what you are asking here, but improper timing of the RX windows is indeed often a problem, and just increasing this setting may not be a solution. People have particularly been having issues with ESP32 based hardware when LMiC is running on top of an Arduino layer.

2 Likes

True for Europe but only after joining the network. OTAA wil take care of this setting.
It is very clear (I checked the code) that it is not applicable for the join request. Response for a join request in RX2 is SF12.

3 Likes