Single Channel Packet Forwarder part 1 [Deprecated]

Gateways [obsolete] SCPF
153

OK, I have a SCGW running on an ESP8266…
My node is a Arduino with an RFM95 radio (USA), firmware is: matthijskooijman/arduino-lmic

Below is the start up sequence, it connect to /#define _TTNSERVER “40.114.249.243”
My GW shows up green on the TTN map with a EUI

I appears that my NODE is sending data.
I’m using the NwkSKey of: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
The dashboard gave me a AppEUI of: 70 B3 D5 7E D0 00 03 8B
My DevEUI is: 00 04 a3 ff fe 31 00 01
My AppsKey is: 5E 93 5E B1 93 34 D0 D6 B3 80 32 E9 6C 29 9D 2A

I can login to the MQTT server…

The dashboard tell me that my device is not active…

So, I’m a bit lost here?? did I miss a step??

Its hard to debug when you have a lot of new moving parts!!

Thanks
PS: is their a way to format code on this forum??

! debug: 2
WiFi connect to: lafleur
.WiFi connected. local IP address: 192.94.167.218
Wlan Connected
Connecting to UDP
Connection successful
MAC: 18:fe:34:d3:03:c8:
SX1276 detected, starting.
Gateway ID: 0FE34FFFFD33C8, Listening at SF7 on 902.30 Mhz.
time Wednesday 17:51:26
Admin Server started on port 8080

stat update: <219> {“stat”:{“time”:“2016-6-8 17:51:27 CET",“lati”:32.9847,“long”:-117.1789,“alti”:100,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“ESP8266”,“mail”:"tom@lafleur.us”,“desc”:“ESP Test Gateway”}}
sendUdp: sent 219 bytes
*** Packet RSSI: -35 RSSI: -108 SNR: 10 Length: 26
*** rxpk update: {“rxpk”:[{“tmst”:255867336,“chan”:0,“rfch”:0,“freq”:902.299987,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-35,“size”:26,“data”:“QAYA/wMASAEBdeUVwL79mn5SiQu1MGqdZMI=”}]}
sendUdp: sent 208 bytes
Received packet of size 4 From 40.114.249.243, port 1700, Contents: 1:46:29:1:
*** Packet RSSI: -36 RSSI: -98 SNR: 10 Length: 26
*** rxpk update: {“rxpk”:[{“tmst”:3149446152,“chan”:0,“rfch”:0,“freq”:902.299987,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-36,“size”:26,“data”:“QAYA/wMASQEBJRvxickmhILPycPLRBLLCMY=”}]}
sendUdp: sent 209 bytes
Received packet of size 4 From 40.114.249.243, port 1700, Contents: 1:4:B4:1:
stat update: <219> {“stat”:{“time”:“2016-6-8 17:51:57 CET",“lati”:32.9847,“long”:-117.1789,“alti”:100,“rxnb”:2,“rxok”:2,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“ESP8266”,“mail”:"tom@lafleur.us”,“desc”:“ESP Test Gateway”}}
sendUdp: sent 219 bytes
WifiServer new client
WifiServer new client
*** Packet RSSI: -37 RSSI: -108 SNR: 10 Length: 26
*** rxpk update: {“rxpk”:[{“tmst”:1748890672,“chan”:0,“rfch”:0,“freq”:902.299987,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-37,“size”:26,“data”:“QAYA/wMASgEBRWn0cJaw4645k83vS7JCYf0=”}]}
sendUdp: sent 209 bytes
Received packet of size 4 From 40.114.249.243, port 1700, Contents: 1:68:A7:1:
stat update: <219> {“stat”:{“time”:“2016-6-8 17:52:27 CET",“lati”:32.9847,“long”:-117.1789,“alti”:100,“rxnb”:3,“rxok”:3,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0,“pfrm”:“ESP8266”,“mail”:"tom@lafleur.us”,“desc”:“ESP Test Gateway”}}

1 Like
154

OK, I just got a node talking by setting it up as a ABP and NOT OTAA…
so, what is needed to do OTTA??

1 Like
155

OTAA requires a full gateway. For OTAA you need downlink (data to node) which is missing in single channel gateways according to this issue.

1 Like
156

A “single channel gateway” is just a “packet forwarder” and nothing more, a real Gateway can handle OTTA, scan all 8 channels, send data to actuators etc. LoRaWAN as an solution for future IoT applications demands real Gateways which complies to the LoRaWAN specs.

I believe that a lot of folks are trying to find a shortcut to more simple and cheaper solutions, and that is good as long as they understand the implications, lack of functionality is just one of them. A full Gateway is the key for good spectrum efficiency and this might be the most important thing for the future.

157

Relax :wink: It’ll be ok. I’m sure that when the normal gateways come online all these experimental stuff will be converted into a new cool project. How else can you test your nodes when you are not in reach of one of the few gateways that are present today.

