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.
Ok, Thanks for the info 
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.
When the DIY gateway option appeared, the GW cost was more in the 500-1200 range. Now some have more hobbyist price point.
With the DIY approach, we’ve been able to play, at a reasonable cost, for a year, without going bankrupt 
.
The initial target was July 2016, but some delay has been experienced. I hope we will have soon our gateways delivered.
Make or wait is up to you and depend of the urgency of your project.
1 Like
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.
Yes, I think it will be the best for me, to just do the LoRa without the WAN and use it to
receive my data from my node far away.
I will keep an eye on prices and opportunities to build a real gateway at a later time.
Thanks for all the good answers. Great with this communities, to share knowledge.
10000… but only one at a time 
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.
1 Like
…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.
1 Like
nailed it 
One of the single channel gateways with ListenBeforeTalk capabilities will give you multiple spread factor capabilities.
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.
Also, the mechanism these single channel gateways use for that limit their range: https://github.com/JaapBraam/LoRaWanGateway#how-multiple-spreading-factors-are-detected
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.
Yes, I had confused LBT with CAD. Thanks.
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.
1 Like
Full LoRaWAN gateways are able to receive multiple transmissions, not transmit multiple streams at the same time. Also as a gateway has one antenna which is switched from the receivers to the transmitter while transmitting the gateway can’t receive while transmitting.
1 Like
The newer Lora gateway code base suggests Semtech fpga based gateways might be able to.
1 Like
But then only for broadcasting, right? Given the defined receive windows, a gateway could tell some backend that RX1 is busy, but for RX2 it has no other choice than just send. (Or keep silent and discard the packet.)
No, if local regulations do not allow transmission when another device is sending the only right choice is to discard the packet and tell the back-end it was not sent.
1 Like