Add Inhero MR2 board variant (nRF52840/RAK4630 solar repeater) - #3132
Draft
liekmarflow wants to merge 5 commits into
Draft
liekmarflow wants to merge 5 commits into
liekmarflow wants to merge 5 commits into
Conversation
liekmarflow
changed the title
liekmarflow
added a commit
to liekmarflow/MeshCore
that referenced
this pull request
Aug 8, 2026
…ev#3131/meshcore-dev#3132) - CONTEXT.md getrackt Stand-Block neu: Issue + beide PRs mit Branch-Zeigern und Naechster-Schritt- Ablauf nach Merge von meshcore-dev#3131. Ueberholte Doktrin ('kein PR-Verkehr zu upstream') entfernt; stattdessen die Sicherungsregel: PR-Branches immer von upstream/main schneiden. Feature-Branches als live PR-Koepfe markiert (nicht loeschen). CONTEXT.md aus .gitignore genommen - auf main getrackt ist sie PR-sicher, weil PR-Branches nie von Fork-main abstammen.
liekmarflow
force-pushed
the
feature/inhero-mr2-variant
branch
from
August 9, 2026 19:22
fd7274b to
4ec5a55
Compare
liekmarflow
force-pushed
the
feature/inhero-mr2-variant
branch
2 times, most recently
from
August 16, 2026 06:10
7f81a00 to
114eda0
Compare
liekmarflow
changed the title
liekmarflow
force-pushed
the
feature/inhero-mr2-variant
branch
2 times, most recently
from
August 21, 2026 16:49
bd8a5c7 to
732262c
Compare
3 tasks
liekmarflow
added a commit
to liekmarflow/MeshCore
that referenced
this pull request
Aug 21, 2026
… of the story The "Relation to upstream" section still described the variant as a standalone out-of-tree product fork. That has not been true since 2026-08-08: meshcore-dev#3130 (hardware request), meshcore-dev#3131 (board hooks) and meshcore-dev#3132 (the variant itself) are open upstream, and the fork releases are the interim until those land. It also left the April withdrawal unexplained. The board was not available yet and CE certification was still in progress; both are settled now, which is the reason the variant is being proposed again.
liekmarflow
force-pushed
the
feature/inhero-mr2-variant
branch
from
August 28, 2026 07:48
771c4c4 to
0701fa0
Compare
liekmarflow
force-pushed
the
feature/inhero-mr2-variant
branch
from
August 28, 2026 13:26
0701fa0 to
0e274c4
Compare
Two no-op virtuals on MainBoard, so a variant can do these things without core changes: - tick(): called from the simple_repeater and simple_sensor main loops. Lets a board feed its watchdog and run periodic housekeeping. - queryBoardTelemetry(CayenneLPP&): simple_repeater asks the board for extra telemetry channels, gated by TELEM_PERM_ENVIRONMENT. Variant-specific CLI is already covered by MainBoard::handleCommand(), so this adds nothing for that. Both defaults are no-ops, so existing variants build and behave unchanged. Used by the Inhero MR2 variant (separate PR).
Application-specific repeater platform for autonomous off-grid operation, in production and field-deployed: - RAK4630 core module (nRF52840 + SX1262), 45 x 40 mm - BQ25798 buck/boost charger: universal solar input 3.6-24V with MPPT, JEITA temperature-controlled charging - INA228 coulomb counter for SOC tracking and 7-day energy statistics - Li-ion, LiFePO4, LTO and Na-ion battery chemistry profiles - RV-3028 RTC wakeup with low-voltage system sleep (<500uA) and autonomous recovery - BME280 environment telemetry - board.* CLI namespace for configuration and diagnostics, dispatched through MainBoard::handleCommand() - slim variant README; the full documentation set (EN/DE) is maintained in the vendor fork Build environments: Inhero_MR2_repeater, Inhero_MR2_repeater_bridge_rs232, Inhero_MR2_sensor.
liekmarflow
force-pushed
the
feature/inhero-mr2-variant
branch
from
September 20, 2026 12:54
42ede8f to
35905cb
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3130. Builds on #3131 (board hooks) — the diff includes that commit
until it lands. This remains a draft; I will rebase and mark it ready after
#3131 is merged.
Adds the Inhero MR2, a purpose-built solar repeater platform that is in
production and shipping:
https://shop.inhero.de/en/products/inhero-mr-2-solar-mesh-repeater-board-rak4630-sx1262-mppt-red-ce-gepruft
I am the hardware manufacturer; I can test changes on real hardware and am
happy to be tagged on anything affecting this variant.
Where the code lives: the MR2 implementation is under
variants/inhero_mr2/, with its board definition inboards/inhero_mr2.json.This includes the charger and current-monitor drivers, chemistry profiles,
SOC accounting, solar recovery, low-voltage sleep and the MR2 sensor manager
with optional QNH correction. The generic changes visible in the diff are
#3131's two no-op hooks; the
board.*CLI uses the existingMainBoard::handleCommand()hook.Hardware: RAK4630 (nRF52840 + SX1262), BQ25798 buck/boost charger with
universal 3.6–24 V solar input and MPPT, INA228 coulomb counter, RV-3028
RTC, BME280, 45 × 40 mm, CE-certified (RED 2014/53/EU).
What the variant provides:
per-chemistry charging and low-voltage thresholds. Battery selection and
charger settings are configurable through the CLI and persist across reboots.
Li-ion and LiFePO4 use JEITA temperature control; LTO and Na-ion run without
JEITA supervision. The firmware does not enforce a Na-ion-specific charging
temperature window; the cell manufacturer's limits still apply.
(
set board.jeitaignore). It requires explicitly configured battery capacityand a maximum charge current no greater than 0.05C. The override bypasses
both the cold and hot JEITA cutoffs.
a time-to-live prediction.
Chemistry changes apply the new threshold immediately; alert-level checks
and periodic voltage polling cover missed interrupts. Each low-voltage wake
restores the configured charge-enable state and maintains solar-input
qualification and MPPT before returning to sleep.
toggle independently of ADC/VBUS readings, with a five-minute cooldown.
Telemetry starts a fresh ADC conversion immediately after clearing HIZ and
requires a fresh completion flag and successful voltage/current reads.
Invalid solar measurements are reported as unavailable and omitted from LPP.
VSYSMINis restored after every CELLsetting, retaining the existing VREG/ICHG restoration and 60 C thermal
regulation. The stored MPPT preference is applied after chemistry and JEITA
configuration.
get board.mpptdiagreads requested/actual MPPT, VSYSMIN,VINDPM, VSYS_MIN, PG, CELL, ICHG and VREG with checked register reads.
Charging profiles and battery sleep/wake thresholds are unchanged.
set board.altitude <m>stores the installation altitude (−500 to 9000 m);
get board.altitudereports it. Pressure telemetry then carries QNH and altitude telemetry the
configured height.
set board.altitude clearrestores station pressure andpressure-derived altitude. Without a configured height, behaviour is unchanged.
board.*configuration and diagnostic commands. The full EN/DE documentationis maintained by the manufacturer and linked from the slim
variants/inhero_mr2/README.md.Inhero_MR2_repeater,Inhero_MR2_repeater_bridge_rs232,Inhero_MR2_sensor.Field record: I run a part of the MeshCore repeater infrastructure for a
region in Saxony, Germany — hilltop and mining-tower sites with links from
70 km to over 100 km, plus a number of small birdhouse-style nodes. Almost
all of them are MR2 by now, so this board already carries a significant share
of the MeshCore traffic here.
A representative small node, read out of the MeshCore app on 2026-08-19:
123 days of continuous uptime on solar, 701,487 packets sent and 2,003,527
received, 4 d 20 h of TX airtime (596 ms per packet, one packet every 15 s
on average), 35 % forward ratio, battery still at 100 %. Measured
consumption in real repeater operation is ~0.98 Wh/day.
Another unit ran 140 days before it surfaced a charge-accounting bug; that
bug is reproduced, verified on two battery chemistries, and fixed in this
branch.
Background on the design and the field failures that drove it:
https://shop.inhero.de/en/blogs/news/warum-es-das-mr2-gibt
Build and checks: all three MR2 environments were rebuilt successfully at
ab02af10on 2026-09-21. All 78 UVLO/INA228/solar/ADC host scenarios were rerunsuccessfully. New checks cover 10 VSYSMIN/chemistry scenarios, three rejected
regressions, and MPPT diagnostic decoding, read failures and output bounds.
The earlier checks at
35905cb5on 2026-09-20 also coveredRAK_4631_repeaterand 38 MR2 sensor-manager scenarios, including detection,address fallback, permissions, telemetry channels and optional GPS. Altitude persistence and the board CLI are checked for live
updates, clearing, invalid values and storage failures. A 47,505-case comparison
confirms the QNH calculation against the ViaMesh implementation. Peripherals are
mocked in these tests; hardware validation of this dev-based branch and its new
variant-local BME280 integration is still pending.
MPPT update scope (2026-09-21): only MR2 variant files and regression tests
were added or changed. #3131 and the generic core remain unchanged by this
update; this PR retains its existing draft/dependency status. The downstream
stable MR2 release
contains the same MPPT fix. Its Na-ion repeater RC was confirmed on hardware:
5.20 V panel readings while battery charging current dropped to about 19–27 mA,
with MPPT cfg/hw = 1/1, VSYSMIN = 2500 mV and VSYS_MIN = 0. This observation
is not a hardware-acceptance claim for this dev-based PR or for LTO thermal
behaviour.
Transparency: this variant was developed with AI assistance under my
continuous engineering direction and review, followed by a full
pre-submission review pass. Stated upfront in line with this project's
position on code provenance. I manufacture this board and run it in the
field; I will keep the variant building and correct, and I am happy to be
tagged on anything that touches it.