Can not send/receive data using OTAA Class-C

[PadmaIoT]

Hello,
I intend to send and receive data using Class C but except for join request acceptance nothing is happening.
No payload is sent and received. serial monitor says only "joining", nothing else.
My all configs & details are given Below:

LoRa Config:
Network Server: Chirpstack
Frequency Plan: AS923 (edited in .h file to enable desired frequency plan)
Mac Version: LoRaWAN 1.0.2
Revision: RP002-1.0.3
OTAA: yes
Class: C

Hardware Config:
MCU: Arduino Nano
LoRa Chip: RA-01H (SX1276)
(Hardware is ok, also tested by Class B operation using LMIC)

Code config:
lora.setDeviceClass(CLASS_C); lora.setDataRate(SF9BW125); lora.setChannel(MULTI);

Pin Config:
const sRFM_pins RFM_pins = { .CS = 10, .RST = 9, .DIO0 = 2, .DIO1 = 3, .DIO2 = 4, .DIO5 = 8, };

Serial monitor:
Joining...

Chirpstack LoraWan frame:

In this situation What I can do? Can anyone guide me?

[AndreaZGuz]

Dear @PadmaIoT

Thank you very much for contacting us.

With the information you gave me, I will do some tests to verify that everything is correct, and in the same way, I will report anything to you.

Could you just give me more information please, for example, did you configure any gateway for your application? Did you move something else in the code? Has it worked for you before?

Have a nice day!

[PadmaIoT]

Hello @AndreaZGuz

Thanks for your kind response. Here are your answers:

1. I am using the Tektelic Kona Macro gateway where no separate settings for class C are configured, which means I changed nothing.
2. No. I didn't move anything. Not even the payload
3. This is the 1st time I am implementing class c. I had never used it before.

I am waiting for any breakthrough.
Thanks

[AndreaZGuz]

Hi @PadmaIoT

We are now trying to replicate your issue in order to give you the best advice for you to make it work!
As soon as we have any news, we will be informing you.

Thank you in advance for your patience.
Have a nice weekend!

[PadmaIoT]

Thanks, I am waiting for your update.

[AndreaZGuz]

Hi @PadmaIoT

My apologies for the delay in my response.

I ran some tests with the US915_0, EU868, AS923_1, and AS923_2 frequency bands and found all of them except AS923_1 (AS923) are working properly for me on ChirpStack, I just got the same performance as you. I would like to empahtize that in the dashboard, all the time the device were shown as "Active", even when the board were still "Joining" according to my Serial Monitor.
I will attach a ZIP file containing screenshots of the configurations I did for every one of them, including the status of the packages sent/received, so you can see my outcomes (OTAA Evidences.zip).

You told me before that Class B worked fine. I would like to ask if there is any possibility you can try any of the tests I ran, in order to confirm maybe an issue specifically with AS923 band. Would you be able to do it?

Thanks in advance for your patience.
We are keeping in touch!

[PadmaIoT]

Thank you so much for the help. I was thinking to give you some debugging data of the Beelan library Class C node. See below:

