Why is power.sds_secs default value 1 year?

I’m not getting the reason behind such a peculiar default value… anyone?


1 Like

Me neither and I changed it to something smaller like 3600. This means that when low on battery at least TBeam goes into SDS and will wake-up after 3600 seconds to check the situation.

1 Like

It should not be less than a day, if you went into super deep sleep the battery died completely.

1 Like

My experience is that during SDS the power consumption is extremely low and the battery survives many days. I test this now continuosly. Besides TBeam goes to SDS around 3260 mV and there is plenty a headroom according to datasheet from Samsung

1 Like

The battery is assumed to be dead, it does not wake up and do anything.

Yes, a day would actually be a much more sensible default.

True, but what if the battery is solar-charged? Eventually the Sun will shine on the PV panel and the node could resume operations. That’s a pretty common issue for remote, fixed nodes.

1 Like

I think the assumption that the battery is dead is at least with TBeam wrong as SDS is called when battery still has 10% left and even this is calculated very conservative. As @IZ1IVA notes: there might be external powersupply like solar panel to charge the battery and then we should wake up every now in order to see if it is possible to continue. In my case I have set it to 1h , however one day could be reasonable as well depending on how often this node is supposed to be active. I normally got batteries deep-discharged when the node went into boot-loop.

1 Like

This is the only sds use case and doing solar with a esp32 and a tbeam specifically is not a great choice when nrf uses 1/10th the power

We all know that, but ESP32 is legacy and most of Meshtastic nodes are still on that hardware, so why having a SDS default of 1 year? It’s fine to preserve the battery, but perhaps that’s not the ultimate goal of a node.

well, at least we know now why it is that way. Luckily it is still possible to change its value an I hope it does not get the same treatment as light-sleep.

Why make it easier to do something that is not recommended? The tbeam is not going to wake back up anyways.

Well, it does. Once we had a bug that the GPS was no longer switched, but that is fixed

1 Like

DEBUG | ??:??:?? 2 [Power] Battery: usbPower=0, isCharging=0, batMv=3247, batPct=4
DEBUG | ??:??:?? 2 [Power] Threads running: SerialConsole Blink Router Power Button Screen GPS NodeInfoModule PositionModule RemoteHardwareModule DeviceTelemetryModule EnvironmentTelemetryModule SerialModule RangeTestModule RadioIf AirTime PowerFSM
DEBUG | ??:??:?? 2 [Power] Heap status: 132692/183420 bytes free (-18528), running 17/25 threads
INFO | ??:??:?? 2 [Power] Enter state: SDS
INFO | ??:??:?? 2 [Power] Entering deep sleep for 0 seconds
INFO | ??:??:?? 2 [Power] GPS prepare sleep!
INFO | ??:??:?? 2 [Power] GPS deep sleep!
INFO | ??:??:?? 2 [Power] Saving /prefs/db.proto
INFO | ??:??:?? 3 [Power] Saving /prefs/config.proto
INFO | ??:??:?? 3 [Power] Saving /prefs/module.proto
INFO | ??:??:?? 4 [Power] Saving /prefs/channels.proto
INFO | ??:??:?? 4 [Power] Setting GPS power=0
ets Jul 29 2019 12:21:46

configsip: 0, SPIWP:0xee
mode:DIO, clock div:2
entry 0x400805e4
E (70) esp_core_dump_flash: No core dump p����ѥ���found!
E (70) esp_core_dump_flash: No core dump partition found!
[ 12][D][esp32-hal-cpu.c:244] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, APB: 80000000 Hz
[ 463][I][esp32-hal-psram.c:96] psramInit(): PSRAM enabled
��@INFO | ??:??:?? 0

//\ E S H T /\ S T / C

INFO | ??:??:?? 0 Booted, wake cause 4 (boot count 3), reset_reason=timeout
DEBUG | ??:??:?? 0 Filesystem files (593920/1048576 Bytes):
DEBUG | ??:??:?? 0 /prefs/channels.proto (53 Bytes)
DEBUG | ??:??:?? 0 /prefs/config.proto (88 Bytes)
DEBUG | ??:??:?? 0 /prefs/db.proto (744 Bytes)
DEBUG | ??:??:?? 0 /prefs/module.proto (68 Bytes)
DEBUG | ??:??:?? 0 /static/.gitkeep (0 Bytes)
DEBUG | ??:??:?? 0 /static/Logo_Black.svg.gz (592 Bytes)
DEBUG | ??:??:?? 0 /static/Logo_White.svg.gz (600 Bytes)
DEBUG | ??:??:?? 0 /static/apple-touch-icon.png.gz (4300 Bytes)
DEBUG | ??:??:?? 0 /static/favicon.ico.gz (2221 Bytes)
DEBUG | ??:??:?? 0 /static/icon.svg.gz (842 Bytes)
DEBUG | ??:??:?? 0 /static/index-3ad6b632.css.gz (14921 Bytes)
DEBUG | ??:??:?? 0 /static/index-7d0857aa.js.gz (347 Bytes)
DEBUG | ??:??:?? 0 /static/index-84fcdb37.js.gz (507158 Bytes)

Not sure what your issue is, you can do the unrecommended thing all you want by changing the setting and most people will avoid ESP32 and especially the tbeam for solar, which is the right and least expensive choice.

My issue was that you stated that TBeam would not wake-up and it works all the time.

1 Like

Fine, then let’s phase out support for ESP32, since there’s a better alternative.
This attitude is more akin to governement policies rather than an open-source hobby project.

1 Like

This is quite a childish response. “I don’t like that you won’t do what I want, so let’s just get rid of it!” You aren’t being told it can’t be done, or won’t be done but that it’s not recommended. The recommended values are set to be the best fit for the most users possible to keep it as stable as possible for the vast majority of users, but of course there’s always going to be exceptions and it might not fit for everyone’s use case. I don’t see why the big fuss when you can configure this setting as you see fit. Additionally, as you mentioned, the project is open-source so if you have such a big issue with having to change the setting manually, you can always fork the project and change to where you don’t have to.

I accept that, but please do note that every single time upstream choices are questioned (even by providing context and real-world examples), replies are condescending at best. Plus, real knowledge is locked up in a Discord vault.

So, yeah.

Nothing is locked up in Discord or elsewhere, it’s all open. If you’ve made the choice not to join, that’s on you.

site:discord.com meshtastic power.sds_secs

And what about the condescending part?