Switch bandwidth and SF of node while gateway doesn't?

End Devices (Nodes)
1

Hi!

I am wondering if it is possible to change the bandwidth and/or SF of a transmitting node while having a single-channel gateway on a constant settings?

Thanks in advance!

2

If the Gateway is using a single SX127x, then no you cannot.

3

I wonder why you’re asking this, so just for the sake of completeness:

A node that has not been explicitly programmed to use only that specific single channel and SF will (and should, if it is LoRaWAN compliant!) change the channel for every transmission, to comply with the specifications:

End-devices may transmit on any channel available at any time, using any available data rate, as long as the following rules are respected:

  • The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency diversity makes the system more robust to interferences.
  • …

A node is not “connected” to some gateway, but just transmits and has no idea what type of gateway(s) is (are) receiving its packets, if any at all. So, a node could change its settings but then obviously the single channel gateway will not receive its packet. But other gateways might.

On a related note: some single-channel gateways do support multiple SFs (often, if not always, yielding a smaller range).

1 Like
4

There are versions of a single channel gateway that appear to use CAD to constanly change the SF, the logic being that if you start a detect at I presume SF7 you can change to SF8 if the CAD fails, then change to SF9 etc and still have time to detect a packet preamble in progress.

I have not tested the effect on sensitivity of that exact regime, but using CAD to detect SF7 BW125khz, I have noticed packet reception becomes unreliable when you are within around 5dB of the link failure when using normal RX.

I guess if there were no downside to using CAD, its use would be the norm.

5

Indeed, taken from Jaap Braam’s explanation of his single channel gateway:

Detecting a signal using CAD takes less than two symbols. So when a SF7 CAD returns, two symbols of the preamble are ‘used’, leaving 6 more to synchronize the reading of the message. When SF7 CAD does not detect a preamble, two SF7 symbols are gone which acounts for ONE SF8 symbol. So there are 7 preamble symbols available to detect a SF8 signal.

For a SF9 signal there will be 8-(1+0.5) = 6.5 symbols available
For a SF10 signal there will be 8-(1+0.5+0.25) = 6.25 symbols available
For a SF11 signal there will be 8-(1+0.5+0.25+0.125) = 6.125 symbols available
For a SF12 signal there will be 8-(1+0.5+0.25+0.125+0.0625) = 6.0625 symbols available.

So there are always enough preamble symbols left to try to detect a higher SF signal, if the lower SF detection fails.

In order to make this work it is important to detect the presence of a signal on the channel as soon as possible, the RSSI detection in FSK mode can be used to do that.

A drawback of this approach is that the range of this gateway will be less of that of a ‘real’ gateway; it can only receive messages that can be detected by RSSI.

6

Thanks for providing the link to the explanation.

However if the code uses the RSSI level detect as in;

“A drawback of this approach is that the range of this gateway will be less of that of a ‘real’ gateway; it can only receive messages that can be detected by RSSI.”

The normal RSSI reading, i.e. not the calculated one during packet reception, cannot I presume read below noise level, so will not see LoRa packets which at their limit are up to 20dB below noise level. That represents a very significant loss in sensitivity and range.

Incidently the CAD detect seem to produce a fair number of false detections, around 3 per minute @ BW125000 @SF7.