No ack's sent by my RAK831 LoRa Gateway

Hi everybody,
I’m having a problem. I’m using a RAK831 raspberry LoRa gateway. I have set up the ack configuration mode on my nodes and I can see over the TTN console that ack packets(Downlink messages) “are sent” by the gateway. However, with an expectrum analyser I verify that the gateway is not sending these ack messages.
I believe that it’s a configuration which I should set up into the Gateway parameters but I can’t find where to do it.

how do you do that ?

In addition to RF test gear (which is certainly workable but very expensive) the RAK831 has a transmit LED. It also exposes some of the radio mode related pins allowing things like timing tests were you trigger a scope off the node’s receive interval and compare the timing of the pulse framing the gateway’s transmission.

But even simpler than that, look in the gateway’s syslog, typical packet forwarders log when they transmit, and possibly when they reject a packet. If yours does not, consider modifying its source code to do so.

Make sure that you are using config files appropriate to your regional bandplan and your gateway’s hardware. Some versions of config files for example have a transmit frequency range which is enforced, if that is wrong for packets which need to appropriately be transmitted, they may be rejected.

o boy …

1 Like

Hi BoRRoZ,
I’m using this expectrum analyzer ( It’s a great tool when you are not sure about work frecuencies. In this case, I’m cheking wheter the packets are sending and their frequency with that device.

Hi cslorabox,
Thanks for replying. I checked that the tx led of the board bliks when the packet is transmited by the Gw.
I don’t think that frequency configuration is the problem, because downlink messages with a payload are perfectly sent. I believe that in some configuration file I should enable the ack’s.
I don’t know whether am I being clear enough…

Ah OK… but that’s not a spectrum analyzer

Seems the issue is probably not that the gateway is not transmitting.

Acks are no different than normal downlinks, in fact they can be embedded in a normal dowlink. An ACK that is sent a part of a downlink with no payload data would be shorter and have the port set to 0, but it is still a LoRaWAN packet sent with the same LoRa air settings as appropriate for any other usage of the RX window where it occurs.

Perhaps you need to debug your node software.

Also realize that using acks is heavily discouraged in TTN as it is extremely expensive of a gateway’s time to transmit; it cannot receive from any other node while it is responding to one.

On the contrary RTL-SDR with typical software very much is a spectrum analyzer, and offers a waterfall display that many traditional bench analyzers do not.

Granted, it’s not a very good analyzer in terms of RF performance or capability, but it’s fine for seeing that nearby LoRa transmissions have happened and quite handy in practice. The catch is that its scan bandwidth isn’t really wide enough to see the whole band, but rather only 2 or maybe 3 downlink frequencies if you tune it to the middle of their range. So it won’t see one occurring on a different frequency further away.

One can dictate the downlink frequency by controlling the uplink frequency; in real usage that should be fairly random but for a brief test it could be fixed.

With that device and its software I am able to analyze the spectrum, that’s why I call it spectrum analyser haha.
As cslorabox says, It’s not very sofisticated but it works perfectly in this kind of tests.

Yes, that’s a good point.
I would check the node side, and I’ll post if I find something.
Thank you!

More accurately, the RTL SDR works well if you understand its limitations and say within those. It cannot see the whole downlink band at once, only part of it. So you’ll miss downlinks outside the region it is tuned to receive. And as a node is normally supposed to hop randomly and the downlink channel maps from the uplink one, you’ll miss some unpredictable fraction of them.

It’s possible if you crank up the gain you’ll overload the receive and see signals splattering all over the place irrespective of frequency; that could actually be usefully exploited.

interesting advise BTW … :wink:

1 Like