search

things4u / ESP-1ch-Gateway

Version 6 of the single channel gateway
MIT License
364 stars 147 forks source link

Downlink not working #26

Open gianni-carbone opened 4 years ago

gianni-carbone commented 4 years ago

Hi, at first my compliments for the good work. I'm using gateway since version "V.5.3.3.H; 180825a", now upgraded at "V.6.2.3.E.EU868; PlatformIO 200223a" Platform is Heltek WiFi Lora 32 (V2) that perfectly work uplinks but not by downlinks. here a piece of debug (please note stateMachine: S_CAD opmode(OPMODE_RX_SINGLE) is a piece of output I placed just before calling opmode(OPMODE_RX_SINGLE) in the stateMachine function) It seems that PKT_PULL_RESP arrives very late... Any suggestion? Thanks in advance

02:49:39.494 -> stateMachine: S_CAD opmode(OPMODE_RX_SINGLE) 02:49:51.163 -> initLoraModem: SX1276 starting 02:49:51.163 -> initLoraModem: SX1276 start OK 02:49:51.196 -> readUdp:: PKT_PULL_RESP received from IP=52.169.76.203 02:49:51.230 -> txLoraModem:: powe: 14, freq: 868100000, crc: 0, iiq: 0X40 02:49:51.230 -> loraWait:: Error wait time < 0 02:49:51.230 -> txLoraModem: opmode(OPMODE_TX) 02:50:04.354 -> stateMachine: S_SCAN opmode(OPMODE_RX_SINGLE)

platenspeler commented 4 years ago

I am working on another release of the software that does not use the current huge delay. However, I need to test it and especially the loraWait() function.

demonday commented 4 years ago

Thanks Maarten. Happy to give it a test when you are ready.

platenspeler commented 4 years ago

I have included version 6.2.4 which reads the uploads. Let meknow if this version works better. It does in my place. (Please update all source files).

platenspeler commented 4 years ago

So, any news on the download? I slimmed down the version a lot, so if all right the dowloads should work.

aeslami commented 4 years ago

Same issue here. OTAA and uplink works perfectly but no downlink at all

andrew01144 commented 4 years ago

Hi - My Gateway seems never to send a packet, even though the debug and stats say that it does. Any suggestions for me to debug it? Is there simply a flag I need to enable?

Using V.6.2.5.EU868. Gateway is an ESP32-MiniKit with a Hallard-like LoRa shield. My Node is a T-Beam, using ABP.

Uplink is reliable. Downlink and OTAA don't work. I have tried swapping the ESP32-MiniKit and T-Beam with each other: Same behavior, so I don't think it's a hardware issue. I have tried driving to a public Gateway to test my Node - and Downlink works there.

BTW - I am fairly new to this. I have never had Downlink working. (I tried V5.3.3, but it crashed on Downlink)

