RSSI of the Downlink ACK

[jithinsisaac]

Hey…

Can you help me how do you get the RSSI of the downlink ACK recevied by device from gateway upon a confirmed Uplink from the device?

I want to make a field test device which can help to find the best location for an end node based on its RSSI value...

[terrillmoore]

Hi @jithinsisaac -- the LMIC captures the RSSI and SNR of every downlink inLMIC.rssi and LMIC.snr, respectively. (This is not an API contract, just a statement about the current code. So this could conceivably change.)

The form of these values is hardware specific, and so care must be taken when interpreting. I think you should look at the Semtech 1276 or 1272 datasheet (as appropriate), sections 5.5.5, to interpret.

• LMIC.rssi has different offsets on an SX1272 than on an SX1726
• LMIC.rssi has different offsets on an SX1276 when working with the HF port, than when working with the LF port.
• LMIC.rssi must be corrected for non-linearity

They also recommend that you calibrate your design. It's not clear, however, exactly how to calibratie, in particular whether the offset is to be applied before or after linearization correction.

The general approach is below. I'll consider adding this to the library. I've tested this code as https://repl.it/@terrillmoore/LMICsx127xrssi -- the test harness prints out the data so you can eyeball it and decide whether you like the correction.

enum sx127x_rssi_method_e {
  SX127x_RSSI_METHOD_1272,
  SX127x_RSSI_METHOD_1276_LF,
  SX127x_RSSI_METHOD_1276_HF,
  SX127x_RSSI_METHOD__MAX
};

const int rssi_default_cal[SX127x_RSSI_METHOD__MAX] = { -139, -164, -157 };

int calcRssi(enum sx127x_rssi_method_e how, int calOffset) {
  uint8_t packetRssi = (uint8_t) LMIC.rssi;
  int8_t packetSnr = LMIC.snr;
  int rssi;

  calOffset += rssi_default_cal[how];

  if (packetSnr > 0) {
    // calOffset + 16/15 * PacketRssi, rounded
    rssi = calOffset + (16 * packetRssi + 7) / 15;
  } else {
    // callOffset + PacketRssi + PacketSnr * 0.25
    rssi = calOffset + (packetRssi * 4 + packetSnr + 2) / 4;
  }
  return rssi;
}

[terrillmoore]

I've been looking at the tables output by my test framework, and realized that I had a polarity reversal in the SNR comparison: had >= 0, needed < 0. Fixed here and at https://repl.it/@terrillmoore/LMICsx127xrssi.

[jithinsisaac]

Hey many thanks for taking this up...

Many modules like the RAK811 have AT commands which give rssi of a proper downlink from the gateway, but not of a downlink ack from the gateway.. So was kinda confused how to go about finding the rssi of a downlink ack.. Your post is surely going to help.. I'll check it up tomorrow on the hardware.

I've a few lingering questions though:

1. If we are sending a confirmed uplink, and we have queued a downlink from the gateway also, how will the code differentiate on which to find the rssi of, the proper downlink or downlink ack? Will it find for both?

2. If we are sending a UNconfirmed uplink and have queued a proper downlink, will this code help us to get the rssi of this proper downlink? (Not the downlink ACK)

3. Is packetSnr going to be the SNR of the downlink ack? Or do we require some offset adjustments as you have done for the rssi?

4. In enum sx127x_rssi_method_e{}, shouldn't it be 1276_HIGH, instead of 1226?

Thanks a lot for your help, eager to check this on the hardware tomorrow..

[jithinsisaac]

Regarding pt. 3 above regarding snr of downlink,
in the datasheet on page 112, section 6.4, it shows the following modifciation.
The RegPktSnrValue register gives estimation of snr of last packet received.

SNR(dB)=PacketSnr[twos complement]/4

(Using SX1276 btw)

[terrillmoore]

You're right, it's a typo; the test code simply goes through the numeric range, rather than use the enum names. And on reflection the names look wrong. Corrected above and at https://repl.it/@terrillmoore/LMICsx127xrssi (and also to include the changes below, which are important).

PacketSnr from the datasheet is exactly the value in the LMIC.snr field. To get the SNR in dB, you need to do the divide-by-four thing.

As for your original points:

1. the data is always for the last packet received. Acks come in the downlink window, and are piggybacked on any downlink traffic; if there's no downlink traffic, the ack piggybacks on an empty packet. SNR and RSSI will be different depending on the channel in use.

2. In reviewing all this today, I see that I still have misread the datasheet. (Too busy looking at the certification issues, I guess.) It's a bit confusing. There are four cases. First the relevant ships.

1272:

1. 

2. 

3. 

Note that 1 and 2 are somewhat contradictory. I think the * 0.25 is spurious. I think the proper equation is: Packet Strength (dBm) = -139 + PacketRssi, (with LnaBoost On and SNR >= 0)

