Single Channel Packet Forwarder part 1 [Deprecated]

Gateways [obsolete] SCPF
1

Disclaimer

Single channel packet forwarders are NOT supported by The Things Network
and we condemn their use.

Single Channel Packet Forwarders are not LoRaWAN compliant gateways.

They negatively impact proper operation of gateways and end devices (nodes) in their area which means they negatively impact The Things Network and its users, but they also impact other LoRaWAN operators. Not only now, but also in the future when new nodes and new gateways are added in the area.

Single Channel Packet Forwarders are often called Single Channel Gateways which is incorrect, confusing and misleading. They shall not be called gateways.

Be aware that some vendors will try to sell Single Channel Packet Forwarders as a gateway which they are not. These cannot be used as gateway for The Things Network.

NOT supported also means that single channel packet forwarders may no longer work after the community network will be migrated to V3.

Only LoRaWAN compliant gateways are supported by The Things Network.

History

Years ago in the early days of The Things Network, LoRaWAN gateways were very expensive and out of reach for many. In those days a Single Channel Packet Forwarder was an affordable alternative to start experimenting with the technology and The Things Network.

During recent years much cheaper and much more affordable gateways have become available. The Things Indoor Gateway costs around €85 (VAT included) and there are many options for both DIY and commercial gateways in the price range from €120 to €200.

In the last years many gateways have been deployed worldwide and network coverage has become available in many areas on the globe. The effect and importance of the negative impact of Single Channel Packet Forwarders on successful operation of the network and its users has substantially increased with the growth of the network. Therefore use of Single Channel Packet Forwarders is now deprecated and is condemned by The Things Network and on this forum.

(end of disclaimer)

I have released a first version of a single channel gateway. This is a proof-of-concept implementation, that can be used for development and node testing. It is not a replacement for a real multi channel/multi SF gateway! It supports some LoRaWAN features, but due to its static nature (single channel) it is not fully LoRaWAN compatible (and will never be).

By default it works with the TTN backend, for testing and development.

It runs on a Raspberry Pi (any model), using an SX1272 (for example the HopeRF RFM92W) over the SPI bus.

@Batilan already kindly offered to tidy and structure the code, add cli options, etc.

The code and instructions you can found here:

Example hardware:

9 Likes
2

@Thomas : That’s great work! Thanks! Exactly what I need for further development of my nodes. :clap:
sad: no support for sx1276 (the only on I’ve on my table)
b.t.w. where did you find the breakout board for the sx1272?

3

Nice! Added to the wiki.

http://thethingsnetwork.org/wiki/Hardware/OverviewGateways#do-it-yourself

4

It looks like an esp8266-12 breakout board. Check this message.

5

ja dat zijn ze :smile:

6

thanks for the module adapter links. ordered :smile:
now I’ve to wait for the RFM92 :disappointed:

7

Great !

I was looking for a cheap solution to complement a full gateway. I plan to perform some tests on location using triangulation, so I need 3 gateways. Could also be useful in ‘closed usergroup’ scenario’s.
I have one mobile node with GPS & LoRa; also considering building a couple of ‘static’ nodes (only LoRa, no GPS but fixed location) to be used as calibration/compensation nodes (think heavy rain, mist, other environmental factors)

thanks for sharing,

Filip.

8

Sorry to bring you the sad news, but you won’t be able to do localisation with this gateway (nor with any other current generation gateway).

It really isn’t a replacement for a real gateway for operational purposes, but still great for testing purposes.

9

Hi Thomas,

could you please elaborate on this ?
Getting RSSI and SNR should be sufficient if you have the (fixed) location of the gateway.
e.g. on loriot.io , I get this:
Last radio 868.300 MHz SNR 10.8 dB RSSI -95 dBm SF11 125kHz

What am I missing ?

thanks for clarifying,

Filip.

10

@onkelflip I guess the “real thing” with regard to geolocation in sensor networks will use multilateration. See also this article for some background information on different geolocation techniques.

There is also a discussion on this forum about this subject. Any questions or suggestions with regard to geolocation are best addressed in such a topic. (lets keep this focussed on the great little gateway that @Thomas provided :slight_smile: )

2 Likes
11

Thanks for sharing Thomas. Great I will get a Pi soon…

I have my ESP8266 nodeMCU @ PFLab (S2M Utrecht)

Soon we will have the $5,- Pi’s from Jurjen in the Lab :D.

I have some rfm95 (also working with litle software mod). So when you in Utrecht, you can send me PM for a rfm95 :D.

I dont get the localisation, cant we set it somehow in your software, and simulate it?? When we know where the gateway is??

