Beginner explanation downlink messages

Hello everyone

I am using a chirpstack installation on Ubuntu and already have a GW and a Dragino temperature sensor in use.
Now I would like to use the Datalog feature of Dragino. For this I have to send a downlink message with the value “PNACKMD=1” to the sensor. I have tried to send a Confirmed hex message on FPort2 with the value: “504E41434B4D443D31”. Unfortunately, nothing changes in the upload behavior of the sensor. How exactly can I troubleshoot this? If I understand the logs correctly, the message was received.

For Dragino, the downlink is not what you are doing.

You need to check for downlink command equivalent to the AT command.

Converting AT command to hex is not correct.

What is the model of your Dragino device?

Im Using a LHT65N
Manual

After Reading the documentation the correct hex should be “0X34 01”. right?
Dragino AT & Downlink Commands

Yah, likely correct.
The hex will be 3401 if you use the ChirpStack GUI to enqueue.
Remember to use hex format.

Thank you! I will test this. What exactly is the FPort all about? Can you explain this?

2 Likes

Fport=0 is internal MAC commands. Beginners would not care about it.

Fport > 0 can be used to classify the packets.

Example: Fport 1 for temperature and humidity.
Fport 2 for datalog.
Fport 3 for alert

LHT65N uses Class A.
So it will only download the downlink after an uplink. By default is 20 mins.

Or you press the button to force an uplink. Then it will download the downlink.

1 Like

Unfortunately the Datalog feature does not yet work. The data does not seem to be uploaded if the GW has been out of range for a period of time.

{
    "deduplicationId": "215397ca-eca6-496c-854d-1c5b6e2caccd",
    "time": "2024-08-15T15:48:05.329769+00:00",
    "deviceInfo": {
        "tenantId": "X",
        "tenantName": "Test",
        "applicationId": "X",
        "applicationName": "test-applikation-1",
        "deviceProfileId": "6be09af9-0e96-4aed-a0db-af3d18a1de16",
        "deviceProfileName": "Tem-Hum-Drag",
        "deviceName": "Dragino-Test-1",
        "devEui": "X",
        "deviceClassEnabled": "CLASS_A",
        "tags": {}
    },
    "devAddr": "X",
    "adr": true,
    "dr": 0,
    "fCnt": 0,
    "fPort": 2,
    "confirmed": true,
    "data": "zAgFTgGEAfjff/8=",
    "object": {
        "Bat_status": 3,
        "Hum_SHT": 38.8,
        "BatV": 3.08,
        "TempC_SHT": 13.58,
        "TempC_DS": -18.25,
        "Ext_sensor": "Temperature Sensor"
    },
    "rxInfo": [
        {
            "gatewayId": "X",
            "uplinkId": 4353,
            "gwTime": "2024-08-15T15:48:05.329769+00:00",
            "nsTime": "2024-08-15T15:48:05.371420776+00:00",
            "rssi": -45,
            "snr": 10.25,
            "channel": 5,
            "location": {
                "latitude": XX,
                "longitude":X
            },
            "context": "CTpd5A==",
            "metadata": {
                "region_config_id": "eu868",
                "region_common_name": "EU868"
            },
            "crcStatus": "CRC_OK"
        }
    ],
    "txInfo": {
        "frequency": 867500000,
        "modulation": {
            "lora": {
                "bandwidth": 125000,
                "spreadingFactor": 12,
                "codeRate": "CR_4_5"
            }
        }
    }
}

You can use UART USB to see the console of LHT65N and confirm if the parameter is set to 1 successfully.

Sometimes, you may need to upgrade the firmware version to support the feature.

By right, the node should be able to send data after the LoRaWAN connection is restored.