Questions about the PacketRouter trait

[tallavi]

Hi,

I’m playing around with a couple of LILYGO T-Beam v1.2 devices . I’m interfacing with them on a raspberry pi using rust code and the meshtastic crate (protobuf API over serial).

I’m having trouble grasping the concept of the PacketRouter trait:

1. handle_packet_from_radio - this method is never called. Instead I am getting the FromRadio packets using the BroadcastReceiver I got from StreamApi::connect() method. So why does PacketRouter::handle_packet_from_radio even exists?

2. handle_mesh_packet - this method is being called, but I also get some of the Mesh Packets using the broadcast receiver mentioned above, as Mesh Packets is one of the payload variants of FromRadio. Why some of the packets are received on the broadcast receiver and some by invoking the method of the PacketRouter? What’s the difference?

More in general on what I’m trying to achieve: Aside from using meshtastic to send/receive text packets between nodes, I’m trying to get the GPS location locally. I have no need for this information to be transmitted, I just need it transferred locally via serial to the controlling device.

3. Is there a way to use PacketRouter to tell the module to skip the transmission of the location packets to other nodes?

Thanks in advance.

[krant]

Hi @tallavi, you could look into an example of using handle_packet_from_radio. We have a consensus that API should be improved somehow, but there are no specific suggestions on how to do that yet.

[andrewdavidmackenzie]

I have similar questions about PacketRouter.

I am using the stream_api and the receiver to get packets from the radio to display in my UI.

I would like to send also using the ConnectedStreamApi::send_text() method, but it requires an implementation of a PacketRouter.

I don't intend to do anything else, and wonder why the router is required to send (docs mention an echo functionality...).

Could the trait provide a default implementation and that could be used by apps that only want to send and receive, and not be involved in routing?

[andrewdavidmackenzie]

@lukipuki Do you have any suggestions on this. I'm looking at the other language (swift, android) app implementations to try and work out how to send, implementing some kind of PacketRouter.

This is the missing part for me to complete an initial alpha version of my Iced app for meshtastic.

thanks for any help

[andrewdavidmackenzie]

I eventually dug into this, and the implementation was simpler than I had imagined, and more related to my app than this crate.

Maybe provide an extremely simple implementation example in doc comment - the simplest would be creating the Packet router with "my_node_num" and then using that in the trait method to return the node number.

Implementing it I learned that the message I send is echoed back and "received" by these methods, and I use that to show the message as "sent" in the UI.

I'll try to do a PR showing all the above, which I hope would allow you to close this issue.

[tallavi]

Yes, my packet router implementation is the same, and I suspect that for many others too. I believe this default implementation can be included in the crate, and allow to optionally extend it for more complicated cases.

But the questions 1+2 at the beginning remain. I don't understand what is the idea behind it, why it is needed. It's strange that I need to listen to a packet to understand my id, retain it, so that the crate can ask for it when it needed. Obviously this functionality could have been completely abstracted inside the crate. What's the design choices that led to having the consumer provide this. And of course, I still don't understand what the other two methods suppose to do. Which use cases do they serve.