Any reason for resetting REG_FIFO_ADDR_PTR in LoRaClass::handleDio0Rise() ?

[iw2lsi]

Hi all,

just a doubt.. what's the reason of resetting REG_FIFO_ADDR_PTR register at the end of the handleDio0Rise() function ?

I cannot find anything pointing in this direction in the datasheets... and it seems to me dangerous in case another packet is incoming while we are executing the _onReceive()...

If this is fine... shouldn't we pospone the reset of the IRQ flags after the line:

writeRegister(REG_FIFO_ADDR_PTR, 0) ?

Best Regards

        Giampaolo

[keithr0]

This caused me problems with an interrupt driven receive application giving incorrect packet contents until that statement was removed. REG_FIFO_ADDR_PTR should point to the start of the current packet as is done a couple of statements back with
writeRegister(REG_FIFO_ADDR_PTR, readRegister(REG_FIFO_RX_CURRENT_ADDR));
Resetting it to zero does not appear to make any sense.

[notascooby]

I have same issue with interrupt driven receive. Master sends a command, slave acknowledges, then acknowledges a second time 4 seconds after first acknowledgement. The LoRa buffer includes both the first acknowledgement and part of the second. ESP32 has to be reset before OnReceive works again.
Deleting REG_FIFO_ADDR_PTR at line 584 in LoRa.cpp (library version 0.5.0) solves problem.
Haven't seen any problems after 1 day continuous use, with messages of around 15 characters.

[iw2lsi]

That's fine...

we are also working without writeRegister(REG_FIFO_ADDR_PTR, 0) at line 583 and it seems to work...

Sandeep what do you think ?

[morganrallen]

Hi just wanted to say I've been following this issue. I have a strong recollection there is a specific reason the reset occurs early (I do the same in esp32-lora). Can someone provide a concrete test case I can work with later this week?

[notascooby]

Thanks iw2lsi, will do and if I see any issues message them here.

[sandeepmistry]

@iw2lsi the fastest way to move on this would be to open a pull request with the suggested, and also provide two sketches (sender and receiver) that can be used to reproduce the issue as @morganrallen suggested above.

[iw2lsi]

Hello Sandeep,

sorry for the delay... I can open the pull request but I have no code reproducing any issues... as I was just wondering myself what happens (with line 583 on) in case of two consecutive packets.

  Giampaolo

[notascooby]

Have written two sketch’s yesterday but need to test to check they exhibit problem. Will upload this week if I see the same issue but won’t be until late Thursday or Friday due to day job Sent from iPhone

…

On 6 Feb 2019, at 08:27, iw2lsi ***@***.***> wrote: Hello Sandeep, sorry for the delay... I can open the pull request but I have no code reproducing any issues... as I was just wondering myself what happens (with line 583 on) in case of two consecutive packets. Giampaolo — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[keithr0]

There is no need to write new sketches, using LoRaSender.ino and LoRaReceiverCallback1.ino in the examples directories adequately demonstrate the problem
With line 583 included
Received packet 'Block 82' with RSSI -48
Received packet 'Block 82' with RSSI -48
Received packet 'Block 82' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'Block 82B' with RSSI -49
Received packet 'k 112 82B' with RSSI -49
Received packet 'k 112Bloc' with RSSI -49
Received packet 'k 112Bloc' with RSSI -49
Received packet 'k 112Bloc' with RSSI -49

With line 583 commented out
Received packet 'Block 209' with RSSI -49
Received packet 'Block 210' with RSSI -49
Received packet 'Block 211' with RSSI -49
Received packet 'Block 212' with RSSI -48
Received packet 'Block 213' with RSSI -49
Received packet 'Block 214' with RSSI -49
Received packet 'Block 215' with RSSI -49
Received packet 'Block 216' with RSSI -49
Received packet 'Block 217' with RSSI -47
Received packet 'Block 218' with RSSI -49
Received packet 'Block 219' with RSSI -49
Received packet 'Block 220' with RSSI -49
etc

Hi,

I had similar results as keithr0, i.e. it looked like the receive buffer was losing its position. Taking the advice from above I commented out line 583 and I haven't had a problem since. Thanks to Sandeep and the commentors.