Hello Mr. Firdaus,
Thank you for the follow-up and for highlighting the DC characteristics for pins 20 and 21. We have adjusted our hardware toward your reference (Q8/Q9 orientation, 10 kΩ from VDD_EXT to module RXD1 / SW6-2, removal of the external RESET_N pull-up, and GNSS VCC at pin 23 ≥ 3.1 V after correcting our board power path). Below are direct answers to your three questions, then our remaining issue.
1. How did we try to get NMEA output — ESP32 UART or from the GNSS module directly?
We tried both, but not by probing pins 20/21 directly at the module.
- ESP32 path (intended product use): UART1 on GPIO18/19 through our level shifters, with SW6 = RUN. For bring-up we often hold ESP in reset (EN low) so the ESP does not drive the bus.
- CH340C path (bench / flash): The same adapter we have used successfully with LC29H breakout boards. On the KartHUD PCB we connect CH340 TX → GPS1 pin 2, CH340 RX → GPS1 pin 1, GND → GPS1 pin 3, 3.3 V I/O, 115200 8N1. SW6 = FLASH selects the dongle path through Q9. We do not apply CH340 VCC to GPS1 pin 4 for module power; the board supplies GNSS power. We added a bodge so Q9 base bias is fed from
3V3GNSS (pin 4 / GPS1_VCC_IN was too low when pin 4 was unused).
We have not seen NMEA on either path on this PCB. On a scope/DMM, TXD1 (pin 20) sits at about 2.81 V with no sustained UART activity; RXD1 (pin 21) is about 2.84 V at idle after the RX pull-up and shifter work.
2. Can we try output directly from the GNSS module (bypass the ESP32)?
Yes — that is our primary bench configuration. ESP traffic is disabled (EN held low or ESP not driving UART), SW6 = FLASH, and we use CH340 on the GPS1 header only as above. This bypasses the ESP32 while still going through our Q6/Q7 (TX out) and Q9 (RX in) circuits as per the integrated design — we are not wiring the CH340 straight to module pins 20/21.
We verified multiple CH340C adapters on breakout boards (same module, same tool versions); those adapters work for NMEA and flashing. On the KartHUD board, with the same adapters and module, we still get no UART data on GPS1 RX at 115200 (or other baud rates we tried).
3. Have we tried to re-flash the firmware?
Yes — that was one of the first steps. We use QGNSS with the same CH340C setup (SW6 = FLASH, GPS1 wiring as above).
The tool does not get past the “reset module” prompt. We have tried:
- Pulling RESET_N (pin 8 /
IODNP test pad) to GND for more than 100 ms, then releasing
- A full power cycle (removing USB/battery so module
VCC at pin 23 actually drops, not only ESP reset)
In all cases, QGNSS does not appear to detect a successful restart. We suspect this is related to there being no UART traffic from the module to begin with (nothing on GPS1 RX for the tool to synchronize with), but we would appreciate your confirmation of what the tool expects after reset (e.g. a specific boot message or baud).
DC characteristics (pins 20 & 21)
We are following the documented levels: idle TXD1 ~2.8 V (VDD_EXT domain), RXD1 biased via 10 kΩ to VDD_EXT, and host TX into the module through Q8/Q9 rather than 3.3 V direct on pin 21. We understand we must not “sag” TXD1; we are focusing on correct level shifting on the host side. We are still verifying with a scope that RXD1 reaches VIL/VIH when CH340 transmits.
Could you please advise on:
- For QGNSS, is a bootloader or banner on TXD1 after reset required for the tool to recognize that the module has restarted?
- With D_SEL1/D_SEL2 left floating (default UART mode on our PCB), is that sufficient for UART firmware upgrade, or is download-mode strapping on D_SEL also required for LC29H(BA)?
- If TXD1 is idle at ~2.8 V with no TX edges for an extended period after valid VCC and reset, but the same module still works on a breakout board, should we treat the issue as host PCB interface rather than a defective module?
Thank you again for your help.
