India bandplan doesn't work on Conduit for ul ch#0/1

[terrillmoore]

Testing in India by TTN Chennai/MCCI revealed that the Conduit was not fully functional: 1) uplink on ch#2 and downlink during the second RX slot worked 2) uplink on ch#0 and ch#1 didn't work.

Investigation and experimentation led us to believe that the intermediate frequency offsets for channel 0 and 1 were too large (> 400kHz). We contacted Multi-Tech who provided their band plan for India. We swapped their channel 2 and 3 (so that we have 0/1/2 as per the LoRaWAN regional spec) and disabled channels above channel 2. (It would be nice to have the join accept enable these channels; but that's probably a change request; this is just a problem fix).

Will submit a pull request momentarily with the file that works for us.

[jpmeijers]

I don't understand what you mean by "the join accept enable these channels <above channel 2>". The join accept is transmitted by the gateway on whatever frequency the network told it to, as long as it is between the "tx_freq_min": 865000000, and "tx_freq_max": 867000000. Do you want the packet forwarder on the gateway to dynamically update its configuration depending on join accepts forwarded by it? This won't work as join accepts are encrypted. But with recent packet forwarders a simple restart would fetch the latest global_conf from TTN, enabling whatever TTN supports.

To enable any other uplink channels except the default 3, we as TTN should decide on the appropriate frequency. A couple of months ago we tried hard to fit 8 channels (+1 FSK +1 250kHz SF7) into the available spectrum in India. The space is really small and congested with RFID. We decided to stick with only the three default LoRaWAN channels for now.

I'll check the global_conf you got from Multitech to see where they defined the extra channels. Perhaps they found a good way to fit in extra channels.

[terrillmoore]

"the join accept enable these channels" -- my understanding is that the Join Accept message can also carry (perhaps as a MAC message) information to enable the additional channels at the device. If we found the Multi-Tech channel plan to be acceptable, (as you say), we could staticly enable the additional channels at the gateway, and tell the devices that they can use the additional channels for data transmission as part of the Join handshake.

Apologies for confusion.

I wasn't meaning to suggest that the packet forwarder should change configuration dynamically.

[jpmeijers]

What you say about the join accept enabling additional channels are already done in other regions. As far as I know this will also be the case for India when we change the frequency plan.

I just calculated and wrote down all the frequencies from the config file. The first three are indeed correct. I'll have a look at the other 7 and where they fit in.

It is a good catch of you that the IF's for the channels were too big. I never new the limit was 400kHz. Do you perhaps have any source for this number? Perhaps it is documented in the sx1301 datasheet, which I have not yet laid my eyes on.

[terrillmoore]

The 400kHz limit... I just guessed, based at looking at other bandplans, and observing that the one working channel was within 400 kHz. Then we tried our own plan, still only using one radio of the two, centered at channel 1 more or less. Channel 1 worked, channel 0 and channel 2 did not -- they were more than 400kHz away. Then I got MultiTech's plan, which arranges the IFs so that no channel is more than 400kHz away from the base. Hence my guess.

Like you, I've not seen the SX1301 datasheet, so I really have no idea what the true restrictions are.

[johanstokking]

Closed by #19

[jithinsisaac]

Thanks a million guys for this 400kHz bandwidth information.. was scratching my head for hours to find why my extra channels in the India band were not working! May be I should post the final IFs for atleast 8 frequencies for enthusiasts from India..