right framework for interrupt-receive periodcally and send ack occasionally

[circlefangr]

Dear fellows,
I am using radionlib 7.7 and arduino 2.3.9, and I have some boards like lilygo t3-s3 and t3-c6 (esp32s3/esp32c6 with sx1262), the t3-s3 is sending packets 20hz and it's working very good. Another c6/s3 try to receive these packets and send ACK in some conditions. If i don't enable ACK, then everything is fine, but if I enable ACK I have some problems (more received packets than expected). Following is my questions,

1. should I use setDio1Action(setFlag) Or radio.setPacketReceivedAction(setRxFlag); radio.setPacketSentAction(setTxFlag); ? If I use the latter, I found only setRxFlag will be triggered. i am not sure why. Even both Irqs are on DIO1 pin, there is no way to differentiate? pos edge for both Irqs?
2. it seems startReceive will be working continuously unless finishReceive/standby/sleep called? I think i should only focus on startReceive/finishReceive, startTransmit/finishTransmit pairs, no need to call standby anymore because the finishXXX will call standby internally. My framework is like this, setDio1Action and startReceive in setup, then in loop,

void loop() {
  if (operationDone) {
    operationDone = false;
    
    if (isTransmitting) {
      radio.finishTransmit();  //terminate TX_MODE?
      isTransmitting = false;
      radio.startReceive(); //now in RX_MODE?
    } else {    
      String receivedStr;
      int state = radio.readData(receivedStr);
      radio.finishReceive(); // not sure why here, it seems readData will also clear Irq. why can't put this just before startTransmit so we don't need else branch for if (some condition met)? 
      
      if (send ACK every 8 packets) {
        // Prepare to transmit
        isTransmitting = true;
        //radio.finishReceive(); //
        radio.startTransmit("Hello World!"); //now in TX_MODE?
      } //no more else if finishReceive can be put just before startTransmit instead of after readData, because it's still in RX_MODE
    }
  }
}

Why I am having one more reduplicated packets every 8 packets, not sure by myself or by master.

I have been stuck in this for a long time, and I really appreciate any feedbacks.

Thanks in advance
Circle

[jgromes]

To answer those questions:

1. In the specific case of SX126x, setPacketReceivedAction and setPacketSentAction doe xactly the same thing as setDio1Action. That's because SX126x treats all interrupts the same way: any interrupt is shown as rising edge on DIO1. This is not the case in general for all radio modules supported here, hence the distinction. To keep your code readable, setDio1Action is the most natural choice since you want to capture all interrupts - those cause by packet being received and those cause by packet being sent.
2. You are correct that startReceive is called without arguments, it will continue receiving (and triggering interrupts as packets arrive) until it is commanded to change its mode. It shouldn't be necessary to explicitly call finishReceive, since startTransmit will ensure the correct mode, will clear IRQ flags etc.

Broadly the code looks OK, it seems somewhat based on the SX126x ping pong example which is a good place to start. When debugging, I would recommed to start with lowering the transmission rate since 20 Hz is quite fast (and if the issue is related to switching between Rx and Tx, the transmission rate or the number packets between ACKs should have no effect).

[circlefangr]

Dear jgromes,
That's so nice, it's really a perfect answer that explains everything. I will try ASAP and post result .
Thanks again.

[circlefangr]

Dear jgromes,
It's working perfectly now.
I have one more question, I want to put this logic to freeRTOS task, and want to save power if possible, do you have any advice for me?

Again thanks so much for your time, have a nicy day

[jgromes]

You should be able to move the contents of loop into your FreeRTOS task, the main difference will be with the signalling - instead of checking the operationDone every single loop (which would make the task always ready to run and never block, starving all other lower-priority tasks), I would use something like xTaskNotifyFromISR to send a notification from the interrupt, and then in the task itself use ulTaskNotifyTake with infinite timeout so that the task is blocked until an interrupt arrives.

As for the power saving strategy, that will be pretty much based on whatever hardware you ahve, which parts of the ESP32 can you put to sleep etc. so it is not really possible to give a generic answer.

[circlefangr]

Thanks jgromes, that's very clear about the task and I totally understand now.
As for the power saving, it's only for the slave node(esp32c6, lilygo T3-C6). when receive the broadcasting command it will check if (cmd.seq % 16 == this_slave_id) and this slave will reply (about 1.25hz). It's acceptable that the command data packet is lost or delayed like no more than 5ms, but it's not acceptable that several consecutive packets are lost. I can't use sleep mode because other peripherals are still working. And since it's ok even several reply packets are lost, so right now my solution is just use a low output power (like 5) for the slave, and i don't use any duty receive APIs because I am afraid the slave will miss command packets is some situations. Anyway it seems the receive current is only like 5ma, and it's okay for me. Right now I am using a multimeter to test the current and it's staying like 20ma (most because cpu is running at 10Mhz). I am going to use an oscilloscope to test peak transmit current next week. Do you have any advices for me?
Thanks again for your great work and time!

[circlefangr]

Thanks jgromes anyway. when transmitting with output power =5, SX1262 only cause an extra 20ma current which last for like 20ms, which seems the best for now. Thanks again and this issue may be closed.