Instead of the tl;dr below you can just go straight ahead to GitHub and
grab the latest code. A lot of useful info has been gathered in this thread, if you have questions or suggestions, please post here.
First I thought I'll just continue an older thread of similar subject for this, but I think that if it gains any notable interest, it's better to have a separate one.
I continued with my OOK/RFM69 project and I can report success. I've succesfully created a working receiver and transmitter solution, and I'm including my current code for review and test for anyone interested. I'm trying to collect my notes in bullet points.
• It's a work in progress, probably many optimisations, code refactorings could be done (some
will be done), but it works. Pull requests will be very welcome after I'll have it uploaded to Github. I haven't decided yet if I'm creating a version that uses the original repo as base or I make it completely indepentent. It would be nice to be able to integrate it into the LPL codebase sometime. Maybe Felix is interested in it. I'm including this code here in an attempt to gauge interest.
• I've taken an older version (from when I started coding on it) of Felix's RFM69 lib, gutted it and added the functions I deemed necessary. A note: many settings specified as defaults in the RFM69 DS aren't actually defaults. I had to set some of them explicitly. It is a separate class with a different name, so it can co-exist with the original lib. No inheritance (might be an option later).
• There are 2 modes of operation for reception: polling and interrupt based. When polling, one can just call poll() to see if the OOK signal is currently active or not. Interrupt based means there is an interrupt attached to the pin change and pulse train decoding logic can be put into an ISR.
• Transmission is very simple: after calling transmitBegin(), one can call send() to activate/deactivate the OOK signal. Simple timing loops can be used to modulate a proper pulse train, for instance. No provisions are made to support encoding modes of the RFM69, like Manchester encoding. Instead, I think the simplest and most efficient method for adding support for specific OOK hardware is grabbing and modifying existing freely available code for older transmitters like the RFM01 or RFM12b.
• The minimum length of a pulse is tied to the reciprocal of the maximum bit rate of the OOK mode of the RFM69, which is 32768 Hz, resulting in a 30.52 us resolution. Since most OOK appliances use pulse lenghts close to 1 ms, it's more than adequate.
• The first '1' pulse after a long silence or '0' is always perceived longer than the rest. It can probably be controlled a little better, needs some more experimenting. But see my previous point, it shouldn't pose a problem in practice. Other than this, accuracy is within 10% for short periods (below 500 us) and a lot better for longer ones, near 100%.
• About the included zip: unzip it into a checked out copy of the LPL RFM69 library. It will not overwrite anything, just adds new files. The included test code is very primitive; it's just a playground. Feel free to modify it to fit your needs. I'm yet to test it with a real OOK transmitter. There is a separate receiver and a transmitter sketch.
• About the hardware mod. First, please see
the image in the first post of this thread. The left-hand side modification needs to be done for both receivers and transmitters. More precisely: one needs to connect DIO2 of the RFM69 to Pin 3 of the Moteino. That's all. Obviously, a pair of Moteinos or a Moteino as receiver and some OOK hardware is needed for testing.
Any comments or suggestions are very welcome.