Changing Data Rate on TTN stack (Multicast)

Hi everyone

I have a Lopy4 as a LoRa end node connected to the open TTN Stack v3.11.3 and being configured as multicast on the TTN stack. The LoPy operates in class C mode using ABP/multicast activation. When I schedule a downlink to the LoPy it works fine when operating in DR=0 but with other DR like DR1, DR2, etc. the data is not received by the LoPy. Does anyone know what could be the cause of this behavior. (The downlink messages were schedule via MQTT client)

What I have the noticed is that the TTN stack gateway does the transmission on SF12 (DR0) and I guess that might be a reason why the LoPy only receives data only on DR0. If what I think is right, how can I make TTN stack to transmit data using other spreading factors/data rate not only with SF12.



Have you set the node to use the ‘Europe 863-870 MHz (SF9 for RX2 - recommend)’ plan? If not only SF12 will be available because Class C nodes listen to RX2 frequency and spreading factor all the time apart from the RX1 window just after the node transmits.

Thanks @kersing, both gateway and the end device were set to use Europe 863-870 MHz (SF9 for RX2 - recommend). I still don’t know where might the issue of not receiving from SF9


The LoPy uses these channels
Capture 3

Your LoPy setup suggests you are not using a full gateway. It that right?

Thank you very much @kersing I was able to receive a downlink message on SF9

Is it possible for me to instruct the TTN in my application to send payload using other DRs/SFs or I am only restricted to send the application payload on DR0/SF12 and DR3/SF9.

You should not be instructing you device to use a particular DR, it should negotiate the best rate with the network server.

Which is why @kersing asked if you were using a full gateway. So perhaps you could help us out and tell us what gateway you are using?

I am using a gateway based on RAK831 and a Raspberry Pi model 3 (running TTN-gateway: GitHub - ttn-zh/ic880a-gateway: Reference setup for iC880a gateways running The Things Network)

Then if you don’t override the device settings, it should work as designed.

DR0 & DR1 are not permitted for normal operation.

SF9 is used for Rx2 downlinks.

But mostly, you should let the network & the device find the best DR for its situation.

Then your python code should not set 3 channels to the same frequency and the 4th to an illegal (for uplink) one. Create code that works on all 8 EU868 channels for class A first (including downlinks in RX2) and then switch to class C. What you are currently doing doesn’t adhere to the LoRaWAN specification.

@descartes and @kersing thank you very much for your help I will also make changes on my code.