After rebooting several times I now get packets but it’s dropping packets like crazy. I’ve received only 3 packets in over 20 minutes
They are now at weird frequencies and they are actually outside of subband and don’t follow the appropriate 200 hz step interval ie, 902.725, 902.325, 903.075.
I’m sending every 5 seconds btw
It’s actually always seemed to have used weird frequencies when I unplugged all of my other gateways and used it solely. When I have it running along side my other gateways it doesn’t see any packets.
Looks like the debug UART of J1 is wired to the CP2102N in the picture. That’s connected to the USB-C port, but kept in reset state by R88 (10k pull-down). Strapping it up to VCC by shorting R86 (or connecting TP5 to 3.3V) seems to enable the device… that gives debug logs on the USB port with the device in the box.
Then I wonder again if things might be hidden due to some aggressive de-duplication? (For which the TIG would still receive and forward the packets, but TTN would somehow not show them?) Any chance you do see the TIG listed in the gateway metadata when clicking an uplink in the application/device’s Data page in TTN Console, even when not shown in the TIG’s Traffic page in TTN Console?
Easiest would probably be a wire from pin 1 of J1 (the square one, 3V3) to TP5, but if you have a good soldering iron I’d say just short R86 with some solder. That’s what I did anyway.
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?
The WiFi config page has a small JS issue when working with Firefox (thank the universe for JavaScript and browser engines). Chrome will work just fine. There will be an automatic firmware update soon that will fix this.
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.
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. )
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.
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.
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.
). 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?
)