1276:

chip/port	SNR	Formula
1272	> 0	-139+16/15 * PacketRssi
1272	<= 0	-139 + PacketRssi + PacketSnr * 0.25
1276 LF	> 0	-164+16/15 * PacketRssi
1276 LF	<= 0	-164 + PacketRssi + PacketSnr * 0.25
1276 HF	> 0	-157+16/15 * PacketRssi
1276 HF	<= 0	-157 + PacketRssi + PacketSnr * 0.25

This results in the table below for SX1276 on the HF port. (Stepping input SNR in steps of 3.33 dB so I can test rounding a little.)

You could change my routine to return a fixed point fraction (quarter dB steps) to keep a little more info. That might be a good idea because you need to average this in order to have any real idea of what's going on -- fading and channel differences will have a big effect on your results. If the LMIC were to support this, we'd want to add info to the channel tables so we're capturing a different value for each channel. In practice, they are generally quite different. Or we'd want to add an API so you can grab the info at the right moment. You could capture this in the EV_RXCOMPLETE event; at that moment, you can still determine the downlink channel, etc. Look at how I get the data printed in the compliance app.

1276 (HF port) PktRssi	0	8	16	24	32	40	48	56	64	72	80	88	96	104	112	120	128
SNR -20.00	-176	-168	-160	-153	-145	-137	-129	-121	-113	-105	-97	-89	-81	-73	-65	-57	-49
SNR -16.67	-173	-165	-157	-150	-142	-134	-126	-118	-110	-102	-94	-86	-78	-70	-62	-54	-46
SNR -13.33	-169	-161	-154	-146	-138	-130	-122	-114	-106	-98	-90	-82	-74	-66	-58	-50	-42
SNR -10.00	-166	-158	-151	-143	-135	-127	-119	-111	-103	-95	-87	-79	-71	-63	-55	-47	-39
SNR -6.67	-163	-156	-148	-140	-132	-124	-116	-108	-100	-92	-84	-76	-68	-60	-52	-44	-36
SNR -3.33	-159	-152	-144	-136	-128	-120	-112	-104	-96	-88	-80	-72	-64	-56	-48	-40	-32
SNR 0.00	-157	-149	-141	-133	-125	-117	-109	-101	-93	-85	-77	-69	-61	-53	-45	-37	-29
SNR 3.33	-157	-148	-140	-131	-123	-114	-106	-97	-89	-80	-72	-63	-55	-46	-38	-29	-20
SNR 6.67	-157	-148	-140	-131	-123	-114	-106	-97	-89	-80	-72	-63	-55	-46	-38	-29	-20
SNR 10.00	-157	-148	-140	-131	-123	-114	-106	-97	-89	-80	-72	-63	-55	-46	-38	-29	-20
SNR 13.33	-157	-148	-140	-131	-123	-114	-106	-97	-89	-80	-72	-63	-55	-46	-38	-29	-20

[jithinsisaac]

Hey Thank you.. I finally got to work on the hardware today..

I tried this part of your code for a start for a SX1276 HF:

int calcRssi() 
{
      uint8_t packetRssi = (uint8_t) LMIC.rssi;
      int8_t packetSnr = LMIC.snr;
      int rssi;    
      if (packetSnr > 0)      {
        // -157 + 16/15 * PacketRssi, rounded
           rssi = (-157+(16 * packetRssi + 7)/15);
      }
      else       {
        // -157 + PacketRssi + PacketSnr * 0.25
           rssi = (-157+(packetRssi*4 + packetSnr + 2)/4);
      }
      //return rssi;
      Serial.print("LMIC.rssi: "); Serial.println(packetRssi);
      Serial.print("RSSI of Downlink: "); Serial.println(rssi);
      Serial.print("LMIC.snr: "); Serial.println(packetSnr);
      Serial.print("SNR of Downlink in dB: "); Serial.println(packetSnr/4);      
}

And I got this output:

LMIC.rssi: 251
RSSI of Downlink: 111
LMIC.snr: 41
SNR of Downlink in dB: 10

Extremely strange values...! The uplink SNR measured is -5 & RSSI is -89.. How can the downlink be so wayward!

Sorry that I didn't use the other part of your code, as I was not able to decipher its working properly.. Would that be a possible reason for such readings?

[terrillmoore]

I again was looking at the RSSI code (for another project), and I find that it's odd and/or wrong. I will open an issue for fixing this. Part of the problem is that LMIC.rssi must have RSSI_OFF subtracted to turn it into engineering units (dB). this wasn't documented anywhere, I just discovered it. (The code storing RSSI just added 64, without using the constant, which made it hard to figure out..)