Is it possible to disable ADR in the server such that the ADR bit is unset?
If not, I guess can you effectively disable ADR by setting min and max DR to the same level?
Thanks.
Patrick
I haven’t checked the latest release, but as far as I know there’s no included way of turning off ADR from loraserver. That said, it’s pretty easy to do so and I’ve done it in our custom loraserver to deal with some faulty Microchip devices that keep on turning ADR on by themselves. It’s probably not the best way of doing it, and it enables/disables it globally instead of per organization/application/device, but it served as a quick hack for some tests that we needed.
What’s needed is to modify loraserver/internal/adr/adr.go where macPL.FHDR.FCtrl.ADR (set by the device on uplink) is checked, to something like this:
// if the node has ADR disabled or it is turned off gloablly
if !macPL.FHDR.FCtrl.ADR || !config.C.NetworkServer.NetworkSettings.ADROn {
return nil
}
Then just add a field at loraserver/internal/config/config.go for the ADROn option (I dit it at the network settings, which made sense):
NetworkSettings struct {
InstallationMargin float64 `mapstructure:"installation_margin"`
RX1Delay int `mapstructure:"rx1_delay"`
RX1DROffset int `mapstructure:"rx1_dr_offset"`
RX2DR int `mapstructure:"rx2_dr"`
EnabledUplinkChannels []int `mapstructure:"enabled_uplink_channels"`
EnabledUplinkChannelsLegacy string `mapstructure:"enabled_uplink_channels_legacy"`
ExtraChannelsLegacy []int `mapstructure:"extra_channels_legacy"`
ADROn bool `mapstructure:"adr_on"`
ExtraChannels []struct {
Frequency int
MinDR int `mapstructure:"min_dr"`
MaxDR int `mapstructure:"max_dr"`
} `mapstructure:"extra_channels"`
} `mapstructure:"network_settings"`
And finally the option to the loraserver config file (loraserver/cmd/loraserver/cmd/configfile.go):
adr_on={{ .NetworkServer.NetworkSettings.ADROn }}
1 Like
Thank you. I appreciate the detailed response and pointer to code changes very much.
That confirms what I thought. I also have test devices that have ADR turned on at the device side that I can’t currently control. So, I wanted to disable the ADR from kicking in from the network side.
Do you know if I set min/max DR the same does that “effectively” turn off network side ADR?
Sorry, I missed that part of the question earlier. I’m not really sure, and a quick search for MinDR and MaxDR at the source code didn’t suggest if it would indeed keep ADR from kicking in. Consider that in Chile it’s saturday night right now, so it’s not the best moment to make sense of the code really 
. But you could look at loraserver/internal/adr/adr.go to check if it does, or wait for Orne to answer it.
Sorry for the unhelpful response .
Don’t rely on Min / Max DR to disable ADR. Would it help to have a global switch in the configuration to disable ADR for the complete network-server?
2 Likes
I think it would. Given the wide swath of potential deployments and the fact that ADR may not be applicable to the entire space it would make things easier and less confusing if you could simply remove the feature if this is not something that you are able to take advantage of.
Even where you can take advantage of it, it might be nice from a testing point of view to remove any confusion early in development and testing while things stabalize.
JMTCW…
This is not my top priority right now, but if one would like to create a pull-request for this, then that would be really appreciated 
I don’t think this should be really complex to implement.
I took a quick peak at the latest version and it seems my workaround (the one I posted above in this topic) is now obsolete, I’m probably 2 or 3 versions behind. I’m currently overwhelmed with work related to another project, but if I get the time in the next couple of weeks and no one has done it yet, I wouldn’t mind reimplementing it. I’ll have to give it a deeper look to see how hard it’d be to also do it on a per application or device basis (if that’s of anyone’s interest).
I would (for now) not worry about this 
(as with the settings, I would like to stay close to the documented fields in the LoRaWAN Backend Interfaces specification).
Hi, I just submitted the PR to disable ADR for the whole network at loraserver: https://github.com/brocaar/loraserver/pull/336
I took a further look and indeed it seems easy to add a simple disableADR field to the device profile to manage it per device, and have it toggled from the appserver’s ui. We do need that for the open network I told you about so I’ll implement it anyway. If at any time you’d like to see it included, just let me know to submit another PR.
EDIT: I had done all the work at loraserver, but just realized that the appserver relies on lorawan/backend and not loraserver’s definition, so yeah, it’d involve messing the lorawan package and breaking the backend interfaces definition just as you mentioned. I’ll give it a thought through the weekend.
I fixed the issue where I mistakenly pushed the device profiles changes to the PR. It’s now passing all tests and device profile bits are removed so only the global disable_adr option is considered.
1 Like
Thanks 
I’ve just merged your changes into the master branch!
Great!
I was thinking in our use case, where turning ADR off would cripple the system for other users, but leaving it on would have the known issues with RN modules, which other users may own too. So it occurred to us that we could be running 2 loraservers, one with ADR on and the other off, and then switch network servers for the service profiles as needed. Does that make sense?
The other ideas I’ve thought of are adding it to device profiles at loraserver, forking the lorawan packet and adding it there too (messing the backend interfaces); adding it at device profile on loraserver but instead of modifying lorawan package, expose some API endpoint just to let appserver modify it (which is horribly hacky); or just letting the appserver know about loraserver’s DB to modify the specific value (which is just awful). All 3 are horribly hacky, messy and just plain wrong, but I can’t think of a good way to deal with the ADR bug. So if you have any ideas on how I could temporarily tackle this, that’d be awesome.
I think a better option would be to push Microchip to finally fix this issue 
The more people report this issue, the better (I reported this issue in May 2017)! I reported this a long time ago and the issue is still open, like some others I reported (I’m not sure if all the open issues are still present in the latest firmware, I gave up on RN bug hunting as it felt like a waste of time). Maybe reporting this multiple times helps. See: https://microchipsupport.force.com
An other alternative is to work around this at the side of the device. E.g. before every mac tx ... you could do a mac set adr off. As far as I have been able to debug this, it is set back to on when the RN device receives a downlink containing mac-commands (any mac-command will trigger this).
2 Likes
Is there a way to report this issue? Or has it been solved in 1.0.3?
I don’t know, best would be to ask Microchip . See the link in my previous post in this topic.
Just to report that I have upgraded my nodes to 1.0.5 firmware version. There was a problem with sending @ adr 0, which; at times, didn’t allow to send more than 5-7 bytes until after sending a dummy payloadless one. The other problem was that every message was treated as confirmed, and subsequently he adr was changed automatically. After upgrading, the first issue is solved; the second one is partially solved as the server forces-changes the Adr on the node after a confirmed message. The are no issues with unconfirmed messages.