You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
The text was updated successfully, but these errors were encountered:
I feel there is something not right with the pin mapping in the arduino core. I could not figure it out myself.
bimalpaneru
changed the title
LoRa RFM95/ board does not work with RedBoard/Artemis Module/ Atremis_ATP environment
LoRa RFM95/ board does not work with RedBoard/Artemis Module/ Artemis_ATP environment
Nov 18, 2022
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:
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.
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
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
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.
The text was updated successfully, but these errors were encountered: