suggest Moteino revision to support RFM69 OOK

[WhiteHare]

"By default, the MOTEINO board does not provide access to the demodulated OOK signal data and clock pins. It has to be wired manually:"

http://www.embeddedrelated.com/showarticle/626.php

@Felix If you can manage it, maybe include traces and soldered connections on your next revision?  It seems others also have interest, as indicated here:  https://lowpowerlab.com/forum/index.php?topic=332.0

A lot of inexpensive wireless sensors use OOK.

[Felix]

Something I can consider, however I will need more details and testing to be done before I release any PCB changes, this would be a major change.
I see in your wiring you're using up D3 which is the other hardware interrupt, and also D4. I would think by default these would not be wired but would go through some solder jumpers that would need to be solder bridged to enable this. I'm taking for granted that you require the extra signals for OOK. A hardware change would require a library change and I'm tight with doing all that leg work for something I'm not using myself, but I do see how it could be useful to others. Maybe if someone has this done and documented and tested and can submit a merge request I can integrate it. The hardware changes I'm more worried about.

[kobuki]

IIRC only DIO2 is needed for OOK operation. DIO1 is needed for the bit synchroniser but it's only for packet mode and it's not the general usage case for OOK. Plus it has certain preconditions that enable it locking onto the signal, akin to FSK packet modes. I've started implementing an OOK mode transceiver library using Felix's code back in spring, and I concluded a few things. First, OOK operation is so much different from FSK packet mode that it's better to write a completely new lib for this. Very little overlap for general usage scenarios, apart from low-level and register settings or mappings. The recommended operation mode is continuous, where (de)modulated data bits can be read from/written to DIO2 any time. I do plan to continue testing and finishing my lib sometime this year, but there are alternatives already, such as one linked by OP. Though I plan to address ease of use like Felix did.

[Felix]

Ok so it sounds to me like OOK should be addressed in a separate library and that would be my preference.
Also if hardware changes are simple enough it might not require a PCB revision. Looking at the majority of use cases OOK is an outlier but I'm open for further developments.