Below is the implementation of SetOpMode, static variable opModePrev is used to keep previous mode, but this value is not always synced with the acctual mode, like situation user transmits one packet, when finished, SX127x will enter standby mode automatically, but opModePrev now is still in transmit mode, this will cause issue, if user doesn't call SetOpMode to set standby/sleep manually (actually not necessary for LoRa chip) before next transmitting, then the transmit will fail.

Related patch is submitted but should have not solved the issue completely. @djaeckle
008f8dd

Two possible solutions:

1. Abandon static local variable, use global value instead. Update the value when LoRa chip mode is
   changed internally automactically (TXDONE, RXDONE, and reset operation need sync the value to standby mode)
2. Abandon static local variable, read OpMode value from lora chip directly. This way costs some extra MCU resources but not much, should be more clean than previous one.

void SX1276SetOpMode( uint8_t opMode )
{
    static uint8_t opModePrev = RF_OPMODE_STANDBY;

    if( opMode != opModePrev )
    {
        opModePrev = opMode;
        if( opMode == RF_OPMODE_SLEEP )
        {
            SX1276SetAntSwLowPower( true );
        }
        else
        {
            SX1276SetAntSwLowPower( false );
            if( opMode == RF_OPMODE_TRANSMITTER )
            {
                 SX1276SetAntSw( 1 );
            }
            else
            {
                 SX1276SetAntSw( 0 );
            }
        }
        SX1276Write( REG_OPMODE, ( SX1276Read( REG_OPMODE ) & RF_OPMODE_MASK ) | opMode );
    }
}

Hi,

To test the duty cycle, I'm looping on LoRaEngine_transmitData(uint8_t , void *, uint16_t).
I realized that only the first packet got send.
After looking deeper in the code, seems like calling the above function 2 times successively brake something in the state-machine.

LoRaMacEventFlags.Bits.Tx always stay on 0.
LoRaMacState stay on MAC_TX_RUNNING.
OnMacStateCheckTimerEvent() called but not doing anything.
OnRxWindow2TimerEvent() or other events not anymore called.
LoRaEngine_transmitData() returns always "busy".

If you don't manage to reproduce the error, please tell me.

Best regards,
Sebastian

Hello,
I am trying to send maximum payload messages (51 bytes on DR0 SF12BW125) from gateway to end-node and they are not received properly.
My understanding is that if there are no fOpts to be transmitted the maximum payload for the message on DR0 is 51 bytes so adding the minimal FHDR, FPort, MHDR and MIC it equals to 64 bytes. When I try to send message with 51 bytes payload size on the packet forwarder log is exactly 64 bytes but the transmission does not even trigger the Rx interrupt on the end-node. To make it successful I have to reduce the payload to the size that makes the whole message size (packet forwarder log) 51 bytes.

Another solution to this problem is to change the MaxPayloadOfDatarate value to 64 but I believe it is against LoRaSpec.

Are my calculations wrong or are there some other variables that limit my payload size?

Hello,

I did some calculations for timeOnAir on US band with LoRa Calculator as well as the formula from sx1272 spec and there is one thing that bothers me. My understanding was that in US band the max timeOnAir for a given channel was 400 ms and that factor was limiting the max payload of messages for a given DR. But for certain examples (SF8BW125, SF12BW500, SF11BW500, SF10BW500) timeOnAir for maximum payload with minimal coding rate is bigger than 400 ms. Does that mean that the hopping mechanism would change the channel in the middle of the packet?

Best regards,
Pawel

Device fail to add the CFList transmitted in a join_accept frame.

When joining on OTA and getting a join_accept, the device will execute function LoRaMacChannelAdd( i, param ) to add incoming channels. This function start with few checks and fail to succeed this one :

if( ( LoRaMacState & MAC_TX_RUNNING ) == MAC_TX_RUNNING )
{
    return LORAMAC_STATUS_BUSY;
}

The LoRaMacState is MAC_TX_RUNNING because it's sending join_request and getting an join_accept.
The flag can not be cleared before as it is running. Is it possible to modify this check?

