search

whaleygeek / pyenergenie

A python interface to the Energenie line of products
MIT License
82 stars 51 forks source link

Increase maximum number of repeats in payload sender #37

Closed whaleygeek closed 8 years ago

whaleygeek commented 8 years ago

The payload sender presently uses the payloadlen register of the HRF radio, which is only 1 byte wide. With an OOK payload length including preamble of 16 bytes, this limits us to 15 repeats before the register overflows (16*16=256, which causes the register to overflow)

There is a range check in the low level C code to protect against payloadlen register overflow at the moment.

To improve reliability, we need to be able to transmit more than 15 packet repeats, especially in noisy or longer range setups. 15 packet repeats presently gives us a maximum burst transmit time (with no inter packet gaps) of 400ms.

The new scheme needs to ditch using the payloadlen counter with a fixed value, and avoid using the packetsent flag. The hope is that we can use the fifolevel and fifoempty interrupt flags in irqflags2 with a payloadlen of 0 (as indicated in the data sheet), to build an arbitrary length transmitter.

This will then allow repeats of more than 8 payloads to be done without any inter-burst gaps appearing, and this will give flexibility for app designers to sacrifice on-air time for improved reliability.

Note that for certification reasons, the duty cycle of 433Mhz radios is specified, and we may have to put hard limits inside the low level driver to prevent them being exceeded.

http://www.ti.com/lit/an/swra090/swra090.pdf

Relative to a 1 hour period: 0.1% maxon(720ms) minoff(720ms) 1% maxon(3.6s) minoff(1.8s) 10% maxon(36s) minoff(3.6s)

The baud rate of the OOK radio is configured at 4800bps, i.e. 208uS per bit. So, a single 16 byte payload takes 26ms to transmit. Not accounting for radio startup and packet end turnaround delays, this would allow a maximum of 27 payload repeats within the 0.1% category, providing that the radio was left off for about 1 second before any further transmission occurs - e.g. a message scheduler might choose to use 1 second scheduling timeslots.

whaleygeek commented 8 years ago

This is now implemented in feature branch long-tx.

Waiting before I finish some additional testing (house codes) before merging this back to master and closing.

whaleygeek commented 8 years ago

Tested, long-tx branch merged, closing