SX1280 zero rssi and snr

[topaz]

Dear fellows,
I do encounter quite a puzzling problem. I’m driving two SX1280 in a pingpong exchange. Each node:
1/ wait for a received frame,
2/ read it,
3/ output the rssi and snr onto an usart,
4/ send a frame
5/ loop back to 1/

Even if both node communicate flowlessly, I’m having a hard time with the rssi and snr value. They are both always equal to 0. I’m pretty sure I’m missing something in the documentation/configuration…
I’ve even tested with 1 node transmitting @13dBm, and the other @-18dBm, to force a difference, but it didn’t help.
If you have any idea.
Best regards

[topaz]

Dear all,
For all those who are playing with SetSleep manually, without resetup after waking up (leveraging the data RAM backup for example, using the 0x84:0x01 SetSleep command), I found a way to ensure non blanked RSSI/SNR values.
1/ Reset the chip
2/ Initial setup (packet type, modulation, tx params,…)
3/ Read register 0x0EF and 0x0F0, and hold those values in the MCU RAM.
…
n/ SetSleep
n+1/ Wakeup for new command
n+2/ Write back 0x0EF and 0xF0 with held values.
n+3/ SetRx

Those 2 values sound like a calibration value for the RSSI/SNR handling. And when reloaded, then everything works pretty fine, and RSSI/SNR values are not zeroized.

Could any Semtech support confirm the problem and the applied solution?

Cheers,

[mantoine]

Hi @topaz,

Thanks for raising this point - I confirm the problem you are encountering is a bug on the chip side.

The official workaround is the following (given in pseudo-code)

wake_up();
if( packet_type == LoRa)
{
write_register(@0x00EF, 0x00);
write_register(@0x00F0, 0xAD);
write_register(@0x00F1, 0x08);
write_register(@0x00F2, 0x9A);
}

Regards.
_Matthieu

[topaz]

Dear Matthieu,

First of all, thanks for your fast reply.

Is the fix only limited to rssi/snr reading or are there any other impacts?

And last question, is there an updated errata sheet?

Cheers,

[topaz]

Dear Matthieu,
I’ve researched a bit more to integrate your complete recommandation, and it seems the SX1280 is locking up in Sleep mode (with a random reproduction rate) when byte 0x0F1 and 0x0F2 are written in memory after waking up the chip.
Is that something you’ve experienced too? (It can take up to a solid 1k packet exchange to reproduce sometimes)
Cheers,

[mantoine]

Is the fix only limited to rssi/snr reading or are there any other impacts?

It is limited to RSSI/SNR reading.

Is that something you’ve experienced too?

I just launched a test bench to see if I can reproduce it.

[mantoine]

@topaz - when you update registers (0xEF/F0/F1/F2), do you perform a write in 1 operation or in 4 operations?

[topaz]

I do perform the write of all 4 values at once.

The MCU is only running @ 2mhz, with a 1MHz SPI, so cutting down on nss switches and opcode+address presentation was definitely needed to cut down the total overhead.

[mantoine]

Thanks - I am still not able to reproduce the issue you are observing.

Here is the sequence I’m using:

1. Reset
2. Initialize the chip
3. Put it in sleep mode (with retention)
4. Wake it up
5. Configure the 4 registers with the value I shared previously.
6. Put the chip in reception mode and wait for a packet
7. Receive a packet and process it
8. Go back to step 3

I played this loop 10’000 times in a row without problem. The main difference I see is the MCU clock speed (80MHz) and the SPI clock speed (5 MHz)

[topaz]

That’s roughly what I do too.
The problem arise when issuing the SetRx after a wakeup. the chip status remains at 0xFF (MISO stuck on hugh level).
I’ll see if I can provide with a sample.

@mantoine What board do you have to be able to reproduce ? (I tested on stm32l0 only for now)

Cheers,

[mantoine]

On my side, to check if the chip is not in sleep mode anymore, I rely on the BUSY signal - as soon as it is low I send the register configuration command and the SetRx command. I suppose you are doing the same.

I’m currently using a STM32L476 with a custom SX1280 shield.

[topaz]

I do this too, yes. I’ll try to reproduce the problem again, with a logic analyzer sniffing and provide you with the log if you want.
Cheers,

[mantoine]

That could help, for sure - thanks!

[topaz]

@mantoine
After struggling for a part of the night about not being able to reproduce the problem, I’ve finally understood the problem root. It seems like it’s somewhat related to the PCB used. On the E28-2G4M12S, no problem weither I use a 2 or 4 bytes workaround, but on the DLP-RFS1280, using the 4 bytes workaround lead to a chip lockup in sleep.
I’m joining 2 capture of the DLP RFS1280 module:

• 1 with 4 bytes, locking up lock
• 1 with 2 bytes, not locking up ok.

Files have been saved with my saleae logic, use the Logic v2 client to read them (even if you don’t have the hardware). Here’s a screenshot of the interesting part

. The command order on the screenshot is:
1/ get status
2/ set sleep (+retention 0x07)
3/ write register (4 byte @ 0x0EF)
4/ set rx (which fails, notice the small reverted spike on the busy during the command processing)

I’m really eager to understand the real physical problem behind that lock up, as, unlike the E28, the RFS module has received some certifications.
Cheers,

ps: if any link goes dead, feel free to ask for reup.

[mantoine]

Hi @topaz,

Thanks a lot for all these valuable information! I’ll be away for the next two weeks. I’ll work on it again when I’m back.

[topaz]

Little follow up here too, Had you had any time to check those things?
Cheers,
Olivier