GUVWAF
GUVWAF
> But we know who we received the packet from, as in which node transmitted the packet that we received, right? No. We only know who the *original* transmitter was....
No, unfortunately not. [The header](https://meshtastic.org/docs/overview/mesh-algo/#layer-1-unreliable-zero-hop-messaging) only includes the *original* sender and this is never changed when relaying.
That’s indeed also a solution, but that would need to be for version 3.0. However, it also changes the routing logic because then each relayer decides whether the packet still...
It's a pretty simple calculation which I would take with a grain of salt: https://github.com/meshtastic/firmware/blob/1085b54069e426b592f7d458548de6e485f72c8b/src/graphics/Screen.cpp#L833 So it seems you're not getting an SNR higher than 7dB. The V2 has a...
Added the high-priority label as it seems to cause ACK failures quite easily, because transmitting triggers the touch button (on a T-Echo) causing multiple e-ink updates. Conclusion of a discussion...
I think for the T-Echo this is not an issue anymore now that it has partial updates which also causes it not to trigger the touch button anymore. I can...
I would also like to propose having a way to show whether a sent message was acknowledged. I don't think it's worth to store transmitted messages as well; a small...
I agree with Garth and Andre. The suggestion to let it send on a different channel at each opportunity is good, but then again if you want frequent updates on...
> For use case, I want my family to know exactly where I am, but I only want the world at large to see approximate location. Assuming you don't want...
This issue seems specific to the RAK4631 + Ethernet combination. A related issue was closed because it was assumed to be fixed: https://github.com/meshtastic/firmware/issues/2242, but it seems that is not the...