Lora SX1262 Tx Timeout

[Cyada.1]

I have connected a Nicerf SX1262 us915 lora module with the STM32L496RG MCU. Lora module has DIO1 and Busy pins for tx and rx confirmation(data send and receive ).

I'm using STM32CubeExpansion_LRWAN_V1.3.1 library and i have used sx1262 example which is sx1262dvk1das. This code is properly working and its generate also interrupt on dio1 and busy pins at exact time but its occurs tx timeout or give on serial port window txtimout. I also get proper data on my gateway and server which is on ttn.

I dont know where is the problem. Interrupt fired on proper time. I checked all physical connections which is properly connected. I'm sharing my serial window data. where 64 is dio1 pin interrupt. . 

[SHATE.1]

Hello

i use in a custom board a DORJI DRF1262T module that contain the sx1262.

i use also the i-cube-lrwan package and the sx12621das projet.

i have the same problem than you and i have the PHY txTimeout directly after the AppKey and everything is stopped. i join a file with the point where the program is bloqued!! the PHY txTimeout is acquired after 4s112ms of the run. in the file there's a bigger value because i made step by step execution to see where the program bloc!!

it's not a hardware problem because i used the ping pong program provided by dorji and the board communicate well with other bord so lora operate well.

But i think that's a problem of lorawan protocole and that the DIO1 interruption is not handled ( i read this on the net) but i don't know how arrange this problem!!! i'm an electronic engineer and a biginner on soft development!!

So please did you already find solution for your problem? if yes can you please share it ? it will help me a lot

Thank you and for everybody who can help

Best regards

[Tesla DeLorean]

Not sure why the TX would timeout unless the packet size and data rate (spread, bw, etc) completely underestimated the time-on-air, or the packet dispatch/buffering didn't actually succeed properly.

Might look at the dwell times for the SPI CS, and the slew rates on the SPI interface pins.

You're going to have to unpack what state the SX1262 is in, and flow/sequence of data into it.

The DIO interrupts should come in via EXTI configuration of the GPIO pins, and it should be reasonably easy to track those, or reflect state to another observable GPIO pin, or scope.

[SHATE.1]

Thank you clive1 for your quick answer

i don't know why you say that there's a disproportion in the data parameter and the time on air!!! how can i verify this?

When i see SPI signal and CS and DIO1 interruption, it seem correct.

Please see the DIO1_INTERRUPT and CS_PIN file.

yelow trace : SPI SCLK

Green trace : SPI MOSI

Blue trace : SPI MISO

Pink trace : CS or DIO1 depending the name of the file

I think it's a problem of the interrupt handling, problem of callback or something like that ( i already readed this on the net : https://github.com/Lora-net/LoRaMac-node/issues/806 ).

Can you tell me please what do you think and what's the solution?

Thank you in advance

[SHATE.1]

here is the DIO1_INTERRUPT file

Thank you

[Tesla DeLorean]

>>i don't know why you say that there's a disproportion in the data parameter and the time on air!!! how can i verify this?

It is a hypothesis about where a "Tx Timeout" might occur. I know for a fact that the "Rx Timeout" can fire while it is actually receiving data, at least in some iterations of the stack, it is triggered by a timer independently of the radio, and it's not cleared by the reception of initial symbols or preamble. In that scenario the "timeout" needs to include the max time between messages, and the max message length/time that could be received after that.

The second one was if the radio didn't get the messages that it was supposed to do anything, and thus failed to complete in the assigned time frame. Your github cite seems to suggest a similar problem.

You would need to look at DIO1_INTERRUPT in the context of where the "Tx Timeout" condition is asserting, or TimerStart vs Timeout.

The state of the radio vs the stacks expectation for it to do something.

For SPI issues you'd want to concern yourself about the CS LOW to DATA OUT phase, and later the CS HIGH to CS LOW minimums between consecutive interactions.

You might want to change the compiler optimization settings, and see if there is something amiss there.

[SHATE.1]

I changed the compiler optimisation but without effect always PHY txTimeout

i don't know what i can do!!!! i use the i-cube-lrwan package!! normally it could work!!

[Tesla DeLorean]

I suppose we'd focus on what is different at an implementational level between instances that work, and those which don't

Let's start by enumerating the pin choices made on this "custom" board that make it different from the others.

For example consider if your EXTI pins clash.

What have you done to inspect the state in the radio under these conditions? Did it attempt to send the data you're trying to send?

[Tesla DeLorean]

>>i don't know what i can do!!!! 

Work backward from the point where the failure is obvious, to the point of origin.

[MViei.1]

i have the exact same issue? where you able to resolve it?