Help needed please, with SX1262 tranceivers not receiving any data!

[JonW]

Sure of course, will set something up.  I have just had a reply from a John X. he said the same thing; there is no code!  I referenced the datasheet, which states that FW is offered as available and shows boards. Therefore, the product sale includes the code as it is part of the datasheet, and more importantly, how can the boards be verified if there isn't any working firmware?  We will see how far this goes, but it doesn't bode well... 

I looked at some of the Ardushite-o libraries and fell asleep after 5 minutes, your better off probing the data and working from that.. 

Good luck selling them anything. I have spoken to them before about some G.HN gigabit modules we developed, and they suffer very badly from not designed-here syndrome...

[top204]

Ditto Jon.

Eventually, I went through the SX126x device's long datasheet, command by command, and register by register, to create the library source code. But they keep refencing the linux C++ firmware, and not actually state what to do in detail. For example:

14. Application

14.1 HOST API Basic Read Write Function

The communication with the SX126x is organized around generic functions which allow the user to control the device
behavior. Each function is based on an Operational Command (refer throughout this document as "Opcode"), which is then
followed by a set of parameters. The SX126x use the BUSY pin to indicate the status of the chip. In the following chapters,
it is assumed that host micro-controller has an SPI and access to it via spi.write(data). Data is an 8-bit word. The SPI chip
select is defined by NSS, active low.

14.2 Circuit Configuration for Basic Tx Operation
This chapter describes the sequence of operations needed to send or receive a frame starting from a power up.
After power up (battery insertion or hard reset) the chip runs automatically a calibration procedure and goes to STDBY_RC
mode. This is indicated by a low state on BUSY pin. From this state the steps are:
1. If not in STDBY_RC mode, then go to this mode with the command SetStandby(...)
2. Define the protocol (LoRa® or FSK) with the command SetPacketType(...)
3. Define the RF frequency with the command SetRfFrequency(...)
4. Define the Power Amplifier configuration with the command SetPaConfig(...)
5. Define output power and ramping time with the command SetTxParams(...)
6. Define where the data payload will be stored with the command SetBufferBaseAddress(...)
7. Send the payload to the data buffer with the command WriteBuffer(...)
8. Define the modulation parameter according to the chosen protocol with the command SetModulationParams(...)1
9. Define the frame format to be used with the command SetPacketParams(...)2
10. Configure DIO and IRQ: use the command SetDioIrqParams(...) to select TxDone IRQ and map this IRQ to a DIO (DIO1,
DIO2 or DIO3)
11. Define Sync Word value: use the command WriteReg(...) to write the value of the register via direct register access
12. Set the circuit in transmitter mode to start transmission with the command SetTx(). Use the parameter to enable
Timeout
13. Wait for the IRQ TxDone or Timeout: once the packet has been sent the chip goes automatically to STDBY_RC mode
14. Clear the IRQ TxDone flag

[top204]

I've just examined the RF Solution's "LAMBDA62-1" board's chip under the microscope, and it is actually an LLCC68! Not an SX1262. But it is supposed to be an SX1262, as stated in its datasheet! Hence the name on the PCB of: "LAMBDA62-1" and not the "LAMBDA68-1".

What on earth are they playing at? I know the LLCC68 device is supposed to be the same as the SX1262 device, but with more output dbm, but why have they got a different device on the board? It's like ordering a PIC18F26K40 device, and being sent a PIC18F26K42 device, but not telling you, because they are similar to each other!!!!

OK... Time to go through the different datasheets again, and see if there is a difference between the LLCC68 and the SX1262. There should not be, but there always is with these companies run by nerds who do not actually live in the real world. :-)

[trastikata]

I've just examined the RF Solution's LAMBDA62-1 board's chip under the microscope, and it is actually an LLCC68! Not an SX1262. But it is supposed to be an SX1262, as stated in its datasheet! Hence the name on the PCB of: "LAMBDA62-1" and not the "LAMBDA68-1".

I've sent you an email about the latest code modification.

I've seen it before, that's why I said few posts ago that's probably a different chip. LLCC68 has a different datasheet, not even the same as SX1268, and I suppose some of the registers are different too.

Pay careful attention to specifications Les. We did our tests with SF=10 and BW=125 kHz assuming the chip is SX1262, but LLCC68 does not support that scheme and this is why we have seen the strange modulation on the SDR. Take a look at this comparison from the datasheet.

P.s. If I were you, I'd ask for a reimbursement of the purchase showing them the evidence that they actually sell lower performance chip than the advertising (LLCC68 has limited modulation options compared to SX1262 and because it does not support the low BW at high SF the link range is quite limited)

