Single Channel Packet Forwarder part 1 [Deprecated]

[No13]

Yeah I’ve been reading up on the differences between a gateway and ‘hacks’ like the single-channel test devices.
I realise I’m going to need a real gateway in the future but coverage in my area is completely non-existent so at the moment anything is better than nothing.

When I can “sell” this network and it’s uses to my other half I’ll buy an iC880A-SPI for example. But meanwhile I’d like to run my single channel gateway to test ideas and come up with some good arguments to sell this

“What’s that antenna doing on the roof?!”

I’ll swap out the RPI, especially the 1B models seem to lie everywhere

[greger-isaksson]

I totally love my RPI:s and also “the single channel gateway” in my projects. Your board should work as expected I think, my experiential setup and wiring with LMIC didn’t give me any problem, it is stable and working of shelf…

My setup is just for the neighborhood, and I have my own measurement equipment (from china)t to check the coverage, my setup for now is just for testing and solving an old problem, and its so good! But I am expecting “the real stuff” soon and then I will change from experimental to an real installation.

I expect (from china) and also from USA and Europe a lot of competition in this area, we will see sensors for peanuts and this is so cool. IoT in real life and this is a field I worked in for more than 20 years

“What’s that antenna doing on the roof?!” Antennas on the roof is my business, was my business before my retirement and the feeling of real freedom

/Greger

[trlafleur]

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”}}

---

[trlafleur]

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

[kersing (Jac Kersing)]

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

[greger-isaksson]

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.

[paulb]

Relax 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.

[Rob65]

@paulb

How else can you test your nodes when you are not in reach of one of the few gateways that are present today.

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.

@kersing

For OTAA you need downlink (data to node) which is missing in single channel gateways

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.

[greger-isaksson]

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 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.

[trlafleur]

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);
}

[old_jbraam (Jaap Braam)]

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?

[arjanvanb (Arjan)]

@jbraam

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?

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

[old_jbraam (Jaap Braam)]

Continuing the discussion from Single Channel Gateway:

@Rob65

@kersing

For OTAA you need downlink (data to node) which is missing in single channel gateways

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.

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?

[Rob65]

@jbraam

Are you sure the join accept has to be sent exactly 6s after the reception of the join request?

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.

[old_jbraam (Jaap Braam)]

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…

[ursm]

@jbraam

I ported the Single Channel Gateway to LUA running on a NodeMCU/ESP8266

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

[old_jbraam (Jaap Braam)]

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…

[old_jbraam (Jaap Braam)]

Yes, I will put my final work on git…

[arjanvanb (Arjan)]

@jbraam

The joining process makes my node use the channels that I disabled

…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.)

@jbraam

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

Yes, please surprise us! Nice work so far!

[old_jbraam (Jaap Braam)]

@"arjanvanb

…but it seems easy to disable them again, in the EV_JOINED event (for LMiC nodes)?

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

(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.)

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…