diff --git a/doc/branch_ook_radio_config.txt b/doc/branch_ook_radio_config.txt
deleted file mode 100644
index 5e09293..0000000
--- a/doc/branch_ook_radio_config.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-Supporting the MiHome Light
-
-The MiHome light requires a longer transmit burst.
-OUTER_TIMES=1, OUTER_DELAY=0, INNER_TIMES=75
-
-This is already possible with the new radio physical layer,
-and the light has been tested at the physical layer and proved to work reliably
-with these settings.
-
-There is presently no way to pass this forward from the device classes to the radio.transmit()
-
-STEPS REQUIRED
-
-DONE 1. Devices.py/LegacyDevice/send_message()
-   needs to read the radio config parameters from it's most concrete instance
-
-DONE 2. Use these to send to the air_interface
-   (which is actually ook_interface,
-   which is a OnAir.TwoBitAirInterface instance).
-
-DONE 3. OnAir.TwoBitAirInterface.send()
-   Needs to read out these radio config parameters
-   and override the defaults passed to radio.transmit()
-
-FINE 4. defaults are presently outer_times=1, inner_times=8, outer_delay=0, modulation=ook.
-
-DONE 5. OnAir.TwoBitInterface.send()
-   Needs default radio parameters that are overriden by any radio parameters passed into it
-   (so that if no parameters are provided, sensible defaults are used).
-
-DONE 6. Need to use the TxDefaults() structure to get good reuse across the class hierarchy
-
-DONE 7 Add MIHO014 3kw relay (It's just a legacy device, so only needs a wrapper class)
-
-
-All tested in simulation and works.
-
-Just need to test on real devices, before merge back to master.
-
-
-
-
-
-FUTURE WORK
-
-Not part of this change, but we should note somewhere that this will need
-considering when the transmit scheduler is implemented.
-
-Note also that when radio transmit parameters are changed, this changes the amount of time that the radio is
-in transmit mode (and therefore alters the amount of time it is in receive mode, and ultimately how wide or
-narrow the receive window is). There will eventually need to be some way for the radio module to pass back up
-the chain how long a certain set of parameters will leave the receive window closed, so that a deterministic
-message scheduler can be written that schedules messages into known transmit and receive slots. No need to
-implement that yet, but we need to allow for it in the future.