[JonW]

Well, that doesn't surprise me.  The LLC68 is a later cost down.  I uploaded the datasheets to a paid AI engine to quickly identify the differences for you (one of the better aspects of AI, which I use frequently). I don't know how accurate these are, but they should be and may save you a considerable amount of time.  They are supposed to pin for pin..   I will get a couple of SX1262  and try your original code.  If you get it working, please PM me the LLC68 code.


Register Differences

Device Identification:

LLCC68: Uses specific register mapping for the LLCC68 chip
SX1261/2: Has distinct register mapping for both SX1261 and SX1262 variants


Long Range FHSS Support (SX1261/2 only):

SX1261/2 adds several registers for Long Range FHSS modulation:

HoppingEnable (0x0385)
PacketLength (0x0386)
NbHoppingBlocks (0x0387)
NbSymbols0-15 (0x0388-0x03E3)
Freq0-15 (0x038A-0x03E7)




Packet Type Definitions:

LLCC68: PacketType values: 0x00 (GFSK), 0x01 (LoRa)
SX1261/2: Adds 0x03 (LR-FHSS) as a third packet type option


Default OCP Configuration:

LLCC68: 0x08E7 defaults to 0x38 (140mA)
SX1261: 0x08E7 defaults to 0x18 (60mA)
SX1262: 0x08E7 defaults to 0x38 (140mA)


IRQ Registers:

SX1261/2: Adds bit 14 "LrFhssHop" to support hopping events for LR-FHSS


Power Amplifier Configuration:

LLCC68: PA settings are optimized for the LLCC68 chip
SX1261/2: Includes device selection parameter (deviceSel) to distinguish between SX1261 and SX1262


Sequencing Differences

PA Configuration Sequence:

LLCC68: Device selection is implied by chip type
SX1261/2: Requires explicit deviceSel parameter (0x00 for SX1262, 0x01 for SX1261) in SetPaConfig()


LR-FHSS Transmission (SX1261/2 only):

Additional sequence required for SX1261/2:

Set packet type to PACKET_TYPE_LR_FHSS (0x03)
Set empty packet parameters (zeros)
Configure modulation parameters for GMSK
Set HoppingEnable bit
Program frequency hopping table
Write pre-processed packet to FIFO
Enable LrFhssHop and TxDone IRQs
Start transmission
Handle hopping IRQs if needed
Disable hopping after transmission




PA Optimal Settings:

LLCC68 and SX1262: Similar high-power settings for +22dBm output
SX1261: Has unique settings for lower maximum power (+14/15dBm)


System Design Considerations:

LLCC68/SX1262: Both can deliver up to +22dBm
SX1261: Limited to +14/15dBm, but with different efficiency characteristics
PA Supply:

LLCC68: PA supply from battery voltage
SX1261: PA supply from internal regulator
SX1262: PA supply from battery voltage



Overall, the SX1261/2 offers more advanced features with the addition of Long Range FHSS capability, while the LLCC68 appears to be a simplified derivative focusing on core LoRa and FSK functionality. The main architectural differences relate to the power amplifier design and its power supply scheme.

Additional Hardware Differences

LoRa Bandwidth Support:

SX1261/2: Supports more bandwidth options (7.81, 10.42, 15.63, 20.83, 31.25, 41.67, 62.5, 125, 250, and 500 kHz)
LLCC68: Supports fewer bandwidth options (125, 250, and 500 kHz)


Spreading Factor Range:

SX1261/2: Supports SF5 to SF12
LLCC68: Supports SF5 to SF11 (lacks SF12 support)


LoRa Bit Rate Range:

SX1261/2: 0.018 to 62.5 kbps
LLCC68: 1.76 to 62.5 kbps (narrower range)


RF Switching Control:

Both have DIO2 for RF switch control, but implementation details differ slightly


Power Amplifier Architecture:

SX1261: Integrated lower-power PA with internal regulation
SX1262: High-power PA with direct battery supply
LLCC68: Similar to SX1262 with high-power PA and direct battery supply

Functional Differences

Supported Operating Modes:

SX1261/2: Explicitly mentions supporting LoRa, Long Range FHSS, and FSK modulations
LLCC68: Supports LoRa and FSK modulations only


LoRa Symbol Timeout Function:

Implementation differences in SetLoRaSymbNumTimeout command
Different symbol number handling when validating LoRa packets


Power Regulation Options:

SX1261: More power-efficient at lower output power
LLCC68/SX1262: More power-efficient at higher output power


Application Circuit Recommendations:

Different reference designs provided for each chip family
Component values and layouts are optimized for the specific chip characteristics


Calibration and Image Rejection:

