sparkfun / Arduino_Apollo3

Arduino core to support the Apollo3 microcontroller from Ambiq Micro
83 stars 37 forks source link

LoRa RFM95/ board does not work with RedBoard/Artemis Module/ Artemis_ATP environment #473

Open bimalpaneru opened 1 year ago

bimalpaneru commented 1 year ago

Using RFM95 breakout board from dragino as lora shield, v1.4 to be precise. Tried using the example code for the TTN OTAA basic example. Artemis does not handle it properly. Throws the error in the serial as

SparkFun_RedBoard_Artemis/MCCI LoRaWAN LMIC library/src/lmic/oslmic.c:53

which is the wrong pin mapping indicator, to my knowledge. Surprisingly, if you specify "NSS PIN" to 10 rather than the correct pin map of the LoRa shield to the "Red boards". The system seems to get connected to the TTN but there is no data relay, only the device is joined to the network successfully.

//The pin map is supposed to be used

const lmic_pinmap lmic_pins = {
                .nss = D10, 
                .rxtx = LMIC_UNUSED_PIN,
                .rst = D9, 
                .dio = {D2, D6, LMIC_UNUSED_PIN}, 
               };

//The pin map that works slightly
const lmic_pinmap lmic_pins = {
                .nss = 10, 
                .rxtx = LMIC_UNUSED_PIN,
                .rst = D9, 
                .dio = {D2, D6, LMIC_UNUSED_PIN}, 
               };

D10 and 10 are different pins but using 10 seems to work slightly but cannot sent data which is not ideal. I know, pin 10 in standard UNO boards is the SS/CS for the SPI comm lines. My best guess is there is some sort of collision in the core using SPI lines.

The hardware is good no issue. The Lora shield works with other Ardunio R2 boards.

It is pretty weird that CS Pin wrongly specified as 10 causes the RFM95 to respond but not the actual D10 pin.

bimalpaneru commented 1 year ago

I feel there is something not right with the pin mapping in the arduino core. I could not figure it out myself.

karl-mohring commented 1 year ago

First of all, the pin mapping should be declared without the 'Dn' notation, which will use the pad definitions when typecast instead of the pin definitions.

In which case, the pin map should be declared as follows:

const lmic_pinmap lmic_pins = {
                .nss = 10, 
                .rxtx = LMIC_UNUSED_PIN,
                .rst = 9, 
                .dio = {2, 6, LMIC_UNUSED_PIN}, 
               };

Secondly, the interrupts() and noInterrupts() does strange things to the runtime state of the Artemis and should be commented out of the LMIC library wherever they appear. Nothing bad seems to come of removing the code and the removal is apparently present in other Sparkfun LoRa examples. I suspect the declaration may be bugged in the Artemis core.

Thirdly, the Artemis platform doesn't seem to play nice with the LMIC timing situation and needs the clock tolerance relaxed by way of the following changes:

In the lmic_project_config.h file in the LMIC library, add the following definition to allow clock tolerances above 0.4%:

#define LMIC_ENABLE_arbitrary_clock_error 1

Then, in your main code, after the LMIC_reset(), add LMIC_setClockError(MAX_CLOCK_ERROR * 1 / 100); to set the clock tolerance to ±1%.

These changes worked with the Artemis Redboard and Dragino LoRaWAN v1.4 shield.