Your ‘gateway’ is providing services to anyone close to it, not only you. So why not stay in-line with the LoRaWAN specification as much as possible given the hardware limitations? Having a 1 channel ‘gateway’ is better than no gateway only if it follows specs (within technical limitations).
You are fully right but, by now, i am only thinking in debug mode and as far I know, single channel gateways work better in a single SF and again, as far I know, TTN uses SF9 for its RX2 window (my gw only works in SF10) …Maybe should I set node and gw in SF9 instead SF10?
Am I right? Thanks!
You ‘gateway’ listens at a single spreading factor, sending can be at any SF as requested by the back-end as far as I know.
This is from my gw firmware:
// Single channel gateways if they behave strict should only use one frequency
// channel and one spreading factor. However, the TTN backend replies on RX2
// timeslot for spreading factors SF9-SF12.
// Also, the server will respond with SF12 in the RX2 timeslot.
// If the 1ch gateway is working in and for nodes that ONLY transmit and receive on the set
// and agreed frequency and spreading factor. make sure to set STRICT to 1.
// In this case, the frequency and spreading factor for downlink messages is adapted by this
// gateway
// NOTE: If your node has only one frequency enabled and one SF, you must set this to 1
// in order to receive downlink messages
#define _STRICT_1CH 1
I think in this (my) case, the gateway ignores the adaptative data rate message from server and continues forwading node packets with the SF and BW pre-set.
I suppose, anyway, as you told, that the gateway is loosing packets for that reason…
PS:Despite that, this morning is working better than other days and i am loosing only 1/10 
ADR is a totally different mechanism. That mechanism provides information to a node to allow/force it to optimize its communication settings. For nodes with only a single channel ‘gateway’ in radio coverage that mechanism could destroy the communication path (it could instruct the node to switch to a different SF which the ‘gateway’ does not support). So you should not enable ADR on your node.
What STRICT_1CH does is force the ‘gateway’ to ignore the SF and frequency settings of any downlink packet. That only works if all nodes within coverage that do use downlinks are also modified for this purpose. You can modify your nodes, others within coverage can’t as they do not know they need to. Because it makes the non compliant ‘gateway’ less compliant it is not a good idea and it is not required so my advice is to change the setting.
The gateway acts as an ADR messages firewall so they doesnt arrive to node, I mean, the gateway re-write those messages (i.e. if server sends new DR1, DR3…etc, the gw always sends to node DR2 (SF10/125Khz))
At the time, in Spain, there is only a few of active gateways. In 15 km around there is no more gws, so I suppose nobody is working with lorawan 
, in addition TTN says that doesnt show single channel gateways because they are not full compilance 
This is the log from 1 TX:
EV_TXCOMPLETE (includes waiting for RX windows)
152117219: Scheduled job 0x3ffc4720, cb 0x400d1a54 at 153992219
152117571: engineUpdate, opmode=0x900
153992219: Running job 0x3ffc4720, cb 0x400d1a54, deadline 153992219
Valid gps Fix.
0
1
2
3
4
154054693: engineUpdate, opmode=0x908
154054697: Uplink data pending
154054700: Considering band 0, which is available at 1299
154054865: Considering band 3, which is available at 0
154055168: No channel found in band 3
154055380: Considering band 0, which is available at 1299
154055700: No channel found in band 0
154055912: Considering band 1, which is available at 153260034
154056259: Considering band 2, which is available at 1299
154056579: No channel found in band 2
154056791: Considering band 1, which is available at 153260034
154057138: Airtime available at 153260034 (channel duty limit)
154057485: Ready for uplink
154057659: Updating info for TX at 154054697, airtime will be 12864. Setting available time for band 1 to 155341097
154058297: TXMODE, freq=868100000, len=24, SF=9, BW=125, CR=4/5, IH=0
Packet queued
154071172: irq: dio: 0x0 flags: 0x8
154071180: Scheduled job 0x3ffc8c58, cb 0x400d2a30 ASAP
154071185: Running job 0x3ffc8c58, cb 0x400d2a30, deadline 0
154071326: Scheduled job 0x3ffc8c58, cb 0x400d2738 at 154133929
154133929: Running job 0x3ffc8c58, cb 0x400d2738, deadline 154133929
154134056: RXMODE_SINGLE, freq=868100000, SF=9, BW=125, CR=4/5, IH=0
154135356: irq: dio: 0x1 flags: 0x80
154135364: Scheduled job 0x3ffc8c58, cb 0x400d3f58 ASAP
154135369: Running job 0x3ffc8c58, cb 0x400d3f58, deadline 0
154135515: Scheduled job 0x3ffc8c58, cb 0x400d2788 at 154196429
154196429: Running job 0x3ffc8c58, cb 0x400d2788, deadline 154196429
154196556: RXMODE_SINGLE, freq=869525000, SF=9, BW=125, CR=4/5, IH=0
154197856: irq: dio: 0x1 flags: 0x80
154197864: Scheduled job 0x3ffc8c58, cb 0x400d3f88 ASAP
154197869: Running job 0x3ffc8c58, cb 0x400d3f88, deadline 0
EV_TXCOMPLETE (includes waiting for RX windows)It can’t. ADR information is contained in messages created by the back-end with information for the node. A gateway can not change the contents of messages as these are signed using a key that is not present on the gateway.
The only thing the gateway can change is the SF and frequency it uses for transmission.
Your node expects data in RX2 to be at the TTN standard frequency and SF. With your current settings downlink data will never work. (TTN chooses RX2 if an uplink uses SF10 and higher and your ‘gaeway’ sends RX2 messages at the wrong SF and frequency for this node setup.)
If you choose not to change the setting, please don’t ask for help when you want to use downlinks later on, I;ve given you plenty of pointers what needs to be done…
1 Like
…for the node in order to improve radio link with gateway
And I appreciate them but, if I only have one scg I can not put the settings that you say because the link would not work (in fact, before,It was configured as you said and didnt enter any data packet to the server).
In spite of this, I will continue investigating how, in my situation, with my hardware, I could improve the reception of messages in TTN.
I just noticed that this type of issues are commented in another post, I will move there.
thaks anyway
Hello I have just purchased a ttgo-tbeam. I’m trying to add it to the things network. I can’t seem to find the DevEUI on the device. Is there any other way to get the deveui if its not on the device?
TTN can provide DevEUI for you, Just press the button and number will be generate (you can change it later)
Thank you
Sorry last question. Is there a default image I can flash the tbeam. The wifi has stopped working so I was going to try and re-install the firm ware? is this done through arduino? or linux?
I took from here Github T-Beam but I had to modify several parameters in order to adapt it to my gw and cayenne
I am happy endly 
It is fully working with TTN and sending gps data to Cayenne
While this definitely works, it is also a good practice to derive DevEUI from the device unique id when it has one.
On ESP32 nodes you can use the MAC address for that – See example here.
Effective from July 13th, LilyGO ships T-Beam boards with this firmware (variant for ESP32) been factory pre-installed by default.
thank you that worked.
Thank you Linar 
Beware that SoftRF is not lorawan (So doesnt work with TTN). SoftRF only works with radio layer…
It is not 100% true statement. It would be more accurate to say: " it does not work with the TTN by default ".
Custom firmware builders may enable, setup and take advantage of optional “TTN Mapper” feature .