I feel that it’s possible that there is some fundamental thing I’m just not understanding, but I’ve been perplexed by what happens when I tell a 3172 to disable ADR. It accepts this, but at the same time all of the uplinks that were previously sent with confirmation are now showing as unconfirmed. I’ve tried to find the right keywords to see if this has been discussed on the forum previously, but without a hit
RAK3172 running RUI 4.1.0 firmware talking to a 7268V2 gateway running WisgateOS 2.2.1. The gateway ADR setting is still “on”, and I’m not sure how this works into the equation. Again, when ADR is turned off on the 3172, the packets continue to be seen on the gateway packet capture but switch from the solid purple uplink symbol (confirmed) to the hollow (unconfirmed) format, and are not forwarded to the MQTT broker. Also weird is that they now only show up in the packet capture at the gateway level. If you go into the associated application and try to view the device directly, nothing shows up in the packet capture at all with ADR turned off.
The reason for this isn’t coming to me, and I’m wondering whether this behavior is explainable or is a bug?
I did some test to try different configurations (mainly playing around on ADR and CFM uplinks both on end-device and gateway side). I cannot replicate what you experience.
I uses hivemq as the MQTT broker and Thingsboard as the application frontend.
Gateway I use is RAK7268V2 (US915) with WisGate OS v2.2.1.
Device is RAK3172 and uplinks are sent via AT commands (not via RUI3 API).
In all setting like ADR on/off gateway built-in LNS, the device on ADR and CFM both tested, all uplinks are received by the HiveHQ broker and captured by Thingsboard.
Thanks for checking this out. I’ve got some more input, and I do believe there is an issue here.
I’m working with the RAK BSP for Arduino. The code is literally an example that I believe is one of BeeGee’s. It works absolutely as expected with ADR turned on. Just changing this:
to “false” breaks it. Apart from setting confirmed mode on, the send command looks like this:
Which I also believe is asking for a confirmed uplink.
Nothing else has changed - but I did make two other observations. If I look at the packet capture for the affected uplinks, not only do they become “uncofirmed”, but I notice this:
On the confirmed uplinks (with ADR turned on), that shows what I would expect - 17. (The payload is the same size every time).
For giggles, while this was running with ADR turned off and showing bogus packets on the gateway, I thought I’d try sending a message with an AT command as you had done…
Guess what? That worked as expected. Something is definitely amiss, here?
I was able to replicate your situation. It turns out that when you turn off ADR, the DR is set to 0. I wasn’t able to capture this before because my test payload is only 4 bytes (default payload of LoRaWAN_OTAA Example).
You can try to increase the DR to avoid that error whenever you will turn off the ADR. I change here the DR to 3.
OK, thanks. That does work. Interestingly, the manual setting of the DR in the example code (I’m pretty sure, now, that the base of what I’ve been playing with was the OTAA example that came down with the Arduino BSP rather than something I grabbed from one of BeeGee’s Git repositories) was commented out - with the remark, “does this work with ADR still on?”.
Whoever was doing that started with DR=2. I can set the DR to anything other than 0, and it will work with ADR turned off. Yay! But it begs the question - if I actually wanted to use DR0, it seems impossible with things the way they are? This is actually moot, as the particular application I’m exploring is battery-powered - and although the payload would fit in the 11 byte max allowed at DR0, the air time and battery power would make it impractical.
Anyway - thanks for your help! I can move forward with what I’m attempting now.
But with respect to a potential issue - if a fringe node did actually negotiate a DR0 connection with ADR turned on, would the uplinks fail the same way? Hmmm…
I haven’t tested that scenario since I have a gateway very close to me. In any case, if your payload goes beyond the limit of DR0, my suggestion is either (1) turn off the ADR and have a fix DR or (2) configure the lowest possible DR in your application if you want ADR to be on. For example in the image below, you can select DR1 as minimum.
It is likely that when DR goes to 0, your uplinks will start to fail if it goes above the uplink size limit.
Well, Carl… I have a bit of egg on my face here. The recap, and the blinding flash of the obvious:
If you don’t expressly say otherwise, the device starts up at DR0. With ADR turned on, this immediately gets changed to something better as it joins the network (DR3, in my case). If you turn ADR off, DR0 persists.
I clearly know there is a limitation to how much data you can send in one packet at DR0 (I alluded to that in my prior post). But looking at my code - and something I even wrote in one of my earlier posts… I wrote it out! The data packet I was expecting to see in my earlier testing is 17 bytes long fer cryin’ out loud. Of course that doesn’t work at DR0. Though - in fairness - the way the error manifests itself when you look at the packet capture on the gateway doesn’t make the real issue obvious.
When I did a test send with an AT command - it worked, because the message I sent was only 6 bytes long. For giggles, I foreshortened the data packet I’m sending through the api to be less than 11 bytes and … yeah, of course it works exactly as expected at DR0 with ADR turned off.
D’oh.
I’ll go away and lick my wounds, now - thanks again for the time you’ve invested in sharing this “adventure” with me. My takeaway is to be sure to set a minimum data rate that is appropriate for my packet size if I’m intending to run with ADR turned off. This exercise has at least been confidence inspiring :-). Nothing is gained if mistakes aren’t made.