Similar calibration procedures but with device-specific optimizations
Image rejection calibration parameters differ slightly

Performance Differences

Power Consumption Profiles:

SX1261: Optimized for lower power applications
SX1262/LLCC68: Optimized for longer range/higher power applications


TX Current vs Power Output:

SX1261: More linear relationship between current and power
SX1262/LLCC68: Most efficient at maximum power


Sensitivity Specifications:

SX1261/2: Specified for a wider range of bandwidths and spreading factors
LLCC68: Focuses on the most common configurations


Temperature Performance:

Similar temperature range specifications but may have different behavior at extremes


Frequency Hopping Capability:

SX1261/2: Supports fast frequency hopping with specific hardware support
LLCC68: Basic frequency changing capability but without dedicated hopping hardware



These differences impact how you would design systems around these devices, especially when considering power budget, range requirements, and advanced features like frequency hopping.


Digital Modem Bank Differences
LLCC68 Digital Modem Bank:

LoRa® Modem:

Bandwidth options: 125, 250, 500 kHz
Spreading Factor range: SF5-SF9 for BW=125kHz
Spreading Factor range: SF5-SF10 for BW=250kHz
Spreading Factor range: SF5-SF11 for BW=500kHz
Bit rates: 1.76-62.5 kbps


FSK Modem:

Supports (G)FSK modulation
Bit rates: 0.6-300 kbps


Limitations:

No Long Range FHSS capabilities
More restricted LoRa bandwidth and spreading factor combinations
Limited to specific SF values for each bandwidth setting



SX1261/2 Digital Modem Bank:

LoRa® Modem:

Wider bandwidth selection: 7.8-500 kHz (10 different options)
Full Spreading Factor support: SF5-SF12 across most bandwidths
Extended bit rate range: 0.018-62.5 kbps
Better support for very low data rates


FSK Modem:

Supports (G)FSK modulation
Same bit rates: 0.6-300 kbps


Long Range FHSS Modem:

Dedicated hardware support for LR-FHSS modulation
Intra-packet frequency hopping capability
GMSK modulation support for LR-FHSS
Frequency hopping sequences for improved coexistence


Additional Features:

More configurable LoRa modulation parameters
Enhanced symbol processing capabilities
Better optimization for very low data rates and longer range

[JonW]

Finally.. No surprise here

JW: So are the LLC68 and SX1262 interchangeable?

AI Response

The LLCC68 and SX1262 are similar but not directly interchangeable without modifications. Here's why:
Hardware Compatibility Issues

RF Performance:

Both can deliver up to +22 dBm output power
Both use similar PA architecture with direct battery supply
Similar receiver sensitivity specifications


Pin Configuration:

Same physical 4x4mm QFN-24 package
Identical pin assignments and functions
Same power supply requirements



Functional Differences That Prevent Direct Swap

Supported Modulation Schemes:

SX1262: Supports LoRa, FSK, and Long Range FHSS
LLCC68: Supports only LoRa and FSK (no LR-FHSS)


LoRa Parameter Limitations:

SX1262: Supports SF5-SF12 and broader bandwidth options (7.8-500 kHz)
LLCC68: Limited to SF5-SF11 and fewer bandwidth options (125-500 kHz)


Register Map Differences:

Different register settings for PA configuration
SX1262 has additional registers for LR-FHSS
Default register values may differ


Firmware/Software Impact:

Driver code would need modifications to account for different register maps
SetPacketType() command requires different parameters
SetPaConfig() implementations differ



Replacement Considerations
If replacing one with the other, you would need to:

Modify your firmware to account for register differences
Adjust RF performance parameters for optimal operation
Update modulation parameter settings to match available options
Adapt any frequency hopping code (if using this feature with SX1262)

Bottom Line
While physically compatible and sharing many characteristics, the LLCC68 and SX1262 are not "drop-in" replacements for each other without software modifications. The LLCC68 appears to be a simplified derivative of the SX1262 with reduced functionality, particularly lacking the LR-FHSS capabilities and having more restricted LoRa parameter options.
For basic LoRa and FSK applications not using SF12 or specialized bandwidths, they could be made compatible with appropriate firmware adjustments, but it would require careful testing to ensure equivalent performance.

[top204]

Many thanks Jon and Dyanko.

I got your emails Dyanko and I will go through the changes you suggested, and again, many thanks for them.

The registers and op-codes seem to be the same for both device types, and the firmware is already using a bandwidth of 125KHz and an SF of 10, so I will try changing it. Also, thanks for spotting my anomaly in the SX_SetSyncWord procedure Dyanko.

