SX1262 irq timeout

[mfvmx]

I am using IRQ code very similar to the example and was hoping to use the IRQ timeout value trigger an IRQ event on DIO. Does this only work in certains mode or am I implementing it incorrectly? It appears the irq register for the RX timeout is set by default in the library.
I changed:
radio.startReceive();
To this expect a 2second timeout but I get nothing no DIO events happen at all, with the sender turned off of course.
radio.startReceive(31250000);

[mfvmx]

[jgromes]

As described in the datasheet (of which you have some old version, judging by the screenshot), timeout in SetRx is a 24-bit number, so the maximum value that can be entered is 0xFFFFFF. The number you're providing (31250000) is 0x01DCD650 in hex, so throwing away the most significant byte, that would be 0xDCD650. Multiply by 15.625 us and you get a timeout of roughly 226 seconds. So if you saw no timeout prior to 226 seconds elapsing, it's possible everything is working fine - albeit not the way you want it to.

To actually set a 2 second timeout, the argument for setRx has to be 128000, or 0x01F400 (2 / 15.625e-6 = 128000).

[jgromes]

@mfvmx I checked out the code and realized this was actually not implemented - timeout interrupt was not enabled on DIO1.

It's fixed now, and quick check with the value 0x01F400 does generate an interrupt on DIO1. However, you will have to use the getIrqStatus() method to find out whether the interrupt was caused by packet reception, or a timeout.

[mfvmx]

Thanks @jgromes it's working now, but I have two more issues.

1. I don't exactly need to know the IRQ but if I check I just get 0x00.

        Serial.println("IRQ startRX again: ");
        uint16_t irq = radio.getIrqStatus();
        Serial.print("IRQ Status: "); Serial.println(irq, HEX);

11:27:01.251 -> IRQ opdone: <-IRQ flag Checked
11:27:01.251 -> IRQ Status2: 2 <-getIrqStatus(), HEX
11:27:01.251 -> IRQ startRX again <-radio.standby() then radio.startReceive(128000) called
11:27:01.287 -> IRQ opdone:
11:27:01.287 -> IRQ Status2: 2
11:27:01.287 -> IRQ startRX again:
11:27:01.320 -> IRQ opdone:
11:27:01.320 -> IRQ Status2: 2
11:27:01.320 -> IRQ startRX again: 
11:27:03.894 -> IRQ opdone: <- Turned off other TX radio so this is a Timeout IRQ
11:27:03.894 -> IRQ Status2: 0
11:27:03.894 -> IRQ startRX again:
11:27:06.450 -> IRQ opdone:
11:27:06.450 -> IRQ Status2: 0
11:27:06.450 -> IRQ startRX again:
11:27:09.022 -> IRQ opdone:
11:27:09.022 -> IRQ Status2: 0
11:27:09.022 -> IRQ startRX again:

[mfvmx]

2. After an IRQ timeout event if I just call radio.startReceive(128000) there is no more activity and no more timeouts. But ,I did get it to work correctly by calling standby() before the new startReceive as shown:

        Serial.print("IRQ startRX again: ");
        uint16_t irq = radio.getIrqStatus();
        Serial.print("IRQ Status: "); Serial.println(irq, HEX);
        radio.standby();
        radio.startReceive(128000);

[jgromes]

@mfvmx

I don't exactly need to know the IRQ but if I check I just get 0x00.

I think you do need to check, because when you call startReceive(128000); and get an interrupt, you don't know what generated it - packet reception, or Rx timeout. Regardless, getting 0 is a bit strange, you should be getting 0x200, which is the timeout interrupt flag. Although there are some methods (startReceive() and clearData() in your case) that do IRQ clearing internally, so if you call one of them prior to getIrq, you will get 0.

After an IRQ timeout event if I just call radio.startReceive(128000) there is no more activity and no more timeouts

To be honest, I'm not entirely sure which mode does the radio enter on Rx timeout, there's a couple standby modes (STANDBY_RC being the one that is entered when you call standby()).

