Unable to join any AS923 network (US915 and AU915 works fine)

[pomplesiegel]

Hello Everyone,

Today for testing purposes I tried my exact same exact program, but for different regions, to make sure everything would work in different places on the globe. To do this, I

• Changed the #defines in "lmic_project_config.h" to enable a particular region one-by one.
• Changed the channel plan in TTN to the appropriate one
• Changed the channel plan on our gateway (Dragino LG308) to match the region's channel plan

What I found was that we were totally unable to join any AS920-925 network.

• I tried AS920-923 (“AS1”) and AS923-925 (“AS2”) with all AS923 settings on our dragino, just to be safe (8 total combinations)
  

The upper two AS923 settings (AS923-1) (920-923 and 923-925) were the right choices and did show data on TTN, however with these selections we were still not able to join

On an LMIC logging side all I would see was

EV_JOINING
…
EV_TXSTART
…
Unknown event: 
20

And on TTN, for 920-923 I saw

and for 923-925:

However, the device never actually successfully joined.

I have not made any changes to the channel plans. From a LMIC config standpoint, this is all I'm doing within setup(). No special config:

    // LMIC init
    os_init();
    // Reset the MAC state. Session and pending data transfers will be discarded.
    LMIC_reset();
    LMIC_setLinkCheckMode(false);
    LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100);
    LMIC_setAdrMode(false);
    LMIC_setDrTxpow(DR_SF10, 17);

    // // Start job (sending automatically starts OTAA too)
    do_send(&sendjob);

Other info

• Everything works fine for US915 and AU915, including OTAA with the exact same gateway and same hardware + TTN application
• LMIC v3.3 on Adafruit Feather M0 w/ Arduino 1.8.13
• HopeRF RFM95CW - 915Mhz

Any thoughts on what is going wrong here, and if I'm doing something silly?

Thank you all very much!

[terrillmoore]

I found that I had to register with the appropriate broker, creaate a new app, and re-register the gateway with TTN. (In fact, because of memory in the TTN systems for a given gateway EUI, I found that it was best to use multiple gateways).

I'm sure that with enough wrangling, this works. But it's tricky doing it all with one gateway.

[pomplesiegel]

Wow, that's nuts! Good catch!

I'm using TTN v2, but I wonder if v3 would alleviate some of that headache.

I will be getting some new LG308s in this week. Do you think they would work if they were new gateways, registered under a certain channel plan, but with the same application?

When you say "appropriate broker" do you mean the app/gateway would have to be hosted by a region that's appropriate for the channel plan?

[terrillmoore]

When you say "appropriate broker" do you mean the app/gateway would have to be hosted by a region that's appropriate for the channel plan?

Yes. Make sure you have your app tied to eu, us-west, etc, based on your target region. Wyen you reigster your gateway, also register it in that region (so it's sending packets upstream to eu, us-west, etc.)

Another way of saying this: becuase of the way devAddrs work, you should have separate applications for each region, connected to the regional handler. Then associate the gateway with the corresponding regional cluster.

[pomplesiegel]

Understood! OK, I'll give this a shot with another gateway and hopefully everything should go to plan. Thank you very much for the help!

[pomplesiegel]

@terrillmoore, thank you for your help!
In my testing I successfully got things working normally for 868Mhz. I am now successfully joining for AS923, but the transmits are taking an insanely long time to go through (about a minute?) before TX_COMPLETE is issued.
Have you seen anything like this?

[terrillmoore]

Sounds like a duty cycle issue. (I really need to move the logging code from the compliance test into the mainline, so anyone can use it... we could immediately tell...)

Some regions impose a duty-cycle limit on channel use, and on radio use. (The channel use is accounted per-channel, the global use counts total tx-on-air time.) If you've used up all your quota, a transmit will... wait until your quota is available. The duty-cycle limit is downloaded over the air. Depending on the network server, it might choose a value that keeps you from transmitting.

Further, the data-rate after join may be SF10 when you could use SF7 successfully. This has the consequence that you use a lot more air time for any given message (16 times as much). So you'd use up your budget a lot faster.

What AS923 variant are you using? Does TTN let you specify a country? If not, they're probably being conservative...

[pomplesiegel]

Is there currently a way to run with logs enabled by checking out a different branch, or are you referring to the logs in compliance-otaa-halconfig.ino?

[terrillmoore]

You have to turn on LMIC_ENABLE_event_logging (define it to 1) in order to get logging calls compiled in. They're not big, but they add a little space.

Then you need a delogger, like the code in compliance-otaa-halconfig.ino. That's the code that ought to be in a library rather than in a sketch. But you can run the compliance sketch and it will likely show what's going on. You don't really care about your app while debugging this, so the compliance sketch is convenient.

[terrillmoore]

By the way, I think this is not really a bug. I suggest converting this to a discussion, if you wouldn't mind.

[pomplesiegel]

Sure, I would always appreciate more logging!
Understood! Perhaps TTN's AS923 was the only region which enforced this.

I saw the same exact behavior with TTN's AS920-923 and AS923-925. In both cases the app was hosted by ttn-handler-asia-se.

Thank you for your help. And yes, this is a discussion at this point. I'll try to convert it now.

[terrillmoore]

You could try running the compliance sketch. It's not perfect but it does output more info. If you build the LMIC with logging (not debug prints!) turned on, the compliance should produce enough info to definitively figure out what's going on.

[pomplesiegel]

Got it. I'll give this a shot! Thank you

[pomplesiegel]

Btw, that option does not appear to be available, following these instructions: https://docs.github.com/en/discussions/managing-discussions-for-your-community/moderating-discussions#converting-an-issue-to-a-discussion

[terrillmoore]

Apparently it's something only the moderator can do. Which I guess means me. Done...

[pomplesiegel]

Great, thanks!