V4 ChirpStack MQTT Forwarder, timestamp in mosquitto message is not the timestamp of lora radio message received

Hello
Some timestamp pb, (was OK for V3)

The config :

Lora Device  
AIR 
<=RF=>
GATEWAY Conduit MTCAP
gtw radio <=> upd_pkt_forwarder <=>ChirpStack MQTT Forwarder <=MQTT qos1 => 
localhost mqtt broker 

INTERNET
<= Mqtt bridge connection. qos 1 => Main Mqtt Broker
<= Mqtt sub connection => my Client

If internet is up, its OK

if internet is temporay fail, for example between 6H00 et 8H20.40

@8H20.40, when internet is recovering, all mqtt message are received, but for all of them the time field is around 8H20.40, and NOT the real received time

In chripstack-gateway-bridge V3 is was OK

Maybe it is something with the GPS time ?
In the config of chirpstack-gateway-bridge.toml v3, they was somethink like :

  # Semtech UDP packet-forwarder backend.
  [backend.semtech_udp]
  fake_rx_time=true

but ‘fake_rx_time’ is not present in the source of chirpstack_mqtt_forwared, so it seems that this config does not exist rigth now.

Some example of received message, all of them are timestamped as 08T08:20:4 instead althoug they were received @06H45 for example

Somebody has the same behavior ?

{"deduplicationId":"651cef3d-a485-4a3f-bd4d-a49933b8ebce","time":"2023-03-08T08:20:42.266506112+00:00","deviceInfo":{"tenantId":"00000000-0000-0000-0000-000000000001","tenantName":"agriscope","applicationId":"00000000-0000-0000-0000-000000000003","applicationName":"AGSP","deviceProfileId":"351973a3-f5a5-4697-ae51-d18cd7acacfb","deviceProfileName":"MDOT","deviceName":"TUILIERE_3270","devEui":"0080000000019f5d","tags":{}},"devAddr":"017077db","adr":false,"dr":3,"fCnt":2584,"fPort":1,"confirmed":false,"data":"AQigTgzGACACCQAEBjAiBzAbCQEPAgbhBAAA3A==","rxInfo":[{"gatewayId":"0080000000024764","uplinkId":3943788227,"rssi":-26,"snr":12.2,"channel":3,"rfChain":1,"location":{},"context":"16C0zA==","metadata":{"region_common_name":"EU868","region_config_id":"eu868"},"crcStatus":"CRC_OK"}],"txInfo":{"frequency":867100000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":9,"codeRate":"CR_4_5"}}}}
{"deduplicationId":"2874f0c0-776c-4cab-b40c-80fc30bd3725","time":"2023-03-08T08:20:42.388483594+00:00","deviceInfo":{"tenantId":"00000000-0000-0000-0000-000000000001","tenantName":"agriscope","applicationId":"00000000-0000-0000-0000-000000000003","applicationName":"AGSP","deviceProfileId":"351973a3-f5a5-4697-ae51-d18cd7acacfb","deviceProfileName":"MDOT","deviceName":"TUILIERE_3270","devEui":"0080000000019f5d","tags":{}},"devAddr":"017077db","adr":false,"dr":3,"fCnt":2585,"fPort":1,"confirmed":false,"data":"AQmgTgzGACACCQAEBjAiBzAbCQEPAgbhBAAA3Q==","rxInfo":[{"gatewayId":"0080000000024764","uplinkId":111881686,"rssi":-25,"snr":13.0,"channel":4,"rfChain":1,"location":{},"context":"DU1gxA==","metadata":{"region_common_name":"EU868","region_config_id":"eu868"},"crcStatus":"CRC_OK"}],"txInfo":{"frequency":867300000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":9,"codeRate":"CR_4_5"}}}}
{"deduplicationId":"118bb086-3131-4b73-ad23-dfb9f98f2b25","time":"2023-03-08T08:20:42.515019979+00:00","deviceInfo":{"tenantId":"00000000-0000-0000-0000-000000000001","tenantName":"agriscope","applicationId":"00000000-0000-0000-0000-000000000003","applicationName":"AGSP","deviceProfileId":"351973a3-f5a5-4697-ae51-d18cd7acacfb","deviceProfileName":"MDOT","deviceName":"TUILIERE_3270","devEui":"0080000000019f5d","tags":{}},"devAddr":"017077db","adr":false,"dr":3,"fCnt":2586,"fPort":1,"confirmed":false,"data":"AQqgTgzGACACCQAEBjAiBzAeCQEPAgbhBAAA2w==","rxInfo":[{"gatewayId":"0080000000024764","uplinkId":166427891,"rssi":-25,"snr":12.0,"channel":1,"location":{},"context":"QvoMlA==","metadata":{"region_common_name":"EU868","region_config_id":"eu868"},"crcStatus":"CRC_OK"}],"txInfo":{"frequency":868300000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":9,"codeRate":"CR_4_5"}}}}

Hello

Solved by using the chirpstack-gateway-bridge V4

chirpstack-gateway-bridge seems to be more configurablean and contains fake_rx_time=true

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

I have opened an issue on GitHub requesting the addition of fake_rx_time.

I did see it and I’m happy to add it, but I haven’t had the time, yet…

OK
We will try it when it will be added

THank you