The following code in lmic.c is wrong:

void LMIC_disableChannel (u1_t channel) {
    if( channel < 72+MAX_XCHANNELS )
        LMIC.channelMap[channel/4] &= ~(1<<(channel&0xF));
}

The penultimate line is supposed to be indexing by word based on channel, which would mean dividing by 16, not by 4.

The result is that disabling channel can write off the end of the channel map, and in any case doesn't work properly unless the channel number is less than 4.

For consistency with other places in the code, it should be rewritten as:

        LMIC.channelMap[channel>>4] &= ~(1<<(channel&0xF));

Need to use LMIC.rxDelay, not the default value, in updataDone().

The US915 configuration incorrectly treats ChMaskCtl as a channel block (80..95, in effect). The LoRaWAN 1.1 regional plan defines this as a channel-group (subband) enable.

The join code for eu868 seems to use 6 channels; the ardunio-lmic code uses three. Per @tftelkamp, these are not part of the eu868 channel plan for LoRaWAN 1.0.2, and were removed in advance based on prior knowledge. So we need to remove them here. Will file new issue.

Not clear that it's needed, but the arduino-lmic code for schedRx12() is much different than the ibm-lmic code for schedRx2(). Much more elaborate clock compensation logic. There are corresponding changes in txDone(), and the schedRx*() functions are used differently. Also check processRx1Jacc(), processRx1DnData().

In lorabase.h, DR_PING is defined as SF9; this is a category error, it should be DR_SF9. It's not correct; SF9 is numerically 3; DR_SF9 is 4.

Hello
this commit 5cb09ab
does not compile.

lmic.c uses a field called rxDelay which is not part of the structure..
Should I add a os_time_t delay to the structure?

Thanks
Julien

If CFG_TxContinuousMode is defined and non-zero, radio_irq_handler() will have dead code after the #endif. Need to #else-out the rest of the ISR.

The IBM code clearsLMIC.pendTxConf while starting a join in LMIC_startJoining(). But the Arduino code does not. Needs review.

Per the resolution of #4, the IBM v1.6 code should be updated to match the arduino-lmic code with regards to the LoRaWAN 1.0.2 channel plan: joins happen on only three channels, not six.

The IBM LMIC code doesnt reset the TX sequence number on join. It also doesn't grab the Rx Delay from the join accept message, nor does it grab the dn2 datarate.

For me it seems LMiC code in radio.c selecting the PA Output pin of SX1276 is erraenous. Always Pin PA_BOOST is selected. This can cause malfunction, if board hardware does not wire this pin, because it uses the RFO_HF / RFO_LF pins only.

Further details on this issue can be found here.

Hello,

I am intending to leverage your library for a vehicle sharing IoT device integrated with Helium. I've managed to get the examples operational, but it appears that only Class A functionality is currently working. If my understanding is correct, Class A requires an uplink transmission before a downlink can be received, which isn't an optimal solution for my use case.

My application requires real-time command transmission to the device, such as initiating lock/unlock operations. This demands a continuous ability to receive downlink messages independent of any preceding uplink transmission.

I understand that Class C, which provides continuous listening for downlinks, is currently not implemented in your library. However, I am interested in knowing if Class B, which according to my research opens the downlink window at regular intervals (e.g., every 10 seconds), is supported or can be implemented. This mode would be more than sufficient for my application requirements.

I appreciate your help and clarification on this matter.

Thank you!

If configured for eu868 mode, initDefaultChannels() sets up LMIC.bands[] so that each entry has a valid .lastchnl entry. However there's a typo; the last channel entry for BAND_CENTI is set twice, but the last entry for BAND_DECI is never set. Found by comparing with the similar code in https://github.com/terrillmoore/arduino-lmic.

The IBM LMIC code reverses the order of these two bytes in the End-device Status message.