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> .

[morganrallen]

This is correct. When you set the radio to CAD mode, DIO0 is set to be raised on CadDone it's up to the user to determine what state to go into next. Typically after calling CAD you'd want to send if the channel is free or receive if you're expecting something. Else you'd probably just go back into CAD mode.

[artemen]

you see, I am working on an application which requires very low latency below 20ms (at some high sensitivity -121db), at the same time it should be hopping channels for each packet (at least 8). my current implementation works quite well on keeping all hops in sync when all packets are received intact, however when signal is degraded, onReceive won't fire so i miss the hop and have to either catch up skipping channels (additional lost packets) or by simply waiting for the full hop cycle 8x20ms + 35ms (return packet) in my case. using onCadDone is not useful as other similar packets on adjacent channels are expected and lora by design is quite wide band, additionally if going between onCadDone and on onReceive this much every lora module I've tried hangs after 8-10mins and i have to do LoRa.end(); Lora.begin(frq); to regain communication with sx127x. this is remedied by going to idle() *after *onCadDone before onReceive(), however it introduces delays, so the hop cycle can't be as tight negating the benefits of onCadDone as i am still losing time (about 4-5fps worth) comparable to just skipping ahead a hop. I am using onCrcError right now for a similar purpose, but this one is fired after the packet has been completely received so it is not as fast as a dedicated onCadDetected should be. but having DIO1 is pretty much essential to using built-in FHSS if someone desires. anyways its a "nice to have" feature, but certainly in many cases can be worked around.

…

On Mon, Feb 24, 2020 at 10:10 AM morganrallen ***@***.***> wrote: This is correct. When you set the radio to CAD mode, DIO0 is set to be raised on CadDone it's up to the user to determine what state to go into next. Typically after calling CAD you'd want to send if the channel is free or receive if you're expecting something. Else you'd probably just go back into CAD mode. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#341?email_source=notifications&email_token=AB3MVF3FEENLBEBU5S4PT33REQEPTA5CNFSM4K2BD6IKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMY6CBI#issuecomment-590471429>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3MVF65KOZ3WD6ZVE2DNQTREQEPTANCNFSM4K2BD6IA> .

-- A rtem Nikitin Travel Adviser Gabriel Travel 5111 College Oak Dr. Ste G Sacramento CA 95841 888.505.4196 toll free 916.348.3500 fax Like us on Facebook! <http://www.facebook.com/GabrielTravel> and receive $20 off next purchase <http://www.facebook.com/GabrielTravel>

[Erik84750]

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.

Continuing on IoTThinks discussion regarding the use of DIO0 to detect an incoming packet (when using onReceive): where in LoRa.cpp does this RegIrqFlags(0x12) bit 6 gets cleared (ie. "writing a 1 clears the IRQ")?

[IoTThinks]

@Erik84750 Then you need to poll the regIrqFlag for events.

[Erik84750]

@Erik84750 Then you need to poll the regIrqFlag for events.

Strange because the DIO0 does get reset after 50usec; so I am wondering where in the LoRa.cpp this is accomplished?

[IoTThinks]

No idea.
(1) After the RXDone, the library will set the chip to listen again.

I wonder if the chip itself automatically resets the DIO0 back to LOW state or due to (1).

[morganrallen]

Yes, writing the flags back clears them.
https://github.com/sandeepmistry/arduino-LoRa/blob/master/src/LoRa.cpp#L696-L697

[EMendesS]

Is there anything missed when not connecting any of the DIOx pins to my microcontroller? I meant, in my project I have no pins available to connect to DIOx, which I'm leaving all six unconnected. Despite my software will suffer, am I missing something by not connecting them all, like lorawan stuff or any possible feature not accessible through SPI?