Thanks @JBraam…Where did you buy hardware? Any help. Also , is there any blogs for this gateway?
Best community,
I have recently setup a single channel gateway with a Dragino lora shield on a RPi2 in order to learn a bit about the lora technology implemented on the TTN.
We are aware of the not compatability of the single channel gateway in the sense that the TTN backend does not fully allow it, be it only in downlink.
At this very moment our gateway with id b827ebffff909fff is running and recognized as uplink active (N/A for downlink though): https://staging.thethingsnetwork.org/gatewaystatus/
However, it does not show up with api, nor json details on the following page : https://www.thethingsnetwork.org/api/v0/gateways/b827ebffff909fff/
Is this one of these constraints with the new TTN backend ?
All comment is very welcome.
For hardware I use a Wemos D1 mini (clone) bought on AliExpress and a RFM95 also bought on AliExpress. The RFM95 is soldered on an ESP adapter board (also bought on AliExpress). I placed both components on a protoboard and used wirewrapping to make the connections.
At the moment there is only the readme.md on github. I’ll write a blog later…
Just posted version 3.1 of the 1-channel software for ESP8266 on github. Major changes:
-
Use the 1-ch gateway as a sensor. See readme file for more info or the _sensor.ino file where this code is defined. It is possible to use local sensors and forward them to the backend as if they are coming from a LoRa node. You have to assign a DevAddr and password to this “node” and use ttnctl etc. to define a sensor for it on the backend system.
-
downlink functions for SF9-SF12. You have to set the #define _STRICT_1CH to 1 in the configuration file to force the gateway to use the same frequency and SF setting as used by the node. As TTN will reply in RX2 timeslot (possibly changing SF to SF12 and freq to 869.525 MHz) the gateway will adjust freq, SF and delay timing to reply in RX1 slot.
-
Bug fixes etc.
Github code: <https://github.com/things4u/ESP-1ch-Gateway-v3.0>
5 Likes
Why are you doing this? This is not good for the network.
Even if you run nodes on only a single channel (uplink), why would you not stick to the LoRaWAN standard for downlink. All stacks will listen to the RX2 frequency at the RX2 data rate in the RX2 slot. And the TTN backend switches between RX1 and RX2 for a good reason, to optimize network capacity.
2 Likes
I agree!
The beauty of the LoRaWAN standard is that the network decides what message to send when. The gateway just sends the message it is ‘ordered’ to send precisely on the time it is ‘ordered’ to send it. The network decides what frequency, SF, CRC, txpower etc settings to use. That way things like ADR and class B devices can be supported by implementing them in the network servers, without changing existing gateways.
Nice, even if only used for a hardware “check connectivity” button!
Nice!! Really like that feature to be implemented in the poly_packet_forwarder, so the GW can sent temp cpu load etc 
If i knew how, i would already have done it.
Why are you doing this? This is not good for the network.
Even if you run nodes on only a single channel (uplink), why would you not stick to the LoRaWAN standard for downlink. All stacks will listen to the RX2 frequency at the RX2 data rate in the RX2 slot. And the TTN backend switches between RX1 and RX2 for a good reason, to optimize network capacity.
I changed the configuration file to use the network settings as the default.
But I think TTN answers on SF9, and not on SF12 according to standard.
Hello,
Did anyone manage to make it work under RPi Zero? I have it working fine with RPi 3, but the code does not with RPi Zero as I have the GW flooded with a zero length messages:
Packet RSSI: -112 RSSI: -113 SNR: -12 Length: 0
rxpk update: {“rxpk”:[{“tmst”:445526776
I got 5-7 message per second as soon as I start the GW software and it does not stop.
Any idea how to solve it please?
Many thanks
Alex
Running the v3.2 1Ch gway code on NodeMCU/RFM95W and I get confirmation of an active gateway here: https://staging.thethingsnetwork.org/gatewaystatus/
and I see my two functioning nodes data up on my staging.TTN/applications page but I don’t see my gateway here https://www.thethingsnetwork.org/api/v0/gateways/ or when I include my EUI here: https://www.thethingsnetwork.org/api/v0/gateways/5CCF7FFFFF8BC60E/ I see old data from 10/31 when the V2 code was running but nothing since running the V3.2 code.
There was a bug in the Lat/Lon string size and I fixed that. I also tried using 5 decimal places on the Lat/Lon in the status messages since I saw 5 decimal places listed in the gateway API listings. Any ideas on how to debug this?
@wdebbaut:
Did you try using uppercase for the id in the API URL:
https://www.thethingsnetwork.org/api/v0/gateways/B827EBFFFF909FFF/
instead of
https://www.thethingsnetwork.org/api/v0/gateways/b827ebffff909fff/
I had the same issue using lowercase, but trying uppercase fixed it.
I hope it helps and excuse me if you already received replies/solutions - I do not see replies on this forum, just trying to help:)
tnx for your reply Milen, in the meantime we have a multichannel gateway to experiment with - the Lorrier device LR2 - because the single channel is not really compatible with the project we are working on. This LR2 is in fact a combination of the IMST Lora concentrator iC880A, a Beaglebone Green as MCU and Mikrotik board as IP interface.
We modified the Dragino board into a lora node and in this way we are able to send the messages from this node via the multichannel gateway up to the WirelessThings, aka TTN backend with no problems. We even succeeded in sending the payload up to 30km !
Wish you all the very best with you endeavors in this exciting field of RF and IP.
Wim.
For those of you using @Thomas’ single channel packet gateway and looking for a way to automate the deployment, I’ve merged several of the pull requests and added debian packaging files to create a .deb package.
My fork of the code can be found at https://github.com/proffalken/single_chan_pkt_fwd and I’d welcome someone testing that it works because my Dragino LoraShield is still in the post!
Contributions/comments/etc. always accepted
1 Like
where did you buy that shield from?
@exquisitus - I got it from Ebay: http://www.ebay.co.uk/itm/272267571206?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
I purchased it after talking with a few people in the Slack channels
Optimization in the CAD procedure for MultiSF (Application Note from Semtech):
The use of a spread spectrum modulation technique presents challenges in determining whether the channel is already in use by a signal that may be below the noise floor of the receiver. The use of the RSSI in this situation would clearly be impracticable. To this end, the channel activity detector is used to detect the presence of a LoRa preamble signal. The CAD behavior is similar to a standard preamble detection used widely with other RF modulations to detect if a message is being sent.
As the LoRa signal can be below the noise floor, there is a non negligible statistical probability that the LoRa CAD detector may trig on RF noise and thus create a false detection. To drastically reduce false detection while using the CAD, it is advised to perform a second CAD after a first valid CAD detected.
The process to perform a double CAD is described below:
Dual CAD state diagram
It is essential to clear the interrupts generated by the radio to ensure good operation of the process. Using this method, the ratio of false detection goes from 1% to virtually 0%.
1 Like