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

[bnzeen]

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]

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

…

On 12-Mar-2017 16:10, "bnzeen" ***@***.***> 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 <#75>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD7r_1niAtjAphlONP79QDXYxL4aJ2nFks5rk8uRgaJpZM4MagKO> .

[bnzeen]

@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]

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

[gizmocuz]

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

[CecileDuthoit]

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]

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]

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]

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.