ESP8266 as DupleTX

[CapnBry]

ESP8266 TXes only work in FREERUN mode with current master, this fixes them so they can operate as DupleTX TXes (internal full duplex modules). Video:

I've only used an EP2 RX, but any ESP-based RX should now be capable of operating in TX mode. The power draw of the EP2 in 10mW output mode is <50mA which means we can have a full TX running at 0.165W which is like 1/10th what an ESP32-based TX uses.

You'll note that I'm only running the ESP8266 at 80MHz because it seems to work just fine, but I am not measuring packet jitter so that may be impacted by the 1/6th the performance of an ESP32 at 240MHz, but the STM32 does it at 72MHz so why waste power? Update: BF RC_SMOOTHING_RATE logs below

Other Receivers

This creates a Unified 8285 TX target and a single DUPLETX_ESP target and others can make their own one-off TXes by editing the hardware.json. Example: a BetaFPV Nano RX can be used as a TX just by setting power_high, power_max, power_values, and setting radio_dcdc.

Why?

I dunno. It just seemed like a fun thing to do now that we have internal CRSF full duplex support and the half duplex issue holding back the ESP won't be a problem.

Channels generator

Using crsf_parser library, change COM10 to your FTDI, and possibly baud from 400000 to 921600 if your FTDI doesn't support arbitrary baud rates
https://github.com/AlessioMorale/crsf_parser

#!/usr/bin/env python3
from crsf_parser.payloads import PacketsTypes
from crsf_parser.handling import crsf_build_frame
import serial
import time

with serial.Serial("COM10", 400000, timeout=2) as ser:
    CH = 0
    channels = [992 for i in range(16)] # set to 1500us
    while True:
        channels[CH] = channels[CH] + 1
        if channels[CH] > 1792:
            channels[CH] = 191

        frame = crsf_build_frame(
            PacketsTypes.RC_CHANNELS_PACKED,
            {"channels": list(reversed(channels))},
        )
        ser.write(frame)

        if ser.in_waiting > 0:
            print(' '.join(map(hex, ser.read(ser.in_waiting))))

        time.sleep(0.020)

[CapnBry]

With unified firmware letting anyone make their own hardware json, I'd like to revisit this so 3.0 can release with ESP8285 RX as TX for fun shenanigans controlling a model from a PC. I might need help though since time is getting tight!

[CapnBry]

Flagged as Do Not Merge because it seems to crash when handling Lua commands beyond just loading.

EDIT: Fixed! Stupid null-flippin callbacks. Who thought this was a good pattern?!

Exception report

``` Exception: 0 (Illegal instruction)

epc1: 0x40223768: hwTimer::nullCallback() at ??:?
epc2: 0x00000000
epc3: 0x00000000
excvaddr: 0x00000000
depc: 0x00000000

ctx: cont

sp: 0x3ffffc10
end: 0x3fffffc0
offset: 0x00000190

stack:
0x40102128: hwTimer::callback() at ??:?
0x40102364: timer0_isr_handler at ??:?
0x4000050c
0x400043e1
0x400044ab
0x4010269c: interrupt_handler at ??:?
0x40102688: interrupt_handler at ??:?
0x40102348: timer0_isr_handler at ??:?
0x40102128: hwTimer::callback() at ??:?
0x402019fa: loop at ??:?
0x401025bc: interrupt_handler at ??:?
0x4000050c
0x402019bc: loop at ??:?
0x40201957: loop at ??:?
0x4000444e
0x401087b7: flash_gd25q32c_read_status at ??:?
0x4000410f
0x40004a3c
0x40108a48: spi_flash_erase_sector at ??:?
0x4020a824: HardwareSerial::available() at ??:?
0x4020a0d6: EspClass::flashEraseSector(unsigned int) at ??:?
0x40101c82: CRSF::handleUARTin() at ??:?
0x4021d0b5: EEPROMClass::commit() at ??:?
0x40205508: ELRS_EEPROM::Commit() at ??:?
0x40205e53: TxConfig::Commit() at ??:?
0x4020545d: devicesUpdate(unsigned long) at ??:?
0x402019e6: loop at ??:?
0x40205381: devicesStart() at ??:?
0x40102244: ets_post at ??:?
0x4020cc3c: loop_wrapper() at core_esp8266_main.cpp:?
0x40103241: cont_wrapper at ??:?

</details>

[CapnBry]

Checking packet rate at with BF log at F1000 rate, one of these the TX is running at 160MHz, and the other is 80MHz. Which is which?!

[commanderguy3001]

Checking packet rate at with BF log at F1000 rate, one of these the TX is running at 160MHz, and the other is 80MHz. Which is which?!

bottom one is 80MHz, top one is 160?

[CapnBry]

Testing 80MHz vs 160MHz using DEBUG_RCVR_LINKSTATS to count packet jitter at 500Hz (my T-Pro isn't updated to do 1KHz yet) over 50,000 packets

80MHz N=50454 mean=0.53us stddev=3.02us
160MHz N=50388 mean=0.58us stddev=2.75us

So 80M had a slightly more accurate average, but with a little wider spread. Both seem close to a margin of error sort of thing. I feel like reducing the heat by reducing ESP8285 power usage is worth it, since receivers will not have any cooling and are in a terrible thermal form factor. We could always make it a Lua option if this ever becomes something that gets a real module solution, but I hope that doesn't happen nor should we approve ESP8285 modules due to their reduced flash capacity and lack of peripheral support.

[JyeSmith]

Feels like I've played this game before.