Does lora.remove_channel only remove uplink channels?

[GregS]

I'm trying to understand the the channel configuration for TTN Australia, and I have a simple question: does the lora.remove_channel command only remove uplink channels? I'm finding it difficult to fully understand the channel mapping mechanism. I have tried looking at the code, but it's not commented well enough for me, as a beginner.
The API reference simply says that remove_channel removes the channel at the given index, but what happens if there are an uplink and a downlink channel with the same index?

[GregS]

Doh! I think I know what's going on - I am simply too far away from a gateway, and the only way I can get a connection is to violate the minimum data rate spec for join requests (which is 2 for Australia).

[GregS]

Sure enough, when I get closer to a gateway, it works without specifying dr=0.

[GregS]

@GregS I've got it to work. (using the proper join code - i.e - by simply removing all channels except 8-15 & 65).

All I had to do was add a dr=0 to the join request.

Should I have had to do that?

Could it be that if I had waited long enough, it would have automatically tried with dr=0?

I don't have my own gateway, so I could be a long way from my nearest one. I am indeed seeing low RSSI's.

[GregS]

@jcaron Thanks. (and indeed those data rates that you observed in the source are the ones I tried, just to see whether the join would still work - it did. I'm glad that I am correctly interpreting the spec)
It has been suggested in another thread (by someone else) to add a function to get the current channel definitions. It does seem like it would be useful in situations like this.

[jcaron]

@GregS There could be a bug in the definition of the channels in the firmware, though that would seem surprising given that the relevant code comes directly from Semtech IIRC.

A quick glance through the source seems to indicate correct default frequencies, though there's a difference in the min/max data rates used. The source you linked to says 0-3 for the 125 kHz channels and 4 for the 500 kHz channel. The firmware source says 0-5 and 6 respectively, which matches the LoRaWAN spec.

It would probably be interesting to add some debug info to see what frequencies and data rates are actually used in each case.

[GregS]

@jcaron again - simply removing the unused channels (i.e - all channels EXCEPT subband 2) does not work. I know it should work, but it does not. I have to manually define the channels, just like that 3 year old code does. If there was something wrong with the TTN gateway, why does manually defining the channels work? The manually defined channels match the TTN Australia recommended plan. (I also changed the data rates to what I now believe are the correct rates - it still works).
It appears to me that for some reason, region=LoRa.AU915 simply isn't working.
Note: I'm using a LoPy 1, if it makes any difference. (I see that the next firmware release will drop support)

[jcaron]

@GregS I’m not in the AU region, so I can’t say what works or doesn’t. There seems to be lots of problems with TTN there so I wonder if there’s not some kind of mismatch somewhere.

If TTN gateways actually listen on the channels listed in their frequency plan, then adding the uplink channels is not only not necessary but counterproductive as it means join requests can be sent on channels gateways shouldn’t be listening on.

The ranges in that code are indeed off by one (Python ranges are start-inclusive and end-exclusive). Just adding channels 8 to 15 and 65, which are “sub-band 2”, or actually even just not removing them and removing all the others, should be enough.

Remember that this should only have an influence on the join process. The network should send the actual channels to use after the join (don’t remember if that’s in the join accept or in a later MAC command though — I suspect the former, too lazy to check right now).

[GregS]

@jcaron Thanks again - all clear. Just btw, I think part of the reason for my confusion is this (rather old) code, which, after deleting all the channels, in addition to defining the uplinks, it also adds the downlink channels back. The code actually works, but it also keeps working if I remove the downlink definitions:
https://www.gaggl.com/2017/05/connecting-your-lopy-to-the-things-network-in-australia/
I'm going to start another thread. When I initialise Lora with region=LoRa.AU915, and simply remove the unused channels, it never joins. (I don't see any join request at all).
When I use the linked code, it works. (I mentioned this in another thread recently too)
(btw, I think that code has some off-by-one range errors - it keeps working when I use what I think are the correct channel ranges)

[jcaron]

@GregS you cannot explicitly remove a downlink channel.

Whenever your device sends something (on one of the configured uplink channels), there will be two short receive windows during which your device will listen for downlinks.

In each of those windows, the channel to use is dictated by the channel which was used for the uplink (in RX1) or fixed (in RX2).

I recommend you read the LoRaWAN spec, especially the regional parameters, it should help you understand how downlinks work.

So to answer your question directly, no, remove_channel will only remove an uplink channel. But this will indirectly change the downlink channels that are used, but those are not under your control, they are under the control of the network.

Edit

To make things clearer, the regional parameters doc says:

2.8.7 AU915-928 Receive windows

The RX1 receive channel is a function of the upstream channel used to initiate the data exchange. The RX1 receive channel can be determined as follows.

• RX1 Channel Number = Transmit Channel Number modulo 8

The RX1 window data rate depends on the transmit data rate (see Table 22 below).
The RX2 (second receive window) settings uses a fixed data rate and frequency. Default parameters are 923.3 MHz / DR8

So if you send on uplink channel 51, the device with listen on downlink channel 3 in RX1, and a fixed frequency (923.3 MHz) in RX2 (unless set differently by the network). If the next uplink is on channel 52, the device will listen on downlink channel 4 and then the same fixed frequency as before.

If you keep a range of 8 consecutive uplink channels (which is the usual setting + one of the larger channels), each of the 8 downlink channels can be used.

[GregS]

@jcaron Thanks. However, back to my actual question - does remove_channel only remove uplink channels? For example, if I initialise Lora with my region (AU915), there will be an uplink channel zero (0), and also a downlink channel(0). Does issuing the remove_channel command only remove the uplink channel?
I'm not ignoring your advice - I'm simply trying to understand exactly what the remove_channel command does. It's a bit confusing how add_channel and remove_channel don't have a "direction" parameter.

[jcaron]

@GregS as far as I know, you don’t need to remove any downlink channels.

The reason one may need to remove uplink channels is because the device may send on any of those which are configured. Since gateways in the channel-rich regions such as the US or Australia only listen on a subset of all possible channels, it’s useful to restrict those the device sends on (though it’s only required for the join request: after that the network should tell the device what channels to use).

In theory it’s not even a full requirement, since the device will send on a different channel on each retry it I’ll end up sending on one the gateway listens on, it’ll just take longer, which is especially annoying during development and testing.

For downlinks, the rules are different: the device always listens only on one specific channel (and data rate) at a time, which is defined by the channel and DR used for the uplink and/or the RX window, along with some settings sent by the network. The exact rules are defined in the LoRaWAN specs and regional parameters.

So you don’t need to define those channels, they are implicitly defined by the uplink channels in use.