I got my project up and running and I'm very happy with it, however, before I make more I'm looking at the transmission size. Currently I am sending 8 bytes per payload, and looking over it, I found a way to reduce that down to a mere 4 or 5 by restructuring how the payload is structured. My trade off would be that in managing the XML file, that will be altered over time, I lose a great deal of human readability in exchange for the smaller packet size. Is it worth it to redo all the code? How much of advantage is the 4 or 5 byte payload from the 8? Keep in mind this is just the payload, not the additional bytes and encryption.
Are you using Moteinos? RFM69? or something else?
Moteinos of course, I have a mix of the Transceiver: RFM69HW - 868/915Mhz, and the new one Transceiver: RFM69HCW - 868/915Mh.
Ok the HW/HCW are basically the same from a software and circuit perspective, physically only different by pin layout.
You say a bunch of things here which i'm not really all following:
Quote from: nerdkingdan on July 19, 2017, 03:41:18 PM
Currently I am sending 8 bytes per payload, and looking over it, I found a way to reduce that down to a mere 4 or 5 by restructuring how the payload is structured. My trade off would be that in managing the XML file, that will be altered over time, I lose a great deal of human readability in exchange for the smaller packet size. Is it worth it to redo all the code? How much of advantage is the 4 or 5 byte payload from the 8? Keep in mind this is just the payload, not the additional bytes and encryption.
Are you referring to my RFM69 library packet structure?
IMO it's not worth the effort saving a few bytes vs the amount of work you put into it plus the ongoing maintenance if you want to continue to integrate further patches into your branch.
Not sure what XML file you mean.
A complete transmission contains lots more "bytes" than just the pure 4 or 8 bytes of payload:
(http://i.imgur.com/mc5dWpq.png)
So overall looking at the big picture you're not saving a ton. Unless you have some stringent power requirements which demand that you save a few coulombs by not sending the extra bytes.
In which case i'd look at saving elsewhere - using RFM69_ATC, increasing bitrate (shortening transmissions) etc.
All in all, nobody said you have to use this RFM69 library, others developed their own to eliminate all the "waste" they don't need :)
Essentially the answer to the original question is: not worth it. You are already under 16 bytes for the payload so encryption is already padding your payload out to 16 bytes prior to encrypting. You can shorten your payload to 1 byte and 16 will still be sent. You would need to turn off encryption in order to send payloads smaller than 16 bytes.
Quote from: ChemE on July 19, 2017, 07:56:04 PM
Essentially the answer to the original question is: not worth it. You are already under 16 bytes for the payload so encryption is already padding your payload out to 16 bytes prior to encrypting. You can shorten your payload to 1 byte and 16 will still be sent. You would need to turn off encryption in order to send payloads smaller than 16 bytes.
Thanks, I had read some about that in another thread, but wasn't clear what the cut off was.
You're welcome. I actually just noticed for the first time that it is even called out in the graph that Felix posted above. So in addition to preamble and sync bytes you will have a length byte + 16/32/48/64 bytes of AES encrypted payload. Preamble is most likely 3-6 bytes for good results, sync must be at least 2 bytes, length is just 1, and then short messages are 16 bytes minimum with AES so you're looking at 22 byte transmissions. I don't use AES so I can get down to 10 byte transmissions. But sending a message every 5 minutes at 300kbps is not the most important factor in my power budget. At a message every 5 minutes, my sleep current absolutely dominates.