Here is a simple Uplink message: 13:35:50.415 -> UP receivePkt:: rxPkt: t=Mon 20-07-2020 14:35:48, f=0, sf=7, a=26:01:15:90:, flags=50, addr=0, len=23 13:35:50.449 -> UP RXPK:: {"rxpk":[{"chan":0,"rfch":0,"freq":868.099975,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":6,"rssi":-30,"size":23,"data":"QJAVASYADAAK9SEEyvEMk2MgiMyRToo=","tmst":1330086125}]} , length=204

Now, I will schedule a downlink message, and send another Uplink. 13:36:33.622 -> UP receivePkt:: rxPkt: t=Mon 20-07-2020 14:36:31, f=0, sf=7, a=26:01:15:90:, flags=50, addr=0, len=23 13:36:33.622 -> UP RXPK:: {"rxpk":[{"chan":0,"rfch":0,"freq":868.099975,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":6,"rssi":-30,"size":23,"data":"QJAVASYADQAKAczFrUv6hRkHfhybgRg=","tmst":1373272200}]} , length=204 13:36:34.887 -> Dwn sendPacket:: {"txpk":{"imme":false,"tmst":1374272200,"freq":868.099975,"rfch":0,"powe":14,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":17,"ncrc":true,"data":"YJAVASYAKgABapkwRrenf1s="}} 13:36:34.887 -> Dwn txLoraModem:: end: micr=1374.518285, tmst=1374.272200, wait=(246085), SF=7, Freq=868100000, a=26:01:15:90: 13:36:34.921 -> Dwn stateMachine: TXDONE OK: rcvd=1374.564847, diff=0.292754

Many thanks!

hujiese commented 4 years ago

Hi, at first my compliments for the good work. I'm using gateway since version "V.5.3.3.H; 180825a", now upgraded at "V.6.2.3.E.EU868; PlatformIO 200223a" Platform is Heltek WiFi Lora 32 (V2) that perfectly work uplinks but not by downlinks. here a piece of debug (please note stateMachine: S_CAD opmode(OPMODE_RX_SINGLE) is a piece of output I placed just before calling opmode(OPMODE_RX_SINGLE) in the stateMachine function) It seems that PKT_PULL_RESP arrives very late... Any suggestion? Thanks in advance

02:49:39.494 -> stateMachine: S_CAD opmode(OPMODE_RX_SINGLE) 02:49:51.163 -> initLoraModem: SX1276 starting 02:49:51.163 -> initLoraModem: SX1276 start OK 02:49:51.196 -> readUdp:: PKT_PULL_RESP received from IP=52.169.76.203 02:49:51.230 -> txLoraModem:: powe: 14, freq: 868100000, crc: 0, iiq: 0X40 02:49:51.230 -> loraWait:: Error wait time < 0 02:49:51.230 -> txLoraModem: opmode(OPMODE_TX) 02:50:04.354 -> stateMachine: S_SCAN opmode(OPMODE_RX_SINGLE)

Hi, at first my compliments for the good work. I'm using gateway since version "V.5.3.3.H; 180825a", now upgraded at "V.6.2.3.E.EU868; PlatformIO 200223a" Platform is Heltek WiFi Lora 32 (V2) that perfectly work uplinks but not by downlinks. here a piece of debug (please note stateMachine: S_CAD opmode(OPMODE_RX_SINGLE) is a piece of output I placed just before calling opmode(OPMODE_RX_SINGLE) in the stateMachine function) It seems that PKT_PULL_RESP arrives very late... Any suggestion? Thanks in advance

02:49:39.494 -> stateMachine: S_CAD opmode(OPMODE_RX_SINGLE) 02:49:51.163 -> initLoraModem: SX1276 starting 02:49:51.163 -> initLoraModem: SX1276 start OK 02:49:51.196 -> readUdp:: PKT_PULL_RESP received from IP=52.169.76.203 02:49:51.230 -> txLoraModem:: powe: 14, freq: 868100000, crc: 0, iiq: 0X40 02:49:51.230 -> loraWait:: Error wait time < 0 02:49:51.230 -> txLoraModem: opmode(OPMODE_TX) 02:50:04.354 -> stateMachine: S_SCAN opmode(OPMODE_RX_SINGLE)

Have you solved the problem？

Samuel-ZDM commented 3 years ago

I have the same problem. I can see the messages on the terminal, and the standard SF is different from the TTN, it's 12 instead of My issue with the terminal message #51

itsygithub commented 3 years ago

I have corrected frequency in json file which will also solve the problem with downlink. I created a pull request from my fork.

IoTThinks commented 3 years ago

I have corrected frequency in json file which will also solve the problem with downlink. I created a pull request from my fork.

@itsygithub : So you can make downlink to work? How about OTAA?

Thanks milions.

itsygithub commented 3 years ago

OTAA works and downlink will also be send. But I have not testet to receive the downlink.

IoTThinks commented 3 years ago

@itsygithub If OTAA works, then very likely downlink will works. I will try next week with 920-923Mhz frequency.

Thanks for your PR https://github.com/things4u/ESP-1ch-Gateway/pull/72 :D

andrew01144 commented 3 years ago

FYI @IoTThinks , @itsygithub I tried this new code for Downlink at 868MHz; it seemed not to work for me. I did not try OTAA; I might try that if I get a chance.

itsygithub commented 3 years ago

Did you tried with TTN V2 or V3? Could you see message for Downlink in TTN and also on gateway website?

andrew01144 commented 3 years ago

TTN V2. The gateway's serial debug and web page showed the Downlink message being sent, but my TTN node did not receive it. As mentioned above, I am pretty sure the node's Downlink receive works because I have tested it on a public gateway.

itsygithub commented 3 years ago

unfortunately I can't test but maybe you can try some tests with this setting:

// NOTE: If your node has only one frequency enabled and one SF, you must set this to 1 // in order to receive downlink messages. This is the default mode. // NOTE: In all other cases, value 0 works for most gateways with CAD enabled

if !defined _STRICT_1CH

define _STRICT_1CH 1

endif

andrew01144 commented 3 years ago

It was tested with #define _STRICT_1CH 1. BTW - I don't need this to work. I am just playing around.