Skip to content

Fix: Luckfox Pico Pi SX1262 Timing Issue#61

Merged
rightup merged 3 commits into
pyMC-dev:devfrom
yellowcooln:dev
Apr 29, 2026
Merged

Fix: Luckfox Pico Pi SX1262 Timing Issue#61
rightup merged 3 commits into
pyMC-dev:devfrom
yellowcooln:dev

Conversation

@yellowcooln
Copy link
Copy Markdown
Contributor

This PR fixes a Luckfox Pico Pi–specific SX1262 bring-up timing issue that caused the radio to appear non-functional at normal INFO logging levels, while working at DEBUG.

On affected Pico Pi boards, the SX1262 initialization path is timing-sensitive. The additional latency introduced by debug logging unintentionally allowed RX/TX to work. At INFO, that incidental delay disappears, causing the radio to initialize in a bad state:

  • No actual on-air RX
  • No actual on-air TX
  • Logs may still indicate successful transmission

What Changed

  • Added a Luckfox Pico Pi–specific extended timing path in sx1262_wrapper.py

  • Introduced explicit settle delays between critical SX1262 bring-up steps, including:

    • Regulator mode
    • Chip calibration
    • Image calibration
    • DIO2 RF switch setup
    • Frequency set
    • Buffer base setup
    • TX power set
    • Modulation setup
    • Packet parameter setup
    • RX IRQ / gain setup
    • Initial RX_CONTINUOUS
  • Applied the same timing constant to key transitions already using generic timing delays:

    • Standby
    • TX
    • RX restore

Scope Control

  • The slower timing path is not enabled globally
  • It is only activated when the runtime board model identifies as:
    • Luckfox Pico Pi

This ensures no impact to:

  • Raspberry Pi installs
  • Luckfox Ultra
  • Other SX1262-based deployments

Why This Approach

  • Issue reproduces specifically on Luckfox Pico Pi hardware
  • Raspberry Pi with the same wrapper does not exhibit the problem
  • Broad timing changes could destabilize otherwise working radios
  • Device-tree model gating keeps the fix targeted and safe

Validation

  • Tested live on a Luckfox Pico Pi repeater with logging.level: INFO

Before:

  • Reliable operation only at DEBUG

After:

  • RX restored at INFO

  • TX restored at INFO

  • Final tested file was deployed to the live board and verified via sha256

User-Facing Outcome

  • Luckfox Pico Pi repeaters no longer require DEBUG logging for RF functionality
  • Reliable radio operation at normal INFO logging levels
  • No behavior changes for non-Pico Pi boards

@yellowcooln
Copy link
Copy Markdown
Contributor Author

Update: Narrowed Luckfox Pico Pi SX1262 Timing Fix

This has been refined based on live testing on Pico Pi hardware. The previous timing workaround was broader than necessary.

What Changed

The fix is now limited to the two transitions that actually matter:

  1. A short settle delay after setDio2RfSwitch()
  2. A short settle delay after the first RX_CONTINUOUS request during initialization

What Was Removed

All previously added broad timing delays have been removed, including:

  • No extra delay after reset / standby
  • No extra delay after regulator / calibration / image calibration
  • No extra delay after frequency / power / modulation / packet configuration
  • No extra TX / CAD restore timing changes

Timing Validation

Tested directly on Pico Pi hardware:

  • 10 ms → failed
  • 11 ms → failed
  • 12 ms → stable
  • Higher values → also stable

Current Behavior

  • Scoped only to Luckfox Pico Pi
  • Applies only two targeted delays
  • Uses:
    LUCKFOX_RADIO_TIMING_DELAY = 0.012

@rightup
Copy link
Copy Markdown
Collaborator

rightup commented Apr 29, 2026

This is a great direction and the hardware validation is appreciated. For maintainability and minimal risk, I’d suggest one small scope change:

Handle platform detection upstream (in config/runtime wiring), and keep this wrapper platform-agnostic by only exposing a configurable timing value with the existing default preserved.

I feel keeping this PR focused on radio timing only
avoids new board-detection logic/imports in core radio code
keeps default behavior unchanged for all current users
makes future board-specific tuning easier without touching low-level driver logic again
If you’re open to it, I’d support this PR with:

default timing unchanged (current value)
optional override parameter/config input for the timing delay
no in-wrapper platform/model detection code

sorry of the back and forth on this one.

@yellowcooln
Copy link
Copy Markdown
Contributor Author

Refactor: Make SX1262 Wrapper Platform-Agnostic

This change removes board-specific logic from the SX1262 wrapper and keeps the driver fully platform-agnostic.

What Changed

  • Removed Luckfox-specific board/model detection from sx1262_wrapper.py
  • Preserved default timing behavior
  • Added a new initialization parameter:
    • radio_timing_delay (defaults to existing RADIO_TIMING_DELAY)
  • The narrowed timing fix (two init transitions) is still available, but only applied when explicitly requested

Behavior

  • By default, nothing changes for existing platforms
  • The wrapper no longer contains embedded platform-specific logic
  • Platform tuning is now handled externally via configuration or runtime wiring

Usage

To apply the Pico Pi timing fix:

radio = SX1262Wrapper(..., radio_timing_delay=0.012)

@rightup rightup merged commit ba0a945 into pyMC-dev:dev Apr 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants