Internet of Things Stack Exchange is a question and answer site for builders and users of networked sensors and control devices in the contexts of smart homes, industry automation, or environmental sensors. It only takes a minute to sign up.
Sign up to join this community
I created a LoRa to USB pass-through via Arduino in order to use it as a temporary gateway for development purposes. So somehow I need to know how big a LoRa packet including PHY headers is, in order to determine how long it will take my software to read and send the data on top a USB.
In order words my architecture will be as follows:
So the PC/Laptop will need to "know" how big the LoRa packet will be in order not to receive via USB countless number of bytes.
How big is a LoRa packet including PHY headers
I assume you mean MAC header? After some LoRa chip has demodulated the LoRa radio signals for you, it will give you the LoRa PHY payload. For a LoRaWAN uplink such PHY payload holds a MAC header, MAC payload and MIC.
For 1.0.x the rule of thumb seems to be that a LoRaWAN packet is at least 13 bytes larger than the application payload:
I think usually at least 13 [ MHDR (1) + DevAddr (4) + FCtrl (1) + FCnt (2) + Fport(1) + MIC(4) ] in a packet with no options
The maximum application payload depends on the selected data rate. If a node should be able to operate in worst conditions, then one should assume the worst data rate, SF12, where the node should not send more than about 51 bytes. (Where in best conditions, SF7, that might be 222 bytes.) All that also depends on the region, I think. (And things might be better when the LoRaWAN node does not use LoRa, but FSK.)
So, for your use case, I'd try not to depend on some maximum length through USB. Instead:
You can easily convert the binary LoRaWAN packet to plain text using Base64. You can then send such text through USB and terminate it with a newline or a NULL-character to let your receiver know when the USB message is complete. You can even send additional meta data in that line of text if you choose a separator that is not in the Base64 character set.
For example, the Semtech UDP protocol between gateways and servers uses JSON text messages, which also allows you to pass additional meta data. In the JSON text, the binary LoRaWAN packet is also encoded using Base64. If the JSON text is pretty-formatted to include newlines, then you could still terminate such text message with a NULL-character and your receiver would not be confused.
