Skip to content

Add an explicit flag to the radio configuration for the Waveshare HAT…#2

Merged
rightup merged 1 commit intorightup:hardware/meshadvfrom
dahanc:non-waveshare
Oct 20, 2025
Merged

Add an explicit flag to the radio configuration for the Waveshare HAT…#2
rightup merged 1 commit intorightup:hardware/meshadvfrom
dahanc:non-waveshare

Conversation

@dahanc
Copy link
Contributor

@dahanc dahanc commented Oct 5, 2025

It shouldn't assume that just because CS is on GPIO 21, the radio module is a Waveshare HAT. For example, the MeshAdv Pi Hat uses the Ebyte E22 radio module and puts CS on 21.

…, instead of assuming only Waveshare uses CS on GPIO21
@rightup rightup requested review from Copilot and rightup October 10, 2025 20:08
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds an explicit is_waveshare boolean parameter to the SX1262 radio configuration to properly identify Waveshare HAT modules instead of relying on the CS pin being on GPIO 21. This change prevents incorrect assumptions about the hardware type when other radio modules (like the MeshAdv Pi Hat with Ebyte E22) also use GPIO 21 for CS.

Key changes:

  • Added is_waveshare parameter to the SX1262Radio constructor
  • Replaced GPIO pin-based detection logic with explicit flag checking
  • Updated example configuration to use the new flag for Waveshare HATs

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
src/pymc_core/hardware/sx1262_wrapper.py Added is_waveshare parameter and replaced pin-based detection with explicit flag
examples/common.py Updated Waveshare configuration to use the new is_waveshare flag

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Copy link
Owner

@rightup rightup left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Valid point, my original idea was to make it as hardware agnostic as possible but the reality is these devices need slightly different setups etc.

@rightup rightup changed the base branch from main to hardware/meshadv October 20, 2025 08:04
@rightup rightup merged commit e5a398c into rightup:hardware/meshadv Oct 20, 2025
3 checks passed
agessaman referenced this pull request in agessaman/pyMC_core Feb 28, 2026
…med - TODO #1 and #2

- Introduced `_pending_ack_crcs` to track pending ACK CRCs in `CompanionBase`, enhancing the handling of confirmed sends.
- Refactored `_track_pending_ack` and `_apply_ack` methods to utilize the new `_try_confirm_send` method for improved clarity and functionality.
- Updated `CompanionRadio` to clear pending ACKs upon key import and added an ACK received listener to the dispatcher for better integration.
- Enhanced the dispatcher to support asynchronous ACK handling, ensuring efficient processing of received ACKs.
rightup pushed a commit that referenced this pull request Mar 6, 2026
feat(companion): implement multi-byte path hash encoding and management
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.

3 participants