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.
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.
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.
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++ )
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…
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:
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?
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.
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…
would you “git” your final work? That’s very nice. Thanks.
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…
Yes, I will put my final work on git…
…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!
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…
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 ?
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.
Thanks @jbraam, Based on people experience here, how many nodes can a Single Channel Gateway can support ?
I had 4 nodes working with it.
But for me it’s only a testing environment, because ACK is not supported (look [here])(ACK is supported or not?)
That very much depends on how much data each node sends, and how often.
The TTN Fair Access Policy maximum of 30 seconds airtime per node, per day, is based on on supporting at least 1,000 nodes per gateway, using 8 frequencies. So that would probably translate to 125 single-channel nodes for a single-channel gateway, if they send 30 seconds per day. (Regular, multi-channel nodes will be alternating the frequencies they use, so would only see 1/8th of their traffic being received by a single-channel gateway.)
In many other places, 8-channel gateways are advertised to support over 10,000 nodes.
But beware: those nodes cannot send at the same time, and there’s no synchronization in place. So if multiple nodes send simultaneously, data will be lost. But that’s the same for multi-channel gateways, when multiple nodes are sending simultaneously using the same frequency and spreading factor.
I published my Lua Single Channel gateway on GitHub.
It is still in its early stage, but it listens on EU channel 0, SF7BW125. Upload messages work, so sending messages to nodes and OTAA is possible (works for me )