Ideas for making RFM69 library extensible

[Tomega3]

TomWS,
Thanks for the info on the number of bytes used by the Session Key and the Auto Transmit Power enhancements.
Are these bytes only used in the Acks or in normal packet transmit or both?
Will there be a new definition of RF69_MAX_DATA_LEN depending if the Session Key or Transmsit Power enhancements or both are used?

Thank you for your offer to help me with creating a derived class. I need the help. My c++ is not so great, I am an old C programmer. I do mostly SQL now. Its a lot of fun working with these little controllers.

I was planning to keep a copy of the original RFM69 lib and modify it to add the setup info and new methods to test my approach to allowing a user to change the radios baud rate and freq deviation after the default initialization routine completed.

Tom

[TomWS]

TomWS,
Thanks for the info on the number of bytes used by the Session Key and the Auto Transmit Power enhancements.
Are these bytes only used in the Acks or in normal packet transmit or both?

It's different for each library, Auto Transmit Level control ONLY adds the data to Acks and only if the sender had requested its RSSI to be included in the Ack (so presumably the sender was agreeable to losing the two bytes on a usually empty Ack.)
Session Keys, I have an idea, but I don't have the library handy or the current wherewithal to get it from Dan's github and analyze it.  I think he uses Acks to set the key, and the sender MUST include the subsequent key on the next message, so its data packet.

Will there be a new definition of RF69_MAX_DATA_LEN depending if the Session Key or Transmsit Power enhancements or both are used?

No, I think both Dan and I consider that constant a constant of the RADIO, not of any enhancements we would make, so you'll simply need to know that the packet is shorter if you use the extension.  However, BOTH enhancements check to see if the sender's packet would exceed the packet length with the extra data and truncate in this case.  We don't break the radio, but we might break your code if you're not checking DATALEN on receive.

Thank you for your offer to help me with creating a derived class. I need the help. My c++ is not so great, I am an old C programmer. I do mostly SQL now. Its a lot of fun working with these little controllers.

No problem, you ask intelligent questions so if I help you, I'll help many people.  I'll try to get something posted tomorrow.
BTW, your statement about being an 'old C programmer' begs many questions.  But, forgetting ALL of them, if you're interested in 'expanding' what you know (whether is new or rusty), then it's why this forum is here.

I was planning to keep a copy of the original RFM69 lib and modify it to add the setup info and new methods to test my approach to allowing a user to change the radios baud rate and freq deviation after the default initialization routine completed.

Tom

Good information - this helps formulate an example lib...  Thanks.

Tom

[TomWS]

I've started a new thread to discuss how to create an derived class extension https://lowpowerlab.com/forum/index.php/topic,974.0.html

[dewoodruff]

Sorry, I forgot to subscribe to this thread so I wasn't getting mail notifications.

Will there be a new definition of RF69_MAX_DATA_LEN depending if the Session Key or Transmsit Power enhancements or both are used?

No, I think both Dan and I consider that constant a constant of the RADIO, not of any enhancements we would make, so you'll simply need to know that the packet is shorter if you use the extension.  However, BOTH enhancements check to see if the sender's packet would exceed the packet length with the extra data and truncate in this case.  We don't break the radio, but we might break your code if you're not checking DATALEN on receive.

Currect, I'm not manipulating RF69_MAX_DATA_LEN in my code. This line which happens in the base sendFrame function has been carried over:

Code Select Expand

if (bufferSize > RF69_MAX_DATA_LEN) bufferSize = RF69_MAX_DATA_LEN;

By using a session key it looks like the max payload length a node can send is reduced by 1.
Did I get this wrong?

Nope, that is right - only one byte is taken up by the session. My code uses two bits of the CTLByte for indicating if the packet is a session request or contains a session key. If the packet contains a session key as indicated by that bit in CTLByte, then interruptHook will save the first incoming byte as the session key before processing the rest of the packet as DATA.

EDIT: See my blog for more details about the extension and how to get it all working: http://www.makethenmakeinstall.com/2015/03/session-key-support-for-arduino-with-rfm69-wireless-module/