US frequency hybrid subbands use wrong downlink channels

[javierpedrido]

Hello, I'm trying to figure out how to configure manual ADR "Set channels" of a node using US frequency subband 2. The channels are:

Index Frequency DR Max Min On 0 903900000 3 0 1 1 904100000 3 0 1 2 904300000 3 0 1 3 904500000 3 0 1 4 904700000 3 0 1 5 904900000 3 0 1 6 905100000 3 0 1 7 905300000 3 0 1 U 904600000 4 4 1 R2 923300000 8 8

If I set the param to 8-15, the DR4 uplink is disabled by ADR and I cannot change the data rate to 4. Is there way to not change the channels, I just want to modify the data rates and the power?

Thanks, Javier

[gotthardp]

Hello. The standard US scheme has no sub-bands. You are probably using Multitech's extension, which my server calls "Hybrid", so please make sure you use the region "US 902-928MHz (Hybrid)".

Then it should be OK to set channels to 0-7 and modify the rates as you wish. There may be an error though, so if this doesn't work please let me know.

[javierpedrido]

If I set the device to US (Hybrid) the node cannot join the network. I might be wrong, but according to the Multitech manual Hybrid means that RX2 can use same freqs as RX1, while the regular mode is RX2 is fixed at 923300000 DR8.

2017-09-26 14:56:22.071 [info] <0.305.0>@lorawan_mac:handle_join:171 JOIN REQUEST 70B3D57EF00050AC 00800000040002F5 -> 02BB86A6 2017-09-26 14:56:22.072 [debug] <0.305.0>@lorawan_mac:handle_join:191 Join-Accept in RX1: {0,8,undefined} 2017-09-26 14:56:22.075 [debug] <0.305.0>@lorawan_mac:txaccept:244 Join-Accept <<"02BB86A6">>, {txq,<<"US902-928-PR">>,923.9,<<"SF10BW500">>,<<"4/5">>,3493426780,undefined,undefined}, netid <<0,0,1>>, rx1droff 0, rx2dr 8, appkey <<"2B7D95F4D9ADCC16916EB9733288A8D6">>, appnce <<"034C5E">>

[gotthardp]

Now I am confused, My "Hybrid" is the "Private" mode described on http://www.multitech.net/developer/software/lora/introduction-to-lora. Is it anyhow similar to your Hybrid mode?

[gotthardp]

But I checked the code and what you said is correct. The "Hybrid" mode uses the same req in RX1 and RX2.

[javierpedrido]

According to this https://www.multitech.com/documents/publications/manuals/s000643.pdf Look at the AT+FSB command, it's possible to select 8 combinations of 8 channels, and depending if you set AT+PN=0 or AT+PN=1, it will have RX2 fixed at 923.3 DR8 or not.

My node is configured as AT+FSB=2 and AT+PN=1 (Fixed RX2), and my gateway (SX1301) uses the same 8 channels determined by AT+FSB=2.

[javierpedrido]

So, I don't know why I can't join using US902-928-PR (It tried to log in with PN=0 and PN=1, in both cases it fails)

[gotthardp]

There is also a gateway and other server settings involved:

• First thing to note is the AT+PN sets also the sync word, which is confiured in the gateway.
• Second thing to note is that the AT+PN changes also the join times, which are set in the server config.

The sync word and join times are by default for public networks, ie AT+PN=1. Try that first, please.

And now the confusion and possible error: my table uses downlink mod 8, while your table says div 8. How are the downlink channels calculated when AT+PN=1 and AT+FSB=something?

[javierpedrido]

So, there are two options (I think):

