Proton BASIC Community

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...

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

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. :-)

Quote from: top204 on Apr 03, 2025, 02:07 PMI'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)

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

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.

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:

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

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

QuoteI 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! 

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.

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.

Quote from: JonW on Apr 03, 2025, 07:22 PMIMHO, 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     

No disrespect T.  Just a different view Pal.

Well the four modules arrived and they are all 1262 on the IC, so not sure why you have a LLC68? I need to update my 18F dev to 26k40 and get building.

I had no problems with the SX1278 devices, and actually created a library for them that took over an unused USART's syntax (USART4), and diverted it to the SX1278 TX and RX routines, so the compiler's syntax was like transmitting and receiving serial data, and it worked very well.

However, the SX1278 devices do not have a deep sleep mode, "that I am aware of", and their standby current is too high.

Below is the code listing for one of the test programs I wrote for the SX1278 library:

'
'   /\\\\\\\\\
'  /\\\///////\\\
'  \/\\\     \/\\\                                                 /\\\          /\\\
'   \/\\\\\\\\\\\/        /\\\\\     /\\\\\\\\\\     /\\\\\\\\   /\\\\\\\\\\\  /\\\\\\\\\\\  /\\\\\\\\\
'    \/\\\//////\\\      /\\\///\\\  \/\\\//////    /\\\/////\\\ \////\\\////  \////\\\////  \////////\\\
'     \/\\\    \//\\\    /\\\  \//\\\ \/\\\\\\\\\\  /\\\\\\\\\\\     \/\\\         \/\\\        /\\\\\\\\\\
'      \/\\\     \//\\\  \//\\\  /\\\  \////////\\\ \//\\///////      \/\\\ /\\     \/\\\ /\\   /\\\/////\\\
'       \/\\\      \//\\\  \///\\\\\/    /\\\\\\\\\\  \//\\\\\\\\\\    \//\\\\\      \//\\\\\   \//\\\\\\\\/\\
'        \///        \///     \/////     \//////////    \//////////      \/////        \/////     \////////\//
'                                  Let's find out together what makes a PIC Tick!
'
' SX1278 Base test. The unit that this firmware sits on, is left in place.
' It receives a signal from the transmitter and send beck what was received
' When a transmission occurs, both LEDs with flash briefly
'
' Written for the Positron8 compiler by Les Johnson
'
    Device = 18F26K40
    Declare Xtal = 64
    Declare Auto_Variable_Bank_Cross = On
'
' Setup USART1 for debugging
'
    Declare Hserial_Baud = 9600
    Declare HRSOut1_Pin  = PORTC.6
'
' Setup the pins to connect to the SX1278 device
'
$define SX_SCK_Pin  PORTC.3                                     ' Connects to the SX1278's SCK pin
$define SX_MISO_Pin PORTC.4                                     ' Connects to the SX1278's MISO pin
$define SX_MOSI_Pin PORTC.5                                     ' Connects to the SX1278's MOSI pin
$define SX_NSS_Pin  PORTB.3                                     ' Connects to the SX1278's NSS pin (Acts as the CS line for the SPI interface)
$define SX_DIO0_Pin PORTB.2                                     ' Connects to the SX1278's DIO0 pin (Used as an IRQ for received data)
$define SX_RST_Pin  PORTB.1                                     ' Connects to the SX1278's RST pin

$define LED_Red_Pin PORTA.3
$define LED_Green_Pin PORTA.1

    Include "SX1278.inc"                                        ' Load the SX1278 library routines into the program
'
' Create some variables for the test
'
    Dim Global_RawString As String * 30 Heap

'----------------------------------------------------------------------------------
' The main program starts here
' Receive data then re-tranmsit it
'
Main:
    LEDs_On()
    DelayMS 300
    LEDs_Off()
    HRSOut1Ln "Transmitter"

    SX_fFrequency = 433.0                               ' Set the frequency to use
    SX_Setup()                                          ' Setup the SX1278 module
TryAgain:
    Do
        SX_SetFor_RX()                                  ' Set the SX1278 to receive mode
        SX_SerIn 5000, TimedOut, [Global_RawString]     ' Receive data from the SX1278 module
        DelayMS 200                                     ' This delay needed between RX and TX setups (for some reason)

        SX_SetFor_TX()                                  ' Set the SX1278 to transmit mode
        SX_OutLn Global_RawString                       ' Transmit what was received

        LEDs_On()                                       ' \
        DelayMS 100                                     ' | Toggle both LEDs to signal that something has been transmitted
        LEDs_Off()                                      ' |
        DelayMS 100                                     ' /
    Loop
'
' Jump here if a timeout occurs while waiting for data
'
TimedOut:
    HRSOutLn "Timed Out"
    DelayMS 100
    GoTo TryAgain

I'll tidy the demo code listings up and the SX1278 library code listing, and the longer range SX1278 packet library code listing and upload it to the forum when I get the chance.

Quote from: top204 on Apr 04, 2025, 09:18 AMHowever, the SX1278 devices do not have a deep sleep mode, "that I am aware of", and their standby current is too high.

What they call "deep sleep mode" in SX1262 is OFF MODE with no register retention and 160 nA current - equivalent of POR, where as in SX1278 it is simply "sleep mode" with 200 nA current. Standby current is indeed 1.6mA vs 0.8mA

P.s. I've sent you an e-mail with some new code to test.

Thanks Dyanko, I'll take a look and try the code out ASAP.

The Sleep mode on the SX126x devices was what I chose them for, because they go into very low current, and using their internal timer, they wake up every x seconds or milliseconds depending on the settings in a register, and look for a receive, then go back to sleep. And on the E220 USART units that use an SX126x or LLCC68 device, this makes batteries last a very, very long time and still have full long range communications.

I never came across this on the SX127x devices.

I created a library for the E220 USART units, and they work excellently, but they are more expensive because they have a microcontroller on-board, so I am trying to do the same thing, but using an inexpensive 18FxxQxx or 18FxxK40, 8-bit microcontroller that is also part of the application it is controlling.

Does the SX1262 have a CW test mode?

Quote from: JonW on Apr 04, 2025, 03:36 PMDoes the SX1262 have a CW test mode?

Yes it has Jon, search the datasheet for SetTxContinuousWave

From this page

https://www.waveshare.com/wiki/Core1262-868M

You can download the sample code Pico-LoRa-SX1262-868M_Code.zip

The file is too large for an attachment.
Maybe it will help.