Multitech Conduit not delivering downlink messages

Dear ChirpStackers!

I’m having issues with my Multitech Conduit MTCDT-H5-210L not delivering downlink messages to devices.

I’m running:

  • mLinux 5.3.31
  • chirpstack-gateway-bridge - 4.0.10-r1
  • lora-packet-forwarder-usb - 1.4.1-r2.0

I’ve edited:

  • /var/config/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml:
    [integration.mqtt.auth.generic] → changed MQTT server address
    [integration.mqtt] → added “eu868/” prefix to event_topic_template, state_topic_template and command_topic_template
  • /var/config/lora-packet-forwarder-usb/global_conf.json
    gateway_ID → set to 000800ffff4a0794

After both services are started, gateway connects to my Chirpstack instance, shows as Online and updates Last seen every 30 seconds.

When I turn on my class C device it joins the network (albeit showing two JoinRequests, first one with error “DevNonce has already been used” - don’t know why) and starts sending uplink messages. Seems like everything’s working fine.

However, when I try to schedule downlink message using Queue tab, the message is never delivered, i.e. I don’t see any effect on the device and it doesn’t go away from the Queue tab. Here’s what I see in the gateway logs:

The following line is printed by the chirpstack-gateway-bridge into /var/log/messages every 6-7 seconds:
Oct 21 02:14:38 mtcdt chirpstack-gateway-bridge[2884]: time=“2023-10-21T02:14:38.941828864+02:00” level=info msg=“integration/mqtt: downlink frame received” downlink_id=2294115924 gateway_id=000800ffff4a0794

The following is being printed by the lora-packet-forwarder-usb:
INFO: [down] PULL_RESP received :slight_smile:
INFO: [down] a packet will be sent in “immediate” mode
lgw_send:1687: DEBUG: Tx pow_index 15, rf_power 26
INFO: [down] PULL_ACK received in 2 ms

And then after a while:
##### 2023-10-21 00:14:59 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 0
# CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 1 (156 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 4 (728 bytes)
# RF packets sent to concentrator: 4 (76 bytes)
# TX errors: 0

I’m not too experienced with lora-packet-forwarder nor with the chirpstack-gateway-bridge. Can someone try to help me investigate this issue? Is something wrong with my config?

Thanks a lot!


May be you should check the RX2 in ChirpStack and nodes to see if they use the same frequency and DR for rx2.

Packet forwarder with USB is an older version of the protocol. I believe there was no TX-ACK message that the bridge and LNS may use to remove the downlink from the queue.

Yes no TX-ACK, I found this post for more info.

1 Like

Dang, that explains it! Thanks @Jason_Reiss !

We might have some newer Lora cards laying around somewhere. If so, the solution is to replace the USB-based card (MTAC-LORA-868, v1.0) with the SPI-based one (MTAC-LORA-H-868, v1.5) and start using lora-packet-forwarder 4.0.1 instead of lora-packet-forwarder-usb 1.4.1, correct?

@Jason_Reiss is right. The packet-forwarder for the USB based cards is really outdated and does not implement the TX ACK packet that ChirpStack uses as an acknowledgement from the gateway.

does anyone knows the packet format for downlink communication

Gateway: Commands - ChirpStack open-source LoRaWAN® Network Server documentation