Module LLCC68 does not initialize

[jrhbcn]

I am using a EBYTE E220-900M22S module that comes with a LLCC68 chip connected to a ESP32 D1 mini. I am experimenting with the SX126x_Channel_Activity_Detection_Receive example. Using the LLCC86 module does not seem to work:

I have changed this part in the example:

LLCC68 radio = new Module(5, 32, 33, 25);
int state = radio.begin(BAND, SignalBandwidth, SpreadingFactor, CodingRate, SyncWord, TxPower, PreambleLength, 0, false);

And it gives the error:

[SX1262] Initializing ... RLB_DBG: 
RadioLib Info
Version:  "7.1.0.0"
Platform: "ESP32"
Compiled: "Nov 22 2024" "15:39:17"
RLB_DBG: SX126x not found! (1 of 10 tries) RADIOLIB_SX126X_REG_VERSION_STRING:
RLB_DBG: 00000320: 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00  SX1261 V2D 2D02.
RLB_DBG: Expected string: LLCC68
...
RLB_DBG: SX126x not found! (10 of 10 tries) RADIOLIB_SX126X_REG_VERSION_STRING:
RLB_DBG: 00000320: 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00  SX1261 V2D 2D02.
RLB_DBG: Expected string: LLCC68
RLB_DBG: No SX126x found!
failed, code -2

However, if I change to using the module SX1262 (LLCC68 is supposed to be pin compatible except that it does not support some configurations), then the module initializes, and it seems to receive messages from other LoRa modules:

[SX1262] Initializing ... RLB_DBG: 
RadioLib Info
Version:  "7.1.0.0"
Platform: "ESP32"
Compiled: "Nov 22 2024" "15:39:17"
RLB_DBG: Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING:
RLB_DBG: 00000320: 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00  SX1261 V2D 2D02.
RLB_DBG: 
RLB_DBG: M      SX126x
success!
[SX1262] Starting to listen ... success!
success!
[SX1262] Data:          0xAAAA
[SX1262] RSSI:          -59.00 dBm
[SX1262] SNR:           9.00 dB
[SX1262] Frequency error:       -30079.69 Hz

What is happening? It seems the LLCC68 chip is actually returning the SX1261 string? Both SX1261 and SX1262 classes seem to work as intended (but not LLCC68)? Is this normal, or is it just a bogus chip?

[jgromes]

There's been a couple other issues/discussions reporting this. The version string is stored in the module itself, so it looks like the module "thinks" it's an SX1261. So the question is whether there's an SX1261 inside that Ebyte module, or if the string is wrong and it really is LLCC68. I don't have that module, so I can't check this.

One way to figure this out by configuring a SF/BW configuration that the LLCC68 does not support (e.g. SF12, BW 125 kHz). If it is LLCC68, it should fail. If it is the more capable SX1261, it should have no issues and freely transmit. @jrhbcn if you could try taht, that would be great.

Since this came up a couple times already, I have added a note about this to LLCC68 examples, and the troubleshooting guide.

[codev123]

i have also encountered the same issue, previously ordered ebyte 220- 400m22s LLCC68 modules were working with constructor LLCC68. but newly ordered ebyte 220 - 400m22s are not working with constructor llcc68, while its working with constructor SX1262. so i ipened shield from module and checked the ic on both prev and new modules. the ic in both is LLCC68. so i think its supplying wrong string.
what should be the solution sir?

[jgromes]

@codev123 it's a good question to ask Semtech ;) The best we can do is test it - would it be possible to perform the test I proposed above, i.e. configuring a LoRa setting not supported by the LLCC68 and trying if it works? If the test fails, then we know it's just the string in the device that is incorrect, and we can work around that. If it works, there might a different issue (wrong marking? though it seems unlikely ...)

Also, if you could take a photo of both ICs so that the markings are visible (the old and the new one) and post them, that would be very helpful. Maybe there's a specific batch of the ICs that has this problem.

[codev123]

Thank you sir. i have already tested what you have mentioned, and when i initialise llcc68 with constructor SX1262, with bandwidth 125.0 and sf 12, it got initialized and i was able to transmit data too. what is this? its against data sheet of llcc68, but i opened the shield and ic has LLCC68 written over it.
i an sending you the image.....
how to send you the images sir,
marking on LoRa IC
new module - LLCC68 LoRa 242687910
old module - LLCC68 LoRa 225034047

[jrhbcn]

I can also confirm that my EBYTE E220-900M22S (bought less than 2-3 weeks ago) works doing a pingpong example with another module with BW=125 and SF=12. So it does not have a LLCC68 inside.

@codev123 you can easily add images to github comments, just copy and paste and it will be included!

I am going to investigate if there is a sx1261 or a sx1262 chip instead of the advertised LLCC68. The only difference I can see is that sx1261 supports +15dBm and sx1262 +22dBm. @jgromes, I see that in the library, sx1261 is capped to 14dBm not 15dBm. Is that intended?

[jrhbcn]

Hello again,

I have done some more tests with the PingPong example. PingPong sender is the E220-900M22S module with the "fake" LCC68 chip. PingPong receiver is a LILYGO T3_V1.6.1 integrated ESP32+LoRa (sx1276). I have configured the receiver with some fixed settings: BW=125, SF=9, CR=5, dBm=20 (max for sx1276).

I compiled the PingPong sender (fake LLCC68) with the sx1261 and sx1262 classes at different dBm:

1. Using sx1261 class with dBm=14

Receiver reports RSSI of around -125dBm. Really weird as both receiver and sender are face to face. This is the receiver log:

