CRSF-over-USB on Ranger Micro `__pinMode(): Invalid pin selected` when setting CRSF to GPIO 3/1

[teal swift]

Hello!
I've been trying to create a "ground control station" that can send CRSF to a drone. The closest thing I've seen someone do is Method 2 from https://github.com/kaack/elrs-joystick-control (done with a BetaFPV Micro instead).
The Ranger Micro has Backpack default pins at 16/17 (RX/TX), although I've had more apparent success setting CRSF Serial Pins to 3/1 in /hardware.html:
While I haven't gotten the module to acknowledge it's connected, I have seen some errors (from what I assume is the boot log) when running python -m serial.tools.miniterm COM6 115200:

--- Miniterm on COM6  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
[   943][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected
[   943][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected
[   944][E][esp32-hal-gpio.c:102] __pinMode(): Invalid pin selected

I don't see any output at 420000 baud.
The LED continues to blink orange even when I send CRSF packets at 420000 baud.

My current theory is that ESP32 Arduino core's pinMode() rejects GPIO 1 and 3 because they are reserved. The firmware tries to configure CRSF on those pins, the HAL refuses, CRSF UART never comes up, hence the silence and blinking orange. If that's right, this is a platform-level limitation on ESP32 modules that doesn't apply to STM32 modules like the BetaFPV 1W Micro, which would explain why elrs-joystick-control works there but not here.

Questions:

1. Is this diagnosis correct, or am I missing something? (my explanation admittedly doesn't feel complete as there are 3 errors when I changed 2 pins)
2. Has anyone successfully done CRSF-over-USB on a Ranger Micro (or any ESP32-based ELRS TX)?
3. Is there a firmware config flag, or a runtime "passthrough" mode, that properly routes CRSF to UART0 on ESP32 targets without hitting the HAL guard?
4. If not: is a custom firmware build the only path, or should I just get a BetaFPV/STM32-based module?

[livid jungle]

✨AI-Generated response✨

Your diagnosis regarding GPIO 1 and 3 on the ESP32 is correct; these pins are indeed the hardware UART0 pins for the USB serial bridge and are typically reserved, causing pinMode() to fail if accessed by the application firmware.

1. Diagnosis: Yes, attempting to use GPIO 1 and 3 via the hardware pin mapper often triggers these esp32-hal-gpio errors because they are tied to the USB-to-UART chip.
2. Success: CRSF-over-USB on ESP32 modules is challenging due to pin conflicts. Most users successfully implementing custom GCS setups with ELRS use modules or targets that allow for dedicated, non-conflicting UART pins or use the built-in Backpack functionality if available.
3. Firmware Configuration: There is no standard config flag to "force" UART0 through the HAL protection. Routing serial protocols to internal USB pins usually requires a custom target definition in the build to remap the pins, provided there isn't a hard-coded conflict in the ESP32 partition.
4. Recommendation: A custom firmware build would be the required path if you are determined to use that specific hardware. However, if reliability is your goal, migrating to an STM32-based module is often the path of least resistance, as they do not have the same HAL pin constraints for serial communication.

For further technical context, consult the Advanced Technical Info page. For specific target configuration and pin mapping, refer to the DIY TX Target guide.

---

please follow up in #help-and-support or #general-quad-help

-# {'cause': 'thread creation'}

[uncut pier]

3,1 for serial rx, tx respectively would've worked:

[teal swift]

Here's the top of my hardware.html

[uncut pier]

doesn't look like it was saved..

[teal swift]

sorry I cropped out the yellow banner above

settings persist on reboot

[uncut pier]

try the elrs buddy.. I didn't had to do much on mine..
set serial rx to 3
set serial tx to 1
save and reboot

connect with the elrs buddy to test

3, 1 are the gpio connected to the uart adapter that's connected to the usb port.
it is what's used as it is also the main serial pins used to flash the module via uart/usb

[teal swift]

Interesting, I tried 921600 bps and got this output

went down to 460800 and then back up to 921600bps and now everything appears fine?

[uncut pier]

if the TX is set with fast packet rate, anything lower than 921K won't work

though per your screenshot, it's at 250Hz.. and 400K should've worked

note that there are only a few baud rates that TX modules work on: i.e. edgeTX baud rates

[teal swift]

thanks for sharing elrsbuddy

[teal swift]

Sounds like this is why I couldn't get my scripts to work at 420000

[uncut pier]

yeah, 420K isn't a "radio" baud rate

it is more of a flight controller-side baud rate

the safest baud you wanna use is 921K baud. that should cover all but 1KHz packet rate

[teal swift]

TYSM! LED shows connected when running my script now