Dynamic packet power
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- c
- Ambito
- embedded-iot, networking
Direzione di ricerca
Start by locating the packet forwarding and radio transmit paths in the C code, then trace how destination or next-hop routing information and recorded SNR are available when a packet is repeated. Compare a static per-node power table with SNR-based scaling and check how either interacts with the global TX setting. Done means repeated packets use appropriately scaled power for the intended link while wider-mesh packets retain the configured maximum; the proposal names no files or tests.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Proposal Draft
Title: [Feature Request] Dynamic Per-Packet TX Power Scaling for Asymmetric Link Budgets
The Problem
Off-grid, solar-powered repeaters deployed to bridge a specific shadowed node (e.g., a user located in an RF depression) waste critical battery capacity and solar budget due to a single global TX power setting. A repeater is currently forced to transmit at maximum power (e.g., 1W / 30 dBm) to reach a companion node that is only a short distance away, simply because that maximum power is required for the repeater to reach the wider mesh network.
The Use Case
Hardware: A 1W-capable repeater (e.g., RAK19007 + RAK13302) powered by dual 2W solar panels, servicing a local companion node located nearby but in a terrain hole.
Current Limitation: A global set tx 22 command forces the repeater to transmit at maximum power for every packet it repeats. This drains the battery bank faster than small solar panels can replenish it during low-sun conditions, especially when repeating heavy traffic.
The Inefficiency: The link budget required to hit the nearby companion node is small, but the link budget required to reach the broader mesh is large. The repeater cannot scale its output down when it only needs to throw a packet a short distance to the known companion node.
Proposed Behavior & Ideal API
Implement dynamic TX power scaling based on the packet's destination or next-hop routing path.
Behavior: When repeating a packet where the destination is a known local node with a high Signal-to-Noise Ratio (SNR), the radio dynamically drops the TX register (e.g., to 10-15 dBm) for that specific transmission. When repeating a packet out to the wider mesh, it utilizes the maximum configured global TX setting.
Implementation Options: This could be achieved via a user-defined static power routing table linking specific Node IDs to specific TX power limits, or by automatically scaling the output power based on the last recorded SNR of the target node.
Outcome: Drastically reduces peak current draw on solar-constrained repeaters and minimizes unnecessary RF noise on the local airwaves.
- Lingua principale
- C
- Stelle
- 3.9k
- Fork
- 1.5k
- Merge medio
- 1g 1h
- PR unite (30g)
- 26
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di meshcore-dev/MeshCore
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
meshcore-dev/MeshCore#3622 ·
I maintainer di solito rispondono entro 1 giorno
-
[Feature Request] Set Australia (Mid) Preset to automatically enable 2 byte default path hash sizeAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
meshcore-dev/MeshCore#3571 · 5 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
meshcore-dev/MeshCore#3567 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
RTC_RX8130CE writes and reads the one-hot WEEK register as a numberForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
meshcore-dev/MeshCore#3549 ·
I maintainer di solito rispondono entro 1 giorno
-
Repeater: CLI reply to 'setperm <key> 0' is lost when the removed ACL entry sits before the requester (stale ClientInfo* after array shift)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
meshcore-dev/MeshCore#3513 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di meshcore-dev/MeshCore
Issue simili
-
v9.6.0: CMake incorrectly enforces presence of libevdevForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug] Unhandled ValueError terminates watchdog thread when GISRC value contains multiple colonsApertabug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
bug Component component: net
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
RT-Thread/rt-thread#11913 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
contiki-ng/contiki-ng#3289 ·
I maintainer di solito rispondono entro 3 giorni
-
area:docs help wanted type:enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno