Dynamic packet power
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- c
- Área
- embedded-iot, networking
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- C
- Estrellas
- 3.9k
- Forks
- 1.5k
- Merge medio
- 1 d 1 h
- PR fusionados (30 d)
- 26
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de meshcore-dev/MeshCore
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
meshcore-dev/MeshCore#3622 ·
Los mantenedores suelen responder en 1 día
-
[Feature Request] Set Australia (Mid) Preset to automatically enable 2 byte default path hash sizeAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
meshcore-dev/MeshCore#3571 · 5 reacciones ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
meshcore-dev/MeshCore#3567 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
RTC_RX8130CE writes and reads the one-hot WEEK register as a numberPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
meshcore-dev/MeshCore#3549 ·
Los mantenedores suelen responder en 1 día
-
Repeater: CLI reply to 'setperm <key> 0' is lost when the removed ACL entry sits before the requester (stale ClientInfo* after array shift)Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
meshcore-dev/MeshCore#3513 ·
Los mantenedores suelen responder en 1 día
Todos los issues de meshcore-dev/MeshCore
Issues similares
-
Bug Status: Needs Triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
v9.6.0: CMake incorrectly enforces presence of libevdevPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
IoTSDK
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Azure/azure-iot-sdk-c#2776 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
-
[Bug] Unhandled ValueError terminates watchdog thread when GISRC value contains multiple colonsAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día