You also need to set ‘“gps”: true’ in your local_conf.json in addition to fake_gps and your coordinates.
Seems odd this is not documented somewhere.
Cheers!
Erwin
It has been described for Multitech mLinux Conduit, but apparantly it hasn’t made it to the other gateway installation notes on the wiki
Finally got Multiech online covering Twickenham, TW2 Greater London.
I’ve been at it over 24 hours and in all that time I missed one line of instruction.
*Edit /etc/init.d/lora-network-server. Around line 17 you need to change from using *
basic_pkt_fwd to using poly_pt_fwd: pkt_fwd=/opt/lora/poly_pkt_fwd
This is insanely hard…
Still another node on line, just need to start sending some data and stuff now
I don’t know wether to laugh or cry right now.
2 Likes
Yeah I reckon having spent the time learning (for learning read, Trial by ordeal). I could get this reasonably off pat now.
Well done to all the guys on here with the massive amounts of shared knowledge.
Mark Stanley I’m just working through your own Reading team website. It’s very good well done.
Jim
1 Like
Small update: the status and coordinates of the gateways on the main website (http://thethingsnetwork.org) are now updated live, based on the API. So if you have a live gateway, be sure to add it - including eui identifier - to the community platform using your own account.
See also:
I only get a Server Error (500) when i try to add a gateway
should be fixed now
Still Server Error (500) I think you need to check some logging on your side. Please let me know if i need to provide some additional information
Note: I`m using another (company) account to add the gateway
Not fixed, still Server Error (500)
Ah, found it.
Yup, seems to be working 
The map on thethingsnetwork is a static map I guess. It contains (at least in Nijmegen) a lot of gateways that are not there (yet) or that are not active.
The lpwan.uk maps looks nice. Too bad that a lot of gateways still do not reveal their location. This would make life for node developers so much brighter.
But then, anyone who claims to have - what they call - a gateway can add this to the map. A Raspberry Pi with a single channel sx1276 board will (and a lot do) show up as a gateway. In my very humble opinion that’s not a gateway but a testing tool. If you place a gateway on the map it should be a “real” gateway that at least listens on the 3 default channels and is also able to do stuff like OTAA. Also make sure it’s always online - or at least try to have it online. The network is now building up and it is time to leave the phase of “development” where network and gateways go on and off at irregular intervals.
As soon as I can guarantee that my gateway is stable and runs 24/7 with 99% up-time I’ll add my GPS coordinates. Until then it’s just one of those “location not disclosed” testing things.
1 Like
Nope; see the explanation of the colors on top: Active, Inactive, Deactivated, Planned. So indeed some are not active yet (including Kickstarter pledges), but some have been added automatically upon receiving the first packet (or the first status message, not sure), where the coordinates are taken from the status messages. This includes single-channel gateways that have coordinates set.
Also, though I agree a single-channel gateway is just for testing, at this moment I like to see them, as they show people’s activity.
1 Like
However it would be nice if they could easily be recognized, or even better filtered, as they are non standard and provide false information regarding the availability of TTN at those locations.
2 Likes
Having correct information is difficult. What is the range of a gateway? and even then - it’s almost never a full circle.
My gateway will be placed on the roof of a building next to the river (Waal) with line of sight in the direction of Arnhem and Dodewaard. I’m almost confident it will be able to pick up nodes in Elst (8km North) but Radbout University at ~ 5km south-east is a challenge: lots of buildings and woods are blocking my line of sight.
All gateways should get a quality index. Something to get an idea of the range of the gateway. This is not an absolute figure with a kilometer range but just some kind of “service level” that gives me an idea if this gateway will stay active and/or has a proper range.
I know the range of a gateway depends on a lot of variables, however we can assume most gateways will have at least a coverage of say 1km in an urban environment. Also knowing if a gateway is at least fully LoRaWAN compliant (which the single channel versions are not) would help as LoRaWAN nodes within range should be to able to send data using a gateway. With single channel gateways it is hit and miss with miss being far more likely (3 different main frequencies and 6 different SF settings, also (assumption) antennas and antenna interface on single channel gateways will probably be less optimal giving a smaller range as well.)
Sounds like an excellent idea, however who is going to assign the values and who will verify those values are realistic? I think people tend to overestimate the range of their gateway. Walking around with a GPS equiped node certainly made me aware of the limitations of my gateway before antenna upgrade.
Hi Jorma,
Unless you’re planning to migrate it: can you please add a note on http://ttnstatus.org/ to say it’s monitoring the obsolete Croft (right?), and refer people to http://staging.thethingsnetwork.org/gatewaystatus/ for the new environment?
2 Likes
Hi,
just got my own gateway up and running. (Raspberry PI+ LinkLabs LoRaWAN shield).
I have one question, the gateway ID as set in local_conf.json: do I need to pick one myself or can I leave the value as I found it? If I need to pick one myself, are they any suggestion how to get a good one?
Thanks, Jan