LoRaWAN Sample App Fails to Join on nRF52840DK + SX1262

[rdauben]

I am running the zephyr LoRaWAN sample app on the Nordic nRF52840DK with a SX1262 shield.  I am also using a Conduit gateway.  Both sides are using the US915 region profile.

I've confirmed the hardware with the simple Tx/Rx and PingPong point-to-point demos.  Also, the MBED LoRaWAN sample app from Semtech, built with Mbed Studio,  runs successfully on the same hardware.

With the zephyr LoRaWAN sample app, I see my Join Request at the gateway and the gateway sends back a successful Join Accept.  But the app does not receive  the response and then times out.

Per the LoRa spec, every Join Request is sent on a random uplink frequency, and the gateway sends back the Accept on a downlink frequency that is derived from the frequency of the Request.  This all appears from the logs to be working correctly.  Sometimes, the gateway sees the Join Request on a frequency that is not what the app sent it on.  Of course, when this happens, the gateway responds on the wrong downlink frequency and the device does not see the Accept response, because it is listening on the expected downlink frequency.  However, I also see this same behavior with the working MBED app, so it must be normal.  The MBED app sends out another Join Request and keeps trying until the gateway responds on the expected frequency.  Then the connection is successful.

But on the zephyr app, even when the gateway receives the Join Request on the correct frequency and sends back the Accept on the correct downlink frequency, where the app is listening, the app does not receive the message and then times out.  Occasionally (1 out of 30-40 attempts), the app gets an interrupt indicating a preamble was detected.  This should be followed by interrupts for valid header and complete RX packet.  But I don’t see that.  I modified the app to retry upon failed joins.

My build is from the Nordic SDK nRF Connect v2.1.0.  Some of the key components are located here:

• Main app                                     zephyr\samples\subsys\lorawan
• LoRaWAN subsystem             zephyr\subsys\lorawan
• LoRaMac module                     modules\lib\loramac-node\src\mac
• SX1262 driver                            zephyr\drivers\lora

I have added some debug logs to printout the Tx and Rx frequencies for the Join messages, so that I can correlate with messages on the gateway.

[Benedikt Bau]

 rdauben : I face the same issue using nrf5340dk + sx1262 lora shield. Do you have any suggestions on how to solve this problem by now?

kind regards

[rdauben]

Hi.  I found out I had some problems with timing for going into standby mode prior to setting the RF Frequency and the Packet Type.

In file <sdk>/modules\lib\loramac-node\src\radio\sx126x\sx126x.c:

I added a small 2 msec delay at the end of SX126xSetStandby() to allow time to settle:

void SX126xSetStandby( RadioStandbyModes_t standbyConfig )
{
    SX126xWriteCommand( RADIO_SET_STANDBY, ( uint8_t* )&standbyConfig, 1 );
    if( standbyConfig == STDBY_RC )
    {
        SX126xSetOperatingMode( MODE_STDBY_RC );
    }
    else
    {
        SX126xSetOperatingMode( MODE_STDBY_XOSC );
    }

    // Added to get JOINs and data Tx to work.
    DelayMs( 2 );
}

Also added a test for standby mode prior to setting packet type and RF freq:

void SX126xSetRfFrequency( uint32_t frequency )
{
    uint8_t buf[4];

    if (SX126xGetOperatingMode() != MODE_STDBY_RC)
    {
        SX126xSetStandby( STDBY_RC );
    }

    if( ImageCalibrated == false )
    {
        SX126xCalibrateImage( frequency );
        ImageCalibrated = true;
    }

    uint32_t freqInPllSteps = SX126xConvertFreqInHzToPllStep( frequency );

    buf[0] = ( uint8_t )( ( freqInPllSteps >> 24 ) & 0xFF );
    buf[1] = ( uint8_t )( ( freqInPllSteps >> 16 ) & 0xFF );
    buf[2] = ( uint8_t )( ( freqInPllSteps >> 8 ) & 0xFF );
    buf[3] = ( uint8_t )( freqInPllSteps & 0xFF );
    SX126xWriteCommand( RADIO_SET_RFFREQUENCY, buf, 4 );
}

void SX126xSetPacketType( RadioPacketTypes_t packetType )
{
    // Save packet type internally to avoid questioning the radio
    PacketType = packetType;

    // Setting modem type must happen in standby mode.
    if (SX126xGetOperatingMode() != MODE_STDBY_RC)
    {
        SX126xSetStandby( STDBY_RC );
    }

    SX126xWriteCommand( RADIO_SET_PACKETTYPE, ( uint8_t* )&packetType, 1 );
}

[Benedikt Bau]

Hi rdauben,

thank you very much for your fast reply.

I've tested your fix but it doesn't seem to help in my case. But I guess your right, it looks like some kind of timing issue since the application runs with other boards quite well.

Thank you.