Why is sleepcycle uint8_t and not uint16_t ?

[JodliDev]

At the moment, Paxcounter is only able to go into deep sleep for 510 (255*2) seconds at the most.
I investigated a bit and realised that this does not seem to be a restriction in the code but because sleepcycle in global.h is using uint8_t as a type.

I changed it to uint16_t and it seems to work fine with bigger time windows on our board.

But now I am unsure on why this restriction was in place in the first place.

Is there an important reason why only uint8_t is used for sleepcycle? Can the additional memory requirement for uint16_t be a problem at some point?

I hope somebody can make that more clear to me.
Thanks! :)

[cyberman54]

Indeed in early versions there was a restriction in configmanager.cpp enforcing uint8_t values for storage of configurations in NVRAM. Meanwhile configmanager.cpp was reworked, now all configuration values are stored as a whole in a struct in NVRAM. So we can have uint_16t, or even uint64_t to get longer sleep times.

Can you create PR for this and test carefully?

Note: We will need adjustments in rcommand.cpp for set_sleepcycle(), too.

[JodliDev]

Ah thank you!

Sure. Ill have my board running with the new setup for a day or two and then send it over (I wont be able to test set_sleepcycle() though. But I added the changes and I think that should be fine).
Are you planning to incorporate my other RT for the e paper display? Because then I can be lazy and just leave the changes in my fork and dont have to "downgrade away" the e-paper changes in my current branch :D

[cyberman54]

Thanks for the Epaper integration! I will merge this to development branch, after i found some time to take a quick look at it, and carry out a test with my waveshare color esp32 epd. Will take a few days probably.

[JodliDev]

I realised that table in rcommand.cpp where set_sleepcycle() is defined, limits the function parameter to uint8_t as well. As far as I can see, that involves a lot of changes / possible side effects.
And since I cant really test lorawan updates I cant really help you with that.
If you want, I can send you a pull request just for SLEEPCYCLE in paxcounter.conf but I dont think that is really helpfull (and is only a single change) :/

On a more positive note: I have my ttgo5 running with a sleep cycle of 900 seconds (half an hour) for a couple days now and it works flawlessly :)

[cyberman54]

Rcommands can have multiple byte parameters:
// format: {opcode, function, number of function arguments}

Thus, we just need a simple MSB/LSB logic in set_sleepcycle() to evaluate e.g. two (uint16_t) or four (uint32_t) parameters.

(uint32_t) would limit possible sleep times to ~17years, while (uint16_t) would result to only ~18hours, if sleep times are processed with 1 second resolution. With 10 seconds resolution we could have ~7days sleep time with (uint16_t).

Currently, with (uint8_t) we achive up to 8 1/2 minutes sleep, with 2 seconds resolution.

My suggestion ist to have a 16bit sleep time counter, where 1 count is 10 seconds.

[cyberman54]

@JodliDev I implemented this today in development branch: 295494b
Could you, please, test? Thanks.

[JodliDev]

Sorry for my late response. I had a busy week in combination with easter :)

I cherry picked the commit and will incorporate it in our own project. But I wont be able to test rcommands since we are not using lorawan