If anyone wants to make a userguide (or two)

A recent question that revealed I hadn’t documented that the middle tbeam button is the only button that matters gave me an idea.

We should have two short userguides written.

meshtastic-device/userguide.md
and
meshtastic-android/userguide.md

They could be really basic: just a list of screens and what they are for and how to use the device/app. Over time we could add screenshots etc…

If anyone wants to contribute and thinks they can make a start at either of these guides a pull request on github to add these would be great. If you don’t know how to write markdown or do a github pull request, there are some great one-page tutorials on google. Or ask here and I’m sure someone will help.

Or if you want - just add these items as pages on the “Wiki” link on the right side of the github pages (then you wouldn’t need to learn how to do a pull request)

2 Likes

Hi, I have made a start on a user guide for the Android app.
The wiki seemed to the easiest way to get this started, and allows some images to be added.
https://github.com/meshtastic/Meshtastic-Android/wiki/User-Guide-for-Meshtastic-Android-App

I have more to add, and will do that over the next few days. Comments and corrections are welcome.

Also any good screen-shots showing a real network on the map would be great, as I only have one node currently.

Andy

6 Likes

Hi all,

I have mostly completed the Android App user guide, but there a few points that I’d like clarification on so I can complete it. Can any of the Android devs please assist? @geeksville

  • Message screen: exact meaning of the 3 cloud icons that show message status.
  • Behaviour of messages when node is not connected to other nodes, not connected to device (stored and forwarded later, lost, etc)
  • Channel options - range, speed - some more specifics in terms of Tx power, bandwidth, polling frequency, etc for each setting.
  • Settings: what does “tbeam unset/unset” mean to the user?

Just give me some notes, or point to the relevant place in the code.
Thanks for any input, Andy

1 Like

Message Screen:

  • cloud only: message has been sent bia bluetoth and sent per LoRa into the Air
  • coud with a check mark: message has been delivered to one (or all???) node in the mesh and one (or all???) node sent back a confirmation which was also successfully received by the initial sender.
  • cloud crossed out: message has maybe been delivered to one (or all???) node in the mesh. If one (or all???) node received the message and sent a confirmation back the initial sender did not received this confirmation within a certain timeout.

Settings:
tbeam unset/unset means

  • tbeam: device type the flashed firmware was built for
  • unset/ : hardware version was not properly set while building (via environment variable or #define)
  • unset: firmware region was not properly set while building (via environment variable or #define)

see here for details

2 Likes

@qurm That is really cool! I’ll add a help button in the app that links to it (initially via http, but once it has settled down a bit we can include the HTML in the app so it works without internet)

Sorry for the late reply - I’m living out of a suitcase at the moment :wink:

1 Like

Thanks @drewsed. Added to the guide as:
@geeksville No problem on the reply! And note that the images are still in my repo, so at so at some stage we can work out where the guide should best reside, and will issue a pull request.

The new router feature raises a question about confirmations - does a route count as a confirmation, or should it come from a user node?

Send a message

ToDo - confirm meaning of symbols; store & forward; time-out durations; does a router confirmation mean a tick?

The message window operates like any chat applications. Note that any messages sent go to the whole group, and there is no one-to-one message feature.

With LoRa (or any radio) there is some uncertainty that the messages has been received, so there is a confirmation built-in to the protocol. There are small cloud icons shown to the right of the messages you send:

  • Cloud only: message has been sent via Bluetooth and transmitted via LoRa.
  • Cloud with a check mark: message has been delivered to at least one node in the mesh and at least one node sent back a confirmation (successfully received by the initial sender).
  • Cloud crossed out: message may have been delivered to at least one node in the mesh. If at least one node sent a confirmation back the initial sender did not receive the confirmation within a certain timeout.

Thus, in a group size of 3 and up, confirmations could be from any one device (not person), so it is good practice to respond, so the initial sender knows you have read their message.

There is no long-term store-and-forward of messages, so messages not received within a time-out (duration?) are lost.

1 Like