The 2nd sub-band would be the second group of 8 channels up from the defined starting point. You can do the math to figure out where they are, and use the center frequencies and offset in the config files to verify that matches - from a quick glance the file you look seems at least plausible, and it is unclear why something that wasn’t right would be published.
@kersing, @cslorabox one more question: the standard says that join requests should be done alternatively on a random 125 kHz channel amongst the 64 channels and a random 500 kHz channel amongst the 8 (upstream) channels.
I guess where the 125 KHz channels are concerned, only those 8 channels are used, and what about those 8 500 KHz upstream channels, are they also used by TTN for OTAA purposes?
If you take a look at the configuration you’ll see a gateway is instructed to listen to 8 channels multi SF, all 125 kHz. There is no multi SF 500 kHz channel in the configuration (just on fixed at SF8) so no, the 500 kHz channels are not available for OTAA.
The actual spec requirement seems to be given in the specific regional parameters.
One key point is that when usage of a 500 KHz channel is specified, the specific datarate is also specified, because Semtech wrote the spec and their hardware cannot even do multi-SF on the 500 KHz channel. The specified datarate should be the one in that region’s definitions that maps to what the hardware can do.
Another is that some regions like EU868 do not even specify that a 500 KHz channel should be used in the joint attempts.
As for what TTN would do if a node transmitted a join request on the configured 500 KHz channel in a region where that is part of the spec… I don’t know. Hopefully if the gateway received it and forwarded it, a join accept would be sent in reply on the proper frequency and downlink SF.
It’s somewhat moot unless a node actually does it, if you have one which can in an appropriate region you might try it and find out. I will mention though that historically umodified LMiC will fatally assert() if it finds no 500 KHz uplink channel configured, which is probably not desired behavior in the field
That will certainly work, but the suggestion that the 500 KHz channels cannot be used is based on a mistaken idea - end devices are only supposed to use the single spreading factor that the SX130x hardware is capable of on the 500 KHz uplink channel, so the fact that it doesn’t support multi-sf on that is irrelevant.
The open question is if the TTN servers could correctly respond to a properly encoded join request on the supported SF on the single 500 KHz channel which a gateway can be, and often is, configured to support.
No one has answered that yet.
But yes, you can probably ignore this - definitely if your region does not even specify the use of a 500 KHz channel in the join pattern, and even if it is specified you can ignore it at the cost of having something that works but does not fully comply with the spec. Remember, the lorawan spec is an industry standard, not a law (although it is informed by some).
A join request at SF8, 917.5 MHz should work, so just one of the 500 kHz frequencies, not all 8 of them as the hardware will not be able to handle that.
You can use OTAA to avoid hard-coding the TTN subset. The join will take a bit longer, but once joined the network can (should) filter out the unused channels with a MAC command.
Last I checked TTN did this for the US mode. At the time it wasn’t doing it for the AU mode but perhaps that has changed.
@cjhdev Yes, but that would be quite inefficient. The standard says the nodes should support all 64 channels out of the box, so if it chooses a random channel for a join request, only one in eight attempts reaches a channel which is in fact used. I think I’d rather limit the channel list in the node and save a bit of battery life.
