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.
It requires the node to connect to port 1700
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.
You are right, I corrected my message.
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.
Kinds regards,
Paul.
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.
Ok. Thanks for the clarification.
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.
@networthings status messages are not part of gateway traffic. You should see uplink messages.
Now that Croft has been obsolete and down for a long time, you should use the right router. Traffic to that IP address is going nowhere.
Best is to use the DNS name, but for testing it’s fine to use an IP address. See New addresses for cloud services: update your gateways
@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.
Are you using the right IP address?
Hint: it’s not the one in the code
“IP” and “DNS name” no longer work ( “router.eu.thethings.network” / “52.169.76.203” )
All was working fine a month ago.
It seems that single channel gateway support is completely broken. I am in Canada and use the following router in my gateway:
“13.66.213.36” // The Things Network: router.us.thethings.network
I see all node messages on my gateway. I can forward them successfully to my own custom-built network server. But when I check TTN, it does not show anything.
What no longer works: Raspberry Pi based Single Channel Gateways based on this code: https://github.com/tftelkamp/single_chan_pkt_fwd
Messages received by these gateways and forwarded to TTN no longer appear on TTN and the gateways no longer appear on the TTN Map.
What does work: ESP8266 based Single Channel Gateways built on this code: https://github.com/things4u/ESP-1ch-Gateway-v4.0
These gateway are seen by TTN, appear on the TTN Map and the data forwarded by these gateways appear on TTN. I did have to trivially modify the v4.0 code to work in the US
I am using a SCG based on this:
And it also seems not to be working. I can see the uplink data forwarded to my own server through a http integration. And I can also see data coming in the TTN console interface. I can also see there that the network server sends an ack back to the node when the data is confirmed, although almost everytime my LMIC-Arduino node gets an invalid downlink (I am correcting for the clock accuracy error).
However the gateway shows as not connected with a NOC connection timed out.
I thought that a SCG based on this code supported downlink messages.
The issue here is that some single-channel forwarders (such as the tftelkamp version) do not support downlink messages. As we mostly focus our development on real gateways (multi channel with downlink support), single-channel-no-downlink gateways are easily forgotten.
We recently implemented an optimization in our backend that connects gateway streams when the gateway is active, and disconnect when the gateway becomes inactive. As some gateways don’t see much traffic, we can’t base this “state” on the uplink messages that are received from those gateways. However, all forwarders (except these single-channel-no-downlink ones) ping the server every 5 seconds, so we decided to use these pings to determine whether the gateway is active or not.
As a result of this choice, forwarders that don’t “ping” for downlink messages are assumed “offline”, and this results in the uplink traffic received from these gateways is not being handled correctly. I’m working on a solution for this.
The problem that @asier mentions is unrelated. For some reason the console does not correctly reconnect to the NOC when the connection breaks. This results in the “NOC connection timed out” message, message counters being 0 and traffic not showing in the “Traffic” view of the console. Messages should still be delivered to applications, because that does not need the NOC.
Thank you! It seems like the gateway is now connected. I guess it needed some time? Anyway, everything is working as before now.
Like @asier I’m also using https://github.com/JaapBraam/LoRaWanGateway. It was stable for some weeks but about 10 days ago began intermittently showing as “not seen for X hours”, and sometimes “Could not subscribe to gateway status NOC connection timeout” in an orange banner appeared in TTN Console.
I don’t believe the HW or SW changed, before the symptoms started appearing.
Yesterday the SCG had not been seen for some hours so I re-loaded all the LoRaWAN LUA scripts into the NodeMCU. After that it was briefly seen in TTN Console, was able to pass some traffic from a Node to TTN console. But now it is again not connected.
I’m posting in case others also see a similar pattern.
Hi: Im having the same problem with the 1ch GW starting 10 days ago too that is using the standard PKT Forwarder. The GW & associated motes worked fine but now can´t be connected. The router.us.thethings.network port 1700 address respond with PKT PUSH ACK so the TTN bridge seems to work but “could not Subscribe GW Status - NOC Connection timeout” message appear as soon the GW start sending.
Neither the GW configuration or firmware version has been changed.
Have you changed any address? Are you stil support this GW?
Do you know how can I solve the issue?
I solved this by replaing the Pi with a Wemos D1 mini and the software I mentioned earlier in this thread.