12

Hi @Thomas

A big thanks for your code!, I took a Raspberry, an RFM92W and a few jumber wires to the Lorawan Eindhoven Tech & Sensor workshop. We were able to build the gateway (not as nice as yours), get the code running and receive sensor packets. Unfortunately the Kerlink didn’t seem to forward the packets, but using your code we could show packets were actually received. So a fruitful evenening after all :-).

Now that I have a working gateway I will start on the code so it can be used with different parameters without having to change the code.

2 Likes
13

Nice to hear! Thanks for your support in enhancing the code.

14

Now supports RFM95W too.

2 Likes
15

I could not wait for the other boards, so I built one with the xbee board. now I can change the radios easily.
thanks @Thomas for the code
but it forwards packages only all 8 minutes. is that working as designed???
it would also be nice if the message would be visible in plain in the local output.

1 Like
16

@Thomas or somebody else familiar with the code …
following the (shortened) output from my gateways console and from the node REST.
as mentioned above, I see all 30 seconds a status update but only all 8 minutes a package receive although I send with my node each minute.
could please somebody give me an explanation or an advice/instruction to patch the code?
I didn’t there seen any “delay” .
Thanks!
.
indent preformatted text by 4 spaces
…
stat update: {“stat”:{“time”:“2015-12-17 07:23:30 GMT”,“lati”:47.43000,“long”:8.54000,“alti”:450,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single Channel Gateway”,“mail”:“mail@me.ch”,“desc”:“my private development server”}}
Packet RSSI: -97, RSSI: -116, SNR: 9, Length: 63
rxpk update: {“rxpk”:[{“tmst”:3869498330,“chan”:0,“rfch”:0,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9,“rssi”:-97,“size”:63,“data”:“QKoBSFoA7wEB8N5cvB9g2WCKU0aGAS/o7Z5HiolUjz8LaqQCH7yhHBvFGlonf6lButBuLxcha6flouZ0AFI0”}]}
stat update: {“stat”:{“time”:“2015-12-17 07:24:00 GMT”,“lati”:47.43000,“long”:8.54000,“alti”:450,“rxnb”:1,“rxok”:1,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single Channel Gateway”,“mail”:“mail@me.ch”,“desc”:“my private development server”}}
…
…

{
    "time": "2015-12-17T08:10:13.699Z",
    "data_plain": "2015/12/17 08:11 4725.764N  832.437E              ",
    "gateway_eui": "B827EBFFFFE05FEF",
    "data": "MjAxNS8xMi8xNyAwODoxMSA0NzI1Ljc2NE4gIDgzMi40MzdFICAgICAgICAgICAgICA=",
    "data_raw": "QKoBSFoAHwIB/aBdU8ruNpft4Ev1jUbwYPrqVTcsLkdQ8l16mNY2KLwGUYR7idwVy6mhMLXaFmtJZgdFlhw2",
    "node_eui": "5A4801AA"
},
17

Hi @ursm

It might help if you provide (a link to) the source code you are using.

Ar you using sendReqAck or send, what channel/frequency are you using?

18

node: https://github.com/tftelkamp/arduino-lmic-v1.5 with reading/sending GPS-position
gateway: https://github.com/tftelkamp/single_chan_pkt_fwd unmodified
to make it clear: on a “real” gateway I see all messages (each minute), only with this Single Channel Gateway was this phenomena
node log from a real gateway in Zurich:
indent preformatted text by 4 spaces

{
    "time": "2015-12-15T18:09:53.460Z",
    "data_plain": "2015/12/15 18:11 4723.521N  830.888E              ",
    "gateway_eui": "FFFEB827EBA00A83",
    "data": "MjAxNS8xMi8xNSAxODoxMSA0NzIzLjUyMU4gIDgzMC44ODhFICAgICAgICAgICAgICA=",
    "data_raw": "QKoBSFoAKQAB//+vfSjIJGNG0vrZFQYZkyFRGcmXmR65+Qzx46JXWNCzcuwZApjUvzxdu7ZrN0qw+p4YFHUF",
    "node_eui": "5A4801AA"
},
19

Are you able to monitor the serial port output? If your sketch is based on thethingsnetwork-send-v1.ino then it will log the channel on which it is sending. My guess is that it uses several frequencies. As this is a Single Channel Gateway only 1 frequency is monitored / received.

20

Your node is sending at 8 frequencies, your gateway is receiving at only 1, hence the one packet per 8 minutes.

This is not a real gateway, it is for testing purposes. It is LoRaWAN compatible, but not compliant.

1 Like