Hello guys,
I’m trying to create my own gateway based on raspberry pi and SX1276 (i’m using lora bee), i’m not looking for a high efficiency gateway that can listen to 8 channels at the same time. it’s just for home project where i can test and install a LoRaWAN network. and that chip is the only lora device is available for me. the end devices are just couple of TTGO boards. so my question is, is there any C (or Python) library i can use to install my gateway. i know about the single channel gateway which is not a gateway for real, it’s just a data forwarding project and it won’t support any downlink unless i do the coding by myself and that what i’m trying to avoid. So i’m open for any suggestions.
Pi + a 1276 will not give you a LoRaWAN Gateway!
A LoRaWAN Compliant GW needs to suppport 8 concurrent channels running on 6 different SF’s. (Plus option for FSK modulation)
All you do is create a Single Channel Packet Forwarder that will under perform, potentially even dropping local netwrok capability, and potentially confusing any users who may find their traffic being (mis) handled by your device 
Remember devices do not ‘associate’ with a GW in the way that say a WiFi device associates with a Wi-Fi access point, but rather are passed on to the back end by all receiving GW’s in range, with associated signal metadata provided to allow the Network Servers to decide which GW is best placed to service a given node.
I recommend you read the TTN documentation and spend time searching TTN Forum before you undertake your project. In the early days when the only GW’s cost >$1000 using a SCPF was an easy and cost effective way of starting to experienience and experiment with a partial solution, however, with the introduction of low cost ‘micro’ GW’s such as the TTIG, Dragino (8 Channel - not single or dual channel note!) or RAK Wireless solutions and many more there is really no excuse…
2 Likes
thankx for your fast replay, but as i said, i’m not looking for any good GW in any kind, my goal here is just to perform an uplink+downlink through that GW i’m trying to build, the end device already using only one channel and one SF, and i’m testing only with one end device (maybe i will use the other but not for now) and for the other users they will not notice my receiver (my GW) because the area i’m working in is kinda limit with this kind of technology regardless of the growth we seeing for the LoRaWan those years. and beside that, the only time my gateway will work is the time i’m working with the project, i’m not intending to install it for ever or even for a long period. think of it as a small project with low budged working alone (i mean in term of spectrum) with low power of TX (i’m talking in meters here not Km). so spending al least 150 euro for a GW which is not cheap in my country (we are not using euro) and the GW devices are not even available (as fare as looked). i wish i could just buy a sx130x something like that or RAK, i wouldn’t ask this question and the TTN and the web is full of documentations about it. sorry if it sound kinda cheap or poor talk but i need to work with what i have. (using SX1276 it’s not impossible in my case as far i a read from the LoRaWAN specification and TTN forums and other websites, the problem is it won’t support the complexity of many end devices with many channel and SF and long ranges, which i don’t have those problem, even other devices are barely noticeable).
Perhaps you’d do better using something even cheaper than LoRa then, for example you could use nRF24 radios, the descendant technology that is BLE, or the ESP8266 “direct” mode that uses the wifi radio in a non-wifi way. I’ve been toying with the idea of implementing something “inspired” by LoRaWAN (but not LoRaWAN) on top of a different sort of radio.
Of course, there are also plenty of legitimate uses of the LoRa radios, that are not TTN and are not even LoRaWAN but more peer-to-peer architectures. Amazon’s offering seems to be built on the idea of an infrastructure based on a high density of node-class radios in people’s porch surveillance cameras.
Most of the issues with, shall we say, “single channel abominations” only come about if you feed data into TTN. If you keep everything in your own non-TTN ecosystem (ie, install a personal instance of LoRaServer, or write something custom, or at least only forward to TTN traffic that matches your node ID) and don’t use the band discourteously they might have their place. But such a project would be a lot of work.
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.
FWIW, while it is in theory a “real gateway” I’d strongly discourage anyone from buying a TTIG until either the issue with it are solved, or source code is released to a allow the community in general to work on solving them. Many of the other options with true 8-channel concentrator cards seem reasonable - given an active business need I’ve bought a lot of equipment from RAK and a little from nFuse, and the impression is that the multi-channel offerings from others would be comparable.
2 Likes
I’m not sure if i’m following what you saying or trying to say. but i don’t think it’s gonna be easy for TTN or any other platform to support such technique. first of all, LoRa is using ISM which is automatically regulated i mean you can use the frequency as you like, you have some sort of limit, this is one. the other think is about supporting all end devices in one channel, don’t forget that you need to reserve the channel each time only for one device, so if we manage to avoid collisions and problem like that, we still have to manage the right time for the end device to start transmission which is not easy if you consider the time precision. and if we manage to do that we still have a transmission-periode/end-device-number compromise which mean if the transmission period is low you have low number of end device and vise versa. i mean, you can do what you thinking about, but it’s not the purpose of LoRa. lora come to give a long range of working with a big number of end devices (it’s the IoT itself). and working with other radio technique to implement LoRaWAN, it’s kind weird. i won’t say it won’t work, it will, after all LoRaWAN is just a lora network standard and we can code it. the problem is, they utility of what you trying to do. in my case i’m just testing. if your case, it’s a project that may lead to be a product, but is it worth the hard work?!!! that’s the question 
, i’m curious now about your project XD hhhh
That’s intermixing a lot of different things to a degree that it’s not really possible to follow.
To simplify a bit, at the moment if you want to interact with TTN you really need an 8-channel LoRa concentrator card, or to be in range of someone else’s one that is running as a TTN gateway.
If you don’t need to interact with TTN there are a lot of things you can do on you own… but implicit in that, you are “on your own” with a lot to figure out, on your own.
i have a question, why i can’t interact with TTN?
if i’m already can forward a message from RPi to the TTN server that come from end-device (uplink). so what is the problem of receiving the response from TTN and manage it and send it back to the end-device.
You’ll confuse TTN if you forward only the single frequency, single spreading factor messages that can be received a node-class radio. ie, if someone else’s node transmits in a way that you can pick up, it may lead to TTN suggesting that they transmit in a way you can’t, causing them to lose network access until they fall back to a mode that more distant “real” gateways can pick up. Or perhaps you receive the signal more loudly than a real gateway that can transmit downlinks, and so you are commanded to transmit the downlink reply, but you don’t, so it never gets sent, when if you hadn’t “dipped a toe into TTN without fully committing” the network would have used a more distant “real” gateway to send that transmission.
If you filter the traffic you pass up so that you are only passing that from your own static (as in ABP) device address, you could substantially mitigate that.
The other concern is that you might over-use certain frequencies. But there are ultimately legal standards there - if you meet those, you aren’t necessarily any worse than some non-TTN, non-LoRaWAN (or even non-LoRa) use of the shared spectrum.
i’m trying to understand what you trying to say.
if i manage to build a GW with single channel, single SF, that may lead to receive other node messages send them to TTN and may return some configurations depends on my poor GW wish gonna lead to some problem in their applications, they will notice TTN application can’t receive their data because of the error in the message cause by my poor GW.
about this part:
if someone else’s node transmits in a way that you can pick up, it may lead to TTN suggesting that they transmit in a way you can’t, causing them to lose network access until they fall back to a mode that more distant “real” gateways can pick up.
can you explain it to me, or send me a documentation.
As @cslorabox has suggested, the detail is in the LoRaWAN specification.
Its not really the job of the forum to explain, in detail, why a simple packet forwarder as you are suggesting is a bad idea. Just accept it can interfere with the operation of nodes that expect to be sending data to proper TTN gateways that are compliant with the specification. You might say that the TTN specification ought to detect such non-compliant devices, but no-one is forcing you to use the free service TTN provide.
Those who own TTN nodes that are affected by your simple packet forwarder might notice a loss of comms or they might not, but how would they be expected to fix the problem ?
cslorabox i read again your replay about the reason why network may get confusing (because yesterday i was sleepy, 2AM) and now i understand what you saying. forwarding a message from end-device through a GW that doesn’t support downlink which is very important feature for OTAA and ABP devices in case of confirmed uplinks and MAC cmds and if the TNN will receive (and he will receive) a message from an end-device through this single channel GW it will send to it(GW) the response that has a very important information that may never be received by the end-device (no downlink), even, if it has a downlink, the GW itself is not appropriate to be installed and work with for a real LoRaWAN network. and i’m totally agree with you, we should never install such bad GW that will mess the network system, TTN or non-TTN, bad is bad. but as i mentioned before. the condition i’m using this cheap technique is just for test and will not be a permanent or a full time GW. the probability that this miss-interraction with other nodes is gonna happen is too low (<2% or even less), i remember when i forget the lora device working (not as a gateway nor forwarding, just listen to the Frequency, RX mode) i receive someTimes a messages from one node. and it happen rarely. so by turning on the gateway the moment i will test one scenario i don’t think it will cause any problem to anyone, i mean 98% being safe to use is good. maybe i miss use the term “install a home gateway”. sorry for that, but my very first question was, is their any library or project i can use for this case. i was hoping if anyone come cross this problem and found a solution.
See https://www.hackster.io/ChrisSamuelson/lora-raspberry-pi-single-channel-gateway-cheap-d57d36
Or search “Single Channel Packet Forwarder part 3” on this forum, noting the disclaimer which has been added since Jan 2018.
Bad is bad - 'nuff said!
“But” = I hear you but am not listening and will disregard because I can! (or that is how it reads)
If you live >50miles from any other potential user - now or in the future then go ahread, knock yourself out but if you are near others simply put dont be knowingly antisocial wrt TTN use. (Where in the world are you) Your short (intermittent) test - a few hours? a few days? a month? a year can be someone elses critical testing phase and may screw what they are trying to achieve.
I know from bitter experience as last year whilst doing a follow up test deployment for a local council after a short coverage check a few weeks earlier I ended up £thousands out of pocket due to over running engineering/on site test time & detailed coverage check and diagnostic activity with hotel bills & subsistance costs for contractors/staff. An early quick and dirty test had indicated existing coverage in some areas from a couple of known & stable GW’s , so we used available budget to look to add a few additional GW’s in key strategic coverage locations and a few infill places. The GW’s were initially put in on temporary basis to check coverage and overall reception and to ‘prove’ the viability of planned use cases over a number of weeks, then critically once client was satisfied we went to deploy permanently, with some minor site adjustments. At the end of the few days work as we were finishing/commissioning and confirming coverage/operation the client complained we were starting to see missed packets, slower than expected join processes and two sites where the node would occasionally ask for confirmed downlink or would expect a command return for end equipment on/off enabling which would either not see action or would have a very long response latency (many minutes even hours before action). We had to stay on site for an extra couple of nights and ~2.5 day longer whilst we monitored and debugged the situation.
It turned out some bozo had deployed an intermittently used SCPF (suspicion was there might have been 2 in close proximity) that was screwing with the real system 
Ironically it was on when we did the initial quick and dirty coverage/planing test and appeared to help (uplink) coverage. It appears it was off for the time we deployed on temp basis and for most to the eval trial before full deployment and was turned on again sometime before or during the final install period and for the commissioning checks. We obviously were initially confused by what we were seeing until the SCPF was spotted in the packet metadata for a few hours, and the penny dropped, then we could focuss evaluation and mitigation efforts. We ended up re positioning one of the infill GW’s to ensure our nodes were heard directly with better coverage than through the SCPF as mitigation and that seemed to solve the problem to better stats than we could reasonably meaure in a short test period so client was happy. To play safe we sent them an additional low cost infill GW to deploy in the area as a back up a few weeks later and there have been no reported issues since.
As you might expect there is now a systematic search & check for SCPF’s operating in the area for any subsequent test deployments 
If we find problems start being reported by a client that is now one of the problem generators we start to look for. Better if we never had to deal with such situations and certainly dont want to encourage any more deployments - hence a passionate poster on the subject on the forum. Fully understand and appreciate the historic reasons for the early use of such devices but there is now no excuse given the relative low cost of micro GW’s (and yes I include the TTIG here despite some reservations as also called out by others - these usually affect ability to uplink vs downlink and therefore do not cause all the problems associated with a SCPF, even better to have ~99% packet del’y than <30% (<10%?) c/w SCPF’s 
- should be fine once natively supported in V3 vs current bridging kludge )
2 Likes
Looks like our posts ‘crossed’ and have to say am sad to see such things being proliferated (guess the internet hates what might be termed holding back information or even sensorship! 
) but would heavily caveat what was originally posted as an article nearly 3 years ago. The title
LoRa - Raspberry Pi - Single Channel Gateway - Cheap!
certainly isn’t viewed that way by those of us who have to mop up the mess after encountering such devices
The money lost on that one job alone could have helped fund several more Community GW’s
I understand the valid point you made, but just thought that it was time he got a simple answer. Do we have any data on how many of these evil things are in use on TTN? I also wonder whether using their own, distinct frequency would avoid the problem you experienced.
Probably avoid the problem, but should they then have free access to the TTN backend …
Appreciate that TTN might not want to provide you the details on setting up your device, especially as the post title is " Low cost raspberry pi gateway" which might well turn up in Google searches.
If you do not want to play along the LoRaWAN rules, why use LoRaWAN? You don’t have software running yet, so why not use plain lora on a different frequency?
1 Like
If you do not want to play along the LoRaWAN rules, why use LoRaWAN?
i didn’t said i don’t want to play along the LoRaWAN rules, other wise i wouldn’t come to TTN to ask for a LoRaWAN implimentation for such case.
and for everyone wondering how some countries still doesn’t have a lora gateway, why you don’t wonder why some countries still doesn’t have a drinking water?!!!
you have only have 2 sx127x devices. you don’t have the option to have any other device for the moment (example for a month). you need to adapt to LoRaWAN for future use. what you can do.
- wait for months to get a gateway.
- or trying to find a work-around way just to start with LoraWan.
i’m not here to complain about the lack of technology here (where i’m) or even crying over that, telling you those reasons so you can just stop asking about getting a real GW device and stop complaining about touching the network like i’m going to violence the whole network and shut down the whole system. when i’m totally agree with some of you when he try to knowledge me about the consequences of doing such thing without trying to shut the doors of trying to find the work-around way. thankx for whom understand the situation and took the time to guide me to the solution. even for the rest , thankx for your warnings, but not all DIY guys (or ppl using cheap materials) are useless or even harmful. (don’t think this is a DIY project). some projects about a single channel forwarder and many other DIY are useful and they was not waste of time or money. this is the open source community, people here are for testing, developing and exploring with every single mean they have to build up good knowledge about the technology and upgrade it, each person in his way try to develop and help each other, this is maybe the last replay i post about the reason of using such technique. and for a real and helpful solution or though or suggestion is welcome in this topic. thank you for your consideration.
with all my RESPECT.