Hmm 
makes diagnoses of issues with a running gateway a little difficult if you don’t already have a serial device connected may be time to do a little #esp8266 serial to UDP devices for remote debugging
Are there any forum members or developers following this thread who own a debugger device (pickit3/icd3 etc) and can read the 2MB flash contents from their gateway using mplab_ide and/or mplab_ipe and the ISCP port? This would help me a lot, thanks!
Just a heads up:
New firmware will be released soon, so for those who cannot complete activation (hence: for whom the gateway reboots before checking if new firmware is available): make sure you’ve got a microSD card, and whatever needed to write data to that, at hand. It will need FAT32. The previous firmware expanded to about 2.8 MB on disk, so any small storage size will do I guess. I don’t know if there’s a maximum size.
3 Likes
GPS queston - Summary - How can I use my The The Things Gateway with TTN Mapper?
I don’t know if this is the place to ask, but, as I bought a The Things Gateway as “the best LoRa TTN gateway” - I’ve been quite disappointed to find it’s no use with TTN Mapper, which is especially disappointing now TTN Mapper is more integrated in to the ecosystem. I don’t really understand why TTN Mapper doesn’t like fake gps (since my gateway can’t move, and I know the very precise location, surely that’s BETTER than live GPS?) but anyway … what’s the plan for getting The Things Gateway to have GPS support? Is there a plan? Did I buy the wrong gateway?
Do you have a sensor, like The Things Node, that you can carry around along with a phone where you’ve downloaded TTN Mapper? If so you should be able to use those in conjunction with your TTN gateway.
Basically, you just state via the console where your gateway is located. And then travel around with a sensor and a phone where you have the TTN mapper software running and the software will map how well the sensor is transmitting data to TTN from locations that it determines via your phone’s GPS.
1 Like
How would you even configure that in the TTN Gateway? And even with a GPS in the gateway (and assuming it would get a proper fix indoors), how would TTN Mapper know where the node is?
Like @sronan wrote: just set the location in TTN Console: Gateways, select yours, Settings, Location. It will take some time before the location is propagated to https://www.thethingsnetwork.org/map so maybe it takes some time for TTN Mapper to know its location too—I don’t know.
This isn’t really answering my question, but ok, I didn’t realise that if I used the mobile app it would also push the gateway location - that’s useful. (Yes, I’ve just built a TTN Mapper node, so was disappointed the effort seemed wasted because my Gateway doesn’t support GPS tagging…)
You’d configure the TTN Gateway position just like you configure it in the console. Heck, with good integration the gateway could even pick it up out of the console surely.
Back to the point though - is anyone looking in to adding GPS support to The Things Gateway? (If not, it’s something I’d look in to doing!)
On such occasions i like to revisit the kickstarter campaign and look at one of the first pics there 
ttn kickstarter
Ok we got Bluetooth instead…
Anyway, i think most of us here use nodes for “wardriving” and not gateways…? But GPS inside the gateway makes sense anyway, especially for timing and pps.
1 Like
Ok, maybe I’ve not understood something - but I’m not wardriving with the gateway - it’s fixed in place. But the TTN Mapper website states:
Possibly the gateway that received your packets does not send its coordinates in its status update packets. If you know the gateway owner, please ask them to enable the GPS (and fake gps) so that the coordinates are sent through.
This implies that the gateway must add GPS information, in addition to that provided by the moving node.
Whatever the case, TTN Mapper is not working with my nice Things Gateway, which is a shame.
AFAIK TTN Mapper knows your fixed GW-position anyway but not via fake gps but over the placement info during registration. I cannot find any issues between my multitech or my TTN-Gateway concerning Mapping.
A Gateway owner can decide not to make the GPS data of a Gateway publicly available. See this topic about that.
If you set the location of your TTN gateway to private (not public) then TTN Mapper won’t be able to add it to the map because it won’t receive that info.
(Note on edit: I just noticed that switching that off does not keep the metadata from being added?!)
You’re saying your TTN Gateway is not working with TTN Mapper. If you look at the metadata of a package in the console, is the location info of your gateway absent there also (in case the package was received by your gateway)?
All the info for my gateway is showing as expected in TTN Console. (It’s been running and public for weeks…) It’s very interesting to hear that people have been able to use The Things Gateway with TTN Mapper though, despite its lack of GPS. It sounds like maybe people don’t think there’s any need for the gateway to have GPS? My mapper issue may be elsewhere in this case.
Big thanks for the replies 
I think it depends:
- If the gateway is indoors (the current TTN Gateway is intended for indoor use, although you could build a waterproof case for it), then GPS often is not a good option;
- If the gateway is stationary, then I would not spend the money on a GPS module for just that single time that I need the GPS coordinates, I would just use my phones GPS for that;
- If the gateway changes location a lot, is outdoors, and I would want the location to be available without manual action on my end, yes, then a GPS would make sense to me.
Yes, I have used TTN mapper with multiple TTN gateways without any problem.
I specify where the gateway is located via the console. Then the TTN mapper software on the phone makes points on the map showing where I am when successful transmissions occur, using my phone’s location services, as I ride around on a bicycle with the phone in one pocket and a TTN sensor Node in another. It even includes indications of what the received signal strength was.
You might enjoy the TTN Mapper author’s presentation at the conference if you haven’t seen it yet:
1 Like
If you want (at a future date) Class B you will need a gateway with GPS too. The GPS time (pulse) is a requirement to synchronize beacon transmissions. GPS also allows for time stamping required for TDoA location determination. So GPS is useful even when the gateway is stationary. However GPS needs to see the sky which is an issue with indoor gateway.
3 Likes
Hi all,
FWIW, I just activated my Things Gateway (backers edition) earlier today and ran into the issue with the Lora circuit board not being seated properly. This was indicated by the ‘Gateway Card: ND’ message on the weblog of the gateway, and the boot cycle mentioned earlier in this thread.
While the lora circuitboard was seated quite firmly (and under a bit of ension in fact), after pushing it in a bit more the gateway was finally able to register with TTN and get online. To be honest I couldn’t really feel the circuitboard move when pushing it in, only bending a bit 
… I hope it continues to work. So far so good anyway.
Before figuring this out I saw a lot of timeouts during the activation procedure as well as the message about packets being blocked.
Anyway, thanks for the posts that highlighted the issue and what to do about it 
Received my Things Gateway last week, got it activated without issues, but it never was stable for more then a day(not on wifi, not on ethernet). Sometimes it worked again after unplugging/plugging the power cord. Sometimes that did not work(config correct: false), and I needed to do a full reset and activation again.
Eventually I enabled beta firmware updates, hoping that would make things better, but that never seem do do anything. It always was on the firmware from june last year every time I looked.
For the last hour I can’t get it to work at all. Did a full reset, activated again, but nothing helps. Also I just noticed that there is a new firmware installed dated today.
Gateway Information
Version Info
Hardware:
v1
Bootloader:
r1-7167873a (2017-06-02T13:48:18Z)
Firmware:
v1.0.1-facdef23 (2018-02-14T08:16:22Z)
Network
Uptime:
1111
Connected:
true
Interface:
Ethernet
Wifi SSID:
Things-Gateway-001EC03B3B76
Configuration
Activation locked:
true
Config correct:
true
Region:
EU_863_870
Gateway Card:
868Mhz
Packet forwarding
Broker connection:
true
Packets up:
61
Packets down:
0
Miscellaneous
External storage:
false
Seems all right to me, but “last seen” status in the console says otherwise(and also my nodes aren’t working).
What to do? Thanks in advance.
I guess the new firmware is also released in the “beta” update channel?
Can’t get it activated in any way since the new firmware.
Edit: and after a “downtime” of 2 hours, I pulled the power cord, and plugged it back in. And now the gateway works again.
Hi, my gateway also received an OTA update to firmware “v1.0.1-facdef23 (2018-02-14T08:16:22Z)”.However this still not fixes the reboot loop issue. What I am observing is that as soon as a packet is received by the gateway there is a high probability that it will “crash” and revert to the reboot loop. However, the firmware does improve things somewhat in the sense that after a (variable) number of iterations the gateway will often achieve a stable connection again (previously it would loop indefinitely).
Also, as I have a working gateway AND a malfunctioning gateway, I am wondering if the following difference is relevant: the socket for the LoRa modem of the working gateway has a number etched on it: 1635D4, whereas the socket for the LoRa modem of the malfunctioning gateway has a different number: 1636D4. Can anyone compare this with his own gateway?
See picture below.
3 Likes
Hi Marcel,
My malfunctioning gateway has also number 1636D4.
1 Like