Newer
Older
pyenergenie / doc / branch_ook_radio_config.txt
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.