Cannot receive ACK

[webfrank]

Hi, I've just compiled and installed the software on a NodeMCU board with a SX1276 radio. This same setup has been successfully used with the Lua 1CH gateway. With this implementation I cannot receive the ACK from the gateway. I setup a fixed SF12 on 868.1 MHz and enabled strict mode, but on console after receiving the uplink there is a loop of "TX:00" (from _stateMachine.ino) and no ACK is received.

Are downlinks working or is a work in progress?

rxPkt:: t=16:31:11, f=0, sf=12, a=0B0F0001, flags=50, addr=0, len=17
PKT_PULL_RESP:: received
sendPacket:: LoraDown filled
sendPacket:: fini OK
readUdp:: TX buff filled
PKT_TX_ACK:: tmst=580311948
TX:00
TX:00
TX:00
TX:00
TX:00
TX:00
TX:00
TX:00
TX:00
.......

[craigpeacock]

Timely post.

I'm been using this code on a LoRaGo DOCK from Sandbox Electronics and I'm having the same issue with Downlink packets from The Things Network.

PKT_PULL_DATA request, len=<12> 1:78:D8:2:2C:3A:E8:FF:FF:45:F:FE:

S_RX:: no RXDONE or RXTOUT intr=0 PKT_PULL_RESP:: received {"txpk":{"imme":false,"tmst":69802338,"freq":923.3,"rfch":0,"powe":20,"modu":"LORA","datr":"SF12BW500","codr":"4/5","ipol":true,"size":17,"ncrc":true,"data":"IPNvDaaFDZH1+EKDPZ4Pp5s="}} <data: IPNvDaaFDZH1+EKDPZ4Pp5s= sendPacket:: LoraDown filled Request:: tmst=69802338 wait=885441 strict=0 datr=SF12BW500 freq=916800000 ->923300000 sf =7 ->12 modu=LORA powe=20 codr=4/5 ipol=1

20:F3:6F:D:A6:85:D:91:F5:F8:42:83:3D:9E:F:A7:9B: sendPacket:: fini OK readUdp:: TX buff filled PKT_TX_ACK:: tmst=68936722 PKT_PULL_RESP:: size 189 From 52.62.83.250, port 1700, data: txpk... PKT_PULL_ACK:: size 4 From 52.62.83.250, port 1700, data: 1:78:D8:4: TX:00 TX:00 TX:00 ... ... TX:00 TX:00 REINIT S_RX:: no RXDONE or RXTOUT intr=0

Yesterday, I tried on a NodeMCU with SX1276 just to verify it hasn't the hardware. I'm checking 923.3MHz with a spectrum analyser and I don't see a peep from the device.

The code is interesting:

case S_TX:

  if (intr == 0x00) {

if DUSB>=1

      Serial.println(F("TX:00"));
      writeRegister(REG_IRQ_FLAGS, (uint8_t) 0xFF);               // reset interrupt flags
      _event=0;
      return;

endif

  }

  // Sset state to transmit
  _state = S_TXDONE;
  writeRegister(REG_IRQ_FLAGS_MASK, (uint8_t) 0x00);
  writeRegister(REG_IRQ_FLAGS, (uint8_t) 0xFF);                   // reset interrupt flags

  // Initiate the transmission of the buffer (in Interrupt space)
  // We react on ALL interrupts if we are in TX state.
  txLoraModem(
      LoraDown.payLoad,
      LoraDown.payLength,
      LoraDown.tmst,
      LoraDown.sfTx,
      LoraDown.powe,
      LoraDown.fff,
      LoraDown.crc,
      LoraDown.iiq
  );

I'm not sure about the placement of the return (seems to only be good for DSUB>=1). If I comment it out, I do see a peep on the spectrum analyser but the device locks up.

Let to work out how the interrupts/interrupt flags work.

[rk125]

Same for me with Brocaar's loraserver.io If set DUSB 0 then gw locks immediately after 1st lora packet received. If DUSB 1 - fills console log with "TX:00" If debug level increased, log fills with: S_RX:: no RXDONE, RXTOUT, HEADER:: I= -- , F=0, SF=9, E=0, S=RX , t=500261896 S_RX:: no RXDONE, RXTOUT, HEADER:: I= -- , F=0, SF=9, E=0, S=RX , t=500269009 S_RX:: no RXDONE, RXTOUT, HEADER:: I= -- , F=0, SF=9, E=0, S=RX , t=500276123 S_RX:: no RXDONE, RXTOUT, HEADER:: I= -- , F=0, SF=9, E=0, S=RX , t=500283236 S_RX:: no RXDONE, RXTOUT, HEADER:: I= -- , F=0, SF=9, E=0, S=RX , t=500290350

Packet receive seem to be working. After some time (once a day or so for me) gw locks up (ping works, but web page does not refresh).

Seems to me it started to happen after lora server update some time ago (did not catch the moment though).

[platenspeler]

Still occuring with the latest software version 5.2.0? I try to make the state machine output as little as possible.

Maarten

[craigpeacock]

Thanks Maarten. I've just installed 5.2.0 on my LoRaGo Dock and can confirm downlink is still not working properly.

[rk125]

Maarten, I moved back to v4 for now, it is more stable. I'm using sensors for receive only for a moment and do not see breaks in data receive flow (gw does not seem to lock and stop receive, like it was in v5) On v5 _stateMachine.ino lines 778 to 783 - is this piece right? Cause setting DUSB to 0 would change if we write to register or not. Reggie

[platenspeler]

Think you for your help. I tested myself, difficult enough since I have a dozen single channels, 2 normal gateways and there are some gateways in Apeldoorn. But found out I must have made a mistake along the line somewhere.

I made version 5.2.1 and it seems to work right now (_STRICT_1CH 0). I plan to download shortly, hope you have time to try.

Thanks,

Maarten

(Tested normal downlink messages oly, no OTAA yet but this might work too).

[halukmy]

where is 5.2.1 ? @platenspeler

[platenspeler]

Like I said .. I plan to I have uploaded an intitial version in 5.2.1. It seems to work for my sensor and gateway combination. Please let me know if it works for you.

Maarten

[halukmy]

@platenspeler very very gooood! my pray with you, hope you will handle downlink and control ( on/off node)

there were a buddy name is Zenghi, he were told on issue page handle the downlink message..

hope you willh andle very soon

thanks buddy

[rk125]

Marteen, 5.2.1 does not compile when DUSB=0 Error: /arduinoSketch/lora/ESP/1ch_gw/ESP-1ch-Gateway-v5.0/ESP-sc-gway/_stateMachine.ino: In function 'void stateMachine()': _stateMachine:139: error: expected primary-expression before '}' token } ^ _stateMachine:139: error: expected ';' before '}' token

Compiles fine with DUSB=1.

Reggie

[platenspeler]

Thanks,

What version of 5.2.x are you using? Mine compiles fine with DUSB==0, so I like to understand whether we use same version and flag settings.

Maarten

[platenspeler]

I think I found it:: Empty #if statement and therefiore empty default: part of switch statement is not OK for compiler

[rk125]

Yep, latest pull compiles ok. Will try on gateway in evening. Thank you! Reggie

[platenspeler]

Please use latest version on github.