Setting additional IRQ flags for SX126x/SX128x

[GUVWAF]

Lately I’ve been looking into the lower layers of Meshtastic, whose firmware roughly works like this. Before transmitting a packet, the device first tries to determine whether it is actively receiving. If not, it performs channel activity detection. Only when the channel is free, it starts transmitting (CSMA/CA).
The former condition works well for SX127x modules by checking the modem status whether a valid header was received. For SX126x and SX128x modules, the same check is implemented, but then using getIrqStatus(). I found out that since the IRQ_HEADER_VALID flag is not mapped to the IRQ in startReceiveCommon(), this actually doesn’t work. Although the CAD procedure afterwards also detects the data part of the packet, it fails to receive it because the module went into standby mode while receiving. This has been mentioned before in #67.

I tested that simply adding RADIOLIB_SX126X_IRQ_HEADER_VALID to the IRQ mask works to check whether we are actively receiving and since it will then not perform CAD, the packet can be received successfully.
Do you think it would be good to expose an option for setting additional IRQ flags to the receive methods? Or maybe even a configuration, similar to setDIOMapping()?. I’m willing to create a PR for this, but would first like to know your opinion on this. Maybe this is not the right way to do it, which I would then also like to hear.

[jgromes]

I'm wondering if it wouldn't be easier to just add the IRQ_HEADER_VALID flag to startReceiveCommon(). If it doesn't interfere with existing high-level functionality (namely blocking and interrupt receive), then there's proabably no need to manually add the flag via some configuration method.

[jgromes]

@GUVWAF most likely you are trying to use SX126x without TCXO. For those, the TCXO voltage must be set to 0.

[GUVWAF]

@jgromes It has a TCXO (it's a RAK4361). I think the default tcxoVoltage was accidentally changed in bd25838 (and fixed again in 00998b5), but it was already set to 1.6 in 2b2dc29.
Can it be related to changes in the SPI functions?

[jgromes]

I don't think it has anything to do with the low-levle SPI changes, as I tested them on both TCXO and XTAL module. I suggest enabling debug + verbose and taking a look at what exactly is failing.

[GUVWAF]

The SPI call for standby gave me:

CMD 80
DATW 0 AA

While normally it returns:

CMD 80
DATW 0 D2

I found that if I comment out the call to SX126x::findChip() in SX126x::begin(), it runs fine.
Edit: this thus means it could not find the correct chip, but I cannot yet see those logs just after startup. The correct SX1262 module is used, I will double-check the wiring later.

[jgromes]

I was not able to reproduce this problem. However, as it seems unrelated to the original point of this discussion, please post this as a new issue, including the full verbose SPI transcript.