After reading the information from many sources - please confirm me, that the following process will be successful to bring the M1 as TTN gateway back to life -or please correct me, if i would do wrong:
JFDI and tell us how it went?
if i will do it - yes. But actually i am not sure, if i better use the included Pi 4 for something else
Toigo,
thank you so much for sharing the correct GPIOs (17 and 05) . Could you please share the url/doc etc that you followed after installation of the basicstation? should we use/compile for corecell? or just standard one (make platform=rpi variant=std)? many thanks in advance
Hi,
as I had been measured the pins… FOR Sensecap M1… please notice that… reset pins are:
SX1302 : GPIO11
SX1262 : GPIO12
I found this on Github
And i found another possibility : go over Balena OS and install a already prepared sytstem
The video on Youtube is called " LoRa Gateway with Basics Station TTN and balena"
lets see, if my given skills are enough for the first version or if i will use the Balena-solution
i just did transform my EX-Helium Sensecap M1 to a TTN gateway. Simply folllow the Github instruction for the seeed-lora/WM1302 (please refer the link above)
and do it exactly like its described. It took me as grand total from creating the Raspi OS image + preparing the Raspberry Pi4 + setting up the Lora software + getting the gateway announced in TTN roughly an hour . And now i will check, if everything is stable…
Addon after 14 hours: runs absolutly stable - no problem with anything. I can only recommend it - buy used ex-Helium Sensecap miners , which are now on the Helium denylist ,for an low price from Ebay or out of any other source and convert them .
I think this is the denylist you are talking about: GitHub - helium/denylist right?
(157394 entries in denylist.csv)
Correct - this is a sick story. Helium discovered, that their setup and reward model has severe unsolvable topics -and now there was a hunt started to catch the cheaters. And this leads to a severely growing denylist , where only a small part of miners will be released from after the approval done by a strange review process. And denied miners are blocked forever by their identity code and cannot join the PoC reward process - but some of them, which are based eg on a Pi4, can be easily converted for other networks .
Anyway - Helium is a network with no customers and at the end its useless - thats the big difference to TTN
One addon question about the interval for achieving the gateway status: in the specific JSON file i find 30 seconds, but this is IMO way too much. I now do it with 180 seconds - or must i go even higher eg to 600 seconds per interval?
OK, you’re entitled to your O, but everyone else has their’s on 30 but I have seen a few on 60. Remember when having an O that the mass mind may have come up with a particular value for a reason, so ideally you should have one (a reason that is), if you are going to vary it. I suspect 180 is fine for a barely used gateway, but if it’s busy, it’s useful for the LNS to know how it’s doing.
So what was the thinking behind making the change?
For the very best opinions, or maybe some science, I’ll draw this to the attention of @Jeff-UK, gateway wrangler and @kersing, developer of the packet forwarder of choice.
thanks for your reply - yes, its a barely used gateway - only 2 sensors are hooked on it. This was it, why i changed the JSON file accordingly. If there will be more traffic, i will switch it back to a more cycles per hour- but at the moment, it should be fine for anybody
Fine for anybody if you’re not on the community network aka TTN - by reducing the update time for a stupidly small packet of information that barely touches the side of any reasonable internet connection you run the risk of compromising anything & everything for another user that sets up, is dormant, comes along, drives past etc etc.
There are many forum posts where someone says that their activity using TTN doesn’t impact anyone else. The community consensus is that this can’t be assured now nor can anyone anticipate what may happen in the next 60 minutes - which could be anything.
Gateways are what make TTN the community that it is. The golden rule is don’t do anything out of the norm with your gateway - with settings, power cycling, filtering etc etc. Particularly power cycling which can render a perfectly good device inoperable for days if the gateway it was settled with disappears.
If you want to setup your own LNS then you are free to do as you wish. You are still free to do as you wish. But the community endeavours to work together to keep the network stable.
You seem to have a personal problem with me - but this is not bothering me at all
This is written in the JSON file - and this advice i followed
And for now, this discussion with you, is for my person finished
Ok LN ops 101:
For an LNS to utilise a GW it needs to know the GW exists, and is ready and available:-
It is able to do this 2 ways - 1) it receives uplinks for nodes in range of that GW (it doesnt have to be the primary GW for that traffic, but the LNS will gather statistics none the less). Following on from that the LNS makes an assumption - that the GW is LoRaWAN compliant as there is no way to identify to the LNS that the GW may have restrictions - e.g. it could be supporting uplinks (Rx) only either by design or by accident (such as if only the Rx port has an antenna connected, or if the RF switch on a joint Rx/Tx ant has failed (it does happen!) or 2) the GW sends a periodic message - the status message - basically saying ‘Hi LNS I might have forwarded no traffic lately but I’m still here and able to send/receive’.
Secondly the LNS needs to know that the GW has available airtime capacity to allow it to Tx - send downlinks, join ACK’s, ADR or MAC commands etc. to assist in device/network optimisation and operation. It does that by maintaining track of the stats around any messages it has forwarded to the GW - again the LNS makes an assumption…that it is the only LNS in control of the GW, hence discussions on the forum around how you should not attempt to connect a GW to two networks/LNS infrastructure - as each LNS will have no knowledge of what the other might be trying to do with the GW if shared!
Any given Network will have its own (operator defined) rules of engagement that will determine how the network overall, and infrastrucrure/devices connected to that network will behave. The list is long, too long to debate here, but there are some obvious ones like, Frequency/Channel plans that are supported, how long a delay is acceptable in GW to LNS backhaul before a late packet is judged ‘too’ late and therefore dropped as a potential replay attack etc., what the safe operating margin is for link integrity with respect to how much headroom might be set when commanding ADR changes, etc., and in this context how long a LNS will consider reasonable when judging if a given GW has not been seen for ‘too’ long to then be considered viable and available to the network. This threshold is set by the Network Operator and is not determined by the GW user/owner, though there is a margin again as clearly the Internet is imperfect and messages might get dropped or lost along the way - be they traffic messages or status messages.
There has been much discussion historically on the Forum and elewhere as to what is “sensible”. After many years or working with LoRa/LORaWAN I would note that I have seen some extremes - very active/high capacity networks where loss or failure to be able to action downlinks I have seen deployed with much less than 30 sec status updates - even as low as 10secs - some GW even default to that depending on how target network profile is chosen - others with much longer status times - 60, 120 even 300+ seconds. Those networks will also have a threshold for how many ‘missed’ is considered acceptable before LNS starts to doubt GW availablility.
For TTN it is generally agreed that 30sec is an good compromise and an acceptable limit - and given the potential unreliabiity inherent in what can be a hobby network in places, often with backhaul not supported by reliable connections or SLA support, this would allow say 10 missed status messages before GW is tagged as offline. This would be 300sec, or >5 mins. I must confess I dont know exact value used by TTS(CE), but judging by how quickly GW’s get declared online/offline in the console I always assumed somewhere 5-15mins. Perhaps we ask a TTI Core team member for clarification if thread continues and there are further queries? On low traffic private networks where missed packets tolerated and accepted and where the application allows for that I have seen GW’s updating just once every 30 mins!
TL:DR for TTN there is a general agreement that 30 secs nominal is just right, 20sec or less considered too often and > 120sec, certainly >180sec too long… but at risk that using higher end may compromise coverage for other Community network users rather than just the folk setting/accepting higher elapsed times…
Advice from WHO?! As noted GW’s - as part of their stock firmware and depending on the chosen network profile selected where several are offered during GW setup - may have a default. Defaults need to be adjusted to reflect the needs and limits set by the LNW operator and are not universal!
I don’t have a personal problem with you at all - I’m trying to cool your jets whilst you get to grips with TTN so that we don’t end up with Google showing results that are directly in contradiction with TTN Community agreed guidelines - like any posts that facilitate SCPFs for instance.
You provided a decision posed as a question based on an opinion with no supporting evidence or rationale. If you’d asked “should I increase this, what’s the pros & cons”, then it would have been a useful contribution to the discussion.
As @Jeff-UK says, sadly we have little control over vendors, many of whom aren’t thinking of TTN but of commercial networks. And indeed in the case of LMIC, create examples that are in direct violation of the FUP.
As I say above, it’s great to talk about the why’s & wherefore’s before the fact - if you need a way to experiment, just ask and we can point you towards resources that you can use that won’t impact the community.
4-6 min are considered the update period for a gateway, that were the norm 2 years back, I doubt it have changed.
I pull the stats of my gateway every 6min and two consecutive stats are defiantly different.
Changing to 180 you have a good chance of messing the LNS around.
teflon1969,
thank you so much for the information and I followed “exactly the same” steps on the github you mentioned and it works !
Hi there,
The package forwarder working perfectly. But my original need is still there:
***Is there any documentation for Basics Station? ***
will be really happy if anybody can share a lead… many thanks in advance
Does this help you ?