[mfvmx]

Although there are some methods (startReceive() and clearData() in your case) that do IRQ clearing internally, so if you call one of them prior to getIrq, you will get 0.

As soon as the IRQ is called I am using getirq I am not clearing or calling anything else.

[jgromes]

Had a little bit of time to dig into this, it seems like there's some deeper issue with Rx timeouts - any time the device timeouts in Rx mode, the next command sent to it will return an SPI timeout error code in the status field.

This is why it didn't work for you without adding an extra call to standby():

Without standby prior to the next startReceive:

19:59:30.415 -> CMD	82	
19:59:30.415 -> DATW	1	A2	F4	A2	0	A2	
19:59:30.415 -> 
19:59:30.415 -> success!
19:59:32.357 -> CMD	8	
19:59:32.357 -> DATW	2	A6	62	C1	2	0	2	D9	0	7	0	C5	0	8	0	E6	
                                 ^ SPI command timeout, absolute bonkers from here on out, the device doesn't respond anymore

With one call to standby:

20:01:29.447 -> CMD	82	
20:01:29.447 -> DATW	1	A2	F4	A2	0	A2	
20:01:29.493 -> 
20:01:29.493 -> success!
20:01:31.382 -> CMD	80	
20:01:31.382 -> DATW	0	A6	
                                 ^ SPI command timeout
20:01:31.382 -> 
20:01:31.382 -> CMD	8	
20:01:31.382 -> DATW	2	A2	62	A2	2	A2	2	A2	0	A2	0	A2	0	A2	0	A2	
                                 ^ SPI command OK, reasonable responses now

With two calls to standby:

20:03:04.735 -> CMD	82	
20:03:04.735 -> DATW	1	A2	F4	A2	0	A2	
20:03:04.735 -> 
20:03:04.735 -> success!
20:03:06.673 -> CMD	80	
20:03:06.673 -> DATW	0	A6	
                                 ^ SPI command timeout on the first call
20:03:06.673 -> 
20:03:06.673 -> CMD	80	
20:03:06.673 -> DATW	0	A2	
                                 ^ SPI command OK on the second call
20:03:06.673 -> 
20:03:06.673 -> CMD	8	
20:03:06.720 -> DATW	2	A2	62	A2	2	A2	2	A2	0	A2	0	A2	0	A2	0	A2	

This is also the reason why getIrqStatus was return 0 for you - it was returning that timeout error as well. I added a call to standby just before getIrqStatus and sure enough, it now returns 0x200. which is the expected timeout flag:

20:04:33.923 -> CMD	82	
20:04:33.970 -> DATW	1	A2	F4	A2	0	A2	
20:04:33.970 -> 
20:04:35.864 -> CMD	80	
20:04:35.864 -> DATW	0	A6	
                                 ^ SPI command timeout on the first call
20:04:35.864 -> 
20:04:35.864 -> CMD	12	
20:04:35.909 -> DATR	0	A2	0	2	0	0	
                                 ^ SPI command OK on the second call
20:04:35.909 -> 
20:04:35.909 -> IRQ Status: 200

I guess the real question now is why is the SX126x unable to process the first command after Rx timeout - I was not able to find anything in the datasheet, unsurprisingly. Given the seemingly erratic nature of output in the first example, it seems lie the device is in some weird state, and kicking it back to standby "fixes" it.

[S5NC]

any time the device timeouts in Rx mode, the next command sent to it will return an SPI timeout error code in the status field

I guess the real question now is why is the SX126x unable to process the first command after Rx timeout

See note 2, it appears the way the timeout feature works on RX or TX is by using this internal watchdog.
I spent a while on this same problem, trying to figure out why it was giving me a command timeout error. Perhaps the wording command timeout is a little misleading, although the SX126x could also be using the watchdog to check that regular commands execute properly...

15.3 and workaround 15.3.2 may be related if @mfvmx was using implicit header