John O'Hare

If at some point we look at the fixed packet length transport mechanism again I believe there is a much simpler run time option available as in: https://github.com/jcw/jeelib/commit/ffafa00c55c5f3a91b2ca036a80b52c7708a9a38

I did think up a run time fix for packets not needing the Jee header. There is a load of conditional stuff for the current compile time approach.

@lettierimarco would you be willing to give my test code a spin. It is derived from jeelib and a full git replacement: https://github.com/jcw/jeelib/tree/RFxConsole

I may have incorrectly assumed you were having this problem with RFM69CW hardware. My adjustments in the RFM69 code are quite extensive. My tweaks for the RFM12B are indeed trivial....

I'm afraid I don't have a summary the changes evolved or quite a long period. A diff of the five RF69\* files will show them.

@lettierimarco can you post your full sketch with an indication as to where the code is returning permanent false (checkmessagereceived).

I don't think your issue is connected with the RF69 issue. Do you use rf12_canSend in your sketch? Are you unable to post a link to your sketch here?

Might you try adding an } else { error-message } to the ``` if(rf12_canSend()) { //populate buffer to send delay(10); rf12_sendStart(toSend.jeeDest, toSend.bytes, totLen); rf12_sendWait(0); } else { print an informative...

I am sorry to have covered old ground for you. I thought you may be locking up where rf12_canSend never returns true. In my case this has been an issue...

It might be interesting to remove line 32 from RF69_compat.h in jeelib. `#define rf12_encrypt rf69_encrypt` Not tested it and no guarantees!