Why ?
Received packets at the Gatetway already have been ‘processed’ with forward error correction, so what is there to be achieved with further ‘processing’ ?
corrupted packets can be processed to find the error bits after that can use error correcting codes.
yes forward error correction is present but even due to single bit errors the packets are getting lost so by analyzing the bit error positions and by using additional processing we can make successful packet transmission without re transmission. it may reduce the interference due to retransmissions.
thank you for the answer , the negative CRC packets will be received by gateway?
All packets are received by the gateway. However at which level do you want to apply your analysis? If looking at LoRa packets after deciding by the concentrator hardware all redundancy information has been lost. All you get is a LoRa packet that might or might not pass thee crc check. And as mentioned forwarding packets with crc failure to TTN is not useful as the backend will not proces them.
Back to the questions: what is your gateway hardware and how do you want to process the failing packets?
I own a Dragino LPS8 and a LIG16. Both gateways seem to have the option to turn the CRC-check off. But I never tried it.
The data-packages are received, demodulated and decoded. Then the CRC-check is performed. If this check is negativ, the data-package is not forwarded to the server. imho this can be turned off in the config.json and packages with negative CRC-will be forwarded to the server which makes no sense and costs only server-time.
If the reception was disturbed, you have a good chance that the CRC-check is negativ but not all errors will be detected.
Its an interesting theory, but LoRa already allows for a very high degree of forward error correction. The default is 4:5, but it can be set at 4:8. If the LoRa internals cannot recover the packet at 4:8, I suspect your chances of doing it by additional external processing are close to zero.
However if you think its possible to improve on LoRas already extensive internal error recovery then by far the easiest way is to develop the allogarithms you think might be possible is outside of TTN.
Using point to point LoRa devices for this type of research would be gazillions of time easier and safer than modifying a TTN server, last thing you want is to inject rogue packets into TTN.
1 Like
One other point to consider.
Whilst if you know the exact packet that was sent, you can then look at what was received and recognise that there was a ‘single bit error’.
But the gateway does not know what was sent so the gateway (outside of the LoRa internals) cannot know that there was a ‘single bit error’.
Hi @Shilpa181188, which university are you at?
Maybe easier to simulate this on paper working backwards - as trying to corrupt LoRaWAN packets is going to be totally random - whereas you could work out what you can recover using pencil & paper & maths and then create a way of tracking how often these types of errors occur.
1 Like
My colleague and me did some experimentation around 2016 on this topic, while we were both at the University of Twente. We discovered that LoRa has a “capture effect”, causing a weaker signal to capture the receiver, preventing it from receiving a stronger signal. This effect was only noticeable if the difference between the two signals is less than a certain amount. The timing of the two signals also plays a role, as the preamble causes the receiver to lock onto a signal, and the signal therefore capturing the receiver. There is therefore also a timing threshold where the capture happens, and where the capture is lost and the second signal is received.
My colleague was an expert on the capture effect with DECT. Maybe he can assist you in your research:
https://www.linkedin.com/in/kallol85/
1 Like
Regarding the idea of getting packet with wrong CRC to still be forwarded to the cloud for later analysis there is value when you have multiple gateway receiving the same packet: there is some chance that bits in error will be different for each packet so you should theoretically be able to locate the bits in error by comparing the different version of the packet and with trial&error approach find the correct packet.
1 Like
You would have to use your own cloud for that as TTN is not doing this and drops any packet with CRC errors as soon as it arrives. So forwarding to TTN is a waste of bandwidth and processing power.
It seems highly unlikely that TTN would turn off CRC checking and risk injecting heaps of corrupt packets into the system.