Node view improvement in App

Hello

I am working on the node view in the Android App, I am putting a battery indicator and last communication info.

I don’t know if we want the exact time to be displayed, or simply the elapsed time since the last communication.

I have few more ideas. It could display a detail button that would display rich data like:

  • List of last communication
  • Details of the hardware
  • Details of the comm settings
  • GPS reliability
  • Estimated remaining time for the battery

You can list your suggestion, I could miss an important one

9 Likes

Wow awesome stuff. This will be pretty handy! Elapsed time since last contact sounds like the more useful metric to me but if you can display both nicely then you might as well (or put the actual time in the detail screen).

Information around the last known received signal strength with an average of the last x messages would be handy. Maybe if you clicked on their distance indicator (or similar) it jumped to the map screen and highlights your node and their node.

I’m sure more things will come in time but this would be some great functionality you are working on.

Can we change those nodes into plain English (language of your choice) names and place them on the map if we know them… (Not asking much I know)

Personally I think time elapsed would be great.

Also just to clarify is this time since a text communication or signal? I think it would be really great to have time since each nodes signal was last seen on the mesh. This is shown on the device display currently. I find my self looking at the device display more then the app because of the lack of this info. I think this is similar to what @dafeman was saying.

Thanks for all the work!

OMG that looks awesome (and thank you for your recent Android app contributions)!

2 Likes

You mean you want something to be displayed other than Unknown 4d0c ?

1 Like

good point - @GaryMortimer. Nodes will have human names if the name has been set in the Settings pane (for the phone connected to that node)

Sorry, not making myself clear. The Bluetooth name for an old duffer like me is unclear, like Unknown 4d0c

Each Node with a configurable name, like say The Garage (where I have one) will make it simple for me to instantly see which nodes (I might be using the wrong term) my currently connected device can see.

Similarly placing them on a map for the fixed, no GPS Heltecs I have will help me see coverage better.

The folks at Open Glider Network have a great coverage tool for their 868 Network

https://flarmrange.onglide.com/#,max,recent,-28.81152_25.88699,10,#80000040:#008000ff,circles;

Now I picked that part of South Africa because there are so very few receivers. Scroll up to Europe, the UK in particular and you will see the receivers are everywhere and coverage pretty amazing.

So much so that the Civil Aviation Authority acknowledge FLARM/OGN as a thing and ATC watch the tracks.

Humm, so what is the upshot of this long post.

Old blokes need to quickly understand how their local mesh is sited and working.

1 Like

You are right about the name. I’ve 3 devices Unknown:
Unknown 4ecc
Unknown 3f8c
Unknown 4d0c

Having one in the hand, I can’t tell you which one of those I am using. I am planning to focus my work on the usecase of having a phone and multiple devices. I want to simplify the setup of a network.

Oh I see. The Bluetooth name! Oh we pick that based on the macaddr.

One thing I’ve wanted to do for a while: whenever there is nothing connected to the device via Bluetooth have one of the screens say “my Bluetooth name is meshtastic 23ab”

@lgx yes exactly that, well put!

1 Like

I don’t know if there’s an easy way to do this. However, some state of the network would be useful.

Basic: nodes last seen time. As suggested.
Advanced: a of b packets sent. c packets acknowledged by at least one other node. d packets acknowledged by all nodes.

1 Like

For the messages, we could provide an ack for receipt and an ack for read
For positions, an ack for receipt. If we receive its positions, my guess is it is receiving our position.

An ack is another transmission, reducing the battery usage. We could create a network setting that propagate ack or not.

btw: we already provide an ack for receipt (that’s what makes the checkmark). An ack for read would be a fine add someday.

1 Like

@geeksville, In order to save some airtime, we might merge several read-ACK’s? A read-ACK packet, with several read-ACK’s, could be automatically sent after n number of ACK’s, or within a predefined timeframe? Those read-ACK’s could also be merged within other mesh packets sent between the nodes (this would also save some airtime)?

Been musing with the gang about what ‘ack’ means in a mesh network.

Are ‘single node ack’ and ‘all node ack’ distinguished in the spec today?