Need your help -- Settings (Part 1) - Reviewing Defaults

1

Hey there!

This is Part 1 of a two part initiative to simplify settings.

Meshtastic 1.3 is getting close to be demonstrable for a public preview with a lot of the core plumbing in already done. It’s beautiful!

We are now examining all the settings and scrutinizing the defaults for those settings. We want the defaults to make sense for most people.

Question for you – What settings do you always change when you setup a new device? Why do you change them? What do you set them to?

We’ll review all feedback and adjust our defaults for how we actually use the nodes.

3 Likes
2

Very very exciting! I hope to try the alpha this weekend.

Apart from setting the names of course, here are some of my common changes:

  • ensure charge current is maxed out (dangerous, only change if you are not too worried about frying your usb controller)

  • set position update interval to 5 minutes

  • set position update to include battery level

  • accept 2d gps fixes

  • screen on secs to something more than 300

  • I usually go with medium slow channel setting as I am testing the store and forward plugin; my main worry with long slow channel as a default for casual users is that they will inherently be expecting real-time messaging, which can be tough with long slow. (To this accord, I’ve been brainstorming better ways to notify users of how long messages take to send and maybe more prominently displaying channel utilization). Maybe passing some more feedback like a browser does so users can conceptualize how long a message really takes to send/receive in the slower modes.

Most of these changes are to improve my experience in testing and evaluating my network. In the grand perspective most of the 1.2 defaults are well chosen for standard clients.

Love to see what others like to change.

1 Like
3

The charge current we really shouldn’t touch. Drawing more than 500ma violates the USB specification. If you (or someone else) changes it, then you take the risk but from the perspective of this project – we need to be good stewards and consciously do our best to protect people’s hardware.

All others you suggested are good candidates.

1 Like
4

It’s all very pre-alpha right now. Expect things to be broken and the clients are now catching up. The python api doesn’t yet work right either.

1 Like
5

I probably should have specified that! I am perfectly comfortable drawing over spec, the default absolutely should remain. I haven’t fried any usb controllers yet!!

I was just being honest what I change :stuck_out_tongue:

1 Like
6

I’ve been waiting to try something broken for a while and the allure is just too great now!
Any suggestions for areas that need more testing? I just got another half dozen tbeams and I am excited to test the flood routing modality.

1 Like
7

We’ll be sharing a pre-alpha that’s can be consumed by a non-developer soon. We’re in the final stretches. Hang tight :slight_smile:

1 Like
8

I always change the following setting for a stationary node that should act as a gateway to a MQTT server:

meshtastic --set-owner XXX
meshtastic --set region EU865
meshtastic --set is_always_powered true
meshtastic --set wifi_ssid XXX
meshtastic --set wifi_password XXX
meshtastic --ch-index 0 --ch-set downlink_enabled true
meshtastic --ch-index 0 --ch-set uplink_enabled true
9

Is this to keep the screen on or is the device a Heltec or Lora32?

meshtastic --set is_always_powered true

10

The new default is have smart position turned on by default, setting the interval is no longer important.

This behavior is changing as it’s going to be handled by the telemetry plugin.

This setting actually didn’t do anything. I’m taking it out.

Changed to 600 seconds

1 Like
11

I can’t really remember anymore and probably I never fully understood the implications of the power settings. I think it would be best to just ask the user for some simple device properties/preferences and derive the power behaviour / routing behaviour with a heuristic based on those settings and battery level measurements from there:

setting values default description
power_mode 'mains', 'battery', 'battery with charging' battery The device can be connected to mains or to a battery, which might be charged e.g. through mains or some kind of renewable energy source. When connected to mains it is safe to assume that no power saving is needed.
display_mode 'always on', 'on demand', 'on event' 'always off' on demand The display can be turned on or off all the time or activated on demand (e.g. with the press of a button or through a sensor) or based on events (e.g. a new message is received). Display on times might be automatically adjusted based on low battery levels.
device_mode 'client', 'router', 'router with network connection' client The device can act as a client that can go to sleep, act as a router which should only go to sleep in case of a low battery or the device can act as a router with a network connection (e.g. internet gateway or to provide the web interface), which should never go to sleep. The sleep behaviour can be automatically adjusted based on power_mode and low battery levels.

I think with those settings all the roles proposed in Need your help -- Settings (Part 2) - Roles will also be covered.

12

No clients are using the phoneTimeoutSecs and I could not find it referred to in the device code anywhere, so we should just delete it.

1 Like
13

This has been removed. It also appears the GPS format enum values are not working, is anyone using these successfully?

1 Like
14

I just tested and these all work perfectly!

1 Like
15

a part of the GPS tweak settings were only for the UBX mode. We yanked that, so a dumb search for the defines will tell you if it is still doing anything in the firmware code.

1 Like
16

I will test that they still work with 1.3 now that I can save them