Hello everyone !
I loaded the example code from STM (I-CUBE-LRWAN, End-node application) on my device and I noticed that it transmits each 2m50s if I forward messages to TheThingsNetwork.
Instead, if I forward messages to my MQTT broker (with the same firmware) using LoRaGatewayBridge, LoRaServer and LoRaAppServer, the device after the first two transmissions transmits each 10s.
Is it normal or did I make some mistakes in the configuration ?
For example, what am I supposed to indicate as max EIRP of the device profile and in the service profile ? (EU 868)
Thank you very much !
Usually for EU the Max EIRP is 14dBm. Note that his does not affect how LoRa Server works (currently). However it is good to have the correct value filled in.
Are you sure your devices support LoRaWAN 1.1.0? Else you have to select 1.0.2.
The difference in the first two messages could be related to mac-commands. When you open your device in the web-interface and navigate to the “live LoRaWAN frames” you will see the message exchange.
Thank you !
Yes, my device support LoRaWAN 1.1.0
So, it is possible that my device is allowed to transmit each 10 seconds ?
If yes, why ?
It could be, but you have to consult your device-firmware. Initiating an uplink transmission is the decision of the device. It could be that TTN sends a mac-command to limit the dutycycle of the device, causing the longer delay between messages.
Thank you very much
First of all in I-CUBE-LRWAN the dutycylcle is managed with this directive (main.c):
/* Defines the application data transmission duty cycle. 10s, value in [ms].*/
#define APP_TX_DUTYCYCLE 10000
This corresponds to the 10 seconds you mention.
Then I-CUBE-LRWAN works as Finish State Machine with two way to send an event:
By timer peripheral interruption in this case the timer is reloaded each 10 sec ( with this APP_TX_DUTYCYCLE) in other words all 10 seconds you send your frame.
Or by External interruption following an event (ex: Push button or others) once again max frequency to send your frame depends on APP_TX_DUTYCYCLE.
static void LoraStartTx(TxEventType_t EventType)
if (EventType == TX_ON_TIMER)
/* send everytime timer elapses */
TimerInit( &TxTimer, OnTxTimerEvent );
TimerSetValue( &TxTimer, APP_TX_DUTYCYCLE);
/* send everytime button is pushed */
initStruct.Pull = GPIO_PULLUP;
initStruct.Speed = GPIO_SPEED_HIGH;
HW_GPIO_Init( USER_BUTTON_GPIO_PORT, USER_BUTTON_PIN, &initStruct );
HW_GPIO_SetIrq( USER_BUTTON_GPIO_PORT, USER_BUTTON_PIN, 0, Send );
thanks for the reply.
Yes, I’m aware that my function OnTxTimerEvent (which calls function Send and then LORA_send) is called each 10 seconds as configured in APP_TX_DUTYCYCLE, but often the packet is not actually sent because of an exceed in the transmission duty cycle (LORAMAC_STATUS_DUTYCYCLE_RESTRICTED in RegionEU868.c, 937).
However, when using LoRaServer this does not happen, instead using TTN the device sends a packet and then remains stuck in LORAMAC_STATUS_DUTYCYCLE_RESTRICTED for the next 2m50s.
I wonder if it is LoRaServer (with appropriate MAC commands) the responsible for this (excellent) behaviour.
What’s your opinion?
What’s your opinion?
To be honest, I don’t know, I never used TTN.
Before using loraserver.io, I used “Senet + cayenne mydevices” (just for proof of concept).
I can’t remember any restriction about dutycycle with Senet.
I know the time on air for europe area must be equal to 1% of emission for ISR band.
Concretely You can emit (ToA) 36 sec / 1 hour.
Here you can find a good link provided by Semtech to calcul link budget, time on air and energy consumption:
In my opinion when you send a packet every 10 seconds you are above 1%.
Do you use the shield X-NUCLEO-IKS01A2?
I noticed something else, after join method OTAA (request/accept) the uplink/downlink occurs only 5 min after.
I didn’t yet understand this behavior…
Thank you for the link ! I’m going to calculate more precisely my TOA.
No I don’t use the shield X-NUCLEO-IKS01A2 since I use my own modified version of the firmware.
I use ABP as join method so I can not help you with you issue using OTAA.
Thank you again