Skip to content

Pass TELEM_RAK12500_ADDRESS to the RAK12500 I2C probe (iteration branch) - #9

Open
ptr727 wants to merge 1 commit into
devfrom
work/rak12500-i2c-address
Open

ptr727 wants to merge 1 commit into
devfrom
work/rak12500-i2c-address

Conversation

@ptr727

@ptr727 ptr727 commented Sep 17, 2026

Copy link
Copy Markdown
Owner

Branch renamed, PR re-opened. This branch was fix/rak12500-i2c-address and carried
#7, including the note recording that
CodeRabbit never reviewed it. It was renamed to work/rak12500-i2c-address to match this fork's
convention — work/* is the iteration log, fix/* is the squashed branch that goes upstream —
and GitHub closed #7 on the rename rather than following it. Nothing in the code changed; the
head is still 89e73970.

The bug

src/helpers/sensors/EnvironmentSensorManager.cpp defines the RAK12500's I2C address inside an
#ifndef, which is the file's convention for "a variant may override this":

#ifndef TELEM_RAK12500_ADDRESS
#define TELEM_RAK12500_ADDRESS   0x42     //RAK12500 Ublox GPS via i2c
#endif

The probe then never passes it:

if (ublox_GNSS.begin(Wire) == true){

SFE_UBLOX_GNSS::begin is declared
bool begin(TwoWire &wirePort = Wire, uint8_t deviceAddress = 0x42, ...), so the address actually
probed is the library's own default, not the macro.

grep -rn TELEM_RAK12500_ADDRESS src/ variants/ platformio.ini examples/ returns only the two
lines of the definition itself. It is the one TELEM_*_ADDRESS in this file that nothing consumes
— every other one reaches its probe through the sensor table (TELEM_AHTX_ADDRESS,
TELEM_BME280_ADDRESS, TELEM_SHT4X_ADDRESS, …) or a driver constructor (TELEM_INA219_ADDRESS,
TELEM_INA226_ADDRESS).

Why it is latent, and why it is still worth fixing

No variant in the tree overrides the macro, and the library's default is also 0x42, so nothing
diverges today. The defect is that the knob exists and does nothing: a variant that overrode it —
which the #ifndef invites — would silently probe one address while every other reference to the
macro named another, and the symptom would be a GPS that is simply not detected.

The fix

if (ublox_GNSS.begin(Wire, TELEM_RAK12500_ADDRESS) == true){

This is the only ublox_GNSS.begin call site in the tree.

Verification

  • Signature confirmed against the pinned library
    (SparkFun_u-blox_GNSS_Arduino_Library.h:715), not assumed.
  • RAK_4631_repeater builds. The RAK_WISBLOCK_GPS block is compiled into that env
    (ENV_INCLUDE_GPS && RAK_BOARD && !RAK_WISMESH_TAG), confirmed by the ublox_GNSS symbol and
    the SparkFun translation unit in the resulting ELF, so the changed line is actually built.
  • Not verified on hardware. The RAK4631 available here carries a CASIC receiver on the UART
    rather than a u-blox on I2C, so it takes the serial fallback and never reaches this line. A
    board with an actual RAK12500 would be needed to exercise it, and since the address is unchanged
    in-tree the observable behaviour would be identical either way.

Notes

This is a detection change rather than a reporting one, which is why it was kept out of the
hwinfo PR (#5) when CodeRabbit raised it there. Independent of that branch and of #6.

Not upstream yet — this is the fork bake.

Summary by CodeRabbit

  • Bug Fixes
    • Improved RAK12500 GNSS initialization by using the configured I2C address, helping ensure reliable device communication.

`TELEM_RAK12500_ADDRESS` is defined inside an `#ifndef`, so a variant can override it, but
`ublox_GNSS.begin(Wire)` never receives it and the SparkFun library falls back to its own
default. The macro is the only `TELEM_*_ADDRESS` in this file that nothing consumes; every
other one reaches its probe through the sensor table or a driver constructor.

No variant overrides it today and the library default is also 0x42, so this changes no
behaviour in the tree as it stands. It makes the knob mean what it says.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings September 17, 2026 14:17
@coderabbitai

coderabbitai Bot commented Sep 17, 2026

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 59b7cab5-fd19-41f4-9bcd-34e03d35c63c


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟢 Approval recommended

The change is minimal, matches the intended configuration behavior, and no issues were found in the updated call site.

Pull request overview

This PR fixes a latent configuration bug in the RAK12500 (u-blox GNSS over I2C) detection path by ensuring the variant-overridable TELEM_RAK12500_ADDRESS macro is actually used when probing the device.

Changes:

  • Pass TELEM_RAK12500_ADDRESS as the I2C address argument to ublox_GNSS.begin(...) during RAK12500 initialization.
File summaries
File Description
src/helpers/sensors/EnvironmentSensorManager.cpp Uses the configured (and variant-overridable) RAK12500 I2C address in the GNSS probe call.
Review details
  • Files reviewed: 1/1 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@ptr727

ptr727 commented Sep 17, 2026

Copy link
Copy Markdown
Owner Author

Squashed onto upstream/dev cdd04077 as fix/rak12500-i2c-address @ 85f016be and filed upstream as meshcore-dev/MeshCore#3434. The clean branch's diff against upstream/dev is byte-identical to this branch's diff against 0ec5ed5f. This branch stays the iteration log: upstream review feedback lands here first, then gets re-squashed onto the clean branch.

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