perhaps we have different understanding of “rf69 features”, the acks and retries are both currently available on rf69 already even in rf12 compat mode as rfm12bs can use acks and retries too.
Things like hardware encryption cannot possibly work on rf12 because it doesn’t have it, there are physical differences between the modules that cannot be overcome in software. But if you do manage it, I’m sure JeLabs would like to hear how as a large part of JeeLib is attempting to get rf12 and rf69 working together, namely rf12 compat mode.
I don’t want to put you off trying though.
The point I make is still valid if you want to ditch JeeLib because it’s limited, and then dumb down LPL so it can communicate with rf12’s too, you will end up in a similar position as it is the rfm12b modules are limiting the feature set, through physical differences, not lib differences.
But please do prove me wrong, it would be great to move forward AND retain compatibility, it’s the compatibility bit that prevents advancement in that area.
There again this need becomes weaker as the years roll by, how many rfm12b devices are there out there that belong to networks that will be upgraded to full rf69?
For some time now, even the emonPi upgrade procedure ignores any possibility that users may still have rfm12b based rfm2pi’s, in fact worse than that, it assumes there definitely isn’t any and over writes the rf12 FW with rf69 FW causing the device to stop responding and the user has to manually re-flash the old rfm12b FW (and remember not to do the same again in the future).
In short, is it still worth holding back progress and features to the bulk of users to retain compatibility for a diminishing minority user base that may or may not even want to change their rfm network at all?
I’m only debating the options, I’m not advocating dropping support for rfm12’s, likewise I’m not looking to block moving forward either, just weighing things up, out loud . .