You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The packet_router_packet_report_v1 represents an individual Uplink and will thereby represent billions or even hundreds of billions of packets. It will be worthwhile to tune the data structure to be more memory compact.
Note
All number types except fixed, double, and float are stored as
varints, meaning as long as your numbers stay in about the int8 or
int16 range, they are only 1 or 2 bytes, even though it says int32.
Current protobuf message
message packet_router_packet_report_v1 {
uint64 gateway_timestamp_ms = 1;
uint64 oui = 2;
uint64 net_id = 3;
// signal strength in dBm
sint32 rssi = 4;
// Frequency in hz
uint32 frequency = 5;
float snr = 6;
data_rate datarate = 7;
region region = 8;
bytes gateway = 9;
// Hash of payload within message packet
bytes payload_hash = 10;
uint32 payload_size = 11;
}
Add Uplink, Confirmed Uplink, Join enum named type.
Consider adding the packet header
net_id uint64 -> uint32
(The maximum net_id is 24 bits)
payload_hash
truncate to uint32 or uint64
a MIC is uin32 and is considered sufficient for LoRaWAN
consider directly using the MIC as there is no security issue instead of a generated hash
A MIC would also be future forward-compatible with the new MIC over payload hash.
I would propose replacing other values with uint16, but uint16 or unt8 is not supported by protobuf
The uint32 len followed by the protobuf msg is a little odd. It took me a while to figure out the structure, and especially since the len was little-endian encoded. I'm wondering if this structure wouldn't be better for the entire file:
The packet_router_packet_report_v1 represents an individual Uplink and will thereby represent billions or even hundreds of billions of packets. It will be worthwhile to tune the data structure to be more memory compact.
Note
Current protobuf message
Add Uplink, Confirmed Uplink, Join enum named type.
Consider adding the packet header
net_id uint64 -> uint32
(The maximum net_id is 24 bits)
payload_hash
truncate to uint32 or uint64
a MIC is uin32 and is considered sufficient for LoRaWAN
consider directly using the MIC as there is no security issue instead of a generated hash
A MIC would also be future forward-compatible with the new MIC over payload hash.
I would propose replacing other values with uint16, but uint16 or unt8 is not supported by protobuf
The uint32 len followed by the protobuf msg is a little odd. It took me a while to figure out the structure, and especially since the len was little-endian encoded. I'm wondering if this structure wouldn't be better for the entire file:
message packet_router_packet_reports_v1 {
repeated packet_router_packet_report_v1 = 1;
}
The text was updated successfully, but these errors were encountered: