Yes, of course, but let’s assume that the AC/DC part is not working very efficient
I have it plugged in for half an hour… it’s not 'hot , the adapter from my internet modem and televison decoder are really hot
I did a small survey on energy consumption of the TIG:
- powered by 230V, using TIG’s wallplug: 2,9 - 3,0 Watt
- powered by 230V, using USB-C from a 5V/3A power supply: 2,3 - 2,4 Watt
Looks like the built-in power supply heats at least 25% of the drawn energy, this is not “green technology”
…but, okay, it’s less than 2€ cost per year
I agree, TTIG is a quality, well build device.
But this seems a little backend bug.
I’d say that if all gateways use the same frequency plan, then the metadata should show the same channel.
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.
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.
Looking at the Basic Station software it seems no longer to be present in the uplink data. So it probably wasn’t/isn’t useful.
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.
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.
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.
do you have to check 'Beta Updates ’ on TTIG ?
And in the UK for £60.12 including VAT:
I apologize, but I can’t find it and I’m anxious to order - is there a hard date on release (US)?
Availability from June according the RS UK