TTN v2 Vs TTN v3 downlink execution

Dear Team,

When i was using the TTN V2, the downlink sent to the LNS gets encoded (using payload formats) only when i next uplink is received.

Whereas in TTN V3, when i send a downlink, the LNS encodes (using payload formatter) the downlink which i have sent immediately once the downlink is received to the server and its queued for execution. When the next uplink occurs the encoded downlink gets executed.

Actually i am doing a time synchronization for my device. I used to read the time from the LNS TTN V2 and do the time sync. My device will trigger an uplink when temperature raises more that the set point, or the counter reached its value, in which we don’t know the eact time of the uplink.

So, as previously said, in TTN v2, when i send a downlink to do the time sync, the downlink get encoded when the LNS receives the uplink from my device and at the same time the encoded downlink gets executed.

In the above process, the time sync was accurate and correct.

Whereas in TTN v3, when i send the downlink it first executes the downlink and gets the time from the LNS and waits for the next uplink. Since, my uplink time is unknown, time mismatch is happening for the time sync in TTN V3.

Example: I sent a downlink at 11:15 to make the time sync. When the unit sends an uplink which is received by TTN-V3 at 11:30. The time set to the device is 11.15 but the correct time that has to be set is 11.30.

The same functionality we followed in TTN-V2 and it worked fine, due to encoding of the downlink happens during the downlink. whereas in TTN-V3 its not happening so.

Is the functionality is default or is there any other way to encode the downlink during the time of uplink from the end device.

I assume this means you’ve figured out your downlink JS encoder issue.

This facility is a convenience function so it’s not in any spec anywhere, so it will be implemented as TTI feel is appropriate. You can look at the source code on GitHub for details.

You may have to create a WebHook that takes an uplink and if appropriate, comes straight back with a downlink to set the time. But I can see that this change is a shame as it does streamline clock updates as the response is automatic and quick.

Dear Descartes,

Yes the DL JS encoder is solved.

Thank you for the reply.

Perhaps as you reached out to the community, you could share your solution so others will benefit, like you did.

1 Like

Dear @Surendar
Have you managed to solve your problem encountered with downlink timestamps on TTN V3?