Is there a minimum channels to be active for a device in 915 MHz ?

For a device in USE_BAND_915_HYBRID I got Channel mask KO when the gateway send a SRV_MAC_LINK_ADR_REQ with only three channels to activate.

After investigation the code responsible is in the function ProcessMacCommands(), checking if there is at least 6 channels enabled.

                        if( CountNbEnabled125kHzChannels( channelsMask ) < 6 )
                        {
                            status &= 0xFE; // Channel mask KO
                        }

Hi,

I use the new stack, with the wrapper for api_V3.

The bug is in class A and class C.

When the network send a new channel(MAC cmd SRV_MAC_NEW_CHANNEL_REQ),
all new channels are refused.
the function LoRaMacChannelAdd() returns LORAMAC_STATUS_BUSY.

I think, the bug can be fixed if you add the lineLoRaMacState &= ~MAC_TX_RUNNING;
in LoRaMac.c, /OnRadioRxDone() / case FRAME_TYPE_DATA_UNCONFIRMED_DOWN: / if( isMicOk == true ) / else of if( multicast == 1 )" / out of if( ( DownLinkCounter == downLinkCounter ) && ( DownLinkCounter != 0 ) )

The second pb with this bug, is the stack uses theses new channels, despite the error.

Thanks

GF.

What is the philosophy when a Join Request fails? At the moment we get no feedback from the code which places the onus on us to place a timer in our code to wait for the 10 or so seconds to see id the Join Accept message has been received.

Would it not be better for the RxTimeout message to be routed out as in indication of the failed attempt? In the MlmeConfirm() function the LoRaMacEventInfo.Status never gets set to the correct state as it only gets set if the mlmeConfirm->Status is equal to LORAMAC_EVENT_INFO_STATUS_OK. Which as the attempt has failed it hasn't been set to this value.

If I add code along the line of

if( mlmeConfirm->Status == LORAMAC_EVENT_INFO_STATUS_OK )

