MSP VTX device

[phobos-]

Initial PR to discuss the changes of MSP VTX for ESP32 + SPI VTX devices.

Implementation is based on trusty OpenVTx with some differences.
https://github.com/OpenVTx/OpenVTx/blob/master/src/src/mspVtx.c

Some ideas/questions:

• where to put the frequency table as it is currently duplicated between SPI VTX and MSP VTX code.
• maybe we could externalize the code to a lib and share it between OpenVTX and ExpressLRS. Where would we keep it?
• I feel like VTX Table power value information should be target specific.

@JyeSmith @pkendall64 please take a look.

[phobos-]

@pkendall64 fixed.

I found one issue with this code, I am getting no PWM output on RF amp (IO12) when trying to change the power from LUA as well as BF. Building with Generic 2400 True Diversity and VTx (option 7).

[phobos-]

PWM output should be now fixed. I tested with two units, one appears to be broken but the other one worked fine. Please check at your end, I will let manufacturers know to test this branch as well.

Output measured with the first unit at R1 (5658MHz):

PWM	Power (mW)	VPD measured after 1 min
0	1000+	2300+
1000	1000+	2300+
2000	1000+	2300
2900	750	2280
3000	600	2250
3100	400	2230
3200	150	2180
3210	140	2000
3220	120	1800
3230	100	1500
3240	70	1300
3250	50	920
3300	25	630
3350	22	580
3400	19	540
3600	13	530
4000	13	530

[JyeSmith]

where to put the frequency table as it is currently duplicated between SPI VTX and MSP VTX code.

Probably with the MSP code. devVTXSPI is looking more like a HAL and could be renamed to be treated as such. FYI Im not suggesting any changes as part of this PR.

maybe we could externalize the code to a lib and share it between OpenVTX and ExpressLRS. Where would we keep it?

I dont have any strong feelings about this. But if you are keen on going down this path may be it would live on OpenVTx and added to ELRS as a dependency?

I feel like VTX Table power value information should be target specific.

This should already be the case with target specific JSON or modding with an overlay?

Oh, I know what you mean. Probably a good idea when a 1W VTx comes along.

[phobos-]

Hey, can you help me identify test cases for wrong PIT behavior with LUA? Prerequisites:

1. MSP-VTX branch flashed to the RX.
2. Betaflight 4.4.0 + flashed to the FC.
3. Ports configured in BF and VTX is marked as Ready = YES in the VTX Tab. Telemetry enabled and sticks moving in Receiver tab.
4. Radio and RX bound, telemetry turned on in ELRS LUA.

In general LUA will not send PIT in the packet, unless power index is configured in LUA as well. Be sure to set power index to anything other than --- in the LUA to test PIT behavior.

Test cases I did for LUA:

• set PIT to OFF.
• set PIT to ON.
• change channel or power with PIT set to OFF, PIT should stay OFF.
• change channel or power with PIT set to ON, PIT should stay ON.
• RCE - boot in PIT.
• set PIT to AUX and toggle PIT with a switch.
• set PIT to AUX, boot with AUX set to PIT != PIT.
• set PIT to OFF, turn off the FC, set PIT to ON, boot in PIT.
• set PIT to ON, turn off the FC, set PIT to OFF, boot in PIT.

I'm looking at last three cases, but the rest looks good.

[phobos-]

@JyeSmith I think I fixed it. At first I forgot that there is a 15 seconds debounce period with lua sends when the RX is power cycled, so it's best to test booting in PIT by power cycling both RX and the handset at the same time. It was implemented by @CapnBry to help with infinite eeprom write issues with SPI receivers.

Another case with RCE - it will boot in PIT, but if you have PIT set to OFF in the lua it will force it out of PIT almost immediately. There is no good way to solve it as RCE has to be forced out of PIT at some point anyway. So it's best to make sure you have your pit switch in the right position before powering the quad up. RCE will not have the power surge in the beginning compared to other modes.

[JyeSmith]

LGTM!