MCCI LMIC payload not received by TTN or node is not sending (AS923Mhz)

[erfan_mahmud]

Hello developers,

I am using Arduino pro mini and RA-01H containing SX1276 to develop a node device. I am using Arduino IDE; the library is MCCI Arduino LoRAWAN library(latest version). I successfully connected the node with the TTN. But without a join request & acceptance, I could not receive any payload through TTN. I am badly in need of obtaining a payload.

my payload is simple “Hello World”
I am using OTAA from the example.
my TX interval is 238 s
My Pin configuration that follows the code is given below:
;

SX1276----Arduino
NSS> 10
RST> 9
DIO0> 2
DIO1> 3
DIO2> LMIC_UNUSED_PIN

In lmic_project_config.h my config is given below

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

On the serial monitor, I see it stuck in "EV_TXCOMPLETE (includes waiting for RX windows) ".

On the TTN side, the LORAWAN setting parameters for the node are given below

and the response is like below

Is there someone who already solved this issue?

[LoRaTracker]

@erfan_mahmud

RA-01H

Are you connecting the UNO pins direct to the RA-01H ?

[erfan_mahmud]

Sorry I edited my post. Mistakenly wrote UNO. I am using pro mini & feeding 3.3v

[Jeff-UK]

@erfan_mahmud

my payload is simple “Hello World”

Side note: text based payloads are wasteful of spectrum and device battery life - please switch to using binary/byte based payload (no that doesnt mean encoding Hello World as ASCII bytes! )

Check out https://www.thethingsnetwork.org/docs/devices/bytes/

[erfan_mahmud]

Thanks for the suggestion @Jeff-UK . But my main problem is I am not receiving any payload though it is connected to TTN. I will be grateful if you help me out

[descartes (Nick McCloud)]

We can see the Join Accept is being issued.

What does the serial debug log from the Pro Mini say?

And what sort of antenna do you have on the radio module?

And how close is it to the gateway (forum search will inform you that too close is BAD - 5m + brick wall minimum).

Please post as text using the </> formatting tool on the toolbar.

[erfan_mahmud]

thanks for answering.

1. EV_TXCOMPLETE (includes waiting for RX windows). After a while it shows OP_TXRXPEND, not sending. No
2. 
   
   Antenna 824-960MHz 3dBi Omni Directional Dipole
3. 3 meters

[erfan_mahmud]

Ok, I solved the issue of not receiving the payload. The important thing I was missing is the Spreading factor. I entered lorabase.h & changed the code where SF is defined seems the code is running & sending Payload to TTN. the code is below in lorabash.h.

enum { DR_DFLTMIN = AS923_DR_SF12 };  // DR2   //----SF10
                                      // DR_PAGE is a debugging parameter
enum { DR_PAGE = DR_PAGE_AS923 };
enum { FREQ_PING = AS923_F2 };         // default ping freq
enum { DR_PING = AS923_DR_SF12 };       // default ping DR: DR3  ---SF9
enum { FREQ_DNW2 = AS923_FDOWN };
enum { DR_DNW2 = AS923_DR_SF12 };        // ---SF10
enum { CHNL_BCN = 5 };
enum { FREQ_BCN = AS923_FBCN };
enum { DR_BCN = AS923_DR_SF12 };            //---SF9
enum { AIRTIME_BCN = 144384 };  // micros
enum { LMIC_REGION_EIRP = AS923_LMIC_REGION_EIRP };

Please see the comments. In the comment, I mentioned previously embedded SF. I changed all of them to SF12. @mrtopu34 helped me to find out SF issue. Now payload is being transmitted in regular intervals.

Now I have fallen into a new problem where after several transmissions, a new error found in the Serial monitor says " OP_TXRXPEND, not sending". Any solution you may help with?

[LoRaTracker]

If changing everything to SF12 makes it work, then that might suggest a range issue, i.e. the Gateway is a good distance away.

And since presumably the LMIC library is imposing legal duty cycle limits high SFs can lead to gaps between transmissions.

[Jeff-UK]

Actually at 3m likely too close esp if antennas aligned hence channel bleed and or front end distortion…. Using SF12 means extended Tx hence opportunity for discriminators to do their job over time……

Move to 10m best with absorber in between…wall, window etc. and drop SF’s back, then try again….

[descartes (Nick McCloud)]

I write:

@descartes

And how close is it to the gateway (forum search will inform you that too close is BAD - 5m + brick wall minimum).

Your reply:

@erfan_mahmud

3 meters

You may want to review the above …

Hacking it to work only on SF12 is not a good thing - you will be exceeding the Fair Use Policy (you already were with your 238 seconds from the start) and be trying to breach legal limits but I suspect LMIC is blocking you from that - it still has a job waiting to send once it is OK to do so.

The other consideration for hacking on the code is that it works for others, so it’s not the code that is the issue, it’s something else that needs fixing.

[erfan_mahmud]

Ok. I will find the fixing except changing SF. Thanks for guiding me. The problem is EU868 & US915 have a lot of resources online, try & fail online but AS923 has very limited resources and problem-fixing.

[descartes (Nick McCloud)]

@descartes

I write:

@descartes

And how close is it to the gateway (forum search will inform you that too close is BAD - 5m + brick wall minimum).

Your reply:

@erfan_mahmud

3 meters

You may want to review the above …

You may want to review the above …

[mrtopu34]

I have the same problem.

[Johan_Scheepers]

What same problem do you have?

[descartes (Nick McCloud)]

Please do not run two or more threads on the same issue - it splits the resources of the volunteers who could answer and causes confusion.