LoPy4: LoRaWAN: setting ACK flag

[toughrock]

Re: LoPy: Confirmed Downlink not supported by design?

Dear all,
My apologies to create a new topic on the same issue, yet I could not solve the problem with the provided information.
I am figuring a way to explicitly set the ACK flag, other than saving NVRAM or preventing the LoPy from going to sleep in order to keep track of the message exchange.
The Dutch service provider I am using (KPN Things), endorses LoPy4, being this the reason to have chosen such hardware. This same provider requires the ACK flag to be set in order to download the next message from the queue. No ACK on the upload, the poll gets stuck.
From LoRaWAN documentation I found this flag is the fifth bit of the fifth byte of the frame header. Unfortunately I found no way to go that low on the code.
Using this pretty good example:
https://docs.pycom.io/tutorials/lora/lorawan-otaa/
I managed to send information to the service provider API and receive the first payload I previously placed on the queue, but then this payload queue got stuck.
After reading the forum post I am referring to, I could incidentally send an ACK on an upload with a slight modification on the example: uploading something just after receiving. This was merely incidental, I could not recreate such conditions ever again.
Every suggestion is appreciated, once this situation is starting to be frustrating.
Relevant data:
Device: LoPy4 on 1.20.0.rc13
Authentication: OTAA
Service provider: KPN (Things) - EU: 868MHz - Country: NL
Cheers!

[jcaron]

@toughrock Can you explain us why you don't want to save NVRAM?

The ACK flag is a LoRaWAN feature that is driven automatically by the LoRaWAN stack. When you receive a (confirmed) downlink, the next uplink will have the ACK flag set, so the network knows the downlink has been received and it can send the next one (otherwise it will send the same downlink again).

If the network and/or network API and/or server support it, you could simply set the downlink as UNCONFIRMED and you would not need the ACK to be set.

But going to deep sleep without saving the LoRaWAN state will result in a lot more issues than just a missing ACK flag:

• Frame counters will be reset
• You would have to re-join each time, which is time-consuming
• Other MAC commands would have no effect, such as channel list updates, ADR, etc.

So, what's your issue with saving the LoRaWAN state?