How would your endpoint recognize retries for confirmed uplinks, without a frame counter and without the
is_retryattribute that is otherwise added for that?
We are leveraging our platform’s (blockchain) built-in de-dup capability, meaning a transaction (message) from the sensor gets applied just once.
I can see where the maintainers would be reluctant to make changes at this stage.
The encoded signature is a whopping 101 characters, 94 without the prefix. So if that is a Base58 representation of binary data, then the source for that alone is about 69 bytes? And how are you creating
packed_trx? In other words: it seems that the payloads are quite long…?
Yes the sensor payloads are indeed relatively large, but still capable of being handled by LoRaWAN. The sensors deliver a payload consisting of a binary representation of the transaction data (incl. sensor readings) and EC signature, on the order of 100 bytes. In practical terms we’re looking at SF7 or SF8 at best and fairly infrequent uplinks to work within airtime restrictions.