Improved flow of code, specifically radio_transmit() ...

Pushes previous mode and restores at end of transmit.
This should auto-return to standby or receive as appropriate.
This will make it easier to implement mode hopping schemes later.

Simulation gets further now due to gpio_sim detection

Started design of new long payload transmitter

Initial design of new radio transmit scheme

Created links to issues for all items on the main TODO list

References to Energenie fixed

OpenHEMS is now OpenThings

Updated README with more up to date status update

Set repeats to get maximum OOK payload burst of 400mS

radio_rpi.so now built as part of the pi build process ...

legacy.py now uses the prebuilt radio_rpi.so

encoder now adds preamble. ...

lecacy.py now uses new C radio driver

Tested radio2.py on Raspberry Pi, now works with OOK transmit

Tiny tidy up

Renamed encoder_test to be consistent with other testers

Wrote radio2_test.py as a python OOK tester for new radio.so lib

radio2.py ctypes wrapper ready for testing

Preparations for new radio interface added to the architecture

Tweaks to radio_test.c layout

Tidied up radio_test.c readability

Removed unnecessary spurious radio configures

Fixed payloadlen bug that was introduced in API refactoring ...

Note: Reconfigures as OOK regularly, unneccesarily now

Fixed bug with OOK struct size in hrfm69_test.c

Finished coding radio_test and radio(tx) module

First pass of spec'ing radio.h/c and radio_test.c

Can now reliably turn energenie switches on and off with hrfm69_test.c

Coded a better payload transmit test routine for OOK

Started coding up new burst transmission scheme

Started to write another test case to blurt out OOK energenie messages. ...

This is only a test case.
But it has highlighted a whole load of discrepancies in the original C
code to do with payload length calculation, and the 'magic' zero byte
at the start of the buffer for stuffing the SPI register address in.

Tracked down the 'long sync bit' problem. ...

It's due to the HRF always preceeding each packed with an extra 01 at start.
Existing driver code sends 'chips' to prove this.
Looking like a preamble of zeros will be required to make this a non issue,
and then generate the real 80000000 preamble as part of the payload.

Got the radio chirping again after a long period of not working at all