I take it the as:up: is generated by the application server and is for internal TTx use? I don’t really see the point of sending custom correlation ids in downlinks only then, as referenced in [MQTT Server | The Things Stack for LoRaWAN|https://www.thethingsindustries.com/docs/integrations/mqtt/]
The Things Stack supports some cool features, such as confirmed downlink with your own correlation IDs. For example, you can push this:
```{
“downlinks”: [{*
“f_port”: 15,*
“frm_payload”: “vu8=”,*
“priority”: “HIGH”,*
“confirmed”: true,*
“correlation_ids”: [“my-correlation-id”]*
}]*
}```
But do either of you know what [@htdvisser|https://www.thethingsnetwork.org/forum/u/htdvisser] meant by his comment:
It is possible for a user to schedule a downlink with correlation ID {{as:up:trololololo}} . If that downlink is acknowledged by their end device, you may receive that correlation ID in your uplink.?
It seems to imply you will see your as:uptrololololo in an uplink which I have seen neither for confirmed nor unconfirmed uplinks?
[@Johan_Scheepers|https://www.thethingsnetwork.org/forum/u/johan_scheepers] - my application is a metered electricity dispenser. And there haven’t been any uplinks for me to read off the RSSI and SNR for a while on the unreliable nodes, the console has refreshed itself. I am not sure of the distance for any particular node. What RSSI, SNR might you look for to get reliable messaging? But please don’t spend your time on this, I can research that in the forums.
I was trying to understand the best way to associate pairs of downlinks and uplinks before looking at reception. And for that it seems I might be able to use fcnts for this purpose rather than a) using default correlation ids, or b) embedding custom cids as part of the end device payloads.
Hi and thank you again [@kersing|https://www.thethingsnetwork.org/forum/u/kersing],
No, my payloads are binary; 1 or 5 bytes for downlinks and 5 bytes for uplinks.
Ah, so when you say send a “small” correlation id you mean I should add my own as part of the payload!
So, in a typical uplink MQTT msg, I might see these correlation ids:
{noformat}"correlation_ids": [ "as:up:01GNATSVGD3FHJF0W9M1RHR5NX", ... "rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01GNATSVGCH0YZVYA4FRMEJNHR" ] {noformat}
I take it the as:up: is generated by the application server and is for internal TTx use? I don’t really see the point of sending custom correlation ids in downlinks only then, as referenced in [MQTT Server | The Things Stack for LoRaWAN|https://www.thethingsindustries.com/docs/integrations/mqtt/]
The Things Stack supports some cool features, such as confirmed downlink with your own correlation IDs. For example, you can push this:
``` {
But do either of you know what [@htdvisser|https://www.thethingsnetwork.org/forum/u/htdvisser] meant by his comment: It is possible for a user to schedule a downlink with correlation ID {{as:up:trololololo}} . If that downlink is acknowledged by their end device, you may receive that correlation ID in your uplink.?
It seems to imply you will see your as:uptrololololo in an uplink which I have seen neither for confirmed nor unconfirmed uplinks?
[@Johan_Scheepers|https://www.thethingsnetwork.org/forum/u/johan_scheepers] - my application is a metered electricity dispenser. And there haven’t been any uplinks for me to read off the RSSI and SNR for a while on the unreliable nodes, the console has refreshed itself. I am not sure of the distance for any particular node. What RSSI, SNR might you look for to get reliable messaging? But please don’t spend your time on this, I can research that in the forums.
I was trying to understand the best way to associate pairs of downlinks and uplinks before looking at reception. And for that it seems I might be able to use fcnts for this purpose rather than a) using default correlation ids, or b) embedding custom cids as part of the end device payloads.
Thanks, Chris