[RAK3401/RAK13302] Intermittent RX/TX failure (error 4) — possible GPS Slot D conflict? #3738

Activity

1. Seeker1028

   changed the title [-][RAK3401/RAK13302] v1.18.0 regression: RX/TX failure (error 4), resolved by downgrading to v1.17.1[/-] [+][RAK3401/RAK13302] Intermittent RX/TX failure (error 4) — possible GPS Slot D conflict?[/+] on Oct 30, 2026
2. Seeker1028 commented on Oct 30, 2026

   

   Seeker1028

   on Oct 30, 2026

   Author

   More actions

   Update — Additional testing and possible GPS conflict

   I have some important new findings that change my original assessment.

   The problem is NOT exclusive to v1.18.0. After downgrading to v1.17.1, the repeater initially operated normally, transmitting and receiving successfully. However, after 40 minutes, it stopped communicating and returned to the same failure state observed under v1.18.0.

   Diagnostic output from v1.17.1 after the failure:

   stats-core
     -> {"battery_mv":4167,"uptime_secs":687,"errors":4,"queue_len":1}
   
   stats-packets
     -> {"recv":0,"sent":0,"flood_tx":0,"direct_tx":0,"flood_rx":0,"direct_rx":0,"recv_errors":0}
   
   stats-radio
     -> {"noise_floor":0,"last_rssi":0,"last_snr":-20.00,"tx_air_secs":0,"rx_air_secs":0}
   

   The processor continued running normally, but the radio stopped transmitting and receiving. Attempts to generate a zero-hop advertisement were unsuccessful.

   Possible cause: GPS module in Slot D

   Both affected RAK19007 builds have the following hardware:

   • RAK3401
   • RAK13302 1W LoRa module
   • RAK GPS module installed in Slot D
   • Temperature/humidity sensor
   • OTAFIX bootloader

   I've since learned that the RAK13302's SX1262 radio-control signals may conflict with signals exposed on Slot D.

   I have now physically removed the GPS module from one repeater while leaving the temperature/humidity sensor installed.

   Initial results without GPS are promising: the repeater is operating normally so far. However, testing is still ongoing, and I have not yet established whether removing the GPS permanently resolves the problem.

   I'll update this issue again after extended testing.

   At this point, this appears to be a possible hardware pin-assignment or peripheral-initialization compatibility issue rather than a regression specific to v1.18.0.

   I'd appreciate confirmation from the developers about whether the RAK3401 + RAK13302 combination officially supports a GPS module installed in Slot D on the RAK19007.
3. Seeker1028 commented on Oct 30, 2026

   

   Seeker1028

   on Oct 30, 2026

   Author

   More actions

   Update — Root cause strongly indicated: RAK12500 GNSS in Slot D

   After extensive troubleshooting, I believe I've isolated the cause of the RX/TX failures on my RAK3401 + RAK13302 (1W) repeaters.

   With the RAK12500 GNSS module physically removed from Slot D, my repeater has operated all day on official MeshCore v1.18.0 without a single error or communication failure.

   Previously, with the RAK12500 installed, both v1.17.1 and v1.18.0 developed errors:4 (ERR_EVENT_STARTRX_TIMEOUT), stopped transmitting and receiving, and reported zero packet activity.

   Additional observations

   • RX/TX now operate normally on v1.18.0.
   • No further error 4 events after extended operation.
   • Packet transmission, reception, and forwarding are functioning correctly.
   • Serial CLI commands respond noticeably faster with the RAK12500 removed.
   • The temperature/humidity sensor remains installed.
   • The OTAFIX bootloader remains unchanged (0.9.2-OTAFIX2.3-BP1.4).
   • Firmware and radio settings are otherwise unchanged.

   Suspected hardware pin conflict

   The RAK3401 firmware defines:

   • P0.09 (WB_IO5) = SX1262 BUSY
   • P0.10 (WB_IO6) = SX1262 DIO1 interrupt

   On the RAK19007, Slot D exposes these same signals, which are used by the RAK12500 GNSS module for PPS and reset functions.

   This appears to create a direct pin conflict between the RAK12500 GNSS module and the RAK13302 SX1262 radio.

   Firmware reference:
   https://github.com/meshcore-dev/MeshCore/blob/81dbae5/variants/rak3401/variant.h

   Corrected conclusion

   My original conclusion that this was specifically a v1.18.0 regression was incorrect.

   Both firmware versions exhibited the failure with the RAK12500 installed. Downgrading to v1.17.1 temporarily restored operation, but the radio eventually stopped communicating again.

   After removing the RAK12500, v1.17.1 operated without errors for over 30 minutes. I subsequently upgraded back to v1.18.0, which has now operated continuously throughout the day without errors.

   This strongly suggests a hardware pin-assignment or peripheral compatibility issue involving the RAK12500 in Slot D, rather than a firmware regression.

   Recommendation

   I recommend documenting this potential incompatibility for users combining the RAK3401, RAK13302, and RAK12500 on the RAK19007 baseboard.

   It would also be helpful to determine whether the RAK12500 can be supported through alternative pin assignments or another hardware configuration.

   I have a second RAK3401/RAK13302 repeater with the same hardware configuration and similar symptoms. Testing on that unit remains to be completed.
4. enigmaspb commented on Nov 10, 2026

   

   enigmaspb

   on Nov 10, 2026

   More actions

   Check conflict https://learn.rakwireless.com/hc/en-us/articles/26743306645143-How-To-Use-the-WisBlock-IO-Pin-Mapping-Tool