FORUM

[LLCC68] Poor Sensitivity

This is a reproducible difference that has been seen over and over again across many different hardware examples. Your point about noise signals stands, but the common factor across all these tests is that the newer sx1262 and llcc68 chips are proving less capable of delivering packets than the older sx1276 series. Power supply characteristics and cabling losses are good things to keep in mind, but the weight of evidence indicates that these are not primary factors in these tests. I think there is a strong case here that something is not working correctly in the newer chips when compared with the older generation. The differences in RSSI and SNR numbers could be worked-around relatively easily, but the significant reduction in packet success rate is a major problem.

1 Like

I’m a solution based person. I have read most parts of the topic, and noticed the difference, yes, was hard to oversee. But I’m interested in finding out about the why.
Just bashing around and saying over and over again, there’s a difference, does not really help in finding a solution.
I’m using the LLCC68 myself in a product (not yet ready for range tests), that’s why I made some suggestions.

Not commenting about the other tests, but the last test with the inacceptable power supply is for me a no-go. I know from my own experience that the power supply makes a hell of a difference.

What I’m trying to say is: a more scientific approach would be far better (means: everything equal during the test setup for both DUTs as far as possible).

Then there are things like software setup. A detailed explanation wouldn’t be bad. DC/DC converter? RX boost? Inverted IQ? etc. etc…

I want to stress again: my approach is solution-oriented.

Have had a look at the SX1276 datasheet and compared it to the LLCC68 datasheet.
Blocking immunity LoRa:
Offset 1 MHz: 80 dB (LLCC68) vs. 89 dB (SX1276)
Offset 10 MHz: 91 dB (LLCC68) vs. 100 dB (SX1276)

To my understanding the LLCC68 is by design more susceptible to noise (9 dB difference). That’s what the datasheet is telling me.

And as for the software, there’s one further question: Has a frequency calibration for the correct band be done?

I imagine you’ll also do some side by side testing once your product is ready? It will be interesting to see your results. Or even pick one up for testing.

@jye.smith I’ve never had an SX1276 and don’t have plans to use it (no offence). Development is very cost intensive, so I can only develop stuff that will definitely be sold in large quantities.

After reading this topic and looking at the charts, my impression is: the LLCC68 does not do anything which is in clear violation to its datasheet. I am confident that a pigtail or a SAW filter and a different power supply would improve reception - together with high performance RX settings in the firmware, that is:

  1. doing a frequency calibration for the right band if it’s different from the default one in the datasheet
  2. if inverted IQ is used, applying the fix from the datasheet
  3. disabling the DC/DC converter for test purposes, and using the LDO instead
  4. Enabling RX Boost

To me a clear indication for a bad power supply or EMI.
I’ve had the same problem with a different transceiver. In my case the power supply was ok (checked the ripple voltage with an oscilloscope), but the ethernet on the same board was causing EMI. It would even interfere with devices in the proximity.
So: get rid of Ethernet, WiFi, SD cards etc. in the near field - all causing EMI. Then test again.

In a different case where I had RX issues, the problem turned out to be the ripple voltage produced by a DC/DC converter. DC/DC converters are tricky because they can change their frequency and hence their EMI. Sometimes they only cause troubles when a certain current is drawn from them or when the input voltage is below/above a certain threshold.

Blocking immunity LoRa:
Offset 1 MHz: 80 dB (LLCC68) vs. 89 dB (SX1276)
Offset 10 MHz: 91 dB (LLCC68) vs. 100 dB (SX1276)

Just a heads up that these are comparing different SF. 12 for the sx1276 and 9 for the llcc68. Looking at the lr1121 it has comparable number to the sx1276 and Im getting tempted to also grab one for testing.

Thanks for the suggestions and Ill be trying the LDO.

doing a frequency calibration for the right band if it’s different from the default one in the datasheet

Done.

if inverted IQ is used, applying the fix from the datasheet

Not used.

disabling the DC/DC converter for test purposes, and using the LDO instead

I can test this. EDIT - turns out it was already off.

Enabling RX Boost

Its enabled.

@jye.smith
at some point there was a remark that you could not receive anything below -110 dBm.

