AES delay

[Felix]

Not with my library so I can't speak to that.
That AES encryption time of 1b == 16b is implied from the library.

[dagid4]

Not with my library so I can't speak to that.

Yes, even with your library you cannot decrypt the message on the receiver side without the whole 16 byte block!

That AES encryption time of 1b == 16b is implied from the library.

Your library is not a datasheet. So, please stop saying it's exactly how the datasheet specifies when it clearly doesn't mention it.

That's all I want, don't imply that I can't read a datasheet.

EDIT: Again, I'm not talking about encryption time. Encryption time is 7us per block and it is completely clear and exactly specified in datasheet. I'm talking about TRANSMISSION time. The delay is caused by TRANSMISSION, because for 1B message you still need to send 16B block and this is not clear from datasheet.

[Felix]

It obviously takes more time to modulate a longer message. Like speaking a longer sentence.
That has nothing to do with the encryption time X which is identical for each 1-to-16 byte block. You have to look at the packet engine not just encryption to fully understand the picture, hence I pointed you to the datasheet.

And since you're not using *THIS* RFM69 library, but another 3rd party library, I don't see how we can talk about any such delays or why you're seeing 120ms more that you expected. I'm trying to point you in the right direction.

[dagid4]

I'm trying to point you in the right direction.

You are not even trying to understand what I'm talking about.

If you would try to send:

• 1B message with 1kbit/s and encryption disabled
• 1B message with 1kbit/s and encryption enabled

You would see the same 120ms delay, even with you library.

[Uncle Buzz]

For 64kbit/s, 1B preamble, 2B sync word, 5B payload, 2B CRC => 10B total:

I got approx. 1,5ms without AES, but 3ms with AES. Why is there 1,5ms delay for AES?

My 2 cents : your 5B unencrypted payload are encrypted in a 16B word, so your total of 10B without encryption becomes 21B with encryption, twice more bits, twice more time to be sent, I don't see any mystery.

The us delay are for decryption computation, not about the bandwidth (imagine sending at 512b/s, decryption will still take some us while the whole process will take much longer time just for the transmission part...)

From the datasheet, you can learn that encryption works with 16B packets, so if your packet is smaller, encryption will compute your payload into 16B packets, adding some bytes to your unencrypted payload. More bytes, more time to transmit depending on the bandwidth, unrelated to the decryption process.

Sorry if I misunderstood your request.

[dagid4]

My 2 cents : your 5B unencrypted payload are encrypted in a 16B word, so your total of 10B without encryption becomes 21B with encryption, twice more bits, twice more time to be sent

Finally someone who understand. You got it right. I wish you reply was first, then I would know immediately.

I don't see any mystery. ... From the datasheet, you can learn that encryption works with 16B packets

From datasheet I can learn that:

If encryption is enabled then the message inside the FIFO is read in blocks of 16 bytes (padded with 0s if needed), encrypted and stored back to FIFO.

But not a single word that the whole 16 bytes block must be transmitted. That was the only mystery for me (see my comment).

I thought that RF sends only part of the block (5B from example) and decrypts only the part (5B from example) of the block. But this is not how AES work.

It is obvious for someone who knows AES, but for me it was a strange delay.