Migration to ChirpStack Gateway Bridge 4, ok for MTCAP but fail with MTCDT

[guillaume_fernandez]

Hello

Both devices (MTCAP et MTCDT) have a last firmware (6.0.1)
They were started from scratch. (Factory reset + last firmware version)

The problem is on the jonction between lora_packet_forwarder and chirpstack-mqtt-forwarder

mtcdt chirpstack-mqtt-forwarder[5174]: Handle PULL_DATA error: Expected protocol version: 2, got: 1, remote: 127.0.0.1:59944

Its look like to a incorrecte protocol version betwen this 2 applications

It seems that the 2 devices does not use the same packet_forwarder

• on the failed MTCDT :

 head  /var/log/lora-pkt-fwd-1.log
*** Basic Packet Forwarder for Lora Gateway ***
Version: 1.4.1
*** Lora concentrator HAL library version info ***
Version: 1.7.0; Options: ftdi sx1301 sx1257 full mtac-lora private;
***
INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: radio 0 enabled, center frequency 868500000
INFO: radio 1 enabled, center frequency 867500000
INFO: Lora multi-SF channel 0>  radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1>  radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2>  radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12

• on the OK MTCAP :

*** Beacon Packet Forwarder for Lora Gateway ***
Version: 4.0.20
*** Lora concentrator HAL library version info ***
Version: 5.0.13;
***
INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
INFO: lorawan_public 1, clksrc 0
INFO: LBT is disabled
INFO: antenna_gain 3 dBi
INFO: Default Temperature Compensation
INFO: Configuring TX LUT with 16 indexes

Does anybody encounter the problem ?

Or do you see some tips to solve it ?

Guillaume

[guillaume_fernandez]

The source of the problem seems to be the hw-version
On the MTCDT, it is :

root@mtcdt:/tmp# mts-io-sysfs show lora/hw-version
MTAC-LORA-1.0

then, the init.d link the lora_packet_forwarder to lora-packet-forwarder-usb… and not to the classic one.

And this packet forwarder does not support the protocol 2 needed by chirpstack-mqtt-forwarder

Does somebody encounter this problem ?

[Jerome73]

Yes, I had the same problem with old usb cards.

And as far as I know, there is no solution except changing the LoRa card, but it costs the price of a new gateway.

[guillaume_fernandez]

OK

Thank you.

I will try to change the LoRa card.
Yes the price is high.

Hopefully, only one gateway to change in my case…

[guillaume_fernandez]

Solved without changing the lora card

Solved by using the chirpstack-gateway-bridge V4

So we don’t use chirpstack-mqtt-forwarder which is not appropriate in our cases.

[Jerome73]

Do you also receive the stats packets with the USB card?

[guillaume_fernandez]

Yes, by using, the binary “gps_pkt_fwd” delivered by lora-packet-forwarder-usb_1.4.1-r2.0_arm926ejste.ipk , under Index of /vendor/multitech/conduit/

thanks to this post : Gateway statistics not showing - #6 by Bocajim

We just untar it and replace the binary, we don’t try to install it by opkg

 ar -x lora-packet-forwarder-usb_1.4.1-r2.0_arm926ejste.ipk

cd /opt/lora
cp basic_pkt_fwd-usb basic_pkt_fwd-usb.bk
rm -rf basic_pkt_fwd-usb 
ln -s /var/config/somewhere/gps_pkt_fwd basic_pkt_fwd-usb basic_pkt_fwd-usb

[brocaar]

I believe the USB packet-forwarder also doesn’t support the TX_ACK packet, which is sent by the gateway after enqueuing a downlink. ChirpStack needs this information to know if a downlink was accepted by the gateway or not. If not (because of collision, …) it will stay in the queue.

This feature was added in v3.0.0 of the UDP Packet Forwarder.

I know upgrading the module costs money, but the USB packet-forwarder is really outdated. Support was dropped in v2.2.0 (2015-10-08) of the packet forwarder.

On the other hand, one could clone the packet-forwarder source and backport these protocol features Or maybe Multitech could provide a custom packet-forwarder with these capabilites.