Generic Race Timer Backpack

[i-am-grub]

Adds in a backpack target for a generic race timer. It has the following features:

• Ability to configure itself for sending messages to multiple pilot's backpacks as directed from the connected race timer.
• Ability to start and stop races by monitoring for the MSP_ELRS_BACKPACK_SET_RECORDING_STATE only from the bound backpack (assuming race director's backpack)

The backpack was built to pair with this RotorHazard Plugin for sending OSD messages throughout the race to pilots with hardware to support it (HDZero goggles).

Has only been tested with the ESP32 chipset.

[i-am-grub]

FYI, I wasn't sure what to set TIMER_BACKPACK_CONFIG_MAGIC and TIMER_BACKPACK_CONFIG_VERSION to, so I just used the TX values.

[i-am-grub]

I suppose the backpack should still have the ability to send messages to the bound backpack by default. Should be a quick fix on my end.

[lesharodin]

Could we have esp82 target too?
I tested osd code on it, it works well #96

[i-am-grub]

There seems to be an issue that I haven't been able to pinpoint down where there are lost packets between the timer backpack and the HDZero goggle's backpack. This will often result in OSD messages not showing up or being cleared on the display. I'm assuming this issue has to do with the rapid rate at which I've been sending packets over the backpack (multiple messages to multiple pilots as fast as possible).

A few different ideas I've tried:

• Slowing down the send rate helped to a degree but never solved the issue. I also tried adding in a queue for received messages on the goggles allowing for the goggles to process the received packet as a lower priority task.
• Taking the queue idea from the previous idea, I added in a condition for the packet to only be processed when the send buffer was empty. This appeared to helped quite a bit, but didn't solve the issue.
• Repeated attempts to send the packet from the timer bp determined by the status of the esp send callback function. Also seemed to help to a degree, but never enough to completely solve the problem

I'm open to trying any other suggested ideas

[pkendall64]

There seems to be an issue that I haven't been able to pinpoint down where there are lost packets between the timer backpack and the HDZero goggle's backpack. This will often result in OSD messages not showing up or being cleared on the display. I'm assuming this issue has to do with the rapid rate at which I've been sending packets over the backpack (multiple messages to multiple pilots as fast as possible).

A few different ideas I've tried:

• Slowing down the send rate helped to a degree but never solved the issue. I also tried adding in a queue for received messages on the goggles allowing for the goggles to process the received packet as a lower priority task.
• Taking the queue idea from the previous idea, I added in a condition for the packet to only be processed when the send buffer was empty. This appeared to helped quite a bit, but didn't solve the issue.
• Repeated attempts to send the packet from the timer bp determined by the status of the esp send callback function. Also seemed to help to a degree, but never enough to completely solve the problem

I'm open to trying any other suggested ideas

I'm thinking we could change the backpacks so you can send more than a single MSP in an ESPNow packet. That would certainly be beneficial for this use case as you could send all the MSP displayport messages to update the screen in one packet. Bearing in mind that the ESPNow packets are limited to 256 bytes.

[i-am-grub]

These changes seem promising on the bench - field results to come this weekend.

Just a heads up, there is a slight modification to the VRx backpack to allow the HDZero goggle backpack to receive and store messages faster than the goggles can processes them.

[i-am-grub]

Testing this past weekend went well. After reviewing the pilot's footage, I would estimate that 98% of the messages are getting through consistently now.

A few ideas as to why its not at 100%

• General RF interference
• Maybe the timer's backpack was rebooting when the messages didn't go through. I might try switching it to only reboot when requested to turn on the WiFi
• The send message callback function on the timer's backpack isn't working properly due to the transmitter's backpack having the same MAC address. When a message is sent from the timer, it currently gets sent all devices with the same MAC address. It would still be considered a successful send by the timer if the transmitter received the message and the goggles didn't.

An interesting (and backwards compatibility breaking) change would be to use the first five octets of the MAC address come from the bind phrase, but the last octet would then be determined by device type (transmitter: 1, Vrx: 2, timer: 3). For simplicity, the transmitter could be set to only send to the vrx and vice versa for the vrx to the transmitter, but the timer would then be able to selectively target one or the other depending on the message being sent.

[i-am-grub]

The last unprovoked changes from me. Removing the periodic reboots fixes the last issue I was worried about.

Synced pilot race demo (warning: audio is loud and unedited)

[pkendall64]

I'll go over this one more time and if it's all good I'll merge the changes.