Multitech Conduit not delivering downlink messages

Gateways
1

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 user.info 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
59.61.99.b5.2.0.0.f.0.9c.13.18.0.8.0.0.60.26.e2.85.1.80.0.0.2.c.df.58.57.7.b6.4a.ea.7b.df.end
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!

N.

2

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

3

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
4

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?

5

@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.

6

does anyone knows the packet format for downlink communication

7

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

Device: https://github.com/chirpstack/chirpstack/blob/master/api/proto/api/device.proto#L146