1) I change the sync word of my packet forwarder to 0×12 and use PN=0 (I don't know how to do it) 2) You add a hybrid public network region.

[gotthardp]

One question: is there a way to disable AT+FSB (i.e. a non hybrid, public mode)? If so, then both tables would make sense and there are 4 modes: always a combination of public-private and hybrid-nonhybrid.

[javierpedrido]

Yes, FSB=0 that turns on all the US channels. I don't know if PN has any effect when using that mode.

[gotthardp]

I see it now. Thanks for your help. Then this is a bug and I will fix it by changing the implementation to the "public hybrid mode" because right now its neither public hybrid nor private hybrid. Since the private is hard to configure anyway we may not need it (at least for now).

[javierpedrido]

The current implementation is the private hybrid, but if you want to change it to public hybrid, Ok. As soon as you push the the modification I will test it and let you know if if works OK. Thanks!

[javierpedrido]

I changed the code and did a quick test and now joins work, but using 0-7 channels does not solve the ADR problem. The problem is that FSB=2 uses channels 8-15 (for DR0 to DR3) and 65 (for DR4). FSB=1 uses 0-7 and 64, FSB=3 uses 16-23 and 66, FSB=4 24-31 and 67, etc.

[gotthardp]

Could you elaborate a bit more on that, please? I am not sure I understand.

[javierpedrido]

If I use the default 0-7 in the ADR Set Channels field, the moment the LinkADRReq command is sent, all the uplinks channels in my node are turned off, if I use 8-15 in that field all the 125kHz are turned on, but the 500kHz (DR4) channel is turned off (That means I cannot change the data rate to DR4 because the uplink channel for the 500kHz channel is always turned off by the LinkADRReq command).

Depending on the sub band selected in the node, here are channels that should be turrned on (bits > 63 are for 500kHz DR4 channels, bits <= 63 are for 125kHz (DR0 to DR3) channels:

FSB1=000100000000000000FF FSB2=0002000000000000FF00 FSB3=00040000000000FF0000 FSB4=000800000000FF000000 FSB5=0010000000FF00000000 FSB6=00200000FF0000000000 FSB7=004000FF000000000000 FSB8=0080FF00000000000000

I'm using the FSB=2 in my node, that means 125 kHz channels 8-15 for DR0-DR3 transmissions and 500 kHz channel 65 for DR4 uplinks.

[gotthardp]

And why don't you specify more channels? You can chain it like 0-2, 4, 5-7.

[javierpedrido]

If I use 8-15, 65 , the LinkADRReq cmd fails and I get some weird data in the node (It seems that the info the server is sending it is not recognized as a mac command)

[gotthardp]

This is the main issue, I guess. Might this be a limitation of the device, or a server bug? Are there some interesting server logs you can share with me?

[javierpedrido]

The server logs this:

2017-09-27 11:19:22.880 [debug] <0.285.0>@lorawan_mac_commands:send_adr:245 LinkADRReq {5,3,[{8,15},{65,65}]} 2017-09-27 11:19:22.881 [debug] <0.285.0>@lorawan_mac_commands:build_fopts:42 039E06D7 <- [{link_adr_req,3,5,2,7,0},{link_adr_req,3,5,65280,0,0},{link_adr_req,3,5,2,4,0},dev_status_req]

[gotthardp]

And your device doesn't like the MAC command?

[javierpedrido]

It doesn´t like something in that cmds, when using 8-15 it sends:

2017-09-27 11:29:45.567 [debug] <0.285.0>@lorawan_mac_commands:build_fopts:42 039E06D7 <- [{link_adr_req,3,5,0,7,0},{link_adr_req,3,5,65280,0,0},dev_status_req]

that works ok.

[javierpedrido]

If I set the channels to just 65, it doesn't change the channel and I get:

2017-09-27 12:33:25.726 [debug] <0.285.0>@lorawan_mac_commands:send_adr:245 LinkADRReq {5,3,[{65,65}]} 2017-09-27 12:33:25.726 [debug] <0.285.0>@lorawan_mac_commands:build_fopts:42 039E06D7 <- [{link_adr_req,3,5,2,7,0},{link_adr_req,3,5,2,4,0}] 2017-09-27 12:33:29.264 [debug] <0.285.0>@lorawan_mac_commands:handle:16 039E06D7 -> [{link_adr_ans,1,1,0},{link_adr_ans,1,1,0}] 2017-09-27 12:33:29.264 [warning] <0.285.0> node 039E06D7 {adr_req_failed,{1,1,0}}

[javierpedrido]

If I hard code this cmds it works fine (all the 125kHz (8-15) channels and the 500kHz 65 channel are on) and I can change to DR4.

[{link_adr_req, DataRate, TXPower, 255, 1, 0} , {link_adr_req, DataRate, TXPower, 2, 4, 0} | FOptsOut]

[javierpedrido]

When using 8-15,65 in the current code it sends:

[{link_adr_req,3,5,2,7,0},{link_adr_req,3,5,65280,0,0},{link_adr_req,3,5,2,4,0},dev_status_req]

{link_adr_req,3,5,2,7,0} and {link_adr_req,3,5,2,4,0} aren´t kind of redundant? That seems to be the problem.

[javierpedrido]

FYI, [{link_adr_req,3,5,2,7,0},{link_adr_req,3,5,65280,0,0},dev_status_req] works fine too.

2017-09-27 14:28:50.390 [debug] <0.285.0>@lorawan_mac_commands:build_fopts:42 039E06D7 <- [{link_adr_req,4,5,2,7,0},{link_adr_req,4,5,65280,0,0},dev_status_req] 2017-09-27 14:28:50.393 [error] <0.285.0>@lorawan_application_backend:data_to_fields:222 Fun failed error:function_clause 2017-09-27 14:28:54.654 [debug] <0.285.0>@lorawan_mac:handle_uplink:395 DataRate 039E06D7 switched to dr 4

[gotthardp]

Oh, true! {link_adr_req,3,5,2,7,0} and {link_adr_req,3,5,2,4,0} are really redundant. Good catch!

[javierpedrido]

So if you fix this issue, you wouldn't need to modify your current Hybrid mode, because it would be possible to set the required subband with Set Channels and use the std US902-928.

[javierpedrido]

The only problem is that auto ADR uses the defautlt ADR channels instead of using the the ones configured in the Set Channels field.

[gotthardp]

Step by step :) I just fixed the duplicate entries and introduced both "Public Hybrid" and "Private Hybrid". It also automatically changes the join times. (Hopefully correctty.)

The auto ADR does sent the command but does not include your settings, or does not send the commamd at all?

[gotthardp]

Update again, please. I misdeclared public and private.

[javierpedrido]

The ADR commands work OK with 8-15,65 now, but the rx1 uplinks are not correct for PU, it should be the same as US902-928. (mod 8, not div 8)

[gotthardp]

So is there any difference between PU and standard US902-928?, because your .PDF says it's div 8, whereas standard is mod 8.

[javierpedrido]

There's no difference, that was what I was trying to tell you when I said "So if you fix this issue, you wouldn't need to modify your current Hybrid mode, because it would be possible to set the required subband with Set Channels and use the std US902-928."

[javierpedrido]

Another minor glitch I'm seeing is that the server is not sending an ACK for the first uplink after a join (it is not a timing issue, it's not being sent to the gateway because I don't see my gateway TX Led blink at all). It works fine for the following uplinks.

[gotthardp]

I removed -PU again. :)

The missing ACK is weird. Do you have some more insights, please? (Log, whatever)

[javierpedrido]

There's nothing about that ACK being sent in the server log, but are you logging ACK downlinks?

[gotthardp]

I am not logging standard messages, just errors. I assume the first message is logged in "Received Frames" and is "confirmed", right?

[javierpedrido]

ADR is working really well now with the latest code, my "2 meters away from the gateway" node goes to DR4, 10 dbm now! Thanks!

Yes, it is logged in "Received Frames" as confirmed.

[javierpedrido]

The ACK doesn't appear in the gateway's log, it seems like the server is not sending it.

[gotthardp]

What FCnt has the first frame? If it's 0, I guess you are experiencing the Issue #194?

Update: I made a fix for #194, so you may try if the fix solves your issue too.

[javierpedrido]

It's working OK now, thanks!

[gotthardp]

Great! Is there anything else-- may I close this issue? :)

[javierpedrido]

I've got nothing to report :)

[gotthardp]

Cool. Just open a new issue if you need.