Maybe this have been addressed already, but I was not able to find anything. Problem:
I have multiple gateways picking up my messages, however when I look at the metadata and see the different gateways recieveing my message I see the following:
On my mini gateway (handed out at the conference) the channel always display 0, while the other gateways that picked up the message shows the “correct” channel, see attached image.
Also, I’ve seen the minigateway show SNR of +15, while the lorix1 showed -12 (highly unlikely).
the “another lorix1” is approximately at the same distance as my minigateway to this perticular node shown in image below, both of the lorix gateways are mounted outdoors ~5-10m above ground.
Gateway settings (same for all gateways):
Europe 868 MHz
ttn-router-eu
Ah, I assumed that TTN determined the channel number given a frequency, SF and bandwidth. But maybe you’re right that the gateway determines and passes the number, and TTN simply shows the number it has been given.
TTN stack V2 does not implement the new Basic Station protocol. Somewhere in between your gateway and the TTN stack there is a process running to translate the new protocol back to the ‘old’ Semtech UDP protocol. The sources of the Basic Station packet forwarder include python code for this purpose and a quick glance does not reveal any code handling the channel.
The channel number is based on the configuration. The frequencies defined in the configuration block is matched. So any gateway using a configuration with frequencies defined in a different order will report a different channel.
Note form my side on TTIG connectivity: Although the led is continous green console says disconnected for 20 hours. Laste maasge received was yesterday 13:01.
Curious to see how they will manage when TTIG sales start coming days (as being announced) and console is not working.
Here the same, they all stop working a 21 hours ago. (i got two under my view)
Maybee a Sales, marketing trick to put back online a 550 TTIG’s on the sales day
But it shall bee some thing in the centrall part off managing off these device’s. 12 days ago there was a look a like problem with only on US915 config’s
Maybe some body off TTI can inform us here (Krishna where are you )
do you really think there should be 24 / 7, highly skilled personnel available for the free of charge community network / gateway ?
realise that this is a new product and we are probably the first group in the world to test this hardware/software … sure something can go wrong (and it did) but its still an amazing product !
better communication I agreed before
just had contact with Krishna - Stack Engineer and Operations The Things Industries, and he is working on it right now. So let’s watch our consoles …
Okay, so it does not match the channel number from the LoRaWAN Regional Parameters document. (And if it should, then TTN would not have added the value to each gateway, as then it should be the same for all.) Does anyone know what’s the use of the channel number in the metadata then?
No SLA thats true. I cannot argue otherwise. Also I have no choice but to use TTN because I cannot configure the product I ourchased.
Future gateways are not free.
When I pay for a product (any) I may expect that is works. TTIG is fixed to TTN so the rule that I may expect a product to work propagates to TTN. Our so SLA does not break (Dutch) laws I expect.
When my product fails (becaus of TTN?) I may return it under Ditch law.
I have my conserns. This is food for thougt for lawyers.
W’ll see.
agree, that should be clarified in the future… you buy the hardware (TTIG) now what level of network service you may expect, will it be free for ever ect ect.
Small Update.
The issue in the US region should be resolved.
On EU, most gateways should be working. I’m adding a couple of fixes to make sure all of them are working.
Stay Tuned!
So after a long battle, the EU gateways must also be working now. If your gateway is not sending uplinks, please send message me your EUI via slack or via a direct message to me.
Reason:
As some of you might know, our V2 stack does not support the new BasicStation protocol and hence we have a temporary/experimental BasicStation-Bridge that bridges the TTIG to our V2 routers. This bridge is functional but breaks at scale which is what’s happening here). I have added some load-balancing in the backend which should keep it functional.
In the next few weeks, we will be replacing this bridge with a native, highly scalable component which will ensure that these kinds of outages don’t happen.
With regards to the delay; we do our utmost best to make sure that the network and the gateways are running without issues (regardless of SLAs). This has no other reason other than the fact that the intermediate bridge is quite difficult to work with and that this happened to be on a weekend when most of us did not have access to resources. I, myself, have spent the best part of my Sunday trying to fix this.
We do understand that these disruptions can be quite frustrating for the users and we will always do our best to keep these issues minimal.
So let’s watch our consoles …
