Sadly I learned that Single Channel gateways are banned, after I failed to register my self made one. So what to do with this board ? It can be set to different frequencies, so maybe it can be programmed to work on all 8 channels ?
You did not make clear which Heltec LoRa dev board exactly you are referring to.
What is clear though is that this is another attempt at trying to make some kind of SCPF which are not supported so I changed the title.
To build a LoRaWAN gateway you need special hardware. A Heltec ESP32 LoRa board does not have that hardware. It only has a LoRa radio suitable for acting as LoRaWAN end device (aka node).
Us it as LoRaWAN node. See: Big ESP32 + SX127x topic part 3
Just to stop you trying to achieve the technically impossible, a gateway has a chipset that can listen on 8 channels over a range of Spreading Factors simultaneously and then, when it detects a signal, configure a channel to receive it. It can receive 8 uplinks at the same time.
The Heltec LoRa board has a chipset that that can listen on ONE frequency and without some considerable effort, only one Spreading Factor at time.
Normal, compliant, specification conforming devices choose one of the eight frequencies / channels at random to transmit on. Which is one of the reasons that SCPF’s are so useless at being a gateway - device transmits on any one of the 48 possible combinations and the SCPF is listening on just one.
So the only real thing to do with the Heltec board is use it as its fundamental design is for, as a device!
Thank you all for these explanations. So I will follow your advice. My original goal was to create a small gateway, that can be taken to areas, where absolutely no LoRa is available, e.g. in the forest of a valley. Are there any portable gateways for outdoor use on the market, or are there somewhere instructions to build one ?
You will now benefit from reading why portable community gateways are almost a bad as SCPF’s before you see the words “effectively a denial of service” in this topic - if devices make use of a portable gateway and have their data rate adjusted to suit but then the gateway goes away, they may not be heard by their original gateways …
If you want to run your own copy of TTS or similar, then that’s all fine, just nothing that interacts with TTS CE - Community Edition. Fundamentally a portable gateway for a forest (another can of worms regarding range) is a gateway in a waterproof box with a really big battery.
Sorry Nick, but here I disagree. The gateway is planned to work in Dhünn, a part of Wermelskirchen. the city is in a valley and the intention is to use it to track some cows and see, where they are going during their daytime outside. There are no other gateways around and there are no nodes, because there are no gateways. Devices have to adjust their data rate anyway, as they are moving with the cows. Closest gateways are in Remscheid and Wipperfürth, far out of reach with some hills in between. So, what’s the problem with a temporary gateway in no mans land ?
It may not stay “no mans land”
That’s not workable. The timeframe of datarate adjustment that fits within permissable LoRaWAN airtime downlink airtime usage to send the adjustment commands (especially within TTN) does not permit rapid adjustment but only adjustment on the time frame of large fractions of a day to several days. And with the “further” case leading to complete data loss until it has adjusted to a suitable rate.
That timeframe is precisely why gateways that move or appear and dissapear are such a serious problem.
Anyway, how were you planning to get Internet backhaul to the TTN servers?
The experiments you are describing sound like those best conducted with a self-contained private network probably using the network server that many gateways can optionally run on their embedded computers as a demo / isolated network mode. That way you can just record the results and not worry about needing realtime backhaul.
And you’re free to use a fixed SF and airtime constrained by regulatory limits, rather than the much stricter TTN usage limits. Though you do need to actually read the regs!
1 Like
Because it is by consensus of the TTN community that there is no such thing as no mans land.
Not all gateways are on the map(s), so you need to perform a local survey.
Even if you survey for a day, you may miss an uplink from a device that is at the limit of its gateway range and take it out of action for several days to come. And it’s not feasible for someone to reliably survey locations if they are moving the gateways frequently.
As for Data Rate change requests, it’s explained above.
A tracking solution (for which there are many discussions about the challenges thereof on the forum) with a mobile gateway is a non-trivial project, perhaps best to use a fixed gateway situated high up to see what coverage you actually get with that.
I guess, that’s a misunderstanding. By mobile gateway I don’t mean a moving gateway. I am thinking of a small gateway, that can be easily moved after the project has finished. During the project its fixed and connected by WLAN or ethernet, but afterwards it will be removed and packed into storage until being needed again.
1 Like
I guess it is choice/use of words here - what you are describing is what might be typically described as a pop-up gateway as opposed to what has been assumed and implied as a moving/intransit/transportable gateway. Pop-ups are typical where you need to do a test deployment to see if real-world coverage approximates to estimates made when planning for new permanent deployments, or doing a feasibility study as part of a deployment proposal development. It is not unusual for a few GW’s to get deployed, signal strength gathered at targets sites/node sights then one of more gw’s get moved slightly to adjust/optimise coverage or overlap/redundancy etc. e.g deploying on one side of a block of flats, an office block or multi-story car-park, results and coverage then evaluated over several days/weeks/months and then a gw repositioned on otherside of the car park roof to better service the target area or specific needs. It may even be that GW moved from one end of a road to another or even across a neighbourhood. Have also seen instances of complete re-orientation of a constelation of GW’s covering a small town and its surroundings. Permanent deployments may follow or if value not demonstrated or proposition fails they may never be seen again! Similar can happen in areas such as you describe in agri biz where a gateway may get moved from one farm building or site to another - swapping barn roof or silo tops to optimise area coverage, or to reflect seasonal movement of animals across pastures/grazing lands. What you dont want to do is carry the GW on a backpack or strapped to your bicycle! or even carry around in your car. Though I have seen GW’s mounted on trains - to provide consistent coverage to nodes on same transiting convoy of carriages, and have seen them deployed in vehicles heading into remote areas (forestry/reservoirs/coastal activities) for loan worker/temp asset monitoring (note not as a life assurance/emergency mechanism - because…), and so on. A short duration contact with a (fast) moving GW - say on a high speed train - should not be too disruptive for the network of fixed nodes it passed and their ADR algorythms, but any reasonable duration deployment that comes and goes is a problem…a problem seen particuarly in the early days of TTN when there were fewer GW’s and people often turned them on and off to suite their own needs - only on at weekends or evenings to support their hobby or only on during the day when in the office/lab doing work, then shutting down over night!
As pointed out there is no such thing as
Given there is an option for any GW owner to mark their deployement as public or not (show location on the various maps or not) - there may be GW’s and you will not even know it also a node in the area covered by your GW could be on the outer reaches of an existing GW that you cant see or might consider too remote, but happily services the node. Yours then appears in the area and appears to deliver a stronger signal service, the node backs off TX under ADR and is no longer reacing the original GW…yours then goes offline and the node is orphend potentially for a long period of time! Also deployments expand rapidly - even if no users there today what about next month, next year, 3 years from now…
Note: I also know of GW’s being deployed just for the duration of music festivals (Glastonbury, Reading, Isle of White & Leeds in UK) - 3-7 days all told, or even for the duration of Industry events…CES Las Vegas, and even the initial (and subsequent) Electronica after LoRaWAN launched where we deployed 5 or was it 6 GW’s around Munich, Telecom World (Geneva), GSM World Congress (Barcelona) et al. 
Bit hard to assume or infer much else from the use of the word mobile = “able to move or be moved freely or easily” - as opposed to ‘temporary’.
Even the metal boxed ones are easily carried with one hand, so you have your pick of any gateway on the market. But running it on a temporary basis still has potential disruption, so perhaps look at a gateway that can also run a stack as well, so it’s not impacting community nodes.
1 Like
Don’t forget The Things Conference (Amsterdam) in this list.