I am new to LoRa, and am trying to learn by capturing LoRa packets on AU915. While going through the collected data using util_pkt_logger (from https://github.com/kersing/lora_gateway) on my gateway, I came across a payload that only contained 2 characters–all integer.
What could be the possible cause of it?
Thank you for your patience and willingness to share your knowledge.
That’s actually one byte, 0x32
Not only is the CRC bad, the coding rate 4/7 is not one typically associated with LoRaWan.
Most likely this is either non-LoRa energy or part of a fractured packet triggering false detection; or at the outside perhaps it is some other non-LoRaWan use of LoRa radio modulation, but still not correctly received given the CRC issue.
LoRaWan and similar networks don’t really use messages that aren’t long enough to include several key identifying fields, which you can read about in the LoRaWan specification.
You’ll probably learn more by generating your own valid packets from an inexpensive node.
Not only is the CRC bad, the coding rate 4/7 is not one typically associated with LoRaWan.
Your comment on the coding rate was particularly helpful as I had not thought about looking at the coding rate to filter out invalid LoRaWAN packets. I had briefly read that LoRa allowed coding rate values were ‘4/5, 4/6, 4/7 or 4/8’ (from a Youtube LoRaWAN tutorial, https://www.youtube.com/watch?v=1zwCYYx1i2I), but did not know that 4/7 was typically not associated with LoRaWAN.
I just understood that different coding rate was used based on the distance between the end node and the gateway, with lower coding rate being used when more distance needed to be covered.
Based on the data that I have collected, all CRC_OK packets seem to have a coding rate of 4/5.
Thank you for your response.
+1.
Are you very sure (@cslorabox too)?
While other values than 4/5 might not be typical, the only references to 4/5 I saw in the specifications were about beacons, maybe to preserve time on air, or to allow for very simple nodes. But I’d say that all coding rates are allowed for a node?
Thank you for correcting my misconception and informing me about the minimum payload byte requirement! This would be helpful in filtering out non-LoRaWAN packets.
Just a quick question on coding rates of a node. Could a node have multiple coding rates?
@arjanvanb: no, I am not very sure, you typically are more true than me 
However, here we have a gateway collecting noise from remote door openers, and is a safe suggestion to exclude a 1 byte payload with 4/7 coding rate from being LoRaWAN
Dont see why not.
The coding rate used to send a packet is included in the header, the receiver should decode automagically.
The LoRaWan coding rate is explicitly stated in the regional parameters document, which is distinct from the one you linked to.
What happens if you deviate from it is probably a matter of implementation detail - might work in some places, in some hardware and software, will probably fail in others. If a node transmits with a non-standard coding rate, then even if that can be received successfully (SX1301 data sheet is not very clear), what should be used for any downlink reply? And does the node’s modeling of its own transmit time to calculate when to open the receive window take the difference in airtime into account?
Indeed, it’s explicitly stated in the 1.0.2 Regional Parameters (and in 1.1) for a few uplink channels as well, but for most nothing is specified? If it would apply to all, I don’t see why a few specific cases explicitly mention the coding rate. (A wild guess could be that for those specific channels it limits the time on air, but I’ve no idea.)
(I’d not explicitly filter on coding rate on a gateway; just forward and let the network decide.)
Ah, I just ran into RP002-1.0.1 (which, so far, I had not even bothered to open as I figured one should use specific versions, such as 1.0.2 rev B for TTN), which is indeed very clear:
3.1.2 LoRa™ settings
In order to be fully compliant with LoRaWAN, an end device SHALL configure the LoRa™ physical layer as follows:
