It happens, that the “problem” of “single channel abominations” (and a few other problems besides) could be readily solved if the TTN backend folks would simply recognize an optional field in a signal report to the effect of “acceptsDownlink”: false and if they see that, not try to route any corresponding downlink through the, er, “abomination” sending in such a report, or even go a step further and ignore its report for ADR purposes, too. I understand the urge to lecture people who want to build single channel setups, but there are quite simple things that could be done server-side to make the issue a non-issue for others.
Due to the fact that the rest of the threads are auto-locked for some reason, I’m asking here. Is there a good reason such a functionality does not exist? It seems very off to me that something is labelled “bad” and “harmful” simply because current software is designed to handle it poorly.
Yes, there is a very good reason. LoRaWAN compliant gateways use multiple channels with multiple spreading factors to create a reasonable capacity and not overload a single frequency. The single channel abominations use one channel with one spreading factor resulting in increased usage of that combination. Because everyone in radio range suffers the results from that bad choice (and radio range is comparatively large for Lora modulation) it has impact on a potential large number of LoRaWAN users.
Many users of the restricted hardware mention they are the only one in their vicinity, based on the TTN map. However TTN is not the only provider using LoRaWAN, there are other commercial providers and countless private networks. And we all use the same, limited, resource.
The single channel solutions are bad. Not the software. If you want to use TTN you need to be LoRaWAN compliant, or at least use equipment and software that should be compliant (no amateur will spend several thousand euros on a formal test and that is not required), not knowingly use sub par hardware that can’t implement the standard. If you want to use that hardware you can implement your own solution using plain Lora. (And in many cases that is perfectly valid)
There will never be software that can be designed to handle a single channel at a time radio as a 8 channel gateway, so it’s nothing what so ever to do with current software being designed to handle it poorly. The software that drives a SCPF or DCPF is usually well designed, it’s just the resulting software & hardware package is not compliant with the requirements that the majority need to have running for a network to work effectively & efficiently.
Threads regarding this matter usually become locked or reach the 30 day timeout & are auto-locked because there is a limited amount to discuss that hasn’t already been discussed. And there is no physical possibility to get a LoRa module to become a LoRaWAN concentrator, so the software improvements are moot.
It is hard to advise you further without knowing where you are in your LoRaWAN journey - if you are starting out and see that the few remaining S/D CPF’s being advertised appear a bargain, this is a false economy as apart from being obliged to setup your own LoRaWAN stack to run it on, you will have to find a way to get your devices to only use the single or two frequencies that your ‘gateway’ runs on. Whereas a fully compliant gateway can be had for €80 - €110 and remove a whole heap of potential failure point whilst you find your way with devices, setup, applications, data integration etc etc.
The hardware can only listen to one channel. As switching between 8 channels and trying to find a signal results in missing most if not all transmissions they are listening to one fixed channel all the time. At one spreading factor in most cases. Switching spreading factors is possible but results in reduced sensitivity of the receiver.
There is a reason a full gateway is more expensive, those use two broadband receiver chips and dedicated decoder chip to process multiple incoming transmissions one multiple frequencies in parallel.
because the chip, something like an SX1262 or SX1276 or similar, designed & manufactured by the inventors of LoRa, Semtech, like many many radios in the world, can only be set to one frequency at a time. These are the chips that we use in our end-devices as they only need to send & receive on a single frequency at a time. At Semtech own the IP / patents on these chips, no one is around to magically create a multi-frequency listening version. But if they did, it would be very similar to a LoRaWAN concentrator chip set.
It’s not even a limitation in the hardware that doesn’t allow it to be able to listen on other frequencies at the same time, the chip is doing as intended and no amount of software will allow it to listen to other frequencies at the very same time.
The spreading factors that @kersing alludes to is that once set to a frequency, a single chip can detect the preamble signal that another chip sends and alert the software that something is being heard. The software, if it has the additional facility, can then switch to the SF and if it can do it in time, hear the transmission. This is called Channel Activity Detect & needs an MCU that has interrupts available for the software to catch the preamble in time. CAD does not work for the entire range of SFs.
Where as a LoRaWAN concentrator can listen on 8 frequencies and detect the whole range of SF’s all at the same time - so 48 possibilities.
You should be aware that a gateway of any variety is unable to receive any uplinks whilst transmitting due to physics and not due to a deficiency in the software.
As I suggested above, tell us where you are & want to go …
So theoretically if you have n receivers, one for each channel, you could listen to all channels without an issue? That still seems to come out much cheaper than the currently available boards. Would there be something else still missing from these?
Take 8 x SX1262’s @ ~$5 each (because you are buying in bulk) you get to $40.
Then you need an MCU with 8 interrupts that can service them fast enough.
But it still won’t be able to hear all the SF’s.
Plus a much larger custom PCB to carry the 8 chips.
And power supply
Or you could go large and have 48 chips. Or maybe 8 for the SF’s it can hear and then another 16 permanently on the frequency/SF combos that the CAD can’t either hear at all or reliably hear.
You’ll need some code to run at a fairly low level to round-robin / be interrupted to deal with the radio chips and then pass them over to the comms layer, the packet forwarder.
Good news on that front, whilst you write your packet forwarder software, we have a subject matter expert on this thread, @kersing, so I’ll leave him to explain the intricacies of taking packets and sending them to the network server. You may be able repurpose his code if you can write an interface that looks like the reference code that Semtech provides to talk to their concentrator chips.
Or you could buy a TTIG @ €90.
You are not the first person to try to find a way. I’ve got a friend in the US on his third iteration of his electric car, going from a lot of lead acid cells and now using a bulk purchase of 18650’s. He now has two fire extinguishers in the car …
If you really really need to get in to LoRaWAN, you can setup anything you like if you use your own backend server because that way, devices on the real LoRaWAN in your area won’t get any response from your setup so won’t be messed up. But if you want to use TTN community, then we ask you don’t compromise the community by bodging together some sort of gateway. Not everything is on the public map so don’t assume there is no one in your area. This would be for a radius of at least 25km. If there is any sign of anyone using LoRaWAN in that area, you may well cause disruption. Assuming you don’t have a radio mast, if you do, then go for 200km.
If you do look on the map and there is a gateway close to hand, then get a device and get started - you don’t have to own a gateway but it helps enormously if you do have one for debugging issues if you are getting creative. If you are buying off the shelf devices you will mostly be OK.
And most critically of all how are you going to engineer a converged RF front end/matching/switching system to bring all these devices (8+) RF paths together…have seen $5000 subsystems fail to achieve what would be needed…
…moving on…go get a LoRaWAN GW and save your and every one else’s time debating this @Avamander
Yes and no. You will still only be listening at one spreading factor. You need to listen at 6 (in EU). To do so with one receiver reduces its sensitivity, with 6 receivers per channel the total hardware cost exceed cheap gateways.
This solution has been proposed before, several times, starting 4 or 5 years ago when gateways were far more expensive. We haven’t seen any gateways using this solution appear during these years so while theoretically a solution, it is realistically not viable.
If you need any expertise on gateways, as well as @kersing being the go to guy for Packet Forwarders, you’ve now got the attention of @Jeff-UK who knows more about the evolution of gateways than is safe for anyone person to know.
Still interested in what you hope to do with LoRaWAN …
