Replies: 7 comments
-
Hi, sorry you're having problems. Since join works, we know that downlink is working. What do you see in the TTN console? --Terry |
Beta Was this translation helpful? Give feedback.
-
Hi, this is what I have seen on the TTN |
Beta Was this translation helpful? Give feedback.
-
Later today, I did not change anything, but I always got \Documents\Arduino\libraries\MCCI_LoRaWAN_LMIC_library\src\lmic\oslmic.c:53 I have no idea what happen.. I check the pin for more than 10 times to make sure that they match with pin map. And the library version is 0.8.0 and I use arduino uno and hopeRF RFM95W Lora. Could somebody give me a hint |
Beta Was this translation helpful? Give feedback.
-
That means your HopeRF is not connected properly on SPI to your Arduino. |
Beta Was this translation helpful? Give feedback.
-
It is really weird. I hook the Lora to 3.3V a few days ago, and it works fine. However, a few days later, I need to hook it to 5V with the same wires, Arduino uno board and Lora module. |
Beta Was this translation helpful? Give feedback.
-
@ptkuo0322 The RFM95 is for 3,3V only. If you connected it to 5V, you may have damaged it. |
Beta Was this translation helpful? Give feedback.
-
Might be better to discuss this on forum.mcci.io -- this doesn't look like a bug per se. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Here is my problem. I tried to use the example code "ttn-otaa" to help me understand how the LoRaWAN works.
I double check the
LMIC.dn2Dr = DR_SF10;LMIC_setDrTxpow(DR_SF7, 14) in the setup right after the LMIC_reset.
However, for the information that print in the serial monitor, I would get the following
02:24:25.103 -> 12737330: EV_JOIN_TXCOMPLETE: no JoinAccept
02:24:39.168 -> 13615511: EV_TXSTART
02:24:44.642 -> 13956081: EV_JOINED
02:24:44.676 -> netid: 19
02:24:44.676 -> devaddr: 26012A7A
02:24:44.710 -> AppSKey: 21-DB-FA-7D-37-86-E1-3F-D4-1F-89-4D-ED-B5-94-0A
02:24:44.779 -> NwkSKey: CF-55-AB-8A-4D-C9-90-7E-C0-52-3C-98-D0-3C-BE-13
02:24:44.813 -> 13962753: EV_TXCOMPLETE (includes waiting for RX windows)
02:25:44.997 -> 17717009: EV_TXSTART
02:25:44.997 -> Packet queued
02:25:47.361 -> 17864463: EV_TXCOMPLETE (includes waiting for RX windows)
02:26:47.524 -> 21614955: EV_TXSTART
02:26:47.559 -> Packet queued
02:26:49.892 -> 21762410: EV_TXCOMPLETE (includes waiting for RX windows)
02:27:50.067 -> 25512903: EV_TXSTART
I do not know what is the problem and I already searched for many reference on the internet. But I still do not know how to fix this problem for my first test. Can anyone give me some hints? I would really appreciate it.
I only change the following three parts in the example code.
`static const u1_t PROGMEM APPEUI[8]={ 0x3B, 0x89, 0x03, 0xD0, 0x7E, 0xD5, 0xB3, 0x70 };
void os_getArtEui (u1_t* buf) { memcpy_P(buf, APPEUI, 8);}
// This should also be in little endian format, see above.
static const u1_t PROGMEM DEVEUI[8]={ 0x63, 0x75, 0xBC, 0xEB, 0x16, 0x94, 0x16, 0x95 };
void os_getDevEui (u1_t* buf) { memcpy_P(buf, DEVEUI, 8);}
// This key should be in big endian format (or, since it is not really a
// number but a block of memory, endianness does not really apply). In
// practice, a key taken from ttnctl can be copied as-is.
static const u1_t PROGMEM APPKEY[16] = { 0xD4, 0xD2, 0xDD, 0x70, 0x7E, 0xE0, 0xD2, 0x01, 0xDF, 0xD3, 0x92, 0xEA, 0x10, 0x87, 0xA5, 0x3F };
void os_getDevKey (u1_t* buf) { memcpy_P(buf, APPKEY, 16);}`
const lmic_pinmap lmic_pins = { .nss = 10, .rxtx = LMIC_UNUSED_PIN, .rst = 9, .dio = {2, 3, LMIC_UNUSED_PIN}, };
LMIC_setClockError(MAX_CLOCK_ERROR * 5 / 100); // Reset the MAC state. Session and pending data transfers will be discarded. LMIC_reset(); LMIC_setLinkCheckMode(1); LMIC_setAdrMode(1); LMIC.dn2Dr = DR_SF10; //LMIC_setDrTxpow(DR_SF7, 14); // Start job (sending automatically starts OTAA too) do_send(&sendjob); }
Beta Was this translation helpful? Give feedback.
All reactions