mcci-catena / arduino-lmic

LoraWAN-MAC-in-C library, adapted to run under the Arduino environment
https://forum.mcci.io/c/device-software/arduino-lmic/
MIT License
636 stars 207 forks source link

Regression on Adafruit Feather M0 Lora #277

Closed VladimirAkopyan closed 5 years ago

VladimirAkopyan commented 5 years ago

I am attempting to get this working on the Adafruit feather M0 Lora. I have a sketch working perfectly with an older version of this library: https://github.com/matthijskooijman/arduino-lmic, basically otaa-feather with credentials added.

When using the otaa-feather in the new library with same credentials, I get:

2455: EV_JOINING
2474: EV_TXSTART
534058: EV_TXSTART
1768133: EV_TXSTART
2276229: EV_TXSTART
2850782: EV_TXSTART
3327535: EV_TXSTART
4088931: EV_TXSTART
4607957: EV_TXSTART
5350247: EV_TXSTART
5860852: EV_TXSTART
6406344: EV_TXSTART
6908931: EV_TXSTART
8256967: EV_TXSTART
8792015: EV_TXSTART
10167636: EV_TXSTART
10695536: EV_TXSTART
11079309: EV_JOIN_FAILED

Are there major changes and the example wasn't updated?

terrillmoore commented 5 years ago

Sorry you are having troubles. I tested with a Feather using OTAA; so I need more info on the problems you're having.

Configuration changes a lot between the older version and this version; that's the most common difficulty.

You can sort out the compliance tests (which were destabilizing) from the other local changes by checking out the most recent release tag and rebuilding, and seeing if that helps. If you installed from the library manager, then you have the release version, and it's even more likely that you have a config problem. (Also your debug prints don't show the new events (which show as "unknown"), so I'm guessing you're using the release version via the library manager).

But my guesses don't count, please let me know...

cstratton commented 5 years ago

Are you using freshly registered credentials? Or could you have "used" credentials and be re-using an already consumed join nonce?

What debug visibility do you have into the server - can you determine if the join requests are being received and decoded and join accepts sent in reply?

If you control the involved gateway, consider making it log transmit packets and adding or enabling extra logging in LMIC so that you see if it is listening at the right time with the right radio settings, if anything is received, and any reason why something received might be being rejected. Comparing such logs between working (if the old one still does) and non-working versions would be especially insightful.

paulalting commented 5 years ago

I too have this same issue it appears with using an Adafruit Feather M0 with LoRa configured for 915MHz Australian AU band.

The gateway gets the join request and sends back the join accept, but the Feather ignores this and after some minutes issues a join failed in my serial output the same as Vladimir.

Have two local gateways, RAK831 with RPi installed with LoRaServer working successfully.

Feather credentials have not be altered while I have updated the gateway from simple packet forwarding gateway to fresh install of LoraServer to act as gateway and network and application server all in one, Gateway OS.

My setup is: Eclipse IDE with configuration for Arduino by Jantje, Sloeber ver 4.3. platform version for SAMD, ver 1.2.3 MCCI-LMIC ver 2.3.2

Hardware is Adafruit Feather M0 with LoRa 900MHz Feather pin 6 is connected to DIO0. Feather pin 11 is connected to DIO2, from previous testing with base LMIC library. Test code based on example 'ttn-otaa-feather-us915-dht22', but with static values instead of using dht library. I have set debug logging to be more verbose, but have seen no additional debug information listed.

Set lmic_project_config.h as follows for AU band plan :

// project-specific definitions
//#define CFG_eu868 1
//#define CFG_us915 1
#define CFG_au921 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP   /* for as923-JP */
//#define CFG_in866 1
#define CFG_sx1276_radio 1
#define LMIC_USE_INTERRUPTS

Have tried with interrupts enabled as well as disabled in above config file. As gateway is only some 10m away in another room, the RRSI is good, typically at around -85dbm, using 1/4 wave ground plane dipole.

As mentioned, it appears the gateway hears the Feather no problem for a join request and issues a join accept, which the Feather doesn't act on.

What information can I provide to assist finding the problem ?

terrillmoore commented 5 years ago

You should not need DIO2 connected, but it probably won't hurt anything. I don't connect it at all, and things run fine on US915.

I've done a lot of testing with exactly this config, otherwise, without difficulty. So I suspect you're running into subtle problems due to timing. The LMIC is hard-realtime, and things that normally don't matter can keep it from working at all.

Please undefine LMIC_USE_INTERRUPTS -- that's a relevant difference in the way that I test. I've never tested it, and it's not likely to add any value.

Please do change the clock accuracy using LMIC_setClockError(10 * MAX_CLOCK_ERROR / 100); during initialization (after LMIC_init() / LMIC_reset(). The usual case for this kind of problem is that there's something else in the system that messes up timing. Debug prints are particularly problematic for timing as they introduce unpredictable delays.

If you're still having problems, I would then suggest you update to the current (post 2.3.2) code from github and run the compliance example script (with your TTN DEVEUI etc.) The output from the compliance script has a lot of timing information and doesn't interfere with anything else (because all printing is deferred). If looking at the compliance example script, I'd suggest you also add #define LMIC_PRINTF_TO Serial (without enabling debugging) as this enables some additional prints that are useful.

terrillmoore commented 5 years ago

@VladimirAkopyan is this still a problem?

terrillmoore commented 5 years ago

Closing for now, can reopen if needed.