gr-lora_sdr
gr-lora_sdr copied to clipboard
tapparelj
Error in receiving and decoding msgs with SF 5 and SF 6
I am using heltec automation LoRa chip for transmitting LoRa packets. Using the LoRa Rx flowgraph in examples, I am not able to rx msgs for SF 5 and 6 . SF 7 to 12 works absolutely fine. Screenshots att
Kindly help.
Hello @jds0987, currently, this repo doesn't support the explicit header mode for the spreading factor 5 and 6 used by the SX1261/2/8. If your device uses one of those chips then it's expected that it won't work (you can have a look at #62 that also concerned that)
Can this block be modified for Sx1261/2/8 for SF 5 and SF 6? Will share the recorded files with SF 5 and SF 6 if required....
I'm planning to start working to add support for those spreading factors as the next improvement to this repo. If the reverse engineering goes well, I should be able to add it to the repo before the end of the year. I'll let you know when I have something working.
Ok....pls let me know if any assistance is required...
Also I am trying to use rtlsdr as source in the rx flowgraph, but the flowgraph keeps throwing error
No device detected, however all the libs pertaining to RTL have been installed.
Y is it so?
I'm sorry, but I don't have too much experience with rtl-sdr. I never had issues when using them so I never had to debug it. You can try using your rtl-sdr with something else than gnuradio to narrow down where the problem comes from (for exemple cubicSDR or GQRX). In gnuradio, iirc, gr-osmocom was supporting rtl-sdr you might give it a try as well.
Hi @jds0987, I've just pushed a new version on this branch that implements the receiver for SF5 and 6. I've tested it with an SX1262 and everything seemed fine. If you have the chance to checkout to this branch, build the module, and check if it's also working for you that would be very helpful to validate that it is not just working in my specific setup (before I start messing with the implementation of the transmitter).
Hi @tapparelj
I tried the SF 5 and 6 Branch of ur code....
Still same issue. This block is not decoding for SF 5 and 6.
It is working fine for SF 7 to SF 12.
Hi, thanks for the test! What is the exact model of your LoRa node? I've noticed that some Heltec nodes uses the sx1276 and not the sx1262 (the one I've tested on my side). If you indeed are using an sx1262 (it should be written on the chip), and you have the time, would it be possible to run the code with the version I just pushed on the feature/sf5_6_sx1276 branch with the following parameters:
- set the receiver variable soft_decoding to False
- Transmit with:
- SF5
- CR1
- the payload "Hello World!"
- Explicit header
- CRC on The raw symbol values will get print in the terminal and that will be helpful to compare with what I get on my side.
I am using WifiLoRA32(V3) which is using SX1262chip. I am also sharing Arduino code of LoRA transmitter which is being used to transmit LoRA messages.
`#include "LoRaWan_APP.h" #include "Arduino.h"
#define RF_FREQUENCY 915000000 // Hz
#define TX_OUTPUT_POWER 5 // dBm
#define LORA_BANDWIDTH 0 // [0: 125 kHz, // 1: 250 kHz, // 2: 500 kHz, // 3: Reserved] #define LORA_SPREADING_FACTOR 5 // [SF7..SF12] #define LORA_CODINGRATE 1 // [1: 4/5, // 2: 4/6, // 3: 4/7, // 4: 4/8] #define LORA_PREAMBLE_LENGTH 8 // Same for Tx and Rx #define LORA_SYMBOL_TIMEOUT 0 // Symbols #define LORA_FIX_LENGTH_PAYLOAD_ON false #define LORA_IQ_INVERSION_ON false
#define RX_TIMEOUT_VALUE 1000 #define BUFFER_SIZE 30 // Define the payload size here
char txpacket[BUFFER_SIZE]; char rxpacket[BUFFER_SIZE];
double txNumber;
bool lora_idle=true;
static RadioEvents_t RadioEvents; void OnTxDone( void ); void OnTxTimeout( void );
void setup() { Serial.begin(115200); Mcu.begin();
txNumber=0;
RadioEvents.TxDone = OnTxDone;
RadioEvents.TxTimeout = OnTxTimeout;
Radio.Init( &RadioEvents );
Radio.SetChannel( RF_FREQUENCY );
Radio.SetTxConfig( MODEM_LORA, TX_OUTPUT_POWER, 0, LORA_BANDWIDTH,
LORA_SPREADING_FACTOR, LORA_CODINGRATE,
LORA_PREAMBLE_LENGTH, LORA_FIX_LENGTH_PAYLOAD_ON,
true, 0, 0, LORA_IQ_INVERSION_ON, 3000 );
}
void loop() { if(lora_idle == true) { delay(1000); txNumber += 0.01; sprintf(txpacket,"Hello world!",txNumber); //start a package
Serial.printf("\r\nsending packet \"%s\" , length %d\r\n",txpacket, strlen(txpacket));
Radio.Send( (uint8_t *)txpacket, strlen(txpacket) ); //send the package out
lora_idle = false;
}
Radio.IrqProcess( ); }
void OnTxDone( void ) { Serial.println("TX done......"); lora_idle = true; }
void OnTxTimeout( void ) { Radio.Sleep( ); Serial.println("TX Timeout......"); lora_idle = true; } `
Made the changes as u told earlier, however not decoding with SF5 and 6 . Sharing screen shots of flowgraph and output.
Flowgraph
Hi, what are the values in the very first frame detected (there should be 20 consecutive values before the header error)? For me this is: 0x0, 0x0, 0x7, 0xc, 0x1f, 0xc, 0x6, 0x7, 0x1, 0x6, 0xa, 0x1d, 0xf, 0x11, 0xb, 0x16, 0x7, 0x1c, 0x1a
This myt be the header, that is getting printed. I ran the test for SF7 it is giving the following output.
Probably, the flowgraph initiates by comparing the header values, Post comparison it starts decoding. For SF7 the header comparison passes and the transmitted msg is then decoded.
But for SF 5 the comparison process is not getting through and the header checksum fails. Probably The header checksum block for SF5 and SF6 need to be modified.
@tapparelj
I am uploading a recording for SF5 transmitted using the heltec transmitter i have for ur testing purpose. It might help u to understand the transmission.
I'm not expecting the header check to pass with sf5 with the version I pushed on the branch. I just wanted to compare what the first 20 values are. Can you send me what the very first values are (here you send screenshots after multiple frames. With the changes I made to understand what is different for you, this is just random, except for the first)?
Yea Sure........Here it is
Hope..... this is what u required......Pls let me know if anything else is reqd.
This is intriguing, if you have those values as well then the header decoding should be handled exactly the same as for me. Can you pull and install the version I pushed now on the branch? Just to be sure, to pull and build the code on the new branch, you did
git clone https://github.com/tapparelj/gr-lora_sdr.git
git checkout feature/sf5_6_sx126x
cd gr-lora_sdr
mkdir build
cd build
cmake ..
make -j4 (the 4 specify that you can use 4 cores to build instead of the default 1, you can change to whatever fits your system)
sudo make install
This new version should work for sf5 and print the values if you set the soft-decoding to false. For me with sf5, the terminal prints
0x7
0xc
0x1f
0xc
0x6
0x7
0x1
0x6
--------Header--------
Payload length: 12
CRC presence: 1
Coding rate: 1
Header checksum valid!
0xa
0x1d
0xf
0x11
0xb
0x16
0x7
0x1c
0x1a
0x7
0x9
0xf
0x1e
0xd
0x3
0x14
0x14
0x9
0x9
0x12
0x16
0x1b
0x1a
0x18
0x1b
0x1e
0x3
0x19
0xd
0x1d
rx msg: Hello World!
CRC valid!
Hi, The branch has worked. I was taking samp_rate to be 2e6, however when i used 500KHz, the flowgraph started decoding but it still misses out on few instances and give Header Checksum Invalid. Can it be troubleshooted?
Snippet of output
[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 2426666 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=2426666
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 2426666 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=2426666
[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 816000 and may result in dropped packets on some NICs
[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs
[WARNING] [RFNOC::GRAPH] One or more blocks timed out during flush!
usrp_source :info: set_min_output_buffer on block 1 to 136
[WARNING] [UDP] The recv buffer could not be resized sufficiently.
Target sock buff size: 2426666 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.rmem_max=2426666
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 2426666 bytes.
Actual sock buff size: 212992 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=2426666
[WARNING] [UDP] The current recv_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs
[WARNING] [UDP] The current send_buff_size of 212992 is less than the minimum recommended size of 307200 and may result in dropped packets on some NICs
Press Enter to quit: D0x1c
0x10
0x6
0xc
0x1b
0x17
0x14
0x19
--------Header--------
Payload length: 41
CRC presence: 0
Coding rate: 2
Header checksum invalid!
0x7
0xc
0x1f
0xc
0x6
0x7
0x1
0x6
--------Header--------
Payload length: 12
CRC presence: 1
Coding rate: 1
Header checksum valid!
0xa
0x1d
0xf
0x11
0xb
0x16
0x7
0x1c
0x1a
0x7
0x9
0x8
0x1e
0xd
0x1c
0x14
0x14
0x9
0x9
0x12
0x16
0x14
0x1d
0x1b
0x1a
0x1a
0x1
0x9
0xd
0x19
rx msg: Hello world!
CRC valid!
The syncword I am using is 0x1424 and 0x16 only sf5 with syncword 0x1424 is decoding by the decoder, when I change that to 0x16 it's not
Hello @jithivk, it makes sense to me that 0x16 doesn't work as it would correspond to modulated symbols 8 and 48, but sf5 can only send symbol index up to 31. I don't know how semtech deals with that, do they allow those values (i.e. you can transmitt with official semtech chips with these parameters?). I'm might look into that if I have time
Yes I can transmit and receive with 0x16 but when I am using 0x34 it's not working with nicerf sx1268 chip
On Fri, 8 Dec 2023, 8:48 pm Joachim Tapparel, @.***> wrote:
Hello @jithivk https://github.com/jithivk, it makes sense to me that 0x16 doesn't work as it would correspond to modulated symbols 8 and 48, but sf5 can only send symbol index up to 31. I don't know how semtech deals with that, do they allow those values (i.e. you can transmitt with official semtech chips with these parameters?). I'm might look into that if I have time
— Reply to this email directly, view it on GitHub https://github.com/tapparelj/gr-lora_sdr/issues/67#issuecomment-1847359908, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSG5WZWBAIUFTDUGEAQMDTYIMVU5AVCNFSM6AAAAABAI64CEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBXGM2TSOJQHA . You are receiving this because you were mentioned.Message ID: @.***>
Hello @tapparelj Can this code be made functional for GNURadio 3.7.13.4 as well?
There is no reason I can think of that would prevent it. Initially, it was developped on GNURadio 3.7. The core c++ files (the ones in /lib ) should work fine, probably the asynchronous message passing callback should be changed back to the form they had before (just the way you declare the callback changed).
Hello @tapparelj Can this code be made functional for GNURadio 3.7.13.4 as well?
Hi @tapparelj
Was playing around with this flowgraph and tried to test the demodulation and decoding of few of the lab recordings I had with me using File Source in thelora_RX flowgraph for SF5.
I have been getting this Output
"CRC not supported for payload smaller than 2 bytes."(Screenshot attached).
Why is this happening and how can we troubleshoot this?
Are you sending a payload of less than 2 bytes? The CRC for payloads of less than two bytes is not supported yet as the last two bytes of the payload are considered in a special way for the CRC computation and I never had the time to check what they do when the Payload length is <= 2.
Are you sending a payload of less than 2 bytes? The CRC for payloads of less than two bytes is not supported yet as the last two bytes of the payload are considered in a special way for the CRC computation and I never had the time to check what they do when the Payload length is <= 2.
Hello @tapparelj
Yes, The payload is less than 2 bytes. Are you planning to add support for payload less than 2 bytes?
Hi @jds0987, yes, it's planned, but probably only around February or March.
@tapparelj Why the received data not showing in its hex format, rpp version is doing that well.
On Wed, 13 Dec 2023, 6:17 pm Joachim Tapparel, @.***> wrote:
Hi @jds0987 https://github.com/jds0987, yes, it's planned, but probably only around February or March.
— Reply to this email directly, view it on GitHub https://github.com/tapparelj/gr-lora_sdr/issues/67#issuecomment-1853856059, or unsubscribe https://github.com/notifications/unsubscribe-auth/APSG5WZHNUPVU75TSFNDXLLYJGPVZAVCNFSM6AAAAABAI64CEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTHA2TMMBVHE . You are receiving this because you were mentioned.Message ID: @.***>
@tapparelj Why the received data not showing in its hex format, rpp version is doing that well.
You would like to print in the terminal the hex content? For example "0x68 0x65 0x6C 0x6C 0x6F" instead of "hello" ? That's a good idea and a simple thing to add. I'll add it very quickly. I'll keep you updated.