Single Channel Packet Forwarder part 1 [Deprecated]

@vseta that would depend on how you set up your nodes. If each node had a RTC and scheduled xmits when it was clear to do so then yes. Being a single channel and single SF you would have to manage when nodes xmitted or if relying on unsynchronized xmits and random numbers you will be seeing collisions( more than 1 node xmitting at the same time).

Why not build or buy a real gateway?

If your nodes will be close to the single channel gateway( a couple of hundred meters) then you could try the Lua based single channel gateway which does multiple Spread Factors too.

Thanks Douglarue for feedback.

I was trying to understand if multiple nodes near a single channel gateway would require timing synchronization?

As single channel gateway works only with one node at a time.

Does the Raspberry Pi hack with PCIe Multitech gateway work or just spend $600 and buy the whole thing. I haven’t read many good things about Multitech from low range (could be antenna impedance matching) to over heating LoRA gateway PCIe card. Not many options for 915Mhz North America. Kerlink is very expensive ~$3,000

you still have to obey FCC rules on how much time your nodes are transmitting. ie they can NOT stream data and infact have to obey a 1% rule as in if they xmit for 1 second then they have to off air for 99 seconds. Theoretically, if you had 100 nodes and each was assigned a sequential number of seconds to wait before xmitting then you could get 100 nodes on a single gateway without much packet loss.

As for a full up gateway goes, the MultiTech MTAC with a rPi/Odroid/etc does work but it requires a heatsink and probably a fan to keep the wasted heat down. Two linear regulators dropping 5V to 3.3V and 1.6V dump/waste lots of heat and it gets very hot without cooling.

I just ordered a board from RisingHF( the RHF0M301V1A-920 ) and should get it in a week or so. MultiTech uses a USB to SPI interface to get the miniPCIe format and that is going away so I was told about a SPI based board which has the 915MHz option. So there are 2 options for the US market for DIY and both are in the $140-$170 range for the radio and <$50 for the gateway controller(rPi/ODroid/OrangePi/etc).

My Single Channel Gateway received a message once sent from more than 30km away… There was perfect line of sight: the node sent it’s message from a balloon…

…true, but just to be sure: a full blown gateway can also only handle a single node per channel and spreading factor. True, unlike a single channel gateway, a full blown gateway can handle multiple simultaneous nodes that use different channels, or use different spreading factors on the same channel. But if multiple nodes use the same settings at the same time, then collisions will occur and data will be lost.

(That’s why it’s important that nodes follow the LoRaWAN specifications to change channels for each transmission.)

@JBraam, I thought you’d said your multi-SF(Lua) version had degraded performance so you keep it for testing locally and have a single channel/single SF for the long haul. Are you saying differently here?

BTW, I just bought a Yaggi for doing long range balloon tests. What antenna(s) did you use?

Fundamentally the multi-SF version is less sensitive because it is only aware of signals above the noise level. It uses RSSI measurements to detect the presence of a signal. A full blown gateway can also detect weaker signals that are below the noise level. When running the gateway in a single SF mode it is just as sensitive as a full blown gateway…

The few hundred meters range that I reported for the multi-SF mode is based on my measurements in my situation. My gateway is situated in the attic of my house, about 7 meter above the ground, The antenna is a homebuilt J-type antenna described on this forum. I live in an area with a high density of houses and trees. My antenna isn’t on a pole and isn’t above any rooftop in my area. So there is hardly any line-of-sight.

In other circumstances like when mounting a better antenna on a large pole in a rural area I would expect the range to be much better, but a full blown gateway will always have better range…

On the other hand, I’ve read about a guy that had troubles getting more than 600m range with his full-blown gateway in a dense city area, so talking about range is not an exact science…

2 Likes

Hello everyone !
The single channel gateway can use with 433MHZ band ? And if I want to upload data to FireBase , what should I do ? .

Great work :slight_smile: can you explain more the wirings (pin assignment) between raspberry and the lora module

Hello to all,

First, I would like to congratulate everyone on their job. And thank you to all the more advanced people who work on the project and support this community. Really an amazing job!

I currently live in Singapore and I’m working on my master thesis which I’ll do about IoT-LoRa implementation. I have started with this single channel gateway version as a first prototype, since the hardware for the full gateway is a little bit expensive for me. My setup is the following:

Raspberry Pi with inAir9b and the code available at the beginning of this thread
Arduino MEGA2560 with inAir9b and the Arduino-LMIC library code from matthijs.
TTN server. (ABP)