I have done a test now with an LLCC68 both as sender and receiver.

Frequency: 868.0 MHz
calibration: 863-870 MHz
payload: 4 bytes
explicit header
SF 5
BW 250kHz
+14dBm output power (optimized settings for low output power)
no CRC, no invert IQ
12 bytes preamble
80us ramp up time
DC/DC converter enabled
OCP 100mA (should have no effect because TX current is ~43mA)
CR 4/5

results:
1km range on a street in center of Vienna (no free line of sight)
the lowest readings I got were:

RSSI Packet | Signal RSSI | SNR
-110 | -113 | -2
-111 | -117 | -6
-111 | -116 | -4
-111 | -116 | -6
-111 | -116 | -5
-111 | -115 | -3
-111 | -116 | -5

To give some context:
I did a similar test with +13dBm using an SX1231, and achieved a similar range. The RSSI threshold was set to -109 at that time and that was also the lowest reading I got (it was very close to the noise floor).

Interpreting the results of the current test:
The noise floor measured on the receiver board with FSK/SX1231 in the previous test showed something around -110 to -112 dBm. I’ve determined the noise floor by lowering the RSSI threshold down to the point where the transceiver would think to detect a preamble (although nothing was being actually transmitted).
Interestingly enough -111 dBm is the lowest RSSI I’m also reading in this test. The receiver I’m using has an ethernet connection with 10MBit onboard.

@sose1 thanks for testing. Any chance you are able to get a measure of link quality e.g. percentage of successful packets being received vs other know good hardware?

I can work around rssi/snr differences, but in the end less packets were being received compared to the sx1276 as shown in these 2 comments.

https://forum.lora-developers.semtech.com/t/llcc68-poor-sensitivity/1480/5
https://forum.lora-developers.semtech.com/t/llcc68-poor-sensitivity/1480/17

@jye.smith alas I don’t have any other LoRa reference device to measure against. So even if I count successful packets, there is nothing to compare against.

What I can do is, use SF10 e.g., enable CRC, and see if range increases and/or “Signal RSSI” changes to the values of the spec sheet.

1 Like

I’ve repeated my last test with different settings now:
CRC: enabled
SF 10
BW: still 250kHz
CR: 4/7
output power is unchanged (+14dBm optimized settings)

Results:
1.4km range walking on the street in one direction
receiver is still in 3rd floor of a building
sender in a cardbox in my hand
no direct line of sight (street is not perfectly straigt, neither horizontally nor vertically)

lowest readings:
RSSI Packet | Signal RSSI | SNR
-111 | -126 | -15
-112 | -126 | -15
-112 | -128 | -18
-111 | -127 | -16

So the Packet RSSI stays the same, but the Signal RSSI is lower.
The datasheet states a max sensitivity of -129 dBm with split RF paths for the given settings.
There were spots on the route where the connection would be gone, but most of the time it seemed to work (3 msgs in a row without loss at a spot).

The screenshots show the readings at certain “waypoints”.

14:23 - 650m
Screenshot_2023-05-19-14-23-21-300_at.tripwire.mqtt.client

14:27 - 1km
Screenshot_2023-05-19-14-27-14-775_at.tripwire.mqtt.client

14:30 - 1.3km
Screenshot_2023-05-19-14-30-28-783_at.tripwire.mqtt.client

14:35 - 1.4km
Screenshot_2023-05-19-14-35-13-374_at.tripwire.mqtt.client

I guess that the RSSI limit @ -112 dBm is caused by noise emitted by the receiver’s LAN. If the antenna was placed away from the LAN (with an adapter cable e.g.), I guess that this figure would be lower. Whether that would have an influence on range, is another story…

1 Like

If you see the performance reports of Semtech’s Corecell products (SX1302+SX1250), you’ll see the reported Signal RSSI has some error near the sensitivity level. You should generally not use RSSI as a benchmark of receiver sensitivity, especially in the field where SNR is an important factor. Semtech finds conducted RX sensitivity specs from a testbench with a signal generator and RF shield box so that the signal strength is precisely known.

Thanks @kmuster

Thats fine and we can look past the RSSI and SNR values. But The percentage of received packets (link quality) is still less compared to the sx1276.