matthijskooijman / arduino-lmic

:warning: This library is deprecated, see the README for alternatives.
704 stars 651 forks source link

ttn-abp example only send to ttn once, need to rest to send again #75

Open bnzeen opened 7 years ago

bnzeen commented 7 years ago

Hello

My node is successfully sending to ttn but I want to send every periodic time even though TX_INTERVAL = 60 but it is only sending one time and need to rest to send again and then stop.

what's the modification in the example code to make it send continuously ?

ttn-abp example with pro mini 3.3 v, 8 MHz

navinyate commented 7 years ago

Nothing, just dumb the code but make sure you have right right fuses for Pro Mini

On 12-Mar-2017 16:10, "bnzeen" notifications@github.com wrote:

Hello

My node is successfully sending to ttn but I want to send every periodic time even though TX_INTERVAL = 60 but it is only sending one time and need to rest to send again and then stop.

what's the modification in the example code to make it send continuously ?

ttn-abp example with pro mini 3.3 v, 8 MHz

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/matthijskooijman/arduino-lmic/issues/75, or mute the thread https://github.com/notifications/unsubscribe-auth/AD7r_1niAtjAphlONP79QDXYxL4aJ2nFks5rk8uRgaJpZM4MagKO .

bnzeen commented 7 years ago

@cattvm can u explain more what u mean by right fuses ??

is it maybe because my LoRa have Tx switch and Rx switch ?

currently I'm just calling setup() function after a period of time to make it send continuously but I think this's not the right way.

sabas1080 commented 7 years ago

Remember that TTN has a minimum time of 30 seconds per request

gizmocuz commented 7 years ago

but higher is recommended... lora is not for real-time traffic, there are other means to do this

CecileDuthoit commented 7 years ago

I'm not sure to understand what your problem is but each time a TX is complete, the code schedules a new transmission (TX_INTERVAL seconds after), so you can modifiy the frequency (by changing TX_INTERVAL) case EV_TXCOMPLETE:
...
// Schedule next transmission os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);

need to rest to send again and then stop.

What do you mean by this? Your device can only re send if you make it wait longer than 60 seconds?

MMalboe commented 7 years ago

Hi, I have the same issue. I'm using a RFM96 module (tested two up to date both behave in the same way). After the initial successful packet sent, the OP_TXRXPEND flag is not reset, Thus, the next transmission never happens (the test is in do_send):

if (LMIC.opmode & OP_TXRXPEND) { Serial.println(F("OP_TXRXPEND, not sending")); } else { // Prepare upstream data transmission at the next possible time. LMIC_setTxData2(1, data, sizeof(data)-1, 0); Serial.println(F("Packet queued")); }

Anyone can help please?

robputt commented 7 years ago

Hi,

I also get this problem with an SX1276 module, after EV_TXCOMPLETE and waiting do_send gets called and says Packed queued although my gateway never receives the packet, but it always receives the first packet, just not subsequent packets :-(.

Best Reagrds,

Rob

Pioquax commented 6 years ago

I was facing the same problem when running the ttn-abp.ino example on an Adafruit Feather 32u4 (SX1276): After the first packet was transmitted, the program stopped.

I could resolve the issue by connecting pins of the Feather board as depicted here.

Additionally, the pin mapping for the Feather needs to be as follows as described here.

For other boards there might be similar effects if the pins are not connected correctly. I assume that the library might not get informed correctly by the hardware about the status of the LoRa chip if the pins are wrong, which then results in a deadlock.