gr-lora_sdr
gr-lora_sdr copied to clipboard
tapparelj
There seems to be a problem with the number of baseband data points in SF9?
Hi, I try to use gr-lora_sdr to generate a baseband data carry one character 'A' , and when I set the SF = 9, I find that the baseband points always are 10368, no matter how I modify the CodeRate. When the SF = 7, CR = 2, the baseband points are 3360 (√) When the SF = 8, CR = 2, the baseband points are 6720 (√) However, when the SF = 9, CR = 0-4, the baseband points always are 10368, and I think this number is not corresponds to any CR.
The reason why I am confused is that when I am using USRP for sending and receiving tests, when SF=9, my Rx only can receive one SF=9 packet at a time. So I looked at the baseband data for each SF.
Finally, I want to thank you for your work. gr-lora_sdr is the best open source LORa baseband project I could find~
Hi, it is expected to get this number of samples because LoRa always sends at least eight symbols using the coding rate 4 and reduced rate mode. Those eight symbols contain the explicit header information (i.e. payload length, coding rate, and CRC presence) and payload data if there is still space. Interestingly enough, even when using implicit header mode those eight first symbols are still sent with CR=4 and reduced rate. In the case of SF9 one byte of payload can be sent within those eight symbols alongside the explicit header and this is what you observe. The number of samples you measure comes from: 2^9*(8+12.25) = 10368. 9 is the sf, 8 is the minimum number of symbols and 12.25 is the length of the frame preamble (8 upchirps, 2 network identifiers and 2.25 downchirps). I am not sure to get your issue with sf9. Do you try to receive multiple frames colliding, using the same sf?
Thank you for your answer. I understand. I'm using the USRP B210 to test internal loopback. When receiving and sending continuously, the data packets can be received stably under normal circumstances. However, when SF=9, I can only receive the first packet, and there is no subsequent data reception. This phenomenon appeared steadily in my tests.
I can't replicate this issue when using the flowgraph tx_rx_usrp and setting the spreading factor to 9, using NI USRP 2920. If you connect a qt_gui_sink to the USRP source, do you see continuous samples being produced? If yes, can you provide a screenshot of the flowgraph you use to check if I can see anything peculiar on your parameters setup?