They seem to communicate properly as I can see in the ttn console that the gateway receives frames sent by the node as well as in the stat update. However, the server drops those packets and don’t get to the application (and you see that the node is “never seen” and it took me a while to realize that it was because the device address received at the gateway side (and then forwarded to the server) is not the same as the one sent by the node. I printed both device addresses, one before exiting the node on the radio side and the other on the gateway side, and I found that they are different. I followed this How can I tell which nodes are connected to my gateway to check for the device addresses. I don’t know why this is. Also, I cannot see if the payload is correct because it is encrypted. This was with the 868MHz frequency band. If I change to 915MHz it doesn’t even work. Should I change the gateway code to the center frequency or the one for the first channel?

I then changed the gateway to one based on Lua and ESP8266 which has been developed by Jaap Braam, and everything is working now. So I’m guessing that there is something wrong with Rpi gateway. I don’t know if it can be the wiring (although I had a problem like that before and the error was a version assertion) or something on the radio part of the code. However, I guess it is working for everybody else so… :confused:

And to make use of the post (sorry it’s too long) here are a couple of questions:

  • If a node sends a confirmed data up and doesn’t get an ack, does it resend the same packet or that case has to be handled on a higher level?

  • Can it be send some command with the ack, as part of the body of the ack? As long it’s short enough to send in the Rx windows. In order to not need a class B end-device.

  • Last, in the Arduino-LMIC code/part, it seems I can only send unconfirmed data up. How can I make it confirmed so that I get an ack back?

Finally, if there’s anybody in Singapore that would like to meet, it would be great!

Sorry in advance for my misunderstanding concepts or inaccurate language or naming. If there is anything I can do to clarify please tell me.

Thank you all!

Asier

1 Like
  • It could also be that there is no (working) gateway in range of the node
    ( keep in mind that you can only send a very limited number of downlink messages per day)

there are some TTN’ers active in Singapore

I understand. So the node doesn’t send again and again the confirmed packet if it doesn’t get an ack right? Because it could be doing that forever in that case.

Thanks!

Hi mate,
can you give me some clarity on the connections you’re using on the InAir9B?
SX1272 - Raspberry
3.3V - 3.3V (header pin #1)
GND - GND (pin #6)
MISO - MISO (pin #21)
MOSI - MOSI (pin #19)
SCK - CLK (pin #23)
NSS - GPIO6 (pin #22) What is NSS called on your InAir9B? Is that the ‘CS’ pin next to the 0V and should that be #24 instead of 22?
DIO0 - GPIO7 (pin #7)
RST - GPIO0 (pin #11)

Thanks in advance.

Yes, SPI buss NSS is the CS (chip select) pin on the InAir9B - I’m currently using a wemos d1 mini (as my particular RPi was locking up every few days) and that’s wired to D8, gpio 15, or this in the code (it’s confusing!) ssPin:

// SX1276 - ESP8266 connections
int ssPin = 15; //DJL 15; // GPIO15, D8
int dio0 = 5; //DJL 5; // GPIO5, D1
int dio1 = 4; // GPIO4, D2
int dio2 = 3; // GPIO3, !! NOT CONNECTED IN THIS VERSION
int RST = 0; // GPIO16, D0, not connected

from this code: https://github.com/dlarue/ESP-1ch-Gateway-v2.0

Hello,

Since about 2 weeks ago my single channel gateway just stopped working. I have tried everything to making it work again, but it just isn’t working.
it used to appear in https://staging.thethingsnetwork.org/gatewaystatus/ but now its also missing here. In the console the “last seen” isn’t updating anymore. My gateway is sending packages.

SX1276 detected, starting.
Gateway ID: b8:27:eb:ff:ff:6c:7c:65
Listening at SF7 on 868.100000 Mhz.

stat update: {“stat”:{“time”:“2017-03-11 17:48:45 GMT”,“lati”:54.34570,“long”:4.64090,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single Channel Gateway”,“mail”:“wout.decker@telenet.be”,“desc”:“Gateway_Brecht”}}
stat update: {“stat”:{“time”:“2017-03-11 17:49:15 GMT”,“lati”:54.34570,“long”:4.64090,“alti”:10,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single Channel Gateway”,“mail”:“wout.decker@telenet.be”,“desc”:“Gateway_Brecht”}}
Packet RSSI: -61, RSSI: -98, SNR: 9, Length: 26
rxpk update: {“rxpk”:[{“tmst”:433718200,“chan”:0,“rfch”:0,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:9,“rssi”:-61,“size”:26,“data”:“QBMRASaAAAAB5wMPgw3e/J/8k7po5MgebV4=”}]}
stat update: {“stat”:{“time”:“2017-03-11 17:49:45 GMT”,“lati”:54.34570,“long”:4.64090,“alti”:10,“rxnb”:1,“rxok”:1,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Single Channel Gateway”,“mail”:“wout.decker@telenet.be”,“desc”:“Gateway_Brecht”}}

This are the settings of my gateway:// SX1272 - Raspberry connections
int ssPin = 6;
int dio0 = 7;
int RST = 0;

// Set spreading factor (SF7 - SF12)
sf_t sf = SF7;

// Set center frequency
uint32_t freq = 868100000; // in Mhz! (868.1)

// Set location
float lat=54.3457;
float lon=4.6409;
int alt=10;

/* Informal status fields /
static char platform[24] = “Single Channel Gateway”; /
platform definition /
static char email[40] = “wout.decker@telenet.be”; /
used for contact email /
static char description[64] = “Gateway_Brecht”; /
used for free form description */

// define servers
// TODO: use host names and dns
#define SERVER1 “router.eu.thethings.network” // The Things Network: croft.thethings.girovito.nl
#define SERVER2 “external01.wirelessthings.be” // wt
#define PORT 1700 // The port on which to send data

Can somebody help me please?

Grtz
Wout

Hello, I’m new to this topic and I’m trying to do some testing with TTN. I made a test gateway with RPI3 + Dragino Lora Shiel v1.3 with the package single_chan_pkt_fwd (https://github.com/tftelkamp/single_chan_pkt_fwd) but I have several different conditions that cause me doubts and cause errors during the tests.

First of all, the Dragino Lora Shield cards work at 915Mhz (this is the frequency authorized and used in my country). Second, I do not know what the TTN server/port I should configure (I understand it is australia: router.au.thethings.network:1700), but I try it and it never appears connected, although apparently it seems to work fine because it is always updating state.

Finally, I do not understand which SF to use (spreading factor), in the example code used they use SF7 but I understand according to what I see that for this frequency must be modified, but I do not know that other portions of the code should also be modified.

These are the messages on the console:

pi@raspberrypi:~/lorawan_gateway/single_chan_pkt_fwd $ sudo ./single_chan_pkt_fwd
SX1276 detected, starting.
Gateway ID: b8:27:eb:ff:ff:53:d6:fd
Listening at SF7 on 915.100000 Mhz.

stat update: {“stat”:{“time”:“2017-03-11 22:06:22 GMT”,“lati”:6.23802,“long”:-75.60986,“alti”:1567,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Test Gateway",“mail”:"dlalvarez@hotmail.com”,“desc”:“Test Gateway”}}
Packet RSSI: -123, RSSI: -121, SNR: -12, Length: 86
rxpk update: {“rxpk”:[{“tmst”:2985016905,“chan”:0,“rfch”:0,“freq”:915.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:-12,“rssi”:-123,“size”:86,“data”:“5E+gX5Kf+Y30hEzF/AueRtBuzC4+CGEueUeZ8JegHzUXs8cBda09hfZ8xI6uc8DN6FEZ/CD3U2+6YHH0PpPe3kuV4R6OBDbeb6dSpeIz0PBKGFPTwI4=”}]}
stat update: {“stat”:{“time”:“2017-03-11 22:06:52 GMT”,“lati”:6.23802,“long”:-75.60986,“alti”:1567,“rxnb”:1,“rxok”:1,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Test Gateway",“mail”:"dlalvarez@hotmail.com”,“desc”:“Test Gateway”}}
stat update: {“stat”:{“time”:“2017-03-11 22:07:22 GMT”,“lati”:6.23802,“long”:-75.60986,“alti”:1567,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Test Gateway",“mail”:"dlalvarez@hotmail.com”,“desc”:“Test Gateway”}}
stat update: {“stat”:{“time”:“2017-03-11 22:07:52 GMT”,“lati”:6.23802,“long”:-75.60986,“alti”:1567,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“Test Gateway",“mail”:"dlalvarez@hotmail.com”,“desc”:“Test Gateway”}}

Thank you very much if you can help me to clear all these doubts and could be solved so that the gateway can work without problems to finish my tests successfully.

@diegoalvarez
We’re on the same frequency.
Try this: #define SERVER1 "40.114.249.243"
Let me know if it works for you.

I would like to know abut the SF too.

1 Like

It worked perfect, many thanks for the help !!!

this one is full… we coninue here Single Channel Gateway part 2