FORUM

SX1276 Lockup while using FSK

Semtech Transceivers SX127x family
#1

Hi all,

I’ve been using the SX1276 in FSK mode. Early in the project, I found that it frequently appears to fully lock up when transmitting a message. There appeared to be some relation to timing of the various SPI operations I was performing, and by taking the following actions, I had the radio seemingly working very reliably:

  • Inserting a ~30us delay immediately after reading the FIFO on Rx (or rather, by reading RSSI after the FIFO, which takes a similar length of time), and
  • Inserting a ~150us delay between stopping the sequencer and restarting it in the relevant mode.

I was in contact with the support team via https://semtech.force.com/ (case #60661), but they closed the ticket due to “high number of support requests”.
At the time, I thought we had a reasonable handle on the situation, so let it be.

Unfortunately my customer has now reported symptoms in the field that align with the behaviour that this issue can exhibit… which may mean that the solution isn’t as robust as I had thought / hoped.

I wonder if this issue is similar or related to those reported here:

I’ve made some demo firmware and taken some logic analyser and RF captures showing the “broken” (i.e: without delays) behaviour, and another set showing the “working” behaviour. There doesn’t appear to be anything wrong in either captures from “my” side.

  • The Tx firmware will transmit a message every 500ms, with an ASCII counter at the end of the message. This works fine.
  • The Rx firmware will attempt to receive the message, and respond with an echo / ACK, substituting one byte (from ; to #). On a timeout (2 seconds), it will reset and reconfigure the radio to get things going again. This is problematic and the subject of this post.

In the “broken” case, the radio will reliably go non-responsive when attempting a Tx, claiming in the RegOpMode register that it has entered the “frequency synthesis for Rx” state (i.e: completed Tx), but it never receives again until you reset it.
I’m not 100% sure if a soft reset will work - I’m performing a hard reset.

On the RF side, one of two things will happen:

  • Nothing - i.e: no toggle on the RXTX signal, no transmit on the RF side (even very quiet)
  • A continuous 0101010 stream, with the RXTX signal high - seemingly forever

This demo is produced using a Microchip SAML21 XPro, and a Semtech SX1276MB1MAS.

The capture files can be downloaded from here: 20220516-sx1276-lockup-report.tgz.

The logic analyser traces (*.sal) can be opened with Saleae’s Logic 2 software, and have annotations on to help identify what’s going on.

The RF captures (*.cfile.gz) can be decompressed and then opened with Inspectrum.

Please let me know if I can provide any additional information or context.

Regards,
Attie

#2

Hi Attie,
I went futher in to my issue reported here.

I discovered using SX1276 with AFC on, it shifts a lot the main frequency, up to 4 MHz in a scenario where I have two radio 1m far from each other.
If I disable AFC in test lab the tx-rx works fine. If I move the code into a real scenario (node about 20 m distant) the situation degrades a lot.

In my case only hard reset give me back the rx.

I’m also in contact with the support. I let you know if there are updates.

Regards,
Davide

#3

There was some delay in my post being approved, and in the meantime I’ve been playing to try and understand what’s going on better.

I’ve now got two units transmitting on a slightly different period (500ms vs 501ms), meaning that they come in/out of phase with each other and the response transmissions… this shows the issue quite well, even with the “fixes” I outlined above. This follows our observations, as my customer’s site is much more busy on the RF side than my lab…

I now believe that there are some timings considerations that we are not aware of (and are not documented) around the use of the sequencer… I’m almost tempted to rewrite the driver to avoid using it and if things improve.

@davide.sartori - are you using the sequencer too?

I’ve reworked the design as follows, and this does appear to be more robust.

  • If no message is received for 30 mins, the radio will be reset and reconfigured
  • Set the radio to standby and confirm it’s actual state when changing modes… the can be automatically retried a series of times and is in place of the fixed delay
  • If an issue is experienced during transmit, the radio will be reset and reconfigured

using SX1276 with AFC on, it shifts a lot the main frequency, up to 4 MHz

Wow, thanks for the info - I’ve not seen the frequency drift nearly so much, but I’ll keep an eye out.

I’m also in contact with the support. I let you know if there are updates.

:+1:

#4

No, actually I don’t use the sequencer. I use driver Semtech at version 4.5.2 driver In my pcb I have connected only DIO0/DIO1 mapped into Tx/Rx Done and Fifo Level respectively. The radio works in packet mode.

In your implementation which kind of driver are you using?

#5

No, actually I don’t use the sequencer

Interesting… As above, perhaps I should try without.

In your implementation which kind of driver are you using?

This project is using Zephyr, and I’ve written a fairly small driver to deal with the radio.

#6

This comment is only tangentially related to your issue. I just wanted to point out that RSSI is really only properly defined during the preamble when there is an equal proportion of 1’s and 0’s. So if you want an accurate value you pretty much have to use the preamble-detect interrupt and grab the rssi then. Doing it after reading the packet from the fifo is way too late. This is not detailed in the datasheet but has been that way in all previous semtech FSK radios I’ve written drivers for.