SPI Write ADDR: 1E DATA: 94
SPI Write ADDR: 1D DATA: 72
SPI Write ADDR: 26 DATA: 4
SPI Write ADDR: 6 DATA: E7
SPI Write ADDR: 7 DATA: 33
SPI Write ADDR: 8 DATA: 5A
SPI Write ADDR: 1 DATA: 86
Joining...
SPI Write ADDR: 1 DATA: 81
SPI Write ADDR: 1E DATA: 94
SPI Write ADDR: 1D DATA: 72
SPI Write ADDR: 26 DATA: 4
SPI Write ADDR: 6 DATA: E7
SPI Write ADDR: 7 DATA: 0
SPI Write ADDR: 8 DATA: 27
SPI Write ADDR: 40 DATA: 40
SPI Write ADDR: 33 DATA: 27
SPI Write ADDR: 3B DATA: 1D
SPI Write ADDR: 22 DATA: 17
SPI Read ADDR: E DATA: 80
SPI Write ADDR: D DATA: 80
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 37
SPI Write ADDR: 0 DATA: 88
SPI Write ADDR: 0 DATA: 23
SPI Write ADDR: 0 DATA: 43
SPI Write ADDR: 0 DATA: 50
SPI Write ADDR: 0 DATA: D8
SPI Write ADDR: 0 DATA: 33
SPI Write ADDR: 0 DATA: 4E
SPI Write ADDR: 0 DATA: 13
SPI Write ADDR: 0 DATA: E0
SPI Write ADDR: 0 DATA: C0
SPI Write ADDR: 0 DATA: 0
SPI Write ADDR: 0 DATA: 3E
SPI Write ADDR: 0 DATA: C5
SPI Write ADDR: 1 DATA: 83
SPI Write ADDR: 12 DATA: 8
SPI Write ADDR: 40 DATA: 0
SPI Write ADDR: 33 DATA: 67
SPI Write ADDR: 3B DATA: 19
SPI Write ADDR: 1E DATA: 94
SPI Write ADDR: 1D DATA: 72
SPI Write ADDR: 26 DATA: 4
SPI Write ADDR: 6 DATA: E7
SPI Write ADDR: 7 DATA: 33
SPI Write ADDR: 8 DATA: 5A
SPI Write ADDR: 1 DATA: 86

And I am pretty sure that if my device can understand the join acceptance then it should work as it should be.

Previously for class B device I used the LMIC library which is still online and sending data. see the photos below, these are pictures for my class B devices:
The device logs are:

The device profile is:

I have only one gateway which supports As923-1 only. My class B device is running through it. The device is working for a long time.

I will run tests and let you know.
one more ques...how to check my Rx1 & Rx2 for my Class -C device using the Beelan library? @AndreaZGuz

[AndreaZGuz]

Hello again @PadmaIoT

If you use our library, RX1 and RX2 windows are fixed to 1 sec.

Of course! Thanks for trying. We will be waiting for your outcomes.

We are keeping in touch!

[PadmaIoT]

Hello @AndreaZGuz ,
Will you please let me know that on the time of building this library which version of LoRaWAN documentation was followed? As an example latest documentation of Lora-alliance is for LoRaWAN (not sure) I believe is 1.0.4 and the regional parameter version is RP-002 1.0.3. Let me know, please. I believe something lacking in the library is making this problem. I hope you guys will also try to fix the issue from your side. Happy sharing.

[AndreaZGuz]

Hello @PadmaIoT,

This library is based on version 1.0.3, it has been tested with version 1.0.4 and worked well, but some features may not be compatible or supported. I have already reported the issue.
Our team will be working on it to improve the performance of the library.
In the meantime, if you share your results with us once you have run the tests, it would be very helpful to us to identify quickly if the issue is only related to AS923 frequency.

Thank you for your patience and collaboration.

[PadmaIoT]

Hello @AndreaZGuz ,

Thanks for your continuous support. I have a lack of gateways for different bands. I will run the test with our developer community. I already found a gateway of EU868 from one of my developer friends. Will let you know about the result. My request is not to close the issue unless it is solved

[AndreaZGuz]

Hi @PadmaIoT

Sure!
We are attentive to your outcomes and comments.

[PadmaIoT]

Hi,
I could use only 2 frequency plans. It works fine with EU868. AS923 default (AS923-1) does not work...shows the same problem. The problem is my region only supports AS923.

[AndreaZGuz]

Hi @PadmaIoT !

Thank you very much for trying.
It seems that we both faced issues with the same frequency. This issue is already reported to our colleagues. Now they will work to solve it.
I cannot assure a specific frame of time to resolve this issue. As soon as we have any updates, we will let you know.
Thanks in advance for your patience and collaboration with the tests.

[PadmaIoT]

Thanks, @AndreaZGuz . I will be waiting for your solution.

[PadmaIoT]

Hello there,
How are you all?
Did you find the bug?

[wero1414]

Hello we updated with a pull request the way that OTAA class works, can you try again?

[AndreaZGuz]

