Arduino LMIC: Figuring out when packet transmission has been started on Chip

Question

I use the following example of an ABP-activated LoRaWaN node:

https://github.com/matthijskooijman/arduino-lmic/blob/master/examples/ttn-otaa/ttn-otaa.ino

But for some reason I cannot figure out when the node transmits some data or not. As far I see from this snippet:

LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
Serial.println(F("Packet queued"));

The packets are inserted into a queue and then transmitted when available. So how I will make the ABP-example to give me an indication when the dragino-shield/hopeRFM9x starts transmitting the physical package that is in the queue?

I am asking because the single-channel-gateway for some reason pings the TTN that exists via Semtech UDP stat message and barely receives any message to transmit. So I want to debug it, therefore I need a more verbose log on when physical transmission started and ended of a queued packet. I occasionally I get some messages when I power off and power on my LoRaWAN node.

Also I may not get any message at all on my LoRaWaN single channel gateway even if I run the setup over 30mins with the Arduino being the only one node on my application and the node be next to my packet forwarder.

Over my gateway I used the instructions in: http://www.instructables.com/id/Use-Lora-Shield-and-RPi-to-Build-a-LoRaWAN-Gateway/

For my packet forwarder I used the following implementation: https://github.com/tftelkamp/single_chan_pkt_fwd

Also I have configured my TTN application to use the legacy Semtech packet forwarder.

Answer 1

LMiC does not tell your code when transmission has started, but you could enable debug logging.

When you're transmitting well below duty cycle limitations, then LMiC will often send almost immediately. It might postpone things:

• When using OTAA and the node has not joined yet, it will first try to join when the first packet is scheduled.

• When duty cycle limitations kick in it will wait for the next opportunity.

• After each uplink it will first listen for any downlinks, after exactly 1 second (RX1) and 2 seconds (RX2, if nothing received in RX1).

• When it did not receive a downlink, it will still not send for some time as it assumes the most nearby gateway might be sending a downlink that the node failed to recognize. As gateways are half-duplex, such gateway won't be listening for any uplinks during that time, so LMiC tries to be smart and postpones sending when it did not receive any downlink. For that, LMiC assumes SF12 in RX2, and will delay for another 3 seconds after RX2.

When a transmission and waiting for RX1 and RX2 (if applicable) have completed, you'll get the EV_TXCOMPLETE event. (But even then, it might still delay a next transmission for 3 seconds; see above.)

Peeking at some old code I once used, it seems you could guess if it's sending right away by using:

LMIC_setTxData2(1, mydata, sizeof(mydata)-1, 0);
// At this point LMIC.txend is still the end time of the last packet?
if(LMIC.txend < os_getTime()) {
  Serial.print(F("Will send right away"));
}
else {
  Serial.print(F("Packet queued"));
}

(But: not tested right now.)

That said, to debug your actual problems:

• When using ABP, ensure you disable the TTN frame counter check during testing.

• When using a single-channel test gateway, ensure your node is only using that very same channel and spreading factor. When not doing that, the node will choose one of eight standard frequencies each time, and you'll receive at most 1/8th of the transmitted messages.

• Don't put your node too close to the gateway; leave at least 3 meters between the devices.

And above all:

I use the following example of an abp-activated lowawan node:

https://github.com/matthijskooijman/arduino-lmic/blob/master/examples/ttn-otaa/ttn-otaa.ino

That example is for OTAA, not for ABP. (And the single-channel test gateway you're using is deprecated and does not support downlinks, hence no OTAA either.)