Platform
Android App
What feature do you want?
Mainline firmware has added a new CMD_SEND_RAW_PACKET to the companion API. It's currently merged into the dev tree (meshcore-dev/MeshCore@c588540), so will be in 1.16 when that is released.
It allows a client app to build and send any packet itself. (And the companion will verify the packet is correcty formed before sending.) So when available, the MeshMapper app can avoid having to add and delete the warmapping channel from the companion device. This means less state/management overhead, and you don't have to worry about the channel table being full already on the companion. You also wouldn't have to set/restore the region transport code or the path hash size in the companion, either. The MeshMapper app would simply do all of that on its own when building the raw GRP_TXT packet.
Why do you need it?
MeshMapper app already uses the rxLog to decode messages without interfering with state on the companion (e.g., it won't consume messages from the Public channel queue, DMs, etc while the app is running, so the user can see them when they switch back to their main messaging app). Using the new CMD_SEND_RAW_PACKET provides the same type of non-destructive functionality, but in the outbound/transmit path instead of the receive path.
How important is this?
Medium - Nice to have
Anything else?
No response
Platform
Android App
What feature do you want?
Mainline firmware has added a new CMD_SEND_RAW_PACKET to the companion API. It's currently merged into the dev tree (meshcore-dev/MeshCore@c588540), so will be in 1.16 when that is released.
It allows a client app to build and send any packet itself. (And the companion will verify the packet is correcty formed before sending.) So when available, the MeshMapper app can avoid having to add and delete the warmapping channel from the companion device. This means less state/management overhead, and you don't have to worry about the channel table being full already on the companion. You also wouldn't have to set/restore the region transport code or the path hash size in the companion, either. The MeshMapper app would simply do all of that on its own when building the raw GRP_TXT packet.
Why do you need it?
MeshMapper app already uses the rxLog to decode messages without interfering with state on the companion (e.g., it won't consume messages from the Public channel queue, DMs, etc while the app is running, so the user can see them when they switch back to their main messaging app). Using the new CMD_SEND_RAW_PACKET provides the same type of non-destructive functionality, but in the outbound/transmit path instead of the receive path.
How important is this?
Medium - Nice to have
Anything else?
No response