My guess is that the resistor is actually not functional, but rather just being used as a machine-installed marker of build version.
I’m also not entirely convinced that a US915 build would fail to start the concentrator with EU833 settings - it’s not like the Semtech silicon knows what the surrounding passive components are tuned for. In theory there could be an IO pin read somewhere by software or FPGA code that throws an error, but it’s not clear it is that smart.
And even in the unlikely case where the resistor is what is preventing it from trying to work on EU frequencies, just moving that wouldn’t change that all of the RF network are tuned for 915 instead of 868 - those aren’t something you can casually change without a full understanding of the design and a stock of the right parts. So even if it started, at best it would work poorly.
Getting shipped the wrong version is of course a problem; but it may not only be the wrong version, but a defective unit.
I had now the TTIG for a while and can now compare it with a RAK2245.
I realize, as many above that the TTIG is missing a lot of packets, and does not work with some of the channels. Is this problem solved ?
What is the way to update the firmware, and what is the current firmware ?
Mine is :
I too found that some packets get lost. Packets I know of because received by 2-3 gateways at distance (10-20km, not mine).
My impression, formed initially when I observed with some attention the gateway log in the console, is that the gateway is like deaf for some time after receiving a packet. This in part could be due to downlinks windows, but I did not check whether downlinks were sent too in those moments.
Interesting - a test to run could be to blast out two packets in quick succession, that aren’t actually from any recognized node (and therefore won’t generate any downlink reply) and see if they get reported as raw gateway traffic.