Orne Brocaar

@IoTThinks I think we are mixing two things in this discussion, what is needed to test LR-FHSS and the LinkCheckReq issue. My answer was related to the latter as the...

> I believe that ACK should be returned for retransmission as well. I believe it should not, at least not for LoRaWAN 1.0.x devices. In LoRaWAN 1.0.x there is no...

@sp193 could you let me know which part of the 1.0.4 spec describes that the NS can re-transmit an ACK? Because I see also this: 

Imagine the following scenario: * Uplink FCnt 20 * Downlink FCnt 10 * NbTrans is 3 * There are 3 application payloads in the device queue (queue is managed by...

Thanks for your feedback @sp193! > The encryption of the message was shifted to right before the frame is about to be sent, to allow additional MAC commands to be...

Thanks for reporting. I ran into the same issue last week. This was a regression that was caused by the txack handling which was added at a later point. The...

Yes, this is a cosmetic issue. I'll fix this in the next (minor) release.

I appreciate that you are posting a bugreport, but could you please use the provided bug-report template? That saves us a lot of time in reproducing the issue and fixing...

Did you make any modifications to the code? As far as I'm aware of, there is no such log in the brocaar/chirpstack-application-server code: > time="2021-10-09T17:44:34+08:00" level=info msg="events/uplink/uplink decryptPayload" data="[]" decrypted_data="[]"...

Thanks for providing the versions. Couple of questions: 1. I can not find any log in the code that prints `msg="events/uplink/uplink decryptPayload"`. Did you make modifications to the code? 2....