Where do I find a list of the changes that were implemented by TTN 5 days ago?
I have two Raspberry PI based Single Packet forwarders that were both running reliably and both stopped being seen by the TTN Network. These gateways are 15km apart and stopped being seen within one minute of each other. Neither status messages or data from their nodes are being received on TTN.
eui-b827ebffff5efda5 was last seen at 3/17/2017 06:24:40
eui-b827ebffffbebbd8 was last seen at 3/17/2017 06:24:36
I can see via diagnostics on the gateways and nodes that they all still working correctly. Something has obviously changed on the TTN back-end.
htdvisser [11:18 AM]
And regarding the online/offline, we indeed stopped showing gateways as online if they canât do downlink
htdvisser [11:30 AM]
Weâre becoming more mature and want to deliver good and predictable quality. If downlink messages âdisappearâ because a gateway canât handle them properly, this gateway does not belong in a âproductionâ environment
I also have a single channel gatway that stopped working today.
Initially I used the ip behind dns ârouter.eu.thethings.networkâ, but a few weeks ago that stopped for me.
After some reading here at the forum I ended up with 40.114.249.243 which as been working until yesterday.
Back again with â52.169.76.203â but not picking up from the gateway console in TTN.
I can confirm, two âold-typeâ gateways using ârouter.eu.thethings.networkâ are also reported down by the TTN console. I think we did not change and/or break anything.
In the console both are reported as not connected with a âNOC connection time-outâ error see screen dump.
Logging on gateways seems fine with a PUSH /PULL ACK received see:
Mar 23 22:00:55 gw1 ttn-gateway[715]: JSON up: {"stat":{"time":"2017-03-23 20:59:55 GMT","rxnb":1,"rxok":1,"rxfw":1,"ackr":100.0,"dwnb":0,"txnb":0}}
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: [up] PUSH_ACK received in 47 ms
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: [down] PULL_ACK received in 40 ms
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: Disabling GPS mode for concentrator's counter...
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: host/sx1301 time offset=(1490299095s:858225”s) - drift=-43”s
Mar 23 22:00:55 gw1 ttn-gateway[715]: INFO: Enabling GPS mode for concentrator's counter.
Mar 23 22:00:55 gw1 ttn-gateway[715]: ##### 2017-03-23 21:00:25 GMT #####
Hope this helps the âback-endâ people. (if not let me know)
What does âdownlink capabilityâ mean?
Is it sufficient to have a gateway with the âfullâ software stack and multi-channel capabilities (vs. experimental single-channel gateway)
or
is it just an issue that the gateway cannot be connected from TTN over UDP port 1700 ?
Downlink is the capability to send data from TTN back-end to a node. It requires the gateway to connect to port 1700, accept downlink data and send the data with the parameters (frequency and datarate) specified by the TTN back-end.
Multi-channel gateways with a packet forwarder based on the Semtech packet forwarder (which include at least basic-pkt-fwd, gps-pkt-fwd, poly-pkt-fwd and mp-pkt-fwd) with the right configurations meet this requirement. Other software might be suitable as well, however the single channel gateway with uplink only software (the default used for many single channel gateways) does not meet the requirements.
I donât think the ânode connects to port 1700â, as the node connects to the gateway using LoRaWAN protocol ant not TCP/IP.
I think you mean the TTN backend-end connects to the gateway via UDP port 1700, which then forwards the downlink data to the node as soon it connects to the gateway (LoRaWAN) the next time.
Things seem to be fixed. All gateways are online again and data is flowing again.
The TTN backend move from staging software/servers to production servers required us to recreate our Lora devices in the console which BTW is excellent!
Also the updated TTN Arduino libraries version 2.4.0 required some code rework on our Nano boards. Nothing major, and we got my first node up and running using OTA.
So, just to clear things up: TTN no longer supports the DIY single channel gateways based on
Is this correct? Can someone please give a definite answer?
I have setup an RPI-based gateway, have registered it on TTN but shows up as not connected. The gateway sends status reports in the form of udp packets properly as I am able to catch them using a custom udp sink.
@networthings it is supported as uplink, but it shows as ânot connectedâ as that Single Channel Gateway implementation does not support downlink. Itâs just not capable enough to include it as connected gateway; we canât do joins or acks from the network.
Weâre working towards a reference design where SCGs use a dedicated frequency (not the default join channels) and support downlink. Those will show up as connected, probably indicating itâs a SCG. Uplink-only SCGs are deprecated and not supported.
Another issue with that implementation is that a) it uses a hard coded IP address and b) itâs the old croft IP address.
Does it mean that I should be able to see the traffic (e.g., status reports) from the gateway on TTN (the server IP is set to the proper router), or this will not work at all? In my case, I do not see anything on TTN.
@johan Would the following be correct for a single_channel gw: on the console it will no longer show time since âlast seenâ but despite that I should be able to see upllink traffic messages? For me that is not the case, I see no traffic anylonger.