Hello @PadmaIoT
Were you able to test the updates?
Did you face any issues?

[PadmaIoT]

Hello @AndreaZGuz

Thanks for your update. I appreciate your help. Right now I am far away from my lab. I hope very soon I will be able to run and test and let you know about the update.

Good work guys.

[AndreaZGuz]

Hi @PadmaIoT
Thank you for informing this.
We are attentive to your findings.

[halukmy]

i can not recieve too anyone fix ?

[PadmaIoT]

Hi @AndreaZGuz ;
I did not tested it directly, but someone else (one of my fellow developer friends) reported me the problem still persistent. Can you please check again?

[AndreaZGuz]

Hello @PadmaIoT!

Many thanks for the updates.
Currently, our dev team is working on some updates that will improve the functions from the library, including those related to the AS923 frequency.
The time that these modifications will take is not accurate to tell at this moment, but as soon as they are completed, we will let you know.

Thank you for all the collaboration and your patience.
We are keeping in touch.

[damattl]

Hi, I had a similar problem.
The uplink was working fine so far, but downlinks where not handled at all.
After trying a few other options I decided to take a look into the implementation and found a flag _CLASS_C_
that was disabled / not defined. After enabling it the downlink worked as expected.
I took the freedom to add a comment about this in the example file for OTAA + Class C and started a pull request.

[PadmaIoT]

@damattl so you mean you solved it somehow?

[damattl]

@PadmaIoT
Yes, at least for my project and configuration.
I found this inside the implementation files, and decided to define the _CLASS_C_ flag via the build flags in the platformio.ini file.

As I'm not using Arduino IDE I don't know how to set build flags in Arduino IDE

[PadmaIoT]

What you are using? Platform io? @damattl

[damattl]

Yes, I'm using PlatformIO @PadmaIoT

[PadmaIoT]

@damattl so you can do uplink and downlink by class C right? Please give me more insight about your configuration of the C class device in LoRa server. I want to know which LoRA server you are using, and when you register your device in the server, what was the configuration you applied. I will be thankful.

[ryandiapsl]

I also have an issue, i attempted to use this library and have imported the new, *fixed library. I setup the end node with the example of Class C OTAA on platform IO and have set all the build flags. I have managed to config my end device on 2 different servers that being TTN and Datacake and managed to make a join connection from my end device to my gateway and also send uplinks and receive them on TTN and Datacake, but for some reason downlinks never work on both of them. I am using ttgo-lora32-v1 with SX1276 lora module.

[AndreaZGuz]

Hello!

Thank you for following up on this issue and helping us with your feedback and comments.
At the moment, some changes have been implemented to enhance the efficiency of this library. The last update we can point you to is pull-request 181.
Due to other priorities, our team will resume work in the next half of the year.

We appreciate your patience and any collaboration. Remember, if you want to contribute to this library, you can always open a pull request with your changes/suggestions.

[aarnaud]

first, thanks for your work.

I'm using LoRa32 V2.1_1.6, I success to use OTAA after connecting lora1 (DIO1) to the esp32. I also connected lora2 (DIO2).

I can joined Helium network (US-915) and send data but It failed to receive any data from the downlink.

The received is working correctly in a p2p setup.

I tested the latest release, master and the branch linked to the PR 181.

Is it something link to RX1 or RX2 frequency for US-915 ?

[AndreaZGuz]

Hello @aarnaud,

It may be related to the Class you are using.
Are you using Class A or Class C?

[aarnaud]

Hi @AndreaZGuz, sorry for this missing info, Class C, I want to receive data from helium(using Meteo Scientific), I also have a hotspot, so both are not fare away.

[AndreaZGuz]

Hi @aarnaud !

The improvements for this library include some features for Class C.
This behavior is expected. Our team will continue working to fix these issues in the next half of the year.

We apologize for the inconvenience and appreciate any contribution.

[IoTThinks]

This pull request should fix the Joining issue for AS923.
#194

Receiving downlink is still an issue. Will check if can fix it.
This feature work before but recent update brokes the downlink.