Enquiry on DIO mapping LoRa mode

[IoTThinks]

Hi all,
It's not a bug but my enquiry on DIO mapping LoRa mode.

On page 46 of the Semtech data sheet, it says the DIOx Mapping 00, 01, 10 and 11 to DIO0.
What do they mean?

In this LoRa library, I don't see we use them.
We only check if the DIO0 is rising and check RegIrgFlags if they are rxDone, txDone...

The masking is according to page 111.

=> So my question is what does the page 46 mean about DIOx Mapping 00, 01, 10 and 11?
Thanks a lot.

[morganrallen]

Looks like you're slightly mixing up two things here.
The register for DIOx Mapping is to set what the DIO pins are doing. For the example of DIO0, setting REG_DIO_MAPPING_1 to 00 will cause DIO0 to be raised when data is receive. Likewise setting it to 01 to cause DIO0 to be raise then TX is done.

The second table you've shown is what you check to see what interrupt has occurred. Sometimes this doesn't matter, because you should know what start you're in, like for RX but in the case of CAD, multiple interrupt flags can be set at the same time.

In this LoRa library, I don't see we use them.

https://github.com/sandeepmistry/arduino-LoRa/blob/master/src/LoRa.cpp#L183
and
https://github.com/sandeepmistry/arduino-LoRa/blob/master/src/LoRa.cpp#L391

These setup the reason DIO0 will be raised. Hopefully this helps you understand what's going on.

[IoTThinks]

Thanks for your reply.
Let me digest your answer this afternoon :)

[morganrallen]

Hopefully I didn't overly complicated it.

Simply put,

• REG_DIO_MAPPING_1 sets what the DIO pins do, according to page table 18
• REG_IRQ_FLAGS hold the state of what happened after one of the DIO pins is raised.

[IoTThinks]

Now I understand.
From what I see in https://github.com/sandeepmistry/arduino-LoRa/blob/master/src/LoRa.cpp#L391
We need to proactive set the chip status when we are done with RX and TX at user code level (aka this library).

I always have a thinking that Semtech should do that for us?

Hopefully I didn't overly complicated it.

Simply put,

• REG_DIO_MAPPING_1 sets what the DIO pins do, according to page table 18
• REG_IRQ_FLAGS hold the state of what happened after one of the DIO pins is raised.

[morganrallen]

Not quite. It's not setting the chip status, but telling the chip to alert us (via DIO0) when one of those things is complete.

[IoTThinks]

Not quite. It's not setting the chip status, but telling the chip to alert us (via DIO0) when one of those things is complete.

1. By default, the chip should alert us via DIO0 (and DIO1-5) when those things are completed even if we do not tell them to do so, right?
   As it is already written in the specs.

2. I feel that Semtech needs the user code level to tell them when we already finish receiving the data. It makes sense to me.
   But why we need to tell Semtech when the TX is completed. Semtech chip should know better than user code.
   => That lead me to confusion.

[morganrallen]

1. The default is 00, so yes, it will default to those in the first row.

2. I think you still misunderstanding, by setting the DIO_MAPPING reg you are not telling it TX is complete, you telling it to tell you when it is complete. Look again at https://github.com/sandeepmistry/arduino-LoRa/blob/master/src/LoRa.cpp#L183, we change the DIO_MAPPING before we set the radio to TX mode.

[IoTThinks]

Ok, well-understood now.
Thanks a lot for your effort. 👯‍♂️

[artemen]

I think it would be useful to add at least one more DIO interrupt callback for DIO2, but this would need some way to keep track of which DIO mapping bits are set.

[IoTThinks]

I think it would be useful to add at least one more DIO interrupt callback for DIO2, but this would need some way to keep track of which DIO mapping bits are set.

Why you want callback to DIO2? I don't seem to know or need to use FhssChangeChannel btw.
Most of the China made LoRa board doesnt seem to connect to DIO2.

I think I may need CadDetected in DIO1 but my board also doesn't connect to DIO1 yet. :/

[artemen]

many people use rfm, ebyte and ai thinker modules with own choice of mcu, so have the liberty to choose which IO pins to connect. For example i could really use onCadDetected in my project which cannot be mapped to DIO1

…

On Sun, Feb 23, 2020, 22:52 IoTThinks.com ***@***.***> wrote: I think it would be useful to add at least one more DIO interrupt callback for DIO2, but this would need some way to keep track of which DIO mapping bits are set. Why you want callback to DIO2? I don't seem to know or need to use FhssChangeChannel btw. Most of the China made LoRa board doesnt seem to connect to DIO2 btw. I think I may need CadDetected in DIO1 but my board also doesn't connect to DIO1 yet. :/ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#341?email_source=notifications&email_token=AB3MVF7L3C5YPNQYYRCR7MDRENVCRA5CNFSM4K2BD6IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWY3LI#issuecomment-590187949>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3MVF27SP6MALLGX7TIQWDRENVCRANCNFSM4K2BD6IA> .

[morganrallen]

I think it would be useful to add at least one more DIO interrupt callback for DIO2, but this would need some way to keep track of which DIO mapping bits are set.

You don't really need to track the DIO mapping state, REG_IRQ_FLAG will have the current state of what has happened since the last time it was cleared, so you can just figure it out from there.

I think I may need CadDetected in DIO1 but my board also doesn't connect to DIO1 yet. :/

Fun fact! CADDetect can be performed with just DIO0.
From datasheet page 44

Once the calculation is finished the modem generates the CadDone interrupt. If the correlation was successful, CadDetected is generated simultaneously.

What this means is, CadDone get triggered on DIO0 you can also check the IRQ flag if CadDetect was raised. This can be seen in PR #334

_onCadDone((irqFlags & IRQ_CAD_DETECTED_MASK) != 0);

[artemen]

Well, thanks for the suggestion, however, maybe i am missing something here, but doesn't that also means that when dio0 is set to onCadDone, onReceive is not fired?

…

On Mon, Feb 24, 2020, 09:22 morganrallen ***@***.***> wrote: I think it would be useful to add at least one more DIO interrupt callback for DIO2, but this would need some way to keep track of which DIO mapping bits are set. You don't *really* need to track the DIO mapping state, REG_IRQ_FLAG will have the current state of what has happened since the last time it was cleared, so you can just figure it out from there. I think I may need CadDetected in DIO1 but my board also doesn't connect to DIO1 yet. :/ Fun fact! CADDetect can be performed with just DIO0. From datasheet page 44 Once the calculation is finished the modem generates the CadDone interrupt. If the correlation was successful, CadDetected is generated simultaneously. What this means is, CadDone get triggered on DIO0 you can also check the IRQ flag if CadDetect was raised. This can be seen in PR #334 <#334> _onCadDone((irqFlags & IRQ_CAD_DETECTED_MASK) != 0); — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#341?email_source=notifications&email_token=AB3MVF42I6DTEMSZPYG3GZTREP66NA5CNFSM4K2BD6IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMYYQPQ#issuecomment-590448702>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3MVFZUSMV5ZJA7GIN3X3TREP66NANCNFSM4K2BD6IA> .