Sending join accept packet about gr-lora_sdr HOT 12 CLOSED

I have updated my local repository with the latest push that you made, as I can see that you have made some changes.

This is the updated waterfall with the same settings:

Noticed that the issue is still not resolved, after the updates. However, it looks different and more correct for a lora packet.
The packet does not clear the bandwidth for noise as the node seems to be doing, could this be a problem?

from gr-lora_sdr.

Hello,
Sorry I'm a bit confused. Can you just clarify those:

• Between which devices do you transmit frames?
• Which direction works, if any, and which doesn't?
• Regarding the waterfall, what do you mean by clear the bandwidth for noise? (The default waterfall has a very large temporal resolution, which render it very difficult to interpret. It might be better to use a frequency sink to at least see the bandwidth shape.)

from gr-lora_sdr.

Yes sorry for the confusion.
To clarify:

1. The SDR is the gateway and the waterfall seen is from the SDR. The end node is a discovery sigfox kit, using I-CUBE-LRWAN software.

2. From the node through the SDR to chirpstack works. At time 100e+01 on the last waterfall. I am trying to send the packet from the SDR to the node at the time 500e+00 on the latest waterfall which is the join accept the packet. The packet on the node is still getting join failed, it could be the timing on the packet or simply just the wrong packet.

3. Not quite sure myself:) I just see the node packet has the "blue background" around it and the sent packet and the packet from the SDR have this kinda distorted look.
   Made a video of the project so far:
   https://www.youtube.com/watch?v=Ra1Xqi8rc0Q

Thank you for your assistance.

from gr-lora_sdr.

Hi,
thanks for the information.
I see some things that might cause difficulties to receive downlink messages:

• For the downlink, LoRaWAN uses downchirps instead of upchirps to reduce the interference. You should check what your node expect. If your node expect downchirps, there is currently no option to choose the reference chirp to use for the modulation in this repository. You have a few options though: 1) you can try changing the expected reference chirp in the end node by setting the register value setting the reference type (I don't remember exactly the name, it should be something referred as flipped or reverse). 2) modify the code of the modulate block to use downchirps as reference 3) take the conjugate of what comes out of the modulate block before fowrarding it to the Osmocom sink.
• The timing might be strict depending on how your end node is setup. Check the what delay the node uses for the two RX windows (the second one might be set to a different spreading factor and/or center frequency).

The color of the waterfall depends on what scale you choose, the received power, the gain of the receiver, etc... the "red" parts between frame don't mean that the noise suddenly increases. For the frequency sink, use the max hold option called "average: high" iirc

from gr-lora_sdr.

Hello,
Do you know if the block complex conjugate will work for this?

Placed like this:

from gr-lora_sdr.

Hello,
it might work but I've never tried it.

from gr-lora_sdr.

Ok,
Thank you for your guidance as always. I apologize if my post was off-topic for issues related to gr-lora_sdr.
I haven't figured it out yet, but I have several points to troubleshoot.

I'm going to close this issue, but please feel free to add any tips for checking if the package sent is a downchirp or upchirp message.
Thanks!

from gr-lora_sdr.

Hello again :)
I am trying to send the PHY Payload through GNURadio to the end-node.

The end node reads the package, but it's not correct (...

I am trying to understand the packaging of gr-lora_sdr but do not fully get it.

This is the correct packet packaging according to "https://lora-developers.semtech.com/documentation/tech-papers-and-guides/lorawan-device-activation/device-activation/"

The first thing I saw was the CRC was not included in the PHY Payload, I tried to change the "Add header" and "Add crc" blocks to "has_crc: False". But still, gets the same message.
Does this repository add all the needed packaging for LoRaWAN package (Preamble, PHY Header, PHY Header CRC and CRC)? Or is modifying needed?

Thank you for your assistance.

from gr-lora_sdr.

Hello,
As indicated in my first message in #37, this repository does only implement the physical layer of LoRa.
This means that it implements everything in the first line of your figure. The PHY Payload will be composed of the bytes you feed into the whitening block.
If you want to make it compatible with LoRaWAN, you have to build the PHY Payload based on the second and third line of your figure. Similarly for the receiver, you will recover the bytes of the PHY Payload and need to process them according to the LoRaWAN specifications, for example, if you want to recover the decrypted content of MAC Payload.

from gr-lora_sdr.

Great, thank you!
I have completed the receiver side. As for sending, I am currently sending a one-byte stream of hexadecimal data, following the instructions provided in #39.
However, I wanted to clarify whether I need to send only a part of the 3 parts of the PHY Payload, instead of the entire payload. For instance, currently, I am sending the following as an example:

phyPayload is received from chirpstack for the join accept packet;
phyPayload: IC4aGygzXcmPr/LtF9PSR14KhEeUf6AQSIxqfjHAjwMu

Then, I convert it into input for the whitening block as follows: "202e1a1b28335dc98faff2ed17d3d2475e0a8447947fa010488c6a7e31c08f032e,"

Based on my understanding of what you said, do I need to split this package into three parts, namely MHDR, MACPayload, and MIC? I want to confirm whether my understanding is correct.

Edit: Ok, I misunderstood a bit. It is ok to send it to the whole PHYPayload as I did?

from gr-lora_sdr.

Hi,
yes exacly, you construct the full physical payload which will contain all the parts required by the MAC layer LoRaWAN and feed it to the dewhitening.

from gr-lora_sdr.

Great, thank you!
It seems that the part we discussed is correct. However, there seems to be another issue that I am unable to identify at the moment.

If you have any suggestions or tips on what else I can check, please feel free to share. For now, I will close.
Thank you for your assistance, as always!

from gr-lora_sdr.