Deepsleep and adr not playing well together

[somervda]

I think there is an issue when using adr (automatic data rate) and deepsleep with nvram_save, nvram-restore together. I put my code I used to experiment up in git hub, see below.

https://github.com/somervda/lopybase/tree/0123726880345761a35d441d184a1b55b4eb34c3

I have a "useADR=True" variable in the config.py file to quickly swap between modes. The only way I could get things to work is NOT to set the socket data rate after returning from deepsleep/nvram_restore() when in ADR mode.

I'm guessing??? that something about adr settings being returned from the TTN gateway is not being save/restored in the non-volatile memory. I am forced to set the data rate at the socket level or I get TX errors (Usually EAGAIN ) Possibly this is also related to me using US915 frequency plan ?

lora_socket.setsockopt(socket.SOL_LORA, socket.SO_DR, 3)

Typical error

Using existing join
Sending data: b'\xbe\x9a\x96\xc2\xdd\xb2 B'
Traceback (most recent call last):
    File "main.py", line 56, in <module>
    File "lopyhelper.py", line 72, in send
OSError: [Errno 11] EAGAIN

My code working well enough for my needs , but I have a feeling the adr is not doing anything when I manually have to set the data rate at the socket level (Being non-adr is not a great loss, but would like to have it working).

[jcaron]

@somervda The pull request linked in that issue is actually completely unrelated (it just has the same number so it got linked by mistake apparently).

Not sure if that was ever actually fixed, one would have to dig into the sources to check. I was under the impression ADR ended up working with deep sleep at some point, but last time I tried it was ages ago and I don't quite remember the details.

[somervda]

Slight update. I should have said "The only way I could get things to work is to set the socket data..." rather than " The only way I could get things to work is NOT to set the socket data..." in third paragraph (NOT should not be there).

Also looking into github for the pycom firmware it looks like this is a known problem, see https://github.com/pycom/pycom-micropython-sigfox/issues/68 , however it says a fix went into the 1.20.2.rc10 release, but I am running this version and still see the problem.

My firmware version

os.uname()
(sysname='LoPy4', nodename='LoPy4', release='1.20.2.rc10', version='v1.11-a159dee on 2020-06-26', machine='LoPy4 with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.5.1')