search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.65k stars 2.97k forks source link

LoRaPHY configures different iq_inverted between tx and rx in LoRa mode #15097

Open davidalo opened 2 years ago

davidalo commented 2 years ago

Description of defect

I am trying to make a LoRaWAN network using Mbed OS stack. I have noticed some differences between LoRaPHY tx and rx:

In FSK mode rx_config configures iq_inverted as false, while tx_config configures it as false. OK, it's the same for both sides.

But In LoRa rx_config configures iq_inverted as true, while tx_config configures it as false.

I cannot make a communication with this configuration, but if change the iq_inverted parameters, it works as expected.

Why in LoRa modulation iq_inverted is changed from tx to rx? Could it be a bug?

I have also posted this issue in Mbed OS Forum but I saw that LoRaWAN issues usually don't receive responses.

Target(s) affected by this defect ?

All LoRa devices.

Toolchain(s) (name and version) displaying this defect ?

All Toolchains should be affected

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.15.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli + pyocd

How is this defect reproduced ?

n/a

mbedmain commented 2 years ago

@davidalo thank you for raising this issue.Please take a look at the following comments:

How can we reproduce your issue?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information.

maxgerhardt commented 2 years ago

But In LoRa rx_config configures iq_inverted as true, while tx_config configures it as false.

..Yes, this is expected and correct. I/Q inversion settings are reverse when transmissing and receiving.

Take note the code you've pointed to is the LoRaWAN stack, not pure LoRa.

A LoRaWAN gateway is transmitting downlink with I/Q inversion on, the receiver needs to have the same I/Q inversion setting (true). When a LoRaWAN node sends an uplink, it does so with no I/Q inversion, and the gateway listen with I/Q inversion off.

See e.g. https://www.thethingsnetwork.org/forum/t/what-prevents-gateways-from-hearing-eachother/19278

If you are using raw LoRa, you need to make sure the transmitter and receiver both agree on the I/Q inversion setting. With a LoRaWAN node and a LoRaWAN gateway setup, that is the case.

The LoRaWAN node and LoRaWAN gateway are supposed to have a different LoRaWAN stack running on them regarding the I/Q setting.

davidalo commented 2 years ago

Thanks for your response @maxgerhardt

I didn't find anything about this in the specification or regional parameters document but it's logical, I will search for it again in the official doc.

Anyway, if I want to create a P2P single channel connection (as it's the case) it would be great to make it configurable in order to use the Mbed OS stack. I was able to make it just by changing this settings. What do you think about this?

maxgerhardt commented 2 years ago

Technically in mbed-os one can instantiate an instance of the appropriate LoRa radio class implementation and use that directly. (https://os.mbed.com/docs/mbed-os/v6.14/apis/loraradio.html, https://github.com/ARMmbed/mbed-os/tree/master/connectivity/drivers/lora) to create a LoRa point-to-point demo, though after some googling I haven't found a ready-made demo that does that (but it shouldn't be too hard to create).

On the other hand, with other frameworks like Arduino, libraries exist with which this can be done comfortably: https://github.com/sandeepmistry/arduino-LoRa/tree/master/examples/LoRaDuplex for example.

davidalo commented 2 years ago

I could create a LoRA point-to-point demo, but as I wanted to use LoRaPHY in both sides I had to override some methods and the final solution was a bit "hacky". That's why I am requesting a change in that implementation.

maxgerhardt commented 2 years ago

Hm, the LoRa p2p demo shouldn't have needed hacks. What exact functions did need changing? You did not use the LoRaWAN stack code referenced above (which is in lorawan/lorastack/phy/LoRaPHY.cpp), but only the LoRa radio class directly, right?

davidalo commented 2 years ago

I needed to override tx_config and rx_config in the "receiver" side. I was using LoRaRadio + LoRaPHY to use the Regional Parameters of LoRaPHY.

"Hacked" LoRaPHY waiting to receive on one side and sending a response. Mbed OS LoRaPHY sending on the other side and waiting for a reply.

maxgerhardt commented 2 years ago

I see. Hopefully the mbed-os people here can apply some changes (and a reference example?) so that LoRaPHY works better when using pure LoRa.

davidalo commented 2 years ago

Yeah, I would be happy to help if anyone gives me an start point