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.
There are people working on satellite LoRaWAN to solve the gateway issue. In the mean time the standard is as it is and it requires receiving multiple frequencies at multiple spreading factors. Any changes are to be discussed with the LoRa Alliance, they maintain the standard, we (the TTN community) don’t.
Until the LoRa Alliance changes the standard any non compliant closed or open source solutions will disrupt and harm the network. You might view it differently but people investing a lot of their own money to support the community network would like to minimize disruptions and issues.
You can experiment without any issues with a local LoRaWAN network for which you could run all components on your RPi. Set it to private (a setting in the packet forwarder) and you won’t be bothering anyone.
1 Like
There are people working on satellite LoRaWAN to solve the gateway issue.
nice to know that.
Any changes are to be discussed with the LoRa Alliance, they maintain the standard, we (the TTN community) don’t.
I know that. and i’m still readying their (LoRa Alliance) documentation about LoRaWAN 1.1 specification (beside few information about the 1.0.x) and from what i notice the gateway itself doesn’t perform any kind of calculation (i guess except for the signal strength, i’m not sure about that). it’s just a forwarder, take a message from end-device and send it to a network server. the thing about have a good GW is to support the whole LoRa network, your, mine and other people nodes. which is a good thing to not think only about yourself. but if we are talking about selfish, bad and cheap users that doesn’t care about others, they can install any cheap GW and infect the whole system, and they will do the codeing from scratch because LoRaWAN is a standard (a guide) to how you should implement the communication system between nodes. and they are no block in the network packet where you specify or tell the system how many frequency, SF etc…, your GW can support, i notice that all the configurations and data in packet are about the network server or the end-device. that’s why i say it’s possible and no one can control it, the only thing TTN did is hiding all single channel from their map but in real life they are exist. it’s bad thing for the network itself if they keep running all the time and surpass the fact that they where just for testing for a duration of minutes (less then hour). and as you said:
You can experiment without any issues with a local LoRaWAN network for which you could run all components on your RPi. Set it to private (a setting in the packet forwarder) and you won’t be bothering anyone.
which is not a harmful act for the network itself. people need to be responsible and know the consequences of their action, it’s sad think that we can’t block a bad GW and baned from the network. this is the work and we need to find a away to make it better. like the satellite idea they are working on. let’s hope the best for the best.
and for the last part about setting the packet forwarder privet, i already did that in the TTN setting so no one can count on my GW, i did it even before i start this topic. but i don’t think you mean that setting, so can you tell me what are you actually mean. (one thing, what do you think about this library: GitHub - Lora-net/packet_forwarder: A LoRa packet forwarder is a program running on the host of a LoRa gateway that forwards RF packets receive by the concentrator to a server through a IP/UDP link, and emits RF packets that are sent by the server.)
Private vs public in this context relates to the message/payload preamble in the pf per LoRaWAN spec not the tick box on the ttn console. That just shows details on the map otherwise if set to private vs made public will show as unknown. If you do put a scpf on the net be open about it…make it public so people can see to be aware, put fact it is single channel in description so people finding problems can try to avoid, show its location on the map so we know where it is to help avoid/mitigate and put up you name (user ID) so we or ttn core team can easily identify and contact if it causes significant problems and disruption
No, probably because the regional settings mandate which frequencies a LoRaWAN device must support. So not supporting some of them is not an option.
And as @Jeff-UK mentioned, the private setting is not related to TTN, I specifically suggested to use your own server and set your network to private in the packet forwarder configuration.
I use miniPCI card SX1308 version (compatible with Semtech picoGW)
with packet_forwarder ported to STM32F401 (inside card).
And ESP32 (via serial line) connected to card.