LR1110 modem driver ALC synch

Hi everybody,
I have problems with implementig application layer clock (ALC) synchronization with LR1110 using modem drivers. I am able to joining the network and than active the ALC service on the port 202. I see on the gateway log uplink packet on port 202 and a downlink immediatly after this, but at the LR1110 i don’t receive anythong and it does not fire an interrupt of clock synchronizations as mentioned in the manual. The same happens with messages on port 199 (DM), the device doesn’t fire any interrupt. Instead if I schedule a downlink with my custom data I receive it, LR1110 fires an interrupt and I can read data.
What can be the problem?
Thanks in advance


Could you please share with is the downlinks generated by the ALC Sync service on port 202 and the Device & Application Services server on port 199?

Hi, here you can see the uplink and the downlink generated

After the join, I receive three LR1110_MODEM_LORAWAN_EVENT_NEW_LINK_ADR, and in the log I see three uplinks on port 202 every 128s, but no downlink seems occurs after it and the device never get synchronized to the network (the function gettime() returns always zero value instead of gps time)


The downlink you are receiving is a MAC command related to network parameters, not ALC Sync.
ALC is for Application Layer Clock synchronization, which mean that you need to provide an application server answering to the device ALCSync requests. Do you have one?
Otherwise you can use as ALCSync server, here is the service description

Hello guys,
I’m also experiencing the behaviour reported by @falleronigianni96 and I can’t figure out what I’m missing out.
My end-Node is an LR1110 shield connected to a custom board with an STM32 micro.
I’m using the Lora join server and TTN as Network and Application servers (still I’m not sure if the free TTN supports ALCSYNC ).
Like @falleronigianni96, I can see my uplink on fPort 202 being sent, but no response (downlink) was received.
After reading the @ogimenez reply on this post, I’ve decided to learn about how to “configure” Lora cloud as the Application server to use the ALCSYNC service offered by the LoRa Cloud™ Device & Application Services.
Searching on the Semtch and TTI websites I’ve found and followed this step-by-step guide that uses TTN MQTT integration to set-up an Application server in node-RED.
I haven’t played with the node-RED flow yet but I was expecting it to work “out of the box” and instead, I still can’t receive any downlink for the ALCSYNC service.
Can you please help me in understanding what I’m missing?

Here a screenshot from the Live data console for my end-node


Hello all,
By running the lr1110_evk_demo_app on the evaluation kit (STM nucleo) I can see that the port used is 199 rather than the 202 has written on the Ref manual. The example code gets the downlink and the event LR1110_MODEM_LORAWAN_EVENT_TIME_UPDATED_ALC_SYNC is correctly trigger, although this is not reliable because the Time doesn’t get synched all the time.
Although, if I run my code (based on the example code) using the same shield, it doesn’t work.
Is there any other step I am missing here?
I’ve followed the instruction reported on the manual and I’m setting the ALC_SYNC port (199) and enabling the ALC_SYNC before joining.


Hello @luca,

Although, if I run my code (based on the example code) using the same shield, it doesn’t work.
Is there any other step I am missing here?

Can you see the uplink requesting the time sync?

Can you please explain “doesn’t get synched all the time”?

Hi @mantoine,

Can you see the uplink requesting the time sync?

Yes, I can see the request being sent (also I can see it in the NODE-RED debug node placed just before the DAS node).
I’ve also modified my code to query the DAS until I don’t get the GPS time and what I’ve seen is a completely random behaviour

Can you please explain “doesn’t get synched all the time”?

whit this I mean that every time I run the code the 1st time request gets completely ignored. Most likely, I get a reply (APP server schedules a downlink) at the 2nd request but the needed time to get the information is random (best case I get the information after 3 minutes from the 2nd request).
Although I guess this problem is related to the TTN App server (which has just a queue for all the ports).