@peder - a gateway is a gateway, in as far as I know. I have not heard of any “comments fields” you can provide, but see https://www.thethingsnetwork.org/wiki/Backend/Connect/Gateway on how to connect a gateway. I’ve noticed that a list of channels / frequencies is available on my gateway, but I’m merely hosting it. Perhaps @kersing can chime in and help you.
What is the difference between a "single-channel gateway" and a "real gateway"?
A real gateway is able to listen on 8 channels and all spreading
factors at the same time. Single-channel gateways are fixed to one
channel and spreading factor, so they will only receive about 2% of the
messages unless you specifically configure your nodes to send at the
exact same configuration as your single-channel gateway.
As LoRaWAN is a spread-spectrum radio protocol, single-channel
gateways are not LoRaWAN-compatible. They can only be used for plain
LoRa (without WAN) communication or for testing, and are not supported
by The Things Network.
I see there is a BIG different between an single and multiply channel gateways.
I just need to send some bytes from a node a few times per day. If somebody has a single
channel gateway 24/7 in my town, I will just use this and not build my own.
If it was possible to make one registration for a normal gateway and another registration for a “limit” single channel gateway, it will help more people to startup playing with lora devices that not need to much data extraction.
Maybe that’s why 75% of gateways in Denmark are unclaimed !
The amount of data is not the issue. Single channel gateways do not adhere to the standard where gateways must listen to multiple frequencies with different speeds. As nodes choose the frequency for a transmission at random from the ones listed in the standard a lot of transmissions will not be received by a single channel gateway.
But is still not LoRaWAN specification compliant. However it is the best choice if you really want to go for a single channel gateway. The esp8266 should beat the price of a raspberry pi as well.
What would be the biggest advantage building gateways this way? For a couple of bucks more, you’d have a full TTN gateway that’s ready out of the box right? I am trying to figure out if it’s better to wait a little longer and buy the TTN gateway, or build one myself.
As I remember from my radio amateur days, working with AX25 packet radio. There are lot of
stations tramsmite and receive on the same frekvens. There are handshake, so the transmitter need a
ok from the receiver, otherwise it will transmite it again. It working perfect with many stations and no data
get missed…
So if the lorawan GW are set with a fixed frekvens, and the Nodes on the same, it must have a handshake in the protocol to control this.
But lorawan are maybe not design for this way to work, so it will not be the same as the AX25 protocol packet radio
LoRaWAN is not designed this way. The idea, for the Class A nodes to send and forget. With the various SF and frequencies, there is little chance all messages will not be received. The node can use few ACKed messages to ensure the communication exist and is reliable.
Nothing prevent to use LoRa (without WAN) technology to benefit from long range low power communication, but a different stack need to be used. RadioHead is one of the various library you can use. It will implement the mechanism to ensure a reliable communication in point to point LoRa modulation using single frequency.
Well one is availability, I’ve had gateways like this since October, but also customisation. For example I can plug in a $10 3G USB dongle and have a 3G ready gateway very quickly, I can add Power over Ethernet or a watchdog circuit using the same methods people have been doing on Raspberry Pis and the like for ages.
Also being Linux based its very easy to configure remote access via SSH/VPN or use something like Resin.io for configuration management.
Of course if you don’t need any of this, only want a gateway you can plug in at your home or office then the TTN gateway should be just what you need.
so if you have for example 6 nodes in your house, and they all point to the same frequency, that will work off course, but the gateway will miss a message if several nodes start transmitting at the same time (collision) a real gateway will not miss these packets, up to 8 simultaniously on all frequencies and SF’s.
…but only one per combination of frequency and spreading factor, right? In other words: a full gateway will also not be able to decode 8 messages if they collide (that is: if they use the same frequency and the same SF at the same time). At best, a gateway will then be able to decode one of the messages.
If nodes use different frequencies (channels) or the same frequency but different spreading factors (sub-channels), then a true gateway can indeed receive multiple messages.
Indeed, some single channel gateways can detect a signal on all SFs of a single channel. But once detected, unlike full gateways, they can only decode one at a time.
As an aside: I think you’re confusing Channel Activity Detecting (CAD) with Listen Before Talk (LBT). No single channel gateway I know does LBT, and given the tightly defined receive windows in LoRaWAN, I think no full gateway can use LBT either. They simply need to send when the time has come, regardless if anyone else is sending too.
As lora is capeable of having multiple transmissions at the same time I do not expect this to be a big issue. Also the fact that up and downlink are kind of a “different path” helps.
But not on the same frequency and SF. (Of course, multiple nodes can send on the same frequency and SF, but a gateway will receive at most one.)
Not sure what you mean, and probably a different topic: gateways are half-duplex. So if a gateway transmits, it cannot listen at all That’s one of the reasons why downlinks are so “expensive” for the network.
.
That’s one of the reasons why downlinks are so “expensive” for the network.