[SX1262]: Chip not correctly recognized

[GUVWAF]

I'm using the latest commit 00998b5 with Meshtastic firmware 2.0.22. It seems the SX126x::findChip() function is recognizing my module as an SX1261, although according to the datasheet, it is a SX1262 using nRF52840. Here is the full SPI transcript when starting up:

CMD 80
DATW 0 AA

CMD 80
DATW 0 A2

CMD C0
DATR 0 22 0 22

CMD 1D 3 20
DATR 0 A2 0 53 0 58 0 31 0 32 0 36 0 31 0 20 0 56 0 32 0 44 0 20 0 32 0 44 0 30 0 32 0 0

SX126x not found! (1 of 10 tries) RADIOLIB_SX126X_REG_VERSION_STRING:
0000320 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00 | SX1261 V2D 2D02.

This then repeats 10 times, after it prints “No SX126x found!”, and the result of function begin is RADIOLIB_ERR_CHIP_NOT_FOUND.

As expected, the module cannot be correctly operated after this.

[jgromes]

I also have a module that the manufacturer (Dorji RF) claims is SX1262. However, the device reports as SX1261. Tomorrow I will remove the shield and check, but it seems to me that the silicon should be trusted in case of discrepancy. Does it work when you change your code to SX1261?

[GUVWAF]

Yes, changing to SX1261 works. Indeed, I would expect the chip is not lying.
It would be interesting though if it is really a SX1261, as it was set to 22dBm output power, while the SX1261 can only do 15dBm.

[jgromes]

I asked a question about the device ID registers on the LoRa dev forum (https://forum.lora-developers.semtech.com/t/sx126x-device-id/1508), hopefully someone from Semtech can clarify. I'm not sure if the device would actively reject an out-of-bound output power request. RadioLib only performs range checking based on information from the user (the wireless module type).

[GUVWAF]

Thanks. I am curious to see whether you get an answer on it, as I found a while ago the answer was as follows: https://forum.lora-developers.semtech.com/t/detect-transceiver-version/1377

[Rustie0125]

@GUVWAF @jgromes Im still at it. I have niceRF modules lying around that is sx1262, I wired this up and found the following and though it might be helpful.

When I setup one of the simple examples like this

Cannot find the chip!

Then change the setup to

18:43:35.736 -> Found SX126x: RADIOLIB_SX126X_REG_VERSION_STRING: 18:43:35.799 -> 0000320 53 58 31 32 36 31 20 56 32 44 20 32 44 30 32 00 | SX1261 V2D 2D02.

18:43:37.946 -> success! 18:43:37.946 -> [SX1262] Scanning channel for LoRa transmission ... CMD 11

This chip has been bought and used as a 915mhz device.. so why would it report sx1261 ?

[jgromes]

@Rustie0125 interesting - maybe all SX1262 devices report as SX1261? That would be very funny ...

I had a few Dorji DRF1262 devices without shield, will try to find them and see if the register description matches the transceiver package markings.

[Rustie0125]

I have some RIP nicerf modules I can open and see.. but beyond this point I have a couple of concerns.

when you compile with 1262 as the intended target. Looking at the output it seems like the library does attempt talking to sx1261 but fails.

Yet when setting up as 1261 by defualt it succeeds in finding the device ?

Does the library not attempt 1261,62,68 anyway and should have worked?

I don't know I'm asking, I'm again trying to attempt tinygs. And they have very fixed(outdated) board profiles that either specific 127x or 126x but not down to 61 or 62. And as a result I keep getting -2 error as I suspect the system can't find the chip and reports spi error

[jgromes]

@Rustie0125 RadioLib does not perform any autodetection, it just checks the module you specified matches the hardware. This is also a good test whether the SPI communication actually works. So if you set in your code the module to be SX1262, but the SPI register says SX1268, it will return the -2 error code.

[Rustie0125]

I see, well in light of what is happening here. Is a simple chip identifier example or method not viable option ? Just run through basic commands and see which one responds accordingly? If I'm new to this and module says 1262 on the tin I would not think to try 1261 or 1268 manually.

[jgromes]

@Rustie0125 the chip type checking was added quite recently, and is still unreleased yet. I would rather wait to get feedback from Semtech about this (https://forum.lora-developers.semtech.com/t/sx126x-device-id/1508) before releasing this change. If need be, the method can be adapted to not differentiate SX1261 and SX1262. Maybe the version register will always be SX1261 for these two and its a known issue (at least to Semtech).

[jgromes]

Found a Dorji DRF1262 with removed shield, and sure enough, it reports as SX1261. However, the IC package seems to disagree:

So it seems like the device string can only be used to distinguish SX1268 and SX1261/2. Although since the only difference between SX1261 and SX1262 is in the PA, I would guess there's some logic to that ...

For now, I set SX1262 to accept the string "SX1261" as the correct option, we'll see if we have the opposite problem in the future (i.e., SX1261 devices reporting as SX1262).

[Velocet]

@jgromes i found this quote and remembered this thread:
The same driver library can operate for both SX1272 and SX1276. Upon starting, the driver auto-detects whether SX1272 or SX1276 transceiver chip is connected by attempting to change the LowFrequencyModeOn bit in RegOpMode register. If this bit can be changed, then the radio device is SX1276. This bit is not implemented in SX1272. A few of the radio driver functions select behavior based on this detection. The differences between these two devices is small, from a software perspective.
(via (chat_sx127x)[https://os.mbed.com/users/dudmuck/code/chat_sx127x/])

So maybe this could be used as a fallback or to verify the board?

[jgromes]

@Velocet That's about distinguishing SX1272/73 and SX1276/77/78/79. Also, it's needlessly complicated. SX1272 and SX1276 have a different chip ID register value, so distinguishing those is very straightforward (it's been in RadioLib since day one). Howeer, telling apart e.g. SX1276 and SX1278 is similarly impossible as telling apart SX1261 and SX1262.

[m4mans]

Same issue I'm facing, my llcc68 modules return "SX1261 V2D 2D02" instead of "LLCC68 V2H 2H02". I can make it work when I use the definition of SX262/Sx1261 while defining the board but LLCC68 is different chip.