I have one device that works great, the other will transmit fine the first time, every time. Then the second transmission starts out OK, but when I expect an “OK” after the “mac tx uncnf 1 blahblahblah” I get the “mac_cmd_reply” response instead.
It seems to be the exact same issue as this person: https://www.microchip.com/forums/m1115438.aspx
Sadly, there was no answer to his problem, and it is pretty much the only thing that shows up with that command.
I attempted to put in a workaround in my firmware, but it seems to be a rough bandaid. The issue is that now on some transmissions (not every one), it will re-transmit the same packet about 5 seconds after the previous one. This gets caught as a re-transmit error and I move on. I’d like to know what is going on so I can fix it and not just create a bandaid and waste airtime and batteries.
A wild guess: TTN sent a downlink with some MAC commands in FOpts, likely the initial ADR Request, and the module is simply notifying your application code about that?
If you can access the gateway Traffic: what do you see, and if there’s a downlink what does it decode to?
Or actually, it may make more sense that TTN already included its (LinkADRReq) MAC command in the downlink of the first uplink, and the RN2903 is responding to that (LinkADRAns) in this second uplink. You’d still want to get to the gateway traffic to see what’s happening.
And as one device is doing this, and another is not: did you compare firmware versions? Are both using OTAA or ABP? Are you also seeing the \n\r rather than \r\n like in that post you linked to?
Firmware all looks the same. What I see is that the troublesome node is getting a download with 4 commands: LinkADRReq, another LinkADRReq, RXParamSetupReq, and a RXTimingSetupReq.
What I don’t understand is why I don’t actually see anything coming out of my RN2903 about this. I would assume that the RN2903 should be ack-ing this and making the changes appropriately. But since it happens on every uplink, I am guessing it isn’t and the server and just trying to get it to make the change over and over. Does that make sense?
I fully realize this is an old thread, but thought I would leave a small bit of information so that others that find this may benefit.
The “mac_cmd_reply” is not in the datasheet, but according to a Microchip FAE this means that the uplink was unsuccessful. This was happening in our case on the third message that went out after power up. We suspect it had to do with some ADR or other mac level transaction that needed some of the payload and there was not enough room to send the full message we had attempted to send. We simply resend the last uplink.
…