Lopy4 nano-gateway TTN Server

  • I connected my lopy nano-gateway to TTN server but I receive downlink messages only on the second receive window RX2 at 6 seconds? Why is that?

  • @jg_spitfire That's the way TTN decided to send the downlink message in the RX2 node. The LoRa spec says:
    The RX2 receive window uses a fixed frequency and data rate. The default parameters are 869.525 MHz / DR0 (SF12, 125 kHz)
    Using SF9 is told by the TTN server to the node with the OTAA join accept message.

  • @robert-hh I thought that the RX2 window always would be SF9 (fixed), if this is the case and if the RX1 uplink is defined by the node so why would I need to setup the SF of the RX windows?


  • @jg_spitfire Somewhere in the LoRaWan specs. The node has to know which frquencies to use for the RX1 and RX2 window. That is set in a downlink message from the server. For RX1, the parameters of the uplink message are used. Since ABP needs no message exchange prior to an uplink, this set-up may not have been arranged at the time of sending, and the node may listen with the wrong parameters for a possible set-up downlink.

  • @robert-hh said in Lopy4 nano-gateway TTN Server:

    but a problem with ABP join, because the node is not informed.

    Hi, could you tell me where did you read that?, thanks

  • @edfj76 utime.ticks_cpu() is suffciently precise, since it is derived from the CPU crystal. It was the previous implementation of ticks_us(), which was derived from the RTC clock, which runs from an internal oscillator, if no RTC crystal is attached. But for the actual firmware this is not the reason. The problem is, that the scheduler of MicroPython does not ensure, that a task gets active at a certain time. The timing requirements of LoRa are very rigid. At SF12, the downlink message must hit a time window of about 10 ms with 4 ms tolerance. The scheduler has a jitter of a few ms. Therefore, the nanogateway typically sends the downlink too late, when the node already stopped listening. That is less a problem with slower data rates. If you go for SF9/DR3, then the receive window is about 30 ms long, at SF12/DR0 it's 200 ms.

    • update the firmware to the latest version for both the gateway AND the node.
    • if you have the nanogateway open, you can see when it sends a dowlink message. If you do not see that, there is a problem with the configuration of the TTN server for the gateway or the device
    • If you see downlink messages at the gateway but still cannot join, try to use higher SF values & lower DR.
    • I tried to set up a gateway software variant which aims at compensating the delay. It is here: https://github.com/robert-hh/pycom-libraries/tree/nanogateway/examples/lorawan-nano-gateway
    • If you have the choice, use a LoPy1 for the gateway. It is more responsive. I have a LoPy1 running as gateway since months without problems.
    • Last not least, you can also use ABP join, which allows to send uplink messages even if the downlink path is unreliable.

    P.S.: If you want to use LoRa reliably, get a full service gateway. Raspberry Pi based models are the IC880a from ICMP or the RAK831. They are not cheap, but meet the full spec. Or look at the offering at the TTN web site.

  • @robert-hh Thank you. I was trying the nano-gateway with a Lopy4 as node. It didn't work (not join OTAA). I thought was for the frequency on the second window different from 868,1. I also red a post when it was said that mounting a cristal oscillator on the board improve the timing of downlink. It's just enough to mount it on the Lopy4, what else can I have to do to have utime.ticks_cpu() more precise?

  • @edfj76 No, it can only listen to a single frequency, but can change that on the fly. So for the RX1 window it may listen on 868.1 MHz, and for the RX2 window it will listen at 869.525 MHz.

  • Thank you @robert-hh. There are lot of things that i need to understand. So the node can listen to more frequency, if the server choose for example the second window it can listen also to 869.525 (and 868.1)?

  • @edfj76 The device has several channels, which in the pycom examples are all set to the same frequency. But you may also set it to different inital frequancies. The TTN server may instruct the node to use other frequencies from the set. This is a problem when using a Pycom device as gateway, because these can only listen to a single frequency & single codeing a a time.
    The donlink message in the RX1 window uses the same frequency and coding as the uplink message, but it is up to the discretion of the sever whích RX window will be used.

  • In the node I set the frequency as unique 868,1 for trasmission. Who sets the frequency for receive? How many frequency exist for receiving? Sorry for my English. What does it mean single channel?

  • @edfj76 The RX2 window always uses a fixed frequency of 869.525 MHz. It does not matter what frequency was used by the uplink request. And if you use OTAA joinn, the accept message also tells the node to use SF9/DR3 for the reception for further downlink message. The OTAA join accept is transmitted with the default settings. TTN uses that SF9/DR3 setting to reduce the time on air. As compensation, the increase the transmission level of the gateway to 20dB. The xxPy as nanogateway may not be able to serve that.

  • I talk about a join-accept message 6 second in the second window. Is a problem if in the second window the downlink frequency is different from 868,1 Mhz with OTAA or APB? (the gateway is single channel) When I set the channel in the code for node and use only 868,1 Mhz how can receive other frequency(these frequency setting is also for receive)?

  • @jcaron I did not look into the details of TTN recently, but the last time I was trying to get the nanogateway working it was using the default values. 5 and 6 seconds for join accept and 1 and 2 seconds for standard downlink messages. The only confusing thing was, that it uses the RX2 windows with SF9 always for slow data rates (uplink SF9 and slower), which is not an issue when using OTAA join, but a problem with ABP join, because the node is not informed.

  • The actual timing of RX1 and RX2 can actually be configured by the network. Don't know what TTN uses for RXDelay. I have seen RXDelay set to 5 on another network, and that is mightily annoying as you need to keep the LoPy awake until the end of RX2, so that has a pretty bad effect on battery life.

  • @edfj76 The TTN server can decide, whether downlink messages are to be sent in the RX1 or RX2 window. The nanogateway is just doing what the TTN server tells it to do. 6 seconds is however a strange time. At low data rates SF >= 9, TTN always selects the RX2 window.
    The RX2 window is open 6 seconds after the uplink message has been sent for a join accept and 2 seconds after the uplink for other downlink messages.

Log in to reply

Pycom on Twitter