2 Likes
158

:+1:

Exactly what I did. The single channel gateway was nice to see that my node works and what the packet forwarder does. As soon as this worked I ordered a ‘real’ LoRa concentrator and the RFM95W module is now being used to develop a new node.

This is a technical limitation. The join accept is send exactly 6s after the reception of the join request. Exactly is within a 20 micro-second window. The LoRa concentrator measures the time in the radio baseband chip but with this single channel gateway that is not possible.

1 Like
159

Just to explain, a “single channel gateway” is not a gateway, its just a packet forwarder and as such its working out of the box. You can have all of your experimental projects working, as I have, just out of the box :slight_smile: But its one way only, no information from the network to your nodes, just information from sensors to your application. You can subscribe to data with MQTT and it works. The coverage is excellent in my opinion and I when I get my hand on the real stuff my antennas will be much higher and the coverage even better.

When using a RN2483 for nodes, it will by default use a number of channels and as the single-channel-gateway is only listening on one channel most of the messages will be lost. One way to handle this problem is to force (fool) the module to use the same frequency for channels 3 to 7, this can be done via MAC SET CHANNEL COMMANDS defined in the spec. RN2483 LoRa TM TECHNOLOGY MODULE COMMAND REFERENCE USER’S GUIDE.

166

What I did to solve the scanning issue on a USA based system, was to tell the Node to ONLY use channel: 0
I’m using LMiC 1.5 on a SC GW with an ESP8266 and RFM95 radio.

// for now only TX on ch 0 , disable all others

for( u1_t i=1; i<64; i++ )
{
LMIC_disableChannel(i);
}

1 Like
167

I am waiting for my SX1276’s to arrive. So I’m studying the datasheet.

The datasheet tells that there is a CAD mode that can be used to check if there is a preamble signal on a channel. If I interpret it right, it can determine very quickly if there is a preamble present.

Would it be possible to use this CAD mode to quickly check all channels one by one and when a preamble is detected receive the message on that channel?

If so, the Single Channel Gateway (packet forwarder) would become a Multi Channel Gateway (packet forwarder) that can handle one message at a time…

Any thoughts?

168

I think not. I was wrong; see Jaap’s smart solution below.

You need to set the Spreading Factor, and while checking one channel, you’re ignoring the others:

https://www.thethingsnetwork.org/forum/t/four-channel-rpi-gateway-board/1794/3

…and:

https://www.thethingsnetwork.org/forum/t/rn2483-promiscuous-mode/2101/5

169

Continuing the discussion from Single Channel Gateway:

Are you sure the join accept has to be sent exactly 6s after the reception of the join request? The LoraWAN spec only specifies that the receiver has to start listening after 6s +/- 20 micro seconds. Just don’t start sending before 6 seconds + 20 microseconds.

Has anyone actually tried to send information back to the node?

170

After 6 seconds, the LoRa node will open a receive window to detect the preamble of the packet that is (can be) send by the gateway. When no preamble is found, the mode will stop listening.
See section 3.3.3 Receive window duration:

The length of a receive window must be at least the time required by the end-device‘s radio transceiver to effectively detect a downlink preamble.

The preamble is 8 symbols long and the receiver is set to detect (at least) 5 symbols as a valid preamble - at least with the Semtech stack. Some delay is possible but you still need to be within a reasonable time frame.

172

I ported the Single Channel Gateway to LUA running on a NodeMCU/ESP8266. It works!

I also implemented the download channel, so my gateway can send messages to the node too.

Now I will try to get the OTAA working…

4 Likes
173

would you “git” your final work? That’s very nice. Thanks.

174

OTTA works! My node can join the network via my LUA/ESP8266 gateway.

The joining process makes my node use the channels that I disabled, so my single channel gateway can only receive some messages.

I will try to listen to more than one channel now…

2 Likes
175

Yes, I will put my final work on git…

1 Like
176

…but it seems easy to disable them again, in the EV_JOINED event (for LMiC nodes)? (But you might want to somehow leave listening to SF9 in place; TTN will very likely send downlinks in RX2, and using SF9, like the Join Accept message will also tell your node.)

Yes, please surprise us! Nice work so far!

177

Yes, disabling the channels in the EV_JOINED event does the trick: all messages are sent on channel 0 now.

My node is an Arduino Pro Micro, running the LMIC port of matthijskooijman. In the LMIC library the frequency and SF are hardcoded for RX2. So there is no need to be careful about what channels to disable…

178

Sorry to ask newbie question, is Single Channel Gateway meaning can only support 1 end module ? Anybody has tried to use with more than 1 end module/node ?

179

No,a Single Channel Gateway only listens on one channel with one datarate. It will receive messages from all nodes that use that channel and that datarate.

2 Likes