Initial feedback after some testing

[Andrew-a-g]

I thought I would take some time to document some of my thoughts from testing this system with a neighbour (A) and myself (B). I like the concepts at play here and think this has some potential. The conditions under which I was testing were...

     (A's house)                              >>> <<<       (B's house)
CLI Client (heltec) > repeater (heltec)  >>> <<< Loft repeater (rak) < T-deck

I also did some tests with another cli client at B.

We could exchange messages fine over the public channel but I could never receive an advert on the t deck over the hops to test private messaging. I am sure this would have worked fine if he had a t deck.

• Messages were very fast.
• Signal strength was comparable to other LoRa solutions.
• The T deck UI is nice. (apart from the screen turning off every time you press the trackball in - I need to stop doing that)
• Once I got my head around the advert process, public channels etc it worked well.

My thoughts around areas that might need some focus. This also includes lots of questions as I am still learning my way around the meshcore framework.

1. Getting / Establishing Contacts

• Announcing. There is no way to force a full announce over the mesh. I do not want to turn off my device, turn it back on again, and then wait 5 minutes on a cloudy day for a time sync just to send an advert.
  • Allow this but enforce a max of x announces in a given time period (24 hours).
• Business cards - Clipboard is too clunky to import ATM.
  • It would be great to exchange contacts via room or request one over public somehow.
  • (I have not thought this one through properly—basically just make it easier while maintaining project privacy goals.)
• Direct contacts - I need to know if someone has tried to contact me and they are not on my home screen. There should be a notification somewhere indicating this. There is a risk that they will never receive my advert and contact request should be possible somehow. I see this being confusing when person A can receive person B but person B tx is not high enough back to A.
• Home screen - Adding nodes OK to receive messages from is going to get very cluttered with this approach. Perhaps a "Trusted" option should be used instead.
• Public channel client details should be added as default.
• Could a repeater queue the last X heard announcements in the day somehow and send them to your t deck if you request it?

2. Setup / Diagnosis

• Time sync - If repeaters can have Wi-Fi, I think it would be good to connect to Wi-Fi to sync time with NTP.
• Signal - No signal stats in the T-Deck UI (I can see them in the CLI client). We need some metrics!
  • Signal stats in the command line are just between the client and the repeater.
  • Need more data / repeater stats to set up meshcore networks.
    • Primary example would be a way to set up the best signal strength to other repeaters.
    • It would be nice to have a list of direct contacts (e.g., to other repeaters) and RSSI/SNR when logging onto your repeater.
    • It would be even better to have the ability to feed this data from the repeater into MQTT over Wi-Fi for reporting.
• We need a way to see if things are alive — a node ping might help to client or, more perhaps more importantly, a repeater.
  • (I know you will say no — busy mesh, yes I get it.)
  • We need a way to troubleshoot/build meshes. At the moment, we are flying blind and asking, Will it work?

3. Usability / T deck

• Long messages on the T-Deck screen scroll left to right.
  • This makes it very tiresome to read.
  • Could there be an option to wrap the message on a new lines or at least provide the option to do so.
• Every time I reboot a repeater, it adds a duplicate entry onto the discover screen.
  • This seems messy - Is it a bug? I think it should update the timestamp for the old entry.

4. Privacy

• How do the GPS positions get distributed around the mesh?
• Who can see them?
• What is the accuracy of such positions?

5. Roadmap / Vision

• When the website is up, a page is needed with the core principles of the project and its future direction.
• Most people will come from other solutions and will need to understand the core mechanisms at play here, especially in comparison to those other solutions.

[SubnetConflict]

Oh! And the ability to remove entries from the discovery list for know dead nodes or repeaters, I know there's a purge after X days but would be nice to be able to manually remove.

[ripplebiz]

OK, a lot to answer.

Every time I reboot a repeater, it adds a duplicate entry onto the discover screen.

This was a bug, fixed on the 4th feb I believe. Also, the RAK repeaters had another critical bug which caused all of them to generate the same keypair on first use. Also was fixed.

It would be great to exchange contacts via room

Yes, this would be a good way to obtain contacts. On the to-do

Direct contacts - I need to know if someone has tried to contact me and they are not on my home screen.

Yes, these attempts at messaging currently seem to go into a black hole, which is not good. I have some ideas how to improve this, so that recipient can better be notified.

Home screen - Adding nodes OK to receive messages from is going to get very cluttered with this approach. Perhaps a "Trusted" option should be used instead.

Being able to navigate into conversation screen from Discover > Details screen should be possible, but there is a technical issue with being able to quickly see the unread counter , say in the Discover list. Is just an internal data structure thing, but would currently be difficult to just see at a glance if that (non-Home/Fav) node has messaged you.

Public channel client details should be added as default.

Hmmm, I currently disagree with that being added by default.

Could a repeater queue the last X heard announcements in the day somehow and send them to your t deck if you request it?

That is possible, but would best be something where you have some established credentials with that repeater. I'll have a think, but I think the new "Share..." mechanism could help in this regard. ie. other nodes can forward you adverts you have missed. But, I understand that is still a manual thing... not something the mesh automatically does.

Need more data / repeater stats to set up meshcore networks

Yes, I see how the currently available stats on the T-Deck fall short here. Would one quick win be a display of the same debug/packet logging that the various firmwares do over serial, but displayed in the (as yet unimplemented) Diagnostics screen?

Time sync - If repeaters can have Wi-Fi, I think it would be good to connect to Wi-Fi to sync time with NTP.

Yes, the repeaters do really need an automatic way to sync their clock. Am a bt reluctant to go the WiFi route, 1) it adds a dependency to The Internet, which is antithetical to the project, 2) because some ESP32's don't like turning off the WiFI once initialised (other than a reboot), and it is very resource hungry (memory, etc)

Adding hardware RTC module support is prob better, like the DS3231, or similar, that just need to be wired to 3.3v and the I2C pins.

How do the GPS positions get distributed around the mesh? ...

The advert packets are, atm, the only mechanism that GPS location is shared. The lat/lon can optionally be included in the advert. These are typically just config atm, either at compile time with the ADVERT_LAT/_LON, or via the CLI "set lat ...". For T-Deck, your location is not encoded into your adverts, unless you switch to the "GPS location: BROADCAST" setting in home screen menu.
And, everyone can see adverts. The accuracy is whatever the GPS says, or whatever you entered for the config.

Proper telemetry is still to be carved out, so that location (and temperature, battery, or other sensor data) can be shared with more granular control (who receives, etc), and in as small a packet as possible.

[ripplebiz]

One more...

When the website is up, a page is needed with the core principles of the project and its future direction.

I don't have the energy or skills to really do this one properly, so am hoping Andy takes this aspect on, and creates something that serves this purpose. Although, I hope to do a few 'core principle'-like articles soon, at my own BuyMeACoffee site, that also give an indication to a general road map.

I want these to be quite clear, that MeshCore has some very specific design principles, and hoped-for outcomes, but I still, as yet, cannot really claim that it's doing everything it's intended to do. A lot of the assumptions are being tested right now, and a lot of findings still emerging.

[andymux]

Yep website is currently under design 👍🏻
Andy

[ripplebiz]

OK, one issue about Discovery is hopefully improved. Repeater and Room server now have this CLI command:

set advert.interval {minutes}
Sets the timer interval in minutes to send a local (zero-hop) advertisement packet. Set to 0 to disable.