Downlink transmission failed with result COLLISION_BEACON


I sent a downlink to a Parametrci Radar but every time we get the message “COLLISION_BEACON”

I can not find a reason in this forum or whta is means.
Can anyone help mee?

This radar sents normaly uplinks to 3 of 4 gateways of my network

“data”: {
@type”: “”,
“namespace”: “pkg/networkserver”,
“name”: “transmission”,
“message_format”: “downlink transmission failed with result {result}”,
“attributes”: {
“correlation_id”: “80c9f473b22041e0b4731de9908ab297”,
“code”: 2


Please can you format technical items using </>

1 Like

Hi @descartes
This would be a new topic as I do not now the to format technical issues :wink:

Do you mean like a JSON format than?
Maybe I can get this out of the TTN console


He means format your message when posting (or as now when you go back and edit to correct!), this is a universal request across the forum that oft needs repeating :slight_smile:

Adoring to the [documentation] (Troubleshooting Gateways | The Things Stack for LoRaWAN) you already have a planned beacon in that time frame.

Edit: How often do you send a downlink? Are you not sending a new downlink before the previous one were RX?

Hi @Johan_Scheepers

we sent earlier a downlink message via TTN but with teh command that a possibile message before is deleted. So that could not be the case I think

But, at EXACT the same time the COLLISION_BEACON in in the TTN console, there is an uplink message form the sensor. The sensor is on SF12 and therefore it take longer airtime to transmit en and therefore the downlink message cloud collide while the uplink is still in the air?

I apologize if my technical terms are not always right as I have limited in-depth knowlegde of LoRa

But I am very thankfull for all the help in this forum


The sensor sends an uplink and then it listens for a downlink, it is irrelevant if you are using SF7 or SF12

The settings between your device/sensor need to match the settings on TTN as for how long after the uplink it listens for a downlink.

Which in theory could end up being blocked by the NS as the LoRaWAN Alliance requires network operators to restrict the regular use of SF11 & 12.

Is this a Class B device - as beacons are usually a function of class B - if not, is there the possibility from the logs that the gateway is servicing a Class B device.

If you want to learn the Fundamentals of LoRaWAN, and who wouldn’t, check out:

1 Like