For anyone using it... The SX_SetSyncWord procedure should be changed to:

Code Select Expand

Proc SX_SetSyncWord(pSync As Word)
    SX_WaitFor_NotBusy()                                                                ' Wait for the SX device to be ready
    SX_SPI_Start()                                                                      ' Start an SPI communication
    SPI_WriteByte(cSX_CMD_WRITE_REGISTER )                                              ' Send the Op-Code to the SX device to write to a register
    SPI_WriteByte(cSX_REG_SX_SYNC_WORD_MSB.Byte1)                                       ' Send the register address high byte
    SPI_WriteByte(cSX_REG_SX_SYNC_WORD_MSB.Byte0)                                       ' Send the register address low byte
    SPI_WriteByte(pSync.Byte1)                                                          ' Send the sync value high byte
    SX_SPI_End()                                                                        ' End an SPI communication
    SX_WaitFor_NotBusy()                                                                ' Wait for the SX device to be ready

    SX_SPI_Start()                                                                      ' Start an SPI communication
    SPI_WriteByte(cSX_CMD_WRITE_REGISTER )                                              ' Send the Op-Code to the SX device to write to a register
    SPI_WriteByte(cSX_REG_SX_SYNC_WORD_LSB.Byte1)                                       ' Send the register address high byte
    SPI_WriteByte(cSX_REG_SX_SYNC_WORD_LSB.Byte0)                                       ' Send the register address low byte
    SPI_WriteByte(pSync.Byte0)                                                          ' Send the sync value low byte
    SX_SPI_End()                                                                        ' End an SPI communication
    SX_WaitFor_NotBusy()                                                                ' Wait for the SX device to be ready
EndProc

That's the trouble with writing code when tired, I forgot to add the low byte register address code for the "cSX_REG_SX_SYNC_WORD_MSB". :-)

I've added two new procedures to to library code, to write and read registers, instead of having to manipulate the SPI pins all the time for register writes within separate procedures. This will save code space.

Now to try out some changes, and maybe add some $ifdefs for LLCC or SX in the library file.

I have just spotted that one of the boards is using the LLCC68 device, and the other is using an SX1262 device (my first viewed one that convinced me they were using SX1262 devices). I had to scrape off the paint from them to see the chip name? But both PCB are printed with the "LAMBDA62-1" name!

Bloody RF solutions!!! They have wasted weeks of my life because of their incompetence!

Where's that reviews site for them... LOL

I have attached modified source codes that have the change in the "SX126x.inc" file, and also a few new procedures to write and read registers. It is named: "SX1262_TX_RX_Code_Mk2_03-04-2025.zip"

Best regards
Les

[JonW]

I noticed that the paint on the photo was strategically placed to mask the part number

[JonW]

I have just spotted that one of the boards is using the LLCC68 device, and the other is using an SX1262 device (my first viewed one that convinced me they were using SX1262 devices). I had to scrape off the paint from them to see the chip name? But both PCB are printed with the "LAMBDA62-1" name!

Well at least you have one of each, one VERY small positive! 

[trastikata]

I find the older SX127x series better and easier to use than the newer SX126x chips.

Both are identical in performance, however the older SX127x have a special future that automatically calculates the frequency offset between the transmitter and receiver, which is very useful and the SX126x lack that option.

Two years ago you could have found the SX1278 for 25 cents and I built a stockpile of 200 pcs for future projects.  My point is I'd stay away from the SX126x series and stick to the older SX127x.

[JonW]

My point is I'd stay away from the SX126x series and stick to the older SX127x

IMHO, I don't agree, the older device may well be better, I completely agree from a personal perspective but when you have a commercial product, you are forced by the chip vendors to change, you must keep up with the evolution, and yeah its a moving target. The LLC68 is a market driven costdown. Sure you can buy 200, 2000, 2M, however eol will force you to change in the long term.

Les's comment of ' I may have to include the 126x and the llc ' is testament to the amount of times the market changes and to keep using the latest devices. He could replace the device, but he won't.  He'll make both work as its the only way forward.

In this case, RF Solutions have dropped the ball big time...A clear example of a company who doesn't test what they sell.

[trastikata]

IMHO, I don't agree, the older device may well be better, I completely agree from a personal perspective but when you have a commercial product, you are forced by the chip vendors to change...

Oh, I spoke from a personal perspective, of course market driven products have completely different definition for what is a "good chip".

I've just pointed out that for personal DIY projects, my tests showed SX1278 to outperform SX162 for long-range applications even though both are supposed to have the same performance. In no way I can claim that the tests I did are indication of anything or based on thorough methodological testing     

[JonW]

No disrespect T.  Just a different view Pal.