Downlink sent with every uplink received

Issue: Downlink sent with every uplink received

Setup: SAMR34 - RAK7258

LoRa® Server: Built-In Lora

Details: Hello people! Are happening something strange but I don’t know if it is normal or my system has a real problem. Every time I send an uplink to the server, It gives me a downlink with the same data as the uplink. The figure following detail what I’m saying.

Someone can help me?

Kind regards!

That’s rather odd - it feels like it might be a mixup in logging as much as something actually happening through the radios.

Can you show us the raw packets from the gateway (rather than network server) tab?

Keep in mind also that sending ASCII text and ASCII representations of numeric digits is really not a very efficient use of airtime.

1 Like

Allright @cstratton, these are the raw information from gateway:

Fri Mar 19 15:53:22 2021 daemon.info appSrv[31569]: [Uplink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169202,“fCnt”:14,“fPort”:1,“data”:“32392E33432F38342E3746”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:22 2021 daemon.info appSrv[31569]: [Downlink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169202,“fCnt”:14,“fPort”:1,“data”:“32392E33432F38342E3746”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:28 2021 daemon.info appSrv[31569]: [Uplink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169208,“fCnt”:15,“fPort”:1,“data”:“32392E38432F38352E3646”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:28 2021 daemon.info appSrv[31569]: [Downlink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169208,“fCnt”:15,“fPort”:1,“data”:“32392E38432F38352E3646”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:33 2021 daemon.info appSrv[31569]: [Uplink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169213,“fCnt”:16,“fPort”:1,“data”:“33302E31432F38362E3346”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:33 2021 daemon.info appSrv[31569]: [Downlink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169213,“fCnt”:16,“fPort”:1,“data”:“33302E31432F38362E3346”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:38 2021 daemon.info appSrv[31569]: [Uplink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169218,“fCnt”:17,“fPort”:1,“data”:“32392E38432F38352E3646”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:38 2021 daemon.info appSrv[31569]: [Downlink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169218,“fCnt”:17,“fPort”:1,“data”:“32392E38432F38352E3646”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:44 2021 daemon.info appSrv[31569]: [Uplink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169224,“fCnt”:18,“fPort”:1,“data”:“32392E34432F38352E3046”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:44 2021 daemon.info appSrv[31569]: [Downlink] - {“applicationID”:“1”,“applicationName”:“Separated Application”,“devEUI”:“8877665544332211”,“deviceName”:“dev-8877665544332211”,“timestamp”:1616169224,“fCnt”:18,“fPort”:1,“data”:“32392E34432F38352E3046”,“data_encode”:“hexstring”}
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]:

2021-03-19 15:53:44 UTC

Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: ### [UPSTREAM] ###
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # RF packets received by concentrator: 5
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # CRC_OK: 100.00, CRC_FAIL: 0.00, NO_CRC: 0.00
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # RF packets forwarded: 5 (120 bytes)
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # PUSH_DATA datagrams sent: 6 (1214 bytes)
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # PUSH_DATA acknowledged: 100.00
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: ### [DOWNSTREAM] ###
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # PULL_DATA sent: 6 (100.00 acknowledged)
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # PULL_RESP(onse) datagrams received: 4 (784 bytes)
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # RF packets sent to concentrator: 4 (104 bytes)
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # BEACON sent so far: 0
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # BEACON rejected: 0
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: ### [JIT] ###
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # SX1301 time (PPS): 3508033071, offset us 0
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: ### [GPS] ###
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # Invalid time reference (age: 1616169224 sec)
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: # no valid GPS coordinates available yet
Fri Mar 19 15:53:44 2021 user.notice lora_pkt_fwd[1466]: ##### END #####

Actually, they’re not.

You’re showing application level logs from the network server of the suspect packets - which do indeed look quite suspicious.

Your gateway level log doesn’t capture any of either the uplinks or the downlinks - just a summary print from a time that seems to have included them.

RF packets sent to concentrator: 4

The total there does seem to show some transmissions however.

So the question is who is telling it to echo the same data back…

Do you have any data platform connected to the gateway via MQTT or otherwise?

While it shouldn’t cause this, are you using “confirmed” uplink? You don’t really want to do so, especially with Chirpstack.

Is there some “echo test” checkbox somewhere you might have set? I can’t think of any but…

Sorry, I thought it was. Maybe are it in next figure what you asked me?

I’m sending the message from de end device now and I’m not using confirmed message in no one place

No, you’re still looking at the network server tabs, not the gateway tab.

However because the gateway summary showed a count of 4 actual transmissions, it does seem that the problem is at the level of the network server, or something talking to it, so my earlier question isn’t really important now.

The focus now would be figuring out why the network server thinks it should be transmitting the same thing back down…

eg:

  • some other piece of software connected to it is telling it to
  • some odd “echo test” type mode has been activated
  • some sort of bug is involved

But it seems like the original idea that it might be a mistaken of log of something that wasn’t actually happening is mostly ruled out by the count of 4 packets being sent to the radio for transmission.

Aaaah wait,
I discovered what I did!! Thank you very much @cstratton

I have put in MQTT uplink topic and downlink topic the same topic, so when I sent a uplink message, it put is as a downlink, I changed and it works normally now

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.