The conference indoor gateway was easily installed here (due to all usefull remarks in this thread!). Strangely enough, ttnmapper reports that my gateway was only seen on 4 channels…and this is confirmed by my experience that a number of packets is dropped. Anyone similar experiences?
That’s weird. We fixed the channel config mismatch for the US version also. We had some unrelated issues on the US bridge where users are reporting their gateways are not visible.
That is now resolved. Can you check if your gateway is still doing this?
So a small update.
Actually this is not uncommon for a new gateway, I’ve seen this before, it is how you can recognize a fresh gateway on the mapper. There is a delay for the gateway radials and channels seen.
After some time the more traffic from mappers comes in then also more channels are used by those mappers.
If not on your list yet, then please:
Is registration in TTN Console required? (Maybe the new Basic Station software gives TTN sufficient information about the frequency plan, so registration might be fully optional? I guess not, as that might work for EU868, but not for, e.g., US915 when used in Australia.)
Is there any difference if one uses an all-lowercase EUI with “eui-” prefixed, like:
…or if one ticks the “I’m using the legacy packet forwarder” checkbox and only enters the bare EUI?
What does the following mean exactly?
And I’m also quite curious how TTN is handling the Basic Station messages. Some bridge on V2, or are the devices connecting to some V3 instance? And can you tell how many devices have been installed already? (Even better yet: naming and shaming of those who did not plug it in yet, is very much appreciated. )
Finally good news.
I operate my gw (after reset) on a new location without changing anything on TTN server site.
Very important: use Chrome for connections to your gw. Firefox and Safari did not work properly. Chrome made me happy again and a new area 30 km out of Frankfurt can now be served.
Thanks for your advises towards Chrome.
That a problem!
Dont use Chrome for anything…Google/Alphabet already know too much!!!
However, RSTn line is datasheet spec’d to be 1k pulled-on, “… In all cases, a 1 k pull-up on the RSTb pin is recommended…”, so some 3mA @ 3V3 supply.
Otherwise, there’s a chance the onboard PS can be loaded to some max. 100mA because of the RSTn sinking behaviour. See Table 3.10. Absolute Maximum Ratings on page 15 of the datasheet.
So, either remove the pulldown and add 1 to 10k pull-up; or simply add a pull up of some 1k as R86, so that you form a divider with the R88-10k one.
I like this idea, Great work!
It’s on the right subband now but it occasionally likes to get stuck at the wrong DR. The node is about 3 meters from the gateway in the same room. After your latest fix, I restarted the TIG and it stayed stuck at SF10 and BW 500.
I occasionally get packets at 500 kHz and ADR isn’t bringing down the SF after 20 packets. I can see the ADR downlink being sent but the SF doesn’t change. My other gateway doesn’t go above 125 kHz when it’s running by itself.
This happens roughly every 3 times that I restart my node using only my TIG as a gateway.
This is intermittent but it requires me to restart the node and sometimes I get the right DR and ADR attempts and others it doesn’t. I never had this issue with my other gateways.
It also doesn’t coexist well with other gateways. If I start the TIG along side my other gateways my node never gets ADR downlinks from the NS.
I have a question about the new Mini Gateway.
Is it possible to connect the gateway to another (not TTN) network server?
Do you mean a private instance or TTI or totally alternate such as Loriot/Orbiwise/Comcast/Orange/Actility/////etc.
That is a very good point, thanks for checking it out… from the datasheet it looks like the module drives the pin at power on reset and power failures. I just swapped my short for a 1k pull-up and it works allright. It also looks like the signal is routed somewhere else on the board (there’s a via going to an inner layer)… wondering if it could be enabled from the main MCU via a firmware update… that would be even better!
Caution: Factory reset requires resetting the credentials on the server side as well to authorize the gateway to fetch new personalized credentials.
This is relevant when client auth methods such as ClientTLS or Auth Tokens are issued to the gateways. Currently, only server auth is supported. (https://doc.sm.tc/station/authmodes.html)
Even better yet: naming and shaming of those who did not plug it in yet:
As of now 234 gateways are registered and active which means that we need to shame 550 people.
Why ‘shame’? It may be they are busy doing other things - tear-downs, re-housing in other cases, modding antenna’s etc…they may be ‘innovating’ so why assume a ‘shame’ needed…may also be waiting for dust to settle and all clear and set up easily (I did same with the Kickstarter GW when troubles 1st emerged!) as time for playing/debugging limited! …shame on you for default shaming!
(Note I don’t have one - yet! - and am not one of the 550…just saying…)
So the AU915 channel plan has been released?
Picked up a TIG at the conf, setup via WIFI ok, shows up as “connected” in TTN GW Console. But cannot connect any kind of node, OTAA’s fail (seen in Arduino IDE or LoPy serial consoles), no traffic in TTN Console. Suspect I have a 915 device. How can I determine that? Could not find a definitive answer in this thread…And if it is 915 is their a mod to switch to 868?
I think I voided the warranty on my gateway. But it seems to have a little more range.
I mean a totally different network server like Loriot.