{
'''
}
else
{
if (mlmeConfirm->MlmeRequest == MLME_JOIN)
{
LoRaMacEventInfo.Status = mlmeConfirm->Status;
}
}

I get the Timeout event and I can deal with the failure.

However this raises another problem. If I do add this code and get the timeout and use this to send another JoinRequest, the transmission time is calculated using a duty cycle of 1%. But the spec states that the "JoinReq message transmit duty-cycle should never exceed 0.1%". So we would be breaking the spec. In this instance are we expected to handle the duty cycle calculations ourselves?

Hi,

To minimize consumption during sleep, I don't have ram retention during sleep. To achieve that, i plan to save DevAddr, NwkID, NwkSKey, AppSKey in flash before sleep, and restore them after .
( LoRaMacMibGetRequestConfirm and LoRaMacMibSetRequestConfirm ).

But there are many others global variables in stack and I'm afraid to loose some important configuration data during sleep.
Is it a problem to loose state of stack ?
May it increase consumption at start ? ( receive each time mac commands with configuration data from network)

Is there a way to properly save stack state during sleep ?

Regards,

In the EU version as a test I've centered Radio_1 on 869.5MHz in the gateway. This produces frequencies of 869.1/3/5/7/9. All of these frequencies lie within an allowed ETSI band.

When I receive the Join Accept message It contains the Channel List containing the above frequencies. However when I check the channel list at the end of the routine 869.3MHz is missing. The frequency is set to 0 and the ChannelsMask is updated accordingly.

The reason for this is that in function LoraMacChannelAdd() there is no band that this frequency sits in. It would fit in the 863-870MHz band but this has been reduced to 865-868MHz so that the duty cycle can be increased to 1% from 0.1% if the full band is used.

Is this something we just have to accept for the increased duty cycle is a gateway uses this center frequency? Is that the reason for the frequency bands being as they are?

Hi,

The LoraWan specification defines 3 default channels(LC1,LC2 and LC3) to guarantee a minimal channelset between and-device and gateways.

In LoraMac-Board.h 9 channels are defined and are used in LoraMac.c.
I don't understand the utility. New channels are sent by the operator, and the range is 863-870MHz.

thanks ,

Guillaume F.

Hello,

I would like to know if the stack is working with the China779-787MHz ISM Band.
I have modified the frequency definitions defined in "LoRaMac-board.h", and it can also communicate with gateway and server, which work at the same band.
Furthermore, There is some code with "CLASS C", is the Class C fully implemented in the code?. I have debugged Class C mode(sensor node), and it seems doesn't work well. Only one packet has been sent to gateway(and forwarded to server) when power on, and downlink data can't been passed to application by callback functions. it seems link the MAC schedule doesn't work well.

Thanks a lot.
Haibo Luo (NPLink)

When sending confirmed messages (from several nodes) at same time the nodes will go back in to Idle State (LoRaMacState is MAC_IDLE) after a while (when all the retransmission is done). But when the concentrator sends concurrently unconfirmed messages to a multicast address (to all nodes), the nodes state machine will hange on some nodes -> LoRaMacState is MAC_TX_RUNNING and the timer TxTimeout is no more running. I tried with 10 nodes (V4.0.0 Stack) and one concentrator.

Hello,

I am trying to open this project in CoIDE only i get the error:
"The chil:STM32L141CBT6 information of current project has something worng."
Does anyone know this error? And how can i fix this?

Greet Justin

I've noticed that the ChannelsMask[0] value might not be handled correctly in EU mode in the ProcessMacCommands() routine. It is originally set in the following line
channelsMask[0] = chMask;
but later in the routine there is a section of code that I'm getting into
if( ( status & 0x07 ) == 0x07 )
{
ChannelsDatarate = datarate;
ChannelsTxPower = txPower;

if defined( USE_BAND_915_HYBRID )

                    ChannelsMask[0] = channelsMask[0] & 0x00FF;
                    ChannelsMask[1] = channelsMask[1] & 0x0000;
                    ChannelsMask[2] = channelsMask[2] & 0x0000;
                    ChannelsMask[3] = channelsMask[3] & 0x0000;
                    ChannelsMask[4] = channelsMask[4] & 0x0001;
                    ChannelsMask[5] = channelsMask[5] & 0x0000;

else

                    **ChannelsMask[0] = channelsMask[0];**
                    ChannelsMask[1] = channelsMask[1];
                    ChannelsMask[2] = channelsMask[2];
                    ChannelsMask[3] = channelsMask[3];
                    ChannelsMask[4] = channelsMask[4];
                    ChannelsMask[5] = channelsMask[5];

endif

which overwrites the ChannelsMask[0] with whatever is in channelsMask[0](in my case this is usually 15).

Should that #else not be #elif defined( USE_BAND_915 ). I think this code might only be relevant to the US version.

Hi,

I would like to know (for my knowledge), why DevEUi and AppEUI are in Little Endian and keys are in BigEndian?

What is the technical reason?

Thanks

GF.

Hi,
I'm working on a project using this loraMac-node code.
In the project I use LoRaMacSendConfirmedFrame in a Class C network on an actility network.
But it seems that the code doesn't recover from a 'LORAMAC_EVENT_INFO_STATUS_ERROR'
Do you have any suggestions on what to do?

Kind regards,

Matijs

If ADR is enabled and a new channel is created by the network server on the device to use FSK.
Then the device's SNR is such that the datarate is raised to FSK mode.
When ACKRetries's are set to 1 or 2 and ACKRetries are exhausted the device will ReEnableDefaultChannels and TxDatarate will remain at FSK mode without a channel enabled.
This will cause the device to be unable to transmit or change datarate without intervention.

It is also an issue if ReEnableDefaultChannels is called after the FSK channel was created when TxDatarate is below FSK mode. When it again reaches the FSK threshold the LinkADRReq will be rejected because the FSK channel is disabled.

Hello,I have difficulty in understanding scheduling management.Can you explain it to me,and I want to know what documents should I refer to.Thank you very much.My Email is :[email protected].

SX1276.RxTx variable is not synced when the device is set to low power mode.
This may cause RxWindow2 receive sesitivity lost issue of LoRaWAN stack.

// Reproduce the issue
SX1276SetAntSwLowPower(false);
SX1276SetAntSw(0);      // SX1276.RxTx is 0 now
SX1276SetAntSwLowPower(false);
SX1276SetAntSw(0);      // SX1276.RxTx is still 0, this function is not worked as expected

The related functions locate at sx127x-board.c files.

void SX1276SetAntSwLowPower( bool status )
{
    if( RadioIsActive != status )
    {
        RadioIsActive = status;

        if( status == false )
        {
            SX1276AntSwInit( );
        }
        else
        {
            SX1276AntSwDeInit( );
        }
    }
}

void SX1276AntSwInit( void )
{
    GpioInit( &AntSwitchLf, RADIO_ANT_SWITCH_LF, PIN_OUTPUT, PIN_PUSH_PULL, PIN_PULL_UP, 1 );
    GpioInit( &AntSwitchHf, RADIO_ANT_SWITCH_HF, PIN_OUTPUT, PIN_PUSH_PULL, PIN_PULL_UP, 0 );
}

void SX1276AntSwDeInit( void )
{
    GpioInit( &AntSwitchLf, RADIO_ANT_SWITCH_LF, PIN_OUTPUT, PIN_OPEN_DRAIN, PIN_NO_PULL, 0 );
    GpioInit( &AntSwitchHf, RADIO_ANT_SWITCH_HF, PIN_OUTPUT, PIN_OPEN_DRAIN, PIN_NO_PULL, 0 );
}

void SX1276SetAntSw( uint8_t rxTx )
{
    if( SX1276.RxTx == rxTx )
    {
        return;
    }

    SX1276.RxTx = rxTx;

    if( rxTx != 0 ) // 1: TX, 0: RX
    {
        GpioWrite( &AntSwitchLf, 0 );
        GpioWrite( &AntSwitchHf, 1 );
    }
    else
    {
        GpioWrite( &AntSwitchLf, 1 );
        GpioWrite( &AntSwitchHf, 0 );
    }
}

If I well understand, when the stack receives a FRAME_TYPE_DATA_CONFIRMED_DOWN, the stack confirmes the frame.

But if the latence is too big, or if there is a network problem with the acknowledge, the network server retries the FRAME_TYPE_DATA_CONFIRMED_DOWN.

At each reception, the stack calls the callback "OnMacEvent". So if the network server tries 3 times to send the FRAME_TYPE_DATA_CONFIRMED_DOWN, the applicative part receives 3 times the donwlink frame, with same data.

The stack can filter the FRAME_TYPE_DATA_CONFIRMED_DOWN, with the "DownLinkCounter".

Is it in the backlog for a next release?

Thank you very much,

GF.

Hello,

In the file aes.c, line 67, the 32 bits unsigned integers are defined as follows :
typedef unsigned long uint_32t;

On a 64 bits machine, this data type is expanded to a 64 bits integer.
May I suggest you to use the stdint.h header and use the uint32_t data type for portability sake ? For debugging purpose, it would be useful to avoid cross compiling every time.

Hi !
I am using the CoIDE toolchain in order to reprogram the iM880A node - ClassA project.

The toolchain is like:
CoIDE v. 1.7.8
GCC 4.9.3 - builds successfully
DFU File Manager v. 3.0.5 - for converting .hex to .dfu
DfuSe Demo v.3.0.5 - for uploading dfu to node, gives at Verify "Matching not good. First Difference at address 0x08000000: File byte is 0x00. Read Byte is 0xD0. !!!!

BR
Michael Alrøe

Hello,

sending large FRM payloads (45 bytes) with class A LoRa devices I see some packet length error.

It happens when LoRa stack includes MAC commands in the FHDR reducing the FRM payload length.

Example: Header 8 bytes + MAC Commands 12 bytes + FRM payload 45 bytes

If I have not misunderstood the code, LoRa stack adds MAC commands even if the MAC payload size exceeds the maximum MAC payload size causing a packet drop.

How to overcome this issue? I have to consider the maximum FRM payload size of 36 bytes (51 N - 23 FHDR -1 Fport) to guarantee a packet delivery in the worst case (FHDR of 23 bytes) or there is a solution to send MAC commands in a different way ?

Thanks in advance

Regards

We would like to know if the maximum payload size in function of the DR is implemented? ==> 7.1.6 EU863-870 Maximum payload size in LoRaWAN™ Specification ,Version: V1.0

And we have try to send a Lora frame with a applicative payload of size 55. It doesn't work.
The error code returned is 3. Do you know if there is a bug?

Thanks a lot.
Guillaume

Hi all,

Trying to program the LoRaMote through DFU, I faced a problem with the bootloader project.
At the compilation LD time, I got an error telling me that the .text section overflow the memory mapped size.

Checking into the ".ld" https://github.com/Lora-net/LoRaMac-node/blob/master/src/boards/LoRaMote/cmsis/arm-gcc/stm32l1xx_md_flash_bootloader.ld, I found an issue at line 4:
/* Memory regions.*/
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 12K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 16K
}

The Flash length is only 12K instead of 128K. It results in a compilation faillure with more than 5K overflow.

Thank you in advance for the fix.

Rgds.
MarcAntoine MARTIN

how does LoraWAN MAC support CSMA/CA management?

I have two questions about Tx-Cw app example for Sx1272 at 868MHz (I've taken main.c example for SK-iM880A).

1. I've changed TX_OUTPUT_POWER from 20 dBm to 14 dBm but after this modification SX1272 still transmits at 20dB
2. I've seen the following register settings:
   Radio.Write( 0x4B, 0x7B );
   Radio.Write( 0x3D, 0xAF );
   Radio.Write( 0x1e, 0x08 );
   Radio.Write( 0x4C, 0xC0 );
   Radio.Write( 0x4D, 0x03 );
   Radio.Write( 0x5A, 0x87 );
   Radio.Write( 0x63, 0x60 );
   Radio.Write( 0x01, 0x83 );

Is there some application note or documentation that describe these registers?

Hi,

I am trying the FSK mode with the Ping Pong Example.
With a buffer size = 64, it's working well.

Then I try with a buffer longer(size = 200).( All bytes are filled)
The radio transfer works, 32 first bytes are ok, but bytes 33 to 199 are egual to zero.

Are you already checked the FSK mode with the radio driver and a frame longer than 64 bytes?

Thanks,
Guillaume.

Why does SX1272GetPaSelect always return RF_PACONFIG_PASELECT_PABOOST?

According to the comment, RF_PACONFIG_PASELECT_RFO should be the default.

Furthermore, I believe this should be a variable that is set in the board-specific board.h file. I am working on a design that does not use the PA_BOOST pin so I must change sx1272-board.c in order to have the correct value written to register 9 on transmit. Instead, can SX1272GetPaSelect check to see if a board-specific value is set before setting to a default value?

Thanks,
Tim

From the OnRadioRxDone handler I see values from -57 to 34. Is this value in cB or dB?

I see the SxRadio has divided the register value by 4 and this looks correct from the Sx1272 documentation. But these values maybe too high for dB and too low for cB.

Also in OnRadioRxDone the SNR value is then put into the event object which has unsigned integer type.

For the SX1272, the output power can be non-linear. I have modified the power table (TxPowers[]) to reflect this below. I think this should be something defined in a board-specific file instead of LoRaMac.c.

const int8_t TxPowers[] = { 30, /* TX_POWER_30_DBM /
28, / TX_POWER_28_DBM /
26, / TX_POWER_26_DBM /
24, / TX_POWER_24_DBM /
22, / TX_POWER_22_DBM /
20, / TX_POWER_20_DBM /
18, / TX_POWER_18_DBM /
16, / TX_POWER_16_DBM /
15, / TX_POWER_15_DBM /
14, / TX_POWER_14_DBM /
12, / TX_POWER_13_DBM /
11, / TX_POWER_12_DBM /
10, / TX_POWER_11_DBM /
10, / TX_POWER_10_DBM /
9, / TX_POWER_09_DBM /
8, / TX_POWER_08_DBM /
6, / TX_POWER_07_DBM /
5, / TX_POWER_06_DBM /
4, / TX_POWER_05_DBM /
2, / TX_POWER_04_DBM /
1, / TX_POWER_03_DBM /
0, / TX_POWER_02_DBM /
0 }; / TX_POWER_01_DBM */

Alternatively, a simple function to convert a desired power in dBm to a register setting would also suffice.

LoRaMac.c static TimerTime_t SetNextChannel( void ) returns 0 even if no channels are supported, if nextTxDelay is never assigned a value after initialization:

    if( nbEnabledChannels > 0 )
    {
        Channel = enabledChannels[randr( 0, nbEnabledChannels - 1 )];
#if defined( USE_BAND_915 ) || defined( USE_BAND_915_HYBRID )
        DisableChannelInMask( Channel, ChannelsMaskRemaining );
#endif
        return 0;
    }
    else
    {
        // Protect the function of returning the initialization value of nextTxDelay
        return ( nextTxDelay == ( TimerTime_t )( -1 ) ) ? 0 : nextTxDelay;
    }

But if .TimeOff of all bands == 0 in the following...

// Update Aggregated duty cycle
    if( AggregatedTimeOff < ( curTime - AggregatedLastTxDoneTime ) )
    {
        AggregatedTimeOff = 0;

        // Update bands Time OFF
        for( uint8_t i = 0; i < LORA_MAX_NB_BANDS; i++ )
        {
            if( DutyCycleOn == true )
            {
                if( Bands[i].TimeOff < ( curTime - Bands[i].LastTxDoneTime ) )
                {
                    Bands[i].TimeOff = 0;
                }
                if( Bands[i].TimeOff != 0 )
                {
                    nextTxDelay = MIN( Bands[i].TimeOff -
                                       ( curTime - Bands[i].LastTxDoneTime ),
                                       nextTxDelay );
                }
            }
            else
            {
                nextTxDelay = 0;
                Bands[i].TimeOff = 0;
            }
        }

...then nextTxDelay == ( TimerTime_t )( -1 ), and if nbEnabledChannels == 0, the function returns 0. This is problematic since ScheduleTx then calls SendFrameOnChannel using the current Channel value, even though no channels are currently enabled.

One quick fix would be for SetNextChannel to return ( TimerTime_t )( -1 ), and then have ScheduleTx check for this as an error. Any problems with this?

While testing my SK-iM880A I found two issues:

1. (minor)
   The project file includes the classA "main.c" in stead of the classC "main.c".
2. (major)
   While using the Class C mode I find that the device acts like a Class A device. The device only sets LED3 afters first sending data. And when sending data from the basestation, the basestations shows "active" and when the data is sent, "Try1". This implies that the end-device does not send a "ACK". When the end device sends new data, the status is set to "Success".

I am using the Kerlink LoRa IoT Station 868 with SPN software.

Hi,

What is the meaning of USE_BAND_915_HYBRID in LoraWan stack (V3.4) ?

Thank you,

Guillaume F.

When the ClassC comes into OnRadioRxDone, RxBuffer is cleared after OnRxWindow2TimerEvent(). Because OnRxWindow2TimerEvent() calls back the SetRx() which would clear the RxBuffer and the payload here points to RxBuffer.

static void OnRadioRxDone()
{
    if (LoRaMacDeviceClass != CLASS_C)
    {
        Radio.Sleep();
    }
    else 
    {
        if (LoRaMacEventFlags.Bits.RxSlot == 0) 
        {
            OnRxWindow2TimerEvent();    
        }
    }

    macHdr.Value = payload[ptkHeaderLen++];

    switch()
    {
        ...
    }
}

So I think it should be like this

static void OnRadioRxDone()
{
    if (LoRaMacDeviceClass != CLASS_C)
    {
        Radio.Sleep();
    }

    macHdr.Value = payload[ptkHeaderLen++];

    switch()
    {
        ...
    }

    if ((LoRaMacDeviceClass == CLASS_C) && (LoRaMacEventFlags.Bits.RxSlot == 0))
    {
            OnRxWindow2TimerEvent();   
    }
}

getter for MIB_UPLINK_COUNTER isn't implemented in LoRaMacMibGetRequestConfirm(), although should be included based on comment block from LoRaMac.h reproduced below.

Also noticed MIB_REPEATER_SUPPORT is missing entirely from comment block below, although getter and setter are both implemented.

/*!
 * LoRa Mac Information Base (MIB)
 *
 * The following table lists the MIB parameters and the related attributes:
 *
 * Attribute                         | Get | Set
 * --------------------------------- | :-: | :-:
 * \ref MIB_DEVICE_CLASS             | YES | YES
 * \ref MIB_NETWORK_JOINED           | YES | YES
 * \ref MIB_ADR                      | YES | YES
 * \ref MIB_NET_ID                   | YES | YES
 * \ref MIB_DEV_ADDR                 | YES | YES
 * \ref MIB_NWK_SKEY                 | YES | YES
 * \ref MIB_APP_SKEY                 | YES | YES
 * \ref MIB_PUBLIC_NETWORK           | YES | YES
 * \ref MIB_CHANNELS                 | YES | NO
 * \ref MIB_RX2_CHANNEL              | YES | YES
 * \ref MIB_CHANNELS_MASK            | YES | YES
 * \ref MIB_CHANNELS_NB_REP          | YES | YES
 * \ref MIB_MAX_RX_WINDOW_DURATION   | YES | YES
 * \ref MIB_RECEIVE_DELAY_1          | YES | YES
 * \ref MIB_RECEIVE_DELAY_2          | YES | YES
 * \ref MIB_JOIN_ACCEPT_DELAY_1      | YES | YES
 * \ref MIB_JOIN_ACCEPT_DELAY_2      | YES | YES
 * \ref MIB_CHANNELS_DATARATE        | YES | YES
 * \ref MIB_CHANNELS_TX_POWER        | YES | YES
 * \ref MIB_UPLINK_COUNTER           | YES | NO
 * \ref MIB_DOWNLINK_COUNTER         | YES | NO
 * \ref MIB_MULTICAST_CHANNEL        | YES | NO
 *
 * The following table provides links to the function implementations of the
 * related MIB primitives:
 *
 * Primitive        | Function
 * ---------------- | :---------------------:
 * MIB-Set          | \ref LoRaMacMibSetRequestConfirm
 * MIB-Get          | \ref LoRaMacMibGetRequestConfirm
 */

Hi,

I think there is a problem with the dafault value of AckTimeoutRetriesCounter.

When I configure LoRaMacSendConfirmedFrame with nbRetries=1, the frame is sent one time( with ACK timeOut of course). and if configure nbRetries=2, the frame is sent two times.

Normally, the number of retrie is in more of the first frame. So if the value of nbRetries is 3, 4 frames are sent if there is no Acknowledge.

Thanks

GF.

Quick question: How does this implementation relate to IBM's LMIC library? Version 3.1 of this library stated that the next version of this library would be based on IBM's LMIC library, but I'm not sure if that change actually happened (a quick look at the code shows the code structure is different from LMIC still). Is it now based on LMIC? Or was the plan to switch over cancelled?

Hi,

I need some assistance with setup the usart for serial debugging, I am recently worked on the LMIC libraries from IBM but was told that is official outdated and that I should try to port my code over to the semtech LoRaMac instead, any help will be highly appreciated. Thank you in advance.

When transmitting a packet the size is the first byte. If 64 bytes are written after that FIFO will be overfilled.

Also, it seems support for FSK packets larger than 64 bytes is not complete in the SxRadio drivers.
The FifoLevel handler attempts to write data from the RxBuffer but the Send function did not copy the payload data into that buffer.

Testing release 4.1.0:
after receiving a downlink message (ADR ACK, ACK, device status request, ...) there seems to be a delay of 5 minutes before the next uplink is transmitted, when uplink messages are scheduled to be transmitted every 3 minutes.

Using the same application with release 4.0.0, we don't have this issue.

Someone else noticed the same?

I think the MacCommandBufferIndex should be checked In the beginning of function "AddMacCommand". When I repeat transmitting a mac command like LinkCheck, if the transmission failed, the MacCommandBufferIndex will ourt of it range in the current code.

in my opinion, it should be like:

static uint8_t AddMacCommand( uint8_t cmd, uint8_t p1, uint8_t p2 )
{
    if (MacCommandsBufferIndex == 14) {
        return 2;
    }

    MacCommandsBuffer[MacCommandsBufferIndex++] = cmd;
    switch( cmd )
    .......
}

Hi,

I 'am in Class C, 868MHz.
I would like to use the LoraMac internal state with the variable LoRaMacState . I created a function to return this state to the application.
My goal is to know when we are in TX.

When I send a Confirmed frame with 5 repetitions for example, the stack is in MAC_TX_RUNNING mode until the acknowledge reception.

I excepted that the stack switch from MAC_TX_RUNNING to MAC_RX and so forth, until the acknowledge reception. And finally, the stack will be in MAC_RX --> due to the Class C.

But the reality is : the state is MAC_TX_RUNNING until the acknowledge reception (even if there is several TX due to the repetitions (confirmed send) ). when the acknowledge is incoming, the state is MAC_RX and after the state is MAC_IDLE.

Is it normal in Class C that the state stack can be MAC_IDLE?
Maybe the variable LoRaMacState is the stack state and not the radio state. But between a TX and a new TX, the stack should be in MAC_IDLE . ?

What are you think about that?

Thanks,

Guillaume F.

Hello,

I would like to know if the stack is working with the US902-928MHz ISM Band.
There is some code with "USE_BAND_915". The stack is it fully compatible with the US 915MHz band?
What are the limitations between the implementation and the specification LoraWan1.0 ?
All DR are not implemented for example. Just DR with BW125 exist.

Do you have a plan to include the 915MHz band in a next version?

Thanks a lot.
GuillaumeF

A Class C device will open a window with rx2 parameters in the TxDone function.
When Rx1Window timeout occurs will the rx1 window be able to open when radio not idle?

Doing the LoRaMote ClassA project trying to change the APP_TX_DUTYCYCLE from 5000000 (5s) does not have any influence on the payload transmission rate! The TX transmission rate is app 2,5 min! How do I reduce the TX transmission rate?

Tried to remove the "LOW_POWER_MODE_ENABLE" from the compiler!

BR
Michael

The vector is defined as:
const uint8_t MaxPayloadOfDatarate[] = { 51, 51, 51, 115, 242, 242, 242, 242 };

But in prepareframe function we put:
ValidatePayloadLength( fBufferSize, ChannelsDatarate, MacCommandsBufferIndex )

In the case ChannelsDatarate = DR0 => SF12, ValidatePayloadLength function will compare the buffer size with 51 when must be compared with 242.

Is this correct or I'm wrong?

Could somebody tell me what are the planned changes and schedule for future versions?

A) Is there a plan to make the stack part less encapsulated to the current code (a clearer OS Abstraction layer)?
B) Is there the plan to support the STM32L051Cx CPU ?

PS: Is there a place where to put those questions?
Thanks

Altitude is declared as an unsigned int in master/src/system/gps.c
In the Netherlands we live often under sealevel, eg where i live:
$GPGGA,160550.000,5200.5854,N,00442.9635,E,1,04,3.3,-40.8,M,47.1,M,,0000*4C
May i suggest you make Altitude in a future release signed ?
regards
Walter Takens