[SX1276] Data:          Hello World!
[SX1276] RSSI:          -124.50 dBm
[SX1276] SNR:           -6.50 dB

while the sender log reports much higher RSSI:

[SX1261] Data:          Hello World!
[SX1261] RSSI:          -42.00 dBm
[SX1261] SNR:           10.50 dB

Measuring the current consumption of the E220-900M22S shows values of 10mA (again too low which correlates with the low RSSI reported):

2. Using sx1262 class with dBm=14
Receiver reports:

[SX1276] Data:          Hello World!
[SX1276] RSSI:          -68.00 dBm
[SX1276] SNR:           8.50 dB

Sender reports:

[SX1262] Data:          Hello World!
[SX1262] RSSI:          -46.00 dBm
[SX1262] SNR:           10.50 dB

Current consumption looks more in line with datasheets with 82mA when transmitting the message:

3. Using sx1262 class with dBm=22
Receiver reports:

[SX1276] Data:          Hello World!
[SX1276] RSSI:          -67.00 dBm
[SX1276] SNR:           9.25 dB

Sender reports:

[SX1262] Data:          Hello World!
[SX1262] RSSI:          -45.00 dBm
[SX1262] SNR:           9.75 dB

Current consumption stays in 82mA when transmitting the message:

Sorry for the extra-long message but I am a bit loss here. It seems that using sx1262 class allows the module to transmit with more power. However, it does not seem to change transmission power (receiving RSSI and mA remain constant). So actually no idea what is going on in that chip. Also, compared with the LILYGO, it seems to transmit at a lower power even with the sx1262 class.

@jgromes, @codev123. Any ideas? If you want me to make any other test to understand a bit better what is happening, let me know!

[jgromes]

@jrhbcn thank you for the test!

I see that in the library, sx1261 is capped to 14dBm not 15dBm

That might be just a small mistake on my part; you are correct that it can go up to +15 dBm, so I will fix that.

Regarding the power, it seems that despite what it reports, the LLCC68 is actually based on SX1262, at least for the PA configuration. In the previous screenshot, the deviceSel parameter is fixed to 1 for SX1261. However, LLCC68 datasheet shows that is should be set to 0, which is the value SX1262 uses.

So to summarize, the LLCC68 you have reports being SX1261, but behaves as if it were SX1262 🙃 If you could confirm this still works with SF12 BW 125 then I'd say you lucked out, because from what I understood, LLCC68 was supposed to be a cheaper alternative to SX1262, with limited features. Now you got the full feature set ;)

[jrhbcn]

That might be just a small mistake on my part; you are correct that it can go up to +15 dBm, so I will fix that.

Perfect, thank you!

So to summarize, the LLCC68 you have reports being SX1261, but behaves as if it were SX1262 🙃 If you could confirm this still works with SF12 BW 125 then I'd say you lucked out, because from what I understood, LLCC68 was supposed to be a cheaper alternative to SX1262, with limited features. Now you got the full feature set ;)

I confirm that it works using SF=12 and BW=125 so it definitely seems to be a sx1262. However, I don't think we were lucky. Transmission power does not works properly. I have done some test modifying the transmission power from 1dBm to 22dBm, and it seems to cap at 10 dBm, and it does not increase power any more (confirmed both with receiver RSSI and mA consumption of the chip). These are my results, all using class sx1262 with the "fake" LLCC68 module:

• dBm=1 --> receiver RSSI=-70 , consumption = 55mA
• dBm=5 --> receiver RSSI=-68 , consumption = 71mA
• dBm=10 --> receiver RSSI=-67 , consumption = 82mA
• dBm=15 --> receiver RSSI=-67 , consumption = 82mA
• dBm=22 --> receiver RSSI=-67 , consumption = 82mA

Comparing to another module (sx1276 with +20dBm in the datasheet) that reports a receiver RSSI = -46 I think it indeed limits the power to around 10dBm. My guess now is that maybe a low quality chip that goes as LLCC68, or very low quality components around it in the E220-900M22S module that prevents the chip to use the needed power. I have checked the datasheet but I don't see anywhere anything we might change to increase that power, it indeed seems to be totally compatible with sx1262...

In any case, many thanks for your help!!

BTW: Any good chip recommendation I can buy to replace it? I am looking for fairly power (>20dBm) and that it supports duty cycle (as I will be receiving 24/7 and trying to reduce power). That is why I went to the sx1262 / LLCC68 in the first place...

[jgromes]

@jrhbcn thank you for the additional test! Lacking any official information from the manufacturer, I think the best we can do for now is to accept the "SX1261" string as valid for LLCC68 and leave all the limits as the datasheet suggests.

EDIT: Regarding the recommended transceiver to use, I'd say SX1262 is your best bet - just not the LLCC68.

[jrhbcn]

Yes, I agree @jgromes, this is the best we can do. Based on my tests, I would recommend, if LLCC68 fails to initialize, to use the sx1262 class instead of the sx1261 (even if it reports the latter). I don't know if you want to change the comment in the examples to reflect this. In any case, I think we can close the issue now. Many thanks!

[jgromes]

@jrhbcn I can't really "change the class if LLCC68 fails to initialize", that's up to the user. What I can do is allow them to use the device even if it has the SX1261 string. The mismatch will also be reported to the debug port.

[jrhbcn]

@jrhbcn I can't really "change the class if LLCC68 fails to initialize", that's up to the user. What I can do is allow them to use the device even if it has the SX1261 string. The mismatch will also be reported to the debug port.

I was just referring to the comment line in the LLCC68 example. However, I just saw you removed them. In any case, I think that commit to the LLCC68 is perfect! ;)