A few more pics.
“LBT” = Listen-before-talk?
The module in the FCC documents looks different. Here is the actual concentrator “under the hood” . There is an ICE40 FPGA in the TX path of radio A.
Probably yes…note the additional SX1276 - probably used for the ‘Listen’
wow… smooth install in 5 minutes
it just… works
Discovered today: If the TIG is powered by USB-C and not by 230V wallplug, it keeps cool.
it doesn’t need the AC-DC part…
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
Hi.
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
Thanks.
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.
maybe they are numbered in